マルチテナントSaaSアーキテクチャ：分離・課金・AI機能とスケーリングの選択

この技術記事は、SaaS製品を設計している、または初期設計を見直す必要が生じているCTO・アーキテクト・シニアエンジニアを対象としています。SaaSプラットフォームエンジニアリングガイドでは、サイロ・プール・ブリッジのテナンシーモデルとコントロールプレーンを紹介しています。本記事はその一段階深い内容として、各レイヤーでの分離の実施方法、データのパーティショニング、課金の構成、AIフィーチャーのテナント境界内への制限、プラットフォームのスケーリングについて説明します。マーケットプレイスについてはマーケットプレイスプラットフォームアーキテクチャで扱っています。

コンテキスト：テナント・ユーザー・デプロイメント

まずテナントの定義を明確にします。BtoB SaaSでは、テナントは通常、多数のユーザーを持つ顧客組織を指します。複数のテナントが必要な顧客もいます（例：独立した子会社や、テスト環境と本番環境の分離など）。BtoC製品では、テナントは個人・家族・グループになることもあります。MicrosoftのAzure Architecture Centerは、このテナントの定義とテナンシーモデルが顧客に受け入れられるかどうかは、技術的な決定であると同時にビジネス上の決定でもあると指摘しています。

論理的なテナントと、それにサービスを提供するデプロイメントは分けて考えます。デプロイメント（スタンプとも呼ばれます）は、1セットのインフラストラクチャです。複数のテナントが1つのデプロイメントを共有することも、1つのテナントが専用のデプロイメントを持つこともできます。最初からテナントとデプロイメントのマップを保持しておくことで、アプリケーションを書き直すことなく後でテナントをデプロイメント間で移動できます。

分離はレイヤーごとに決定する

SaaSテナント分離戦略に関するAWSホワイトペーパーは、分離をSaaSデザインの根幹と位置づけ、テナント境界を越えることはビジネスにとって回復不能なイベントになり得ると説明しています。Microsoftは分離を単一のスイッチではなくスペクトラムとして捉えています。実際には、各レイヤーごとに答えが異なります：

よく見られる合理的な結果は、プールされたアプリケーション層と、それを必要とするテナントのための分離されたデータという組み合わせです。Microsoftは、一部のコンポーネントをテナントごとに分割しながら他を共有する方法を「水平パーティショニング」と呼び、選ばれたテナントに専用デプロイメント全体を提供することを「垂直パーティショニング」と呼んでいます。

データパーティショニングのオプション

プールされたデータベースの場合、分離はアプリケーションコードだけでなくデータベース自体でも適用します。PostgreSQLの行セキュリティポリシーはその一例です。テーブルで有効化されると、ポリシーが許可しない限り行は非表示になり、テナントフィルターなしのクエリは全件ではなく何も返しません。注意すべき2つの詳細があります。ポリシーはテーブルごとに有効化する必要があり、テーブルオーナー・スーパーユーザー・BYPASSRLSアトリビュートを持つロールはデフォルトでポリシーをバイパスします。したがって、アプリケーションはテーブルを所有しないロールで接続するか、テーブルに行セキュリティを強制することで、オーナーにもポリシーが適用されるようにする必要があります。

課金・メタリングアーキテクチャ

マルチテナントSaaSの課金は、単一のインテグレーションではなくパイプラインです。

AI機能：データ分離とテナントごとのモデルコスト

アシスタント・AI検索・要約は、ほとんどの画面よりも1リクエストで多くのテナントデータを読み込むため、同じ場所で同じ境界を適用する必要があります。AIガバナンスはその背後にあるポリシーを規定しています。

• プロンプトの外で検索をフィルタリングする。検索サービスはセッションコンテキストからテナントとユーザーの権限を適用します。「このお客様のデータのみを使用してください」というプロンプト指示は分離にはなりません。
• すべてのAIキャッシュをテナントでキーイングする。テナントキーのないキャッシュされた回答や埋め込みは、あるお客様のコンテンツを別のお客様に返す可能性があります。
• テナントデータを共有トレーニングから除外する。1テナントのデータで共有モデルをファインチューニングしないこと。また、リクエストをトレーニングに使用しない条件を定めたモデルプロバイダーを選択します。規制対象テナントにはリージョンまたは専用モデルデプロイメントが必要になる場合があります。
• テナントごとにモデルコストを計測する。トークンと呼び出し数はテナントによって大きく異なります。機能ごとに帰属させ、エンタイトルメントを通じて上限を適用します。
• オフボーディング時に削除する。退去テナントの埋め込み・インデックス・ログに記録されたプロンプトは、データベースの行と共に削除します。

スケーリングの選択肢

テナント移行パスは早期に計画します。共有データベースから専用データベースへのデータ移動方法、トラフィックの切り替え方法、結果の検証方法を設計します。オンデマンドで考案するより、早期に設計する方がはるかに容易です。

