SaaSモノリスのモジュラーアーキテクチャ移行：先にリファクタリング、分割は必要性が確認されたときだけ

このガイドは、変更のたびにシステム全体に影響が及ぶためにプロダクトのリリースが遅いSaaSファウンダー、CTO、エンジニアリングリードを対象としています。稼働中のプロダクトと有料テナントが存在することを前提としています。最初のバージョンの構築についてはSaaS MVPアーキテクチャロードマップを、全体像についてはSaaSプラットフォームエンジニアリングガイドを、リビルド・リファクタリング・リプラットフォームの一般的な選択についてはデジタルトランスフォーメーションとモダナイゼーションガイドをご参照ください。

このガイドの内容

• モノリスは本当に問題なのか？
• 目標：サービス化の前にモジュラーモノリスへ
• 移行ルートの選択
• 境界線（シーム）を見つけてから境界を引く
• ステップバイステップ：モジュール化のパス
• 移行中のテナント、請求、データ
• モダナイゼーションにおけるAI
• どのような納品実績があり、何がないか？
• 代替案：誰が作業をリードするか
• このガイドの限界は何ですか？
• よくある質問
• 次のステップ

モノリスは本当に問題なのか？

モノリスとは、一つのアプリケーションを一つのユニットとしてデプロイするものです。これ自体は欠陥ではありません。Martin Fowlerの「モノリスファースト」の考え方では、成功したマイクロサービスのほぼすべてが大きくなりすぎたモノリスから始まっており、ドメインを把握する前に安定したサービス境界を引くことは難しいと述べています。構造を変える前に、次のサインを確認してください。

• 変更が衝突する。複数のチームが同じファイルを編集し、リリースは互いを待ち、小さな修正にも全体の回帰テストが必要になる。
• 一つの障害がすべてを止める。重いレポートやインポートが、すべてのテナントのサインインや請求処理を遅延させる。
• 誰もある部分を説明できない。コードが別のコードのデータに直接アクセスしているため、一箇所の変更が別の箇所を壊す。
• 特定のワークロードが異なる扱いを必要とする。検索、メディア処理、AI機能が、他の部分とは異なるハードウェア、スケーリング、またはリリースルールを必要とする。

別の問題に対してリファクタリングしないでください。ページが遅い場合はインデックスが不足していることが多く、リリースが不安定な場合はテストが不足していることが多く、コストが高い場合はコスト帰属が不明確なことが多いです。これについてはクラウドコスト管理ガイドで解説しています。システム全体が古くなっている、サポートが切れている、または不透明な場合は、まずレガシーシステム評価チェックリストを実行してください。

目標：サービス化の前にモジュラーモノリスへ

モジュラーモノリスは依然として一つのデプロイ可能なアプリケーションですが、コードは明確なパブリックインターフェースと専用データを持つモジュールに分割されています。Shopifyのエンジニアリングチームは大規模なRailsアプリケーションへのこのアプローチについて説明しています。定義された境界を持つコンポーネントにより、開発者は関連する部分だけで作業でき、テストはシステム全体ではなく一つのコンポーネントに対して実行できます。同記事では、もし最初からやり直すとすれば異なる方法で適用する教訓も列挙されているため、反復を前提に計画してください。

モジュールが単なるフォルダではなく、本物であるための要件：

1. パブリックインターフェース。他のモジュールは関数を呼び出すかイベントを送信する。内部実装に直接アクセスしない。
2. データのオーナーシップ。各モジュールは自身のテーブルを所有する。他のモジュールはそれらを直接読み取ったりJOINしたりしない。
3. オーナー。一つのチームがモジュールの動作とテストに責任を持つ。
4. 強制されたルール。モジュールが別のモジュールの内部をインポートした場合、ビルドチェックが失敗する。

SaaSプロダクトの典型的なモジュールは、アイデンティティとアクセス、テナントとエンタイトルメント、請求とサブスクリプション、コアプロダクトドメイン、通知、レポートです。テナントコンテキストはすべてのモジュールを通過します。その判断が依拠する分離の選択については、マルチテナントアーキテクチャガイドで説明しています。

移行ルートの選択

ほとんどのプロダクトはモジュラーなコアと、ゼロから数個の切り出されたサービスという構成になります。チームは完全なマイクロサービス構成を、出発点としてではなく、到達すべき目的地として扱うべきです。

境界線（シーム）を見つけてから境界を引く

シームとは、コードの一部を少ない変更で残りから切り離せる箇所です。アーキテクチャ図からではなく、証拠から見つけてください。

