SaaSモノリスからモジュラーアーキテクチャへ：まず再構成し、テストが必要性を示したときだけ分割する

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

このガイドの内容

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

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

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

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

別の問題に対して再構成しないでください。ページが遅いのはインデックスが不足していることが多く、不安定なリリースはテストが不足していることが多く、費用が高いのはコスト配分が不足していることが多く、これについてはクラウドコストコントロールガイドで扱っています。システムが古い、サポートされていない、または全体として不透明な場合は、まずレガシーシステム評価チェックリストを実行してください。

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

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

モジュールを単なるフォルダではなく本物にするもの：

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

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

ルートの選択

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

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

つなぎ目とは、コードの一部を変更を最小限にして他の部分から切り離せる箇所です。アーキテクチャ図からではなく、証拠から見つけてください。

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

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

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

マルチテナンシーは、再構成が静かに失敗する箇所です。3つのルールが助けになります。

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

データ移行には、移行中の読み取りと書き込みの計画が必要です。デュアルライト、変更キャプチャ、または短い停止のいずれかで、それぞれ後に照合チェックが伴います。

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

Netbase JSCはマルチテナントSaaSプロダクトを構築・運営しており、これがこのガイドが書かれた背景です。

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

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

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

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

4つの基準が決定します。テストと監視が存在するか、古いコードを理解している人数、移行中に続けなければならないロードマップ作業の量、そして誰がその後アーキテクチャを所有しなければならないかです。Netbase JSCはテナンシー、請求、セキュリティ、コストのアーキテクチャレビューから始め、スライスを計画します。Netbase JSCのカスタム開発では、クライアントがそのために作成されたIPを所有し、ほとんどのプロジェクトはディスカバリー後に合意された請負契約で進められます。このオファーはSaaS開発とクラウドプラットフォームエンジニアリングにあります。

このガイドの限界

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

次のステップ

現在のプロダクトのデプロイ方法、何チームが変更しているか、どの部分が最も問題かをお聞かせください。ソリューションレビューを予約して、つなぎ目をマッピングし最初のモジュールを提案します。また、Netbase JSCのインサイトをもっと読むこともできます。

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