運用：リリース・マイグレーション・リストア

• リングでリリースする。社内テナント、次に少数の顧客、最後に全員へと、テナントごとのフィーチャーフラグを使いながら順次展開します。
• フリート全体のスキーママイグレーションを自動化する。スキーマごとまたはデータベースごとのアーキテクチャでは、1回のリリースで多数のマイグレーションが発生します。どのテナントがどのバージョンにあるかを追跡します。
• プラットフォーム全体ではなく1テナントのリストアを行えるようにする。顧客は特定テナントのデータのリストアを要求します。要求が来る前にテストしておきます。
• テナントごとのコストを計測する。メタリングとクラウド請求書を組み合わせ、どのテナントとプランがコストをカバーしているかを把握します。

テスト根拠：テストすべき項目

以下は特定プロジェクトの結果ではなく、一般的なエンジニアリング実践です：

• クロステナントアクセステスト。すべてのエンドポイントとジョブについて、別テナントのデータを読み取りまたは変更しようとする自動テストを行い、必ず失敗することを確認します。
• 行ポリシーテスト。テナントコンテキストなしで実行されるクエリは、アプリケーションのデータベースロールで実行した場合も含め、行を返してはなりません。
• ノイジーネイバー負荷テスト。1つのテナントが高負荷を発生させながら、他のテナントのレスポンスタイムを計測します。
• シングルテナントリストアテスト。バックアップから1テナントをクリーンな環境にリストアし、レコードを比較します。
• メタリングテスト。再生・重複したイベントが同じ使用量合計を生成することを確認します。
• クロステナントAIテスト。アシスタントに別テナントのレコードについて質問した場合、キャッシュされた回答も含め、何も返ってこないことを確認します。

より広範なチェックはSaaSセキュリティチェックリストに記載されています。

事例：Printcart

Printcartは、Netbase JSCの5つのビジネス部門のうちの1つで、オンライン注文を印刷可能なファイルとルーティングされたフルフィルメントに変換するWeb to Printおよびプリントオンデマンドプラットフォームです。マーチャント自身のストア上、またはShopify・Wix・WooCommerceのアプリとして動作し、約7日でセットアップが完了し、2000以上のストアにサービスを提供しています。これだけ多くのマーチャントに1つの製品でサービスを提供することは、本記事が説明するマルチテナント問題そのものです。各マーチャントは、共有プラットフォーム上で独自のカタログ・注文・ストア接続を必要とします。Printcartのポートフォリオレコードでは、Netbase JSCがエンジニアリングし運用している内容を説明しており、印刷・パッケージングでセクターのコンテキストを確認できます。

自社製品以外では、Netbase JSCは2020年から、名前が公開されていない米国クライアントのマルチテナントクラウドERPのSaaSプラットフォームのオフショア開発・管理パートナーとして従事しており、中小企業向けにSaaSとして販売されています。

Netbase JSCのマルチテナント構築へのアプローチ

Netbase JSCはAWS・Google Cloud・DigitalOcean・Cloudflareと連携しています。クラウドパートナーティアやクラウド認証は主張していません。一般的な期間の目安は、SaaS MVPが8〜12週間、中規模製品が3〜6カ月、エンタープライズプラットフォームがスコープによって6〜12カ月以上です（これらは見積もりではなく目安の範囲です）。セキュリティは最初のスプリントから設計に組み込まれています。セキュアコードレビュー、転送時のTLS・保存時のAES暗号化、ロールベースアクセス制御、管理ダッシュボードへのMFA、脆弱性スキャン、ディザスタリカバリ計画が含まれます。AIモデルは製品ごとに選択し、特定ベンダーに縛られません。SaaS開発サービスが製品を構築し、SaaSプロダクトアクセラレーターはアカウント・テナント・ロール・課金の再利用可能なモジュールから開始します。

本記事の限界

• 本記事は一般的なパターンと実践を説明しています。最適な組み合わせは、テナント・データ・リージョン・顧客との契約によって異なります。
• 引用しているAWSホワイトペーパーはAWSによって歴史的参考資料として位置づけられています。分離の原則は広く使用されていますが、サービス固有の詳細については現在のAWSガイダンスを確認してください。
• PostgreSQLはデータベース強制分離の一例として使用しています。他のデータベースは異なるメカニズムを提供しています。
• 期間は一般的な目安の範囲です。Printcartは公開された製品情報をもとに説明しており、ここではパフォーマンス指標は主張していません。

次のステップ

テナントプロファイル・データの機密性・料金モデルをお知らせください。最初のリリースに最適な分離と課金設計を選択するためのソリューションレビューをご予約いただけます。関連サービスを確認するか、Netbase JSCのインサイトをご覧いただくこともできます。

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