マルチテナンシー

マルチテナンシーとは?

マルチテナンシーは、アプリケーションの単一インスタンス(基盤となるデータベースやハードウェアを含む)が複数のテナント(組織、部門、またはユーザーグループ)にサービスを提供しながら、各テナントのデータと設定を論理的に分離するソフトウェアアーキテクチャパターンです。このモデルにより、多数の顧客が同じインフラストラクチャとコードベースを共有しながら、テナント間でデータの厳格な分離とプライバシーを維持できます。

テナントは、アプリケーションへの共通アクセス権を持つ個別ユーザーまたはグループです。各テナントのデータは、プライバシーと規制コンプライアンスのために他のテナントから分離されています。マルチテナンシーは、Software-as-a-Service(SaaS)およびクラウドコンピューティング提供モデルの基盤であり、類似のニーズを持つ多数の顧客に対して、スケーラブルでコスト効率が高く、管理しやすいソフトウェア提供を可能にします。

主要概念

テナント: 共有アプリケーションへの分離されたアクセス権を持つ顧客または論理単位(組織、部門、ユーザーグループ)。

アプリケーションインスタンス: 共有コードベースから複数のテナントにサービスを提供する実行中のソフトウェア。

データ分離: 別々のスキーマ、テナントID、またはデータベースを通じて、テナントが他のテナントのデータにアクセスできないようにすること。

リソース共有: 効率性のためにプールされたハードウェア、コンピュート、ストレージ、ネットワークリソース。

RBAC(ロールベースアクセス制御): ユーザーロールによって権限を割り当て、テナントごとにスコープを設定するセキュリティモデル。

ノイジーネイバー: あるテナントのリソース使用が他のテナントのパフォーマンスに悪影響を与えるシナリオ。

カスタマイゼーション: コード変更なしに、テナントがブランディング、ビジネスルール、設定を構成できるようにすること。

論理的分離 vs. 物理的分離: 論理的分離はコード/データベースのパーティショニングを使用し、物理的分離は専用サーバーまたはクラスターを使用する場合があります。

アーキテクチャタイプ

単一アプリケーション、単一データベース

構成: 1つのアプリインスタンス、1つのデータベース。すべてのテナントのデータが同じテーブルに共存し、テナントIDでパーティション化されます。

長所: シンプル、コスト効率が高い、管理が容易。

短所: 分離が失敗した場合のデータ漏洩リスク、テナントのカスタマイゼーションが限定的。

単一アプリケーション、複数データベース

構成: 1つのアプリインスタンス、複数のデータベース。各テナントが専用データベースを持ちます。

長所: 強力なデータ分離、テナントごとのバックアップと移行が容易。

短所: 運用の複雑性が高い、スケール時のコストが高い。

複数アプリケーション、複数データベース

構成: 各テナントが別々のアプリインスタンスとデータベースを持ちます。

長所: 最大限のセキュリティとカスタマイゼーション。

短所: 高コスト、複雑な管理、リソース効率が低い。

アーキテクチャ比較

データ分離アプローチ

テナントID: 各データレコードに一意のテナント識別子をタグ付け。すべてのクエリがスコープ設定され、テナント間アクセスを防止します。

別々のスキーマ: 各テナントのデータを単一データベース内の専用スキーマに保存し、より強力な分離を提供します。

専用データベース: 各テナントが物理的に分離されたデータベースを持ち、最大限の分離とセキュリティを実現します。

例: Salesforceはテナント ID(OrgID)を使用してすべてのデータにタグ付けし、クエリが自動的にスコープ設定されて組織間アクセスを防止します。

マルチテナンシー vs. シングルテナンシー

例え: マルチテナンシーは、各テナントがプライベートな「アパート」(データ/設定)を持ちながら、すべてが建物のインフラストラクチャ(コンピュート、ストレージ、ネットワーク)を共有するアパートメントビルのようなものです。プロバイダーはプライバシーを確保し、建物を管理します。

メリット

コスト効率: 共有インフラストラクチャにより、リソースプーリングと規模の経済を通じて顧客あたりのコストが削減されます。

スケーラビリティ: 別々のデプロイメントなしで新しいテナントを迅速にオンボーディングでき、高速な成長を可能にします。

一元管理: すべてのテナントに対して同時に更新、パッチ適用、サポートを簡素化します。

一貫したエクスペリエンス: すべてのテナントが同じバージョンを使用し、バージョンのずれや互換性の問題を排除します。

リソース利用率: ハードウェアとコンピュートが複数のテナント間でより完全に利用されます。

設定可能なカスタマイゼーション: コード変更なしで、ブランディングと設定をテナント固有にできます。

課題

セキュリティリスク

データ漏洩: 不十分な分離により、コーディングエラーやセキュリティ脆弱性を通じてテナントデータが露出する可能性があります。

アクセス制御: テナント対応の認証、RBAC、厳格なAPIセキュリティが必要です。

