SaaS顧客コミュニティプラットフォーム：コストを75～80%削減し、セットアップ時間を2週間から6時間へ短縮。既存の優れた特性を損なうことなく、拡張性を高めるためモジュール型プラットフォームを再構築しました。

課題

同社のプラットフォームは、初期の顧客基盤には十分に機能していたレガシーコードベース上に構築されていました。製品を商業的に特徴づけていたモジュール性は、同時にアーキテクチャを複雑にしていました。各クライアントへの導入は独自の構成であったため、単一の変更を一般的なベースラインに対してテストすることは不可能でした。 そして2020年。パンデミックにより、数年分のデジタル化が数ヶ月で進みました。プラットフォームは、設計時には想定されていなかった需要の急増に直面しました。同時接続ユーザーの増加、並行データストリームの増加、そして同時に稼働するアクティブな統合の増加です。レガシーアーキテクチャは負荷に耐えきれなくなり、パフォーマンスの低下、データボトルネックの発生、稼働時間の信頼性リスクの増大が見られるようになりました。 この問題は、クライアントのビジネスの性質によってさらに複雑化しました。レガシーシステムを全面的に置き換える従来の再構築では、クライアント契約の基盤となっていたモジュール型構成レイヤーが破壊されてしまいます。そのため、あらゆる最適化は既存アーキテクチャのロジックを尊重しつつ、その性能特性を大幅に向上させる必要がありました。 グラディオンに問われたのは、運用上のプレッシャーがある中で、複雑でクライアント固有のレガシーシステムを、その製品価値を損なうことなくどのようにモダナイズするか、という問いでした。

アプローチ

Gradionのアプローチは、全面的な置き換えではなく、意図的な精密化でした。チームはまず、レガシーコードベースの綿密な監査から着手し、パフォーマンスボトルネックを特定し、モジュール間の依存関係を把握し、連鎖的なリスクを招くことなく最大の効果が得られる介入ポイントを特定しました。 まず、フロントエンドのツールチェーンを刷新しました。BowerをWebpackとnpmに置き換えたのは、単なる流行の追従ではありません。継続的な進化が求められるプラットフォームにおいて、従来のビルドツールがデプロイ速度と信頼性に対する具体的な制約となっていたためです。 レガシーコードのリファクタリングは、モジュール性を維持するという明確な制約の下で行われました。目標は、抜本的なアーキテクチャの再構築ではなく、的を絞った最適化でした。クライアントのデプロイが依存する設定ロジックを変更することなく、パフォーマンスボトルネックを解消し、ビルドパイプラインを強化し、スケーラビリティの余地を改善することです。 DevOpsの強化により、負荷時に顕在化していた安定性のリスクに対処しました。Jenkinsには基本認証が追加されました。リアルタイム監視を構成し、エンドユーザーやクライアントに影響が及ぶ前にプラットフォームの劣化を検知できるようにしました。これは、システムが自らを監視し、エンジニアリングチームの運用負担を軽減することで、企業が製品開発に注力できる基盤を構築することを意図したものです。 チーム体制は、効率性という目標を反映していました。初期のエンゲージメントは、5名の専門家（プロジェクトマネージャー、シニア開発者、DevOpsエンジニアを含む）で構成されました。ツールが成熟し、プラットフォームが安定するにつれて、運用責任は単一の多機能なGradionエンジニアに集約され、現在も継続的にプラットフォームを維持しています。