単一のコードベース、数百のテナント、データ漏洩ゼロ — すべてのスケーラブルなSaaSビジネスの基盤。

単一のデプロイメントから複数の顧客にサービスを提供するプラットフォームを構築している場合。各顧客はデータ分離、ブランド体験、テナントごとの請求を期待しますが、それぞれに個別のインフラストラクチャを運用する余裕はありません。共有インフラストラクチャの経済性と、専用システムの分離保証が必要です。これはSaaSアーキテクチャの根本的な課題であり、初期段階で分離モデルを誤ると、プラットフォーム開発において最も高価な間違いの一つになります。
マルチテナントSaaSアーキテクチャは、基盤となるコンピューティング、ストレージ、およびネットワークリソースを共有しながら、テナント間で論理的または物理的な分離を提供します。このパターンには、テナントプロビジョニング、データ分離、機能管理、請求計測、ホワイトラベルカスタマイズが含まれます。中核となる設計上の決定は、分離モデルです。行レベルセキュリティ(RLS)を備えた共有データベース、テナントごとのスキーマ、またはテナントごとのデータベースのいずれかです。各モデルは、分離の強度と運用上の複雑さおよびコスト効率の間でトレードオフがあります。
Explore more design patterns and system architectures
最適な選択は、テナント分離の要件と規模によって異なります。MicrocosmWorksは通常、ほとんどのB2B SaaS製品に対して、コスト効率とデータ分離のバランスが取れる共有データベース、分離スキーマのアプローチを推奨しています。ただし、医療や金融のような厳格なデータ分離が義務付けられている規制産業のクライアントに対しては、テナントごとのデータベースを実装しています。当社のアーキテクトは、適切なテナンシーモデルを推奨する前に、お客様のコンプライアンス要件、予想されるテナント数、およびクエリパターンを評価します。
MicrocosmWorksは、テナント認識型レート制限、テナントごとのクォータを持つコネクションプーリング、およびコンピュート層でのリソース分離を実装し、「騒がしい隣人」問題を防止しています。私たちは、重み付け公平キューイングやテナント固有のキャッシング層のような技術を使用しており、これにより、ある顧客からの突然のスパイクが他の顧客の遅延に波及しないようにしています。エンタープライズティアのテナントに対しては、共有コントロールプレーンをそのまま維持しつつ、専用のコンピュートパーティションをプロビジョニングすることが可能です。
MicrocosmWorksは、必要な複雑性やチームの経験レベルに応じて、1時間あたり15ドルから45ドルのコンサルティング料金で、アーキテクチャ設計および実装サービスを提供しています。一般的なマルチテナントSaaSアーキテクチャのプロジェクト(データベース設計、テナント分離、認証、デプロイメントパイプラインを含む)は、クロスファンクショナルチームで8〜16週間かかります。当社は、お客様が構築に着手する前に費用全体を把握できるよう、すべてのプロジェクトを固定料金の検討フェーズで範囲設定します。
MicrocosmWorks は、新規登録から数分以内にスキーマ作成、DNS設定、機能フラグの初期化、およびシードデータのデプロイを処理する、自動化されたテナントプロビジョニングパイプラインを構築します。当社は、Terraform や Pulumi のような infrastructure-as-code ツールとイベント駆動型ワークフローを組み合わせて使用し、各新規テナントが手動介入なしに完全に設定された環境を得られるようにします。このアプローチにより、お客様はオンボーディングプロセスを変更することなく、10テナントから10,000テナントまで規模を拡大できます。
MicrocosmWorks は、フィーチャーフラグ、テナント固有のメタデータ、およびコード分岐なしでテナントごとの動作を可能にするプラグインアーキテクチャを使用して、設定駆動型のカスタマイズレイヤーを実装しています。UIテーマ設定、ワークフローエンジン、および統合レイヤーに拡張ポイントを設計しており、これによりテナントは独自のブランディング、ビジネスルール、およびサードパーティ接続をすべて設定を通じて管理できます。これにより、お客様のエンジニアリングチームは多様な顧客要件をサポートしながら、単一のコードベースを維持できます。
システムは3つの層に分けられます。テナント認識型ゲートウェイは、認証、テナント解決(サブドメイン、JWTクレーム、またはAPIキー経由)、およびリクエストルーティングを処理します。アプリケーション層は、完全にテナントコンテキスト内で動作します。すべてのクエリ、すべてのキャッシュキー、すべてのキューメッセージは、解決されたテナントにスコープされます。データ層は、行レベルセキュリティポリシー、テナントごとの接続プール、および保存時の暗号化されたパーティショニングを通じて、ストレージレベルで分離を強制します。
tenant_idでフィルタリングします。スキーマごとのテナントの場合: 接続プール管理を伴う動的接続ルーティング。データベースごとのテナントの場合: Terraform/Pulumiによるプロビジョニング自動化。acme.yourapp.com)はホワイトラベル製品にとってよりクリーンであり、テナントごとのTLS証明書を可能にします。パスベース(yourapp.com/acme/)は実装がよりシンプルで、ワイルドカードDNSの複雑さを回避します。MicrocosmWorksは、ホワイトラベル要件を持つB2B SaaSにはサブドメイン解決を、内部マルチテナントツールにはパスベースをお勧めします。
共有機能フラグ vs. テナントごとの設定。 私たちは2層の機能フラグシステムを使用しています。グローバルフラグはプラットフォーム全体のロールアウトを制御し、テナントレベルのオーバーライドにより、特定の顧客にベータ機能を有効にしたり、下位ティアプランのテナントの機能を無効にしたりできます。Edge ConfigまたはLaunchDarklyは、これをサブミリ秒の読み取りでサポートします。
テナント認識型キャッシュ。 すべてのキャッシュキーはtenant_idにスコープされる必要があります。これは当然のことのように思えますが、テナント間のキャッシュキーの衝突は、最も一般的なマルチテナントのバグの一つです。私たちは、テナントコンテキストを自動的にプレフィックスとして付加するキャッシュキーファクトリを通じてこれを強制します。| 層 | 技術 |
|---|---|
| コンピューティング | Node.js (NestJS), Python (FastAPI), ECS FargateまたはKubernetes上でコンテナ化 |
| データ | PostgreSQL with RLS, Redis (テナントスコープの), S3 (テナントパーティショニングされたバケット) |
| ID管理 | Clerk, Auth0, or Okta (テナントスコープの組織と連携) |
| 請求 | Stripe Connect (マーケットプレイスモデル), Stripe Billing (従量課金制サブスクリプション) |
| 可観測性 | Datadog (テナントディメンションタグ付き), すべてのエントリにtenant_idを含む構造化ロギング |
| 使用すべきケース | 避けるべきケース |
|---|---|
| 共有インフラストラクチャから10社以上の顧客にサービスを提供するB2Bプラットフォームを構築する場合 | 各顧客が完全に専用のインフラストラクチャを必要とする場合(コンプライアンス/契約上) |
| ホワイトラベルブランディング、カスタムドメイン、およびテナントごとの機能制御が必要な場合 | 顧客数が3社未満の場合 — よりシンプルな顧客ごとのデプロイメントで十分な場合があります |
| 使用量ベースまたはティアード料金がテナントごとの計測を必要とする場合 | 製品がユーザーレベルのアカウントを持つコンシューマーアプリであり、組織レベルのテナントではない場合 |
| 単一のデプロイメントパイプライン、単一の監視スタック、単一のオンコールローテーションを望む場合 | テナントが根本的に異なるスキーマまたはビジネスロジック(設定だけでなく)を持つ場合 |
MicrocosmWorksは、マルチテナンシーを機能ではなく横断的関心事として扱います。私たちはミドルウェアレベルでテナントコンテキスト伝播を実装しているため、アプリケーションコードが手動でテナントによってフィルタリングすることはありません — それはフレームワークによって強制されます。私たちのRLS実装には、すべてのCI実行でテナント間のデータアクセスを試みる自動テストスイートが含まれています。私たちは、共有インフラストラクチャ上で500以上のテナントにサービスを提供するマルチテナントプラットフォームを構築し、データ漏洩事故ゼロを達成しました。また、ストランブラー・フィグ・パターンを使用して、シングルテナントのモノリスをマルチテナントアーキテクチャに移行してきました。
モデルはそれ自体で動作するわけではありません。モデルのトレーニング、検証、デプロイ、監視を行うパイプラインこそが実際の製品であり、モデルはその成果物の一つに過ぎません。