• 依存関係マップ。実際のインポートグラフを生成します。インバウンド呼び出しが多くアウトバウンドが少ないモジュールが最初の候補として適切です；絡み合ったコアは最後に残します。
• データのオーナーシップ。各テーブルについて、どのコードが読み書きするかをリストアップします。多くの領域が書き込むテーブルは、まだ存在しない境界を示しています。
• 変更履歴。一緒に変更されるファイルは通常同じモジュールに属します。独立して変更されるファイルは境界を示唆します。
• ビジネス用語。「アカウント」が請求とサインインで異なる意味を持つなど、場所によって異なる意味を持つ名称はドメイン間の境界を示します。

最初のモジュールはリスクが低く学習効果の高いものを選びます：明確な機能、小さなインターフェース、共有データが少ないもの。通知やレポートが適していることが多いです。請求とアイデンティティは手法が実証されるまで残し、エラーがすべてのテナントに影響するため特別な注意を払って扱ってください。

移行中のテナント、請求、データ

マルチテナンシーは、リファクタリングが静かに失敗する場所です。3つのルールが役立ちます。

• テナントコンテキストはオプションではない。すべてのモジュールとすべての新しいサービスは、テナント識別子を受け取り強制する必要があります。理想的には手動で繰り返すのではなく、共有コードで実装します。
• テナントをコホートで移行する。社内の友好的なテナントから始め、エラーとパフォーマンスを監視してから拡大します。10の小さなテナントで機能する移行が、数年分のデータを持つ一つの大規模テナントでは機能しない場合があります。
• 請求とエンタイトルメントを契約として扱う。コードが変わる間も、顧客向けの使用イベントとプランの制限は同一でなければなりません。切り替える前に、旧パスと新パスの請求書とエンタイトルメントの結果を比較してください。

データ移動には移行中の読み取りと書き込みの計画が必要です：デュアルライト、変更キャプチャ、または短時間のフリーズ。いずれも、その後の調整チェックが必要です。

どのような納品実績があり、何がないか？

Netbase JSCはこのガイドが書かれた設定であるマルチテナントSaaSプロダクトを構築・運用しています。

• Cloodo Workspace。CRM、HRM、クラウドERP、AIモジュールを一つのプロダクトに統合したワークマネジメントのデジタルワークプレイス。Netbase JSCのビジネス部門として構築・運用されています（Cloodoの記録）。
• 米国クライアント向けクラウドERP（非公開）。Netbase JSCが2020年からオフショア開発およびマネージングパートナーとして開発しているマルチテナントのクラウドERPです（クラウドERPの記録）。
• Printcart。Netbase JSCビジネス部門のWeb to Print SaaSです（Printcartの記録）。
• Netztech。Magento 1からMagento 2 Commerceへ35営業日で移行したストアです（Netztechの記録）。これはプラットフォーム移行であり、モノリスの分解ではありません。

Netbase JSCのデリバリーライフサイクルにはモジュラーでプロダクト化されたコンポーネントが含まれており、SaaSプロダクトアクセラレーターは再利用可能なモジュールから構築されています。

存在しないもの。稼働中のSaaSモノリスをモジュールまたはサービスに分解したNetbase JSCの公開実績はなく、そのような作業の期間、デプロイ頻度、コスト、パフォーマンス結果を公開しているものもありません。上記の手法は引用されたソースと一般的なエンジニアリングの実践から来ており、Netbase JSCの測定された成果からではありません。

代替案：誰が作業をリードするか

4つの基準が判断を左右します：テストとモニタリングが存在するか、旧コードを理解している人が何人いるか、移行中にどれだけのロードマップ作業を継続しなければならないか、そして誰が移行後にアーキテクチャを所有しなければならないか。Netbase JSCはテナンシー、請求、セキュリティ、コストのアーキテクチャレビューから始め、スライスを計画します。Netbase JSCのカスタム開発では、クライアントがそのために作成されたIPを所有し、ほとんどのプロジェクトはディスカバリー後に合意された請負契約で実行されます。提供内容はSaaS開発とクラウドプラットフォームエンジニアリングにあります。スコープ付きエージェンシーと専任チームの広義の選択については、専任SaaSチームとプロダクト開発エージェンシーを参照してください。

このガイドの限界は何ですか？

• コードベースはそれぞれ異なります。最初の依存関係マップが計画を変えることが多いです。
• フレームワークと言語によって境界を強制するためのツールが異なります。ご使用のものが何をサポートしているか確認してください。
• ソースはドキュメント化している内容について引用されています。速度、コスト、信頼性の数値は主張していません。

次のステップ

現在のプロダクトのデプロイ方法、変更を加えるチームの数、最も問題のある部分をお知らせいただければ、シームをマッピングして最初のモジュールを提案するソリューションレビューを予約します。Netbase JSCのインサイトもあわせてご覧ください。

関連サービスとソリューション