コンプライアンス: 標準(GDPR、HIPAA)を満たすには、監査可能性とデータ制御が必要です。

軽減策: 厳格なクエリスコープ設定(テナントIDフィルター)を使用し、保存時および転送時のデータを暗号化し、監査証跡と定期的なセキュリティレビューを適用します。

ノイジーネイバー問題

問題: あるテナントの重いリソース使用が、共有コンピュート/ストレージ環境を通じて他のテナントのパフォーマンスを低下させます。

一般的なシナリオ: CPU集約的な操作、大規模データクエリ、高トラフィック量。

軽減戦略:

• テナントごとのリソースクォータと制限
• スロットリングとレート制限
• リソース使用状況の監視とアラート
• 動的リソース割り当て
• 高需要テナント向けの物理的分離

リソース競合

課題: 共有リソースが競合を生み出し、レイテンシスパイクや停止につながります。

管理戦略:

• 論理的分離(名前空間、クォータ)
• 物理的分離(専用ノード/クラスター)
• 動的スケーリングとオートスケーリング
• リソース使用状況の監視とアラート

ユースケース

SaaSプラットフォーム

Salesforce: テナントIDを使用した強力な組織レベル分離を持つマルチテナントCRM。

Shopify: 各ストアがテナントで、グローバルに共有されたプラットフォームインフラストラクチャ。

Zendesk: 共有バックエンドと分離されたデータを持つ複数の顧客サポートチーム。

クラウドサービス

AWS、Azure、GCP: コンピュート、ストレージ、ネットワーキングにまたがるマルチテナントインフラストラクチャ。

Microsoft 365: 分離された設定を持つ数百万のビジネステナント。

分析&AIプラットフォーム

GoodData: 分析とビジネスインテリジェンス向けのテナントごとのワークスペースモデル。

Tableau、Power BI: マルチテナントビジネスインテリジェンスプラットフォーム。

サーバーレスプラットフォーム: コスト効率のためにテナントごとに関数実行を分離。

実装のベストプラクティス

認証と認可

テナント対応認証: テナントクレームを持つSSOまたはJWTトークン。

RBAC実装: アプリケーション層とインフラストラクチャ層の両方でロールベースアクセス制御。

API認可: APIレベルでテナント境界を強制し、テナント間アクセスを防止。

データパーティショニング

すべてのレコードにタグ付け: すべてのデータレコードにテナントIDを含める。

スキーマ分離: 機密性の高いテナントや規制対象テナントには別々のスキーマまたはデータベースを使用。

暗号化: 保存時および転送時の機密データを暗号化。

定期的なテスト: データ漏洩テストと分離検証のためのコードレビュー。

スケーリングとメンテナンス

オートスケーリング: テナント負荷に基づいてコンピュートとストレージを動的にスケール。

コンテナ化: 柔軟性と分離のためにコンテナ化されたデプロイメントを使用。

一元化された更新: バージョンのずれを避けるために更新を一元的にデプロイ。

リソース監視: テナントごとのリソース使用状況を監視し、クォータを強制。

テスト

分離テスト: テナント間アクセスが不可能であることを検証。

パフォーマンステスト: スケールとノイジーネイバー条件下でテスト。

設定テスト: テナント固有の設定パスを検証。

コンプライアンステスト: プライバシーとセキュリティ標準が満たされていることを確認。

テクノロジースタック

バックエンド: Node.js、Python(Django、FastAPI)、Java、PHP、Go

データベース: PostgreSQL(スキーマ付き)、MySQL、MongoDB、Azure SQL

認証: Auth0、Keycloak、OAuth2、Firebase Auth

DevOps: Docker、Kubernetes、Terraform、Helm

監視/セキュリティ: クラウドネイティブ監視、DLPツール、監査ログ

マルチテナンシーを使用すべき場合

推奨される場合:

• 類似の要件を持つ多数の顧客にサービスを提供する場合
• コスト効率、スケーラビリティ、一元管理が優先事項である場合
• テナントごとのカスタマイゼーションがコアコードではなく設定に限定される場合

理想的でない場合:

• 厳格なコンプライアンス、分離、または規制要件を持つテナント(テナントごとのDBまたはアプリインスタンスを使用)
• 広範なカスタマイゼーションを必要とする深くカスタマイズされたクライアント固有のデプロイメント

参考文献

• IBM: What is Multi-Tenant?
• Wikipedia: Multitenancy
• Salesforce: Platform Multitenant Architecture
• Microsoft Azure: Multitenant Storage and Data Approaches
• Qrvey: Multi-Tenant Security—Risks and Best Practices
• Neon: The Noisy Neighbor Problem in Multitenant Architectures
• Spectro Cloud: Managing the Noisy Neighbor Problem in Kubernetes
• GoodData: Multi-Tenant Architecture
• Cigen: AI in SaaS Use Cases and Applications
• LinkedIn: Multi-tenant SaaS in the Real World