SaaSモノリスからモジュラーアーキテクチャへ：まずリファクタリング、分割はテストが示すときだけ

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

このガイドの内容

• モノリスが本当に問題なのか？
• 目標：サービス分割前のモジュラーモノリス
• ルートの選択
• 継ぎ目を見つけ、境界を引く
• ステップバイステップ：モジュール化のパス
• 移行中のテナント、課金、データ
• モダナイゼーションにおけるAI
• 存在する納品実績と存在しないもの
• 代替案：誰が作業をリードするか
• このガイドの限界
• よくある質問
• 次のステップ

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

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

• 変更が衝突する。 複数のチームが同じファイルを編集し、リリースが互いを待ち、小さな修正でもフルリグレッションが必要になる。
• 1つの障害がすべてを停止させる。 重い帳票やインポート処理がすべてのテナントのサインインと課金を遅らせる。
• 誰も一部を説明できない。 コードが他のコードのデータに手を伸ばしているため、ある部分の変更が別の部分を壊す。
• 1つのワークロードが異なる扱いを必要とする。 検索、メディア処理、AI機能が他の部分と異なるハードウェア、スケーリング、またはリリースルールを必要とする。

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

目標：サービス分割前のモジュラーモノリス

モジュラーモノリスは依然として1つのデプロイ可能なアプリケーションですが、コードは明確なパブリックインターフェースと独自のデータを持つモジュールに分割されています。Shopifyのエンジニアリングチームは、大規模なRailsアプリケーションへのこのアプローチを説明しています：定義された境界を持つコンポーネントにより、開発者は自分たちに関連する部分で作業でき、テストはシステム全体ではなく1つのコンポーネントに対して実行できます。同じ記事では、チームが改めて始めるなら異なる方法を取るだろうという教訓も挙げており、イテレーションを計画することが重要です。

モジュールを単なるフォルダでなく本物にする要素：

1. パブリックインターフェース。 他のモジュールは関数を呼び出すかイベントを送信します。内部に直接アクセスすることはありません。
2. データの所有権。 各モジュールは自身のテーブルを所有します。他のモジュールは直接読み込んだり結合したりしません。
3. オーナー。 1つのチームがモジュールの動作とテストに責任を持ちます。
4. 強制されたルール。 モジュールが他のモジュールの内部をインポートするとビルドチェックが失敗します。

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

ルートの選択

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

継ぎ目を見つけ、境界を引く

継ぎ目とは、コードの一部をわずかな変更で残りから分離できる箇所です。アーキテクチャ図からではなく、証拠から見つけます：

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

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

移行中のテナント、課金、データ

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

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

データ移動には、移行中の読み書きの計画が必要です：デュアルライト、変更キャプチャ、または短い凍結、それぞれの後に照合チェックが必要です。

存在する納品実績と存在しないもの

Netbase JSCはマルチテナントSaaSプロダクトを構築・運営しており、このガイドはそのコンテキストで書かれています：

• Cloodo Workspace。 CRM、HRM、クラウドERP、AIモジュールを1つのプロダクトに含む業務管理デジタルワークプレース。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開発とクラウドプラットフォームエンジニアリングにあります。

このガイドの限界

• すべてのコードベースは異なります；最初の依存関係マップが計画を変えることがよくあります。
• フレームワークと言語によって境界を強制するツールは異なります；お使いのものが何をサポートしているか確認してください。
• 情報源は記録されている内容について引用されています；スピード、コスト、信頼性の数値は主張していません。

よくある質問

マイクロサービスに移行すべきですか？ 通常、最初のステップとしてはお勧めしません。1つのアプリケーション内でモジュールにリファクタリングし、独自のスケーリング、リリースペース、または分離の測定されたニーズを持つモジュールに対してのみサービスを切り出します。

どのくらいかかりますか？ コードのサイズ、テストカバレッジ、データの絡み合い具合によって異なります。Netbase JSCはアーキテクチャレビューと最初の依存関係マップの後に見積もりを出し、典型的な期間は公開していません。

その間も機能のリリースを続けられますか？ はい、作業がスライスでリリースされ、ビルドが新しい境界を出現時に強制する場合は可能です。両方のキャパシティを計画してください。

モノリスがレガシーシステムの場合はどうですか？ まず評価してください。プラットフォームがサポートされていないか、ルールが不明な場合、リプラットフォーミングまたはディスカバリーがモジュール化の前に来る場合があります。

次のステップ

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

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