マルチテナントSaaSの構築は、単なる技術的な課題を超えて、ビジネス価値の提供と運用効率の両立を目指す挑戦的な取り組みです。本記事では、マルチテナントSaaSの設計から実装まで、実践的な知見を共有していきます。
SaaS概要編
マルチテナントとは
マルチテナントとは、単一のアプリケーションインスタンスで複数の顧客(テナント)のデータを安全に分離・管理するアーキテクチャパターンです。各テナントのデータは論理的に分離され、他のテナントからアクセスできないようになっています。
SaaS以前のソフトウェア
従来のソフトウェアは、各顧客ごとに個別のインスタンスをインストール・管理する必要があり、運用コストが高く、アップデートも煩雑でした。これに対し、SaaSはクラウド上で一元管理することで、これらの課題を解決します。
SaaSの本質
SaaSの最大の目的は、テナントをまとめて管理および運用する機能を通じて、俊敏性、イノベーション、規模の経済性、効率性を実現することです。個別対応のモデルに流れると、SaaS本来の目的から遠ざかってしまいます。
MSPとの違い
SaaSは本質的にはビジネス価値、サービスを提供することを目的としています。一方、MSP(マネージドサービスプロバイダ)は主にインフラや運用の管理に焦点を当てています。
SaaSの2つのプレーン
SaaSアーキテクチャは一般的に以下の2つの論理的なプレーンで構成されています。これらのプレーンは責務を明確に分離することで、スケーラブルで管理しやすいシステムを実現します:
-
コントロールプレーン
- テナント管理:テナントのプロビジョニング、設定、ライフサイクル管理
- 認証・認可:ID管理、アクセス制御、セキュリティポリシーの適用
- 課金管理:使用量計測、請求処理、支払い管理
- 運用管理:監視、メトリクス収集、アラート、自動化
コントロールプレーンはSaaS全体の「心臓部」として機能し、テナントの作成から削除までのライフサイクル全体を管理します。このプレーンは一般的に専用のインフラストラクチャ上に構築され、高い可用性と信頼性を確保する必要があります。
実装例:
- AWS Control Tower や AWS Organizations を活用したマルチアカウント管理基盤
- カスタム開発されたテナント管理サービス
- Keycloak や Auth0 などのIDプロバイダーと連携した認証システム
- AWS Cognito とカスタムテナントマッピングを組み合わせたマルチテナント認証
-
アプリケーションプレーン
- ビジネスロジック:サービスの中核機能、業務ルール、ワークフロー
- データ処理:データの格納、取得、変換、分析
- ユーザーインターフェース:テナントユーザー向けのUI/UX
- テナント固有の機能:カスタマイズ、拡張、統合
アプリケーションプレーンはテナントユーザーが直接操作する部分で、実際のビジネス価値を提供します。このプレーンは、選択したデプロイモデル(サイロ型、プール型、ポッド型など)に基づいて、単一または複数のインフラストラクチャに分散配置されることがあります。
実装例:
- マイクロサービスアーキテクチャに基づくビジネスロジックの実装
- GraphQLやRESTfulなAPIを通じたフロントエンドとバックエンドの通信
- フロントエンドフレームワーク(React, Vue, Angularなど)を活用したUI
- テナント固有の設定に基づいた動的な機能制御
プレーン間の相互作用
両プレーン間の連携は、SaaSシステム全体の効率性と信頼性に大きく影響します。例えば、コントロールプレーンでテナントがオンボーディングされると、アプリケーションプレーンでそのテナント用のリソースが自動的にプロビジョニングされます。同様に、アプリケーションプレーンでのテナントの活動(リソース使用量など)は、コントロールプレーンに報告され、課金や監視に活用されます。
設計上の考慮事項
プレーンの設計においては、以下の点を考慮することが重要です:
- 分離と結合:両プレーンを適切に分離しつつ、効率的に連携させるバランス
- スケーラビリティ:各プレーンが独立してスケールできるアーキテクチャ
- 耐障害性:一方のプレーンの障害が他方に与える影響を最小化
- セキュリティ:プレーン間の通信におけるセキュリティの確保
- 運用効率:両プレーンを一元的に管理・監視する仕組み
各プレーンの設計と実装方法は、ビジネス要件、規制要件、および技術的な制約によって異なりますが、責務の明確な分離という原則は常に維持されるべきです。
デプロイ戦略:サイロ型とプール型
マルチテナントSaaSのデプロイ戦略は、テナントごとのリソース分離とコスト効率のバランスに大きく影響します。主に「サイロ型」と「プール型」の2つのアプローチが存在し、それぞれ異なる特性と適用シナリオを持っています。
サイロ型(Silo Model)
- 基本構造: 各テナントに専用のリソースを割り当て、完全に分離された環境を提供
- 分離レベル: アプリケーションスタック全体、またはインフラストラクチャレベルでの完全な分離
- セキュリティ特性: 高い分離性により、テナント間のデータ漏洩やリソース干渉リスクを最小化
- コスト構造: リソースの共有がないため、テナント数に比例してコストが増加
- 運用特性: テナントごとに独立した管理が可能で、個別のカスタマイズやスケーリングが容易
サイロ型の実装パターン:
- テナント毎のアカウント分離: AWS Organizations などを活用し、テナントごとに独立したクラウドアカウントを提供
- テナント毎のVPC分離: 単一アカウント内で、テナントごとにVPCを分離して提供
- テナント毎のコンテナクラスター: EKS/ECSなどで、テナントごとに専用のクラスターを割り当て
- テナント毎のサービスインスタンス: サービスレベルでテナントごとに個別のインスタンスを展開
適したユースケース:
- 厳格な規制遵守が必要な金融・医療・政府系システム
- データ主権やリージョナル要件が厳しい国際的なサービス
- エンタープライズ向けの高額・ハイエンドサービス
- カスタマイズ要件が高く、テナントごとの個別対応が必要なケース
プール型(Pool Model)
- 基本構造: 複数のテナントでリソースを共有し、論理的な分離を実現
- 分離レベル: アプリケーション層での論理的な分離(テナントID、認証、認可など)
- セキュリティ特性: 適切な分離メカニズムが必要で、実装ミスがクロステナントの脆弱性につながる可能性
- コスト構造: リソースの効率的な共有により、テナント単位のコストが大幅に削減
- 運用特性: 一元的な管理が可能でメンテナンスが容易、ただし個別化の柔軟性は低下
プール型の実装パターン:
- マルチテナントデータベース: スキーマ共有型や行レベルフィルタリングによるデータ分離
- 共有コンピューティングリソース: リクエスト時のテナントコンテキスト認識による論理分離
- 共有API層: リクエストヘッダーやベアラートークンによるテナント識別
- 共有インフラ: 単一のアプリケーションスタック上での論理的テナント分離
適したユースケース:
- 中小企業(SMB)向けの低価格・大量顧客型サービス
- カスタマイズ要件が低く、標準化されたサービス
- スタートアップフェーズで迅速なスケールが必要なサービス
- コンシューマー向けの大規模サービス
ハイブリッドアプローチ
実際の多くのSaaSシステムでは、単純なサイロ型やプール型ではなく、ハイブリッドモデルを採用することが一般的です。例えば:
- ティア別分離: プレミアムティアのテナントにはサイロ型、標準ティアのテナントにはプール型を適用
- コンポーネント別分離: ストレージはサイロ型で分離し、コンピューティングリソースはプール型で共有
- データの機密性に基づく分離: 機密データはサイロ型で保存し、一般データはプール型で管理
デプロイ戦略の選択基準
デプロイ戦略を選択する際には、以下の要素を考慮することが重要です:
-
法規制とコンプライアンス要件
- データ保護法(GDPR、HIPAA、PCI DSSなど)が要求する分離レベル
- 業界固有の規制やデータローカライゼーション要件
-
テナントのSLA要件
- パフォーマンス保証の厳格さ
- ノイジーネイバー問題への耐性
-
ビジネスモデルとコスト構造
- サービスの価格帯とマージン
- テナント獲得コストと運用コストのバランス
-
運用の複雑さとスケール能力
- DevOpsチームの規模と技術力
- テナント数の増加予測とスケーリング戦略
-
テナントカスタマイズの要件
- 標準機能と個別機能のバランス
- バージョン管理とアップグレード戦略
最終的には、ビジネス要件とテクニカル要件のバランスを取りながら、サービスのライフサイクル全体を考慮した戦略選択が重要です。多くの成功しているSaaSプロバイダーは、成長段階に応じて戦略を進化させ、初期段階ではシンプルなプール型から始め、必要に応じてハイブリッドモデルへと移行していく傾向があります。
サイロとプール
マルチテナントSaaSの最も根本的な設計選択は「リソースの専有か共有か」という点に集約されます。この選択はアーキテクチャのあらゆる側面に影響を与えます。
リソース分離の本質
「サイロ」と「プール」という概念は、リソース分離の哲学を表しています:
サイロモデル(専有リソース):
- 各テナントに対して独立した専用リソースを割り当てる
- 物理的または論理的な壁を設けて、テナント間の干渉を完全に防止する
- テナントごとに「自分だけの空間」を提供する
- 「高級マンションの個別部屋」のようなイメージ
プールモデル(共有リソース):
- 複数のテナントが同じリソースを共有する
- テナントIDによる論理的な分離のみを実装する
- マルチテナンシーのコード内での実装に依存する
- 「シェアオフィスの共有スペース」のようなイメージ
分離レベルの階層
リソースの分離は様々なレベルで実装可能です:
- インフラレベル: クラウドアカウント、VPC、サブネット、セキュリティグループの分離
- コンピューティングレベル: EC2インスタンス、コンテナ、Lambda関数の分離
- データレベル: データベース、スキーマ、テーブル、行レベルの分離
- アプリケーションレベル: マイクロサービス、API、UIの分離
これらのレベルは互いに独立しており、あるレベルではサイロモデル、別のレベルではプールモデルを採用することも可能です。例えば、データベースは各テナントで専有(サイロ)しながら、アプリケーションサーバーは共有(プール)するといった組み合わせです。
トレードオフの本質
サイロとプールの選択は、以下のトレードオフを伴います:
側面 | サイロモデル(専有) | プールモデル(共有) |
---|---|---|
分離性 | 高い(物理的/論理的分離) | 低い(ソフトウェアによる分離) |
コスト効率 | 低い(重複リソース) | 高い(リソース共有) |
カスタマイズ性 | 高い(テナント個別対応可能) | 低い(共通基盤に依存) |
運用複雑性 | 高い(多数のインスタンス管理) | 低い(集中管理可能) |
スケーラビリティ | テナント単位(粒度粗い) | システム全体(粒度細かい) |
フルスタックのサイロモデル
フルスタックのサイロモデルは、テナントごとにアプリケーションスタック全体を完全に分離する最も強力な分離アプローチです。このモデルでは、インフラからアプリケーションコードまで、すべてのレイヤーで完全な分離を実現します。
フルスタックサイロモデルの特徴
採用する組織の特徴:
- コンプライアンスとセキュリティを最優先事項とする組織(金融機関、医療機関、政府機関など)
- 既存のレガシーシステムをSaaS化する移行プロジェクト
- 各テナントに高度なカスタマイズを提供するビジネスモデル
- 限られた数の大規模テナントをターゲットとするサービス
アーキテクチャ上の利点:
- シンプルな設計:各テナントのスタックは独立しており、相互干渉がない
- 明確な境界:テナント間のリソース分離が物理的に明確
- 安全性:テナント間のデータ漏洩リスクを最小限に抑制
- 個別最適化:テナントごとのニーズに合わせたリソース割り当てが可能
ビジネス面での利点:
- ティアリング戦略の実装が容易:各テナントに異なるサービスレベルを提供できる
- 影響範囲の局所化:一つのテナントの問題が他に波及しない
- パフォーマンス保証:専用リソースによるSLA提供が容易
- 規制対応:厳格なコンプライアンス要件への適合
実装アプローチ
フルスタックサイロモデルを実装する主な方法には、以下の2つがあります:
-
サブドメインアプローチ:
- 各テナントに固有のサブドメイン(例:tenant1.saas-service.com)を割り当て
- サブドメインごとに独立したインフラとアプリケーションスタックを配置
- DNSルーティングでテナントを適切なスタックに誘導
- メリット:明確なURL分離、テナントごとのカスタムドメイン対応が容易
- デメリット:DNSの管理複雑化、証明書管理のオーバーヘッド
-
テナントコンテキスト生成アプローチ:
- 共通のエントリーポイント(例:saas-service.com/tenant-id)を使用
- リクエスト内のテナントIDに基づいて、適切なバックエンドスタックにルーティング
- APIゲートウェイやロードバランサーでルーティングロジックを実装
- メリット:URL構造の一貫性、証明書管理の簡素化
- デメリット:ルーティングロジックの複雑化、単一障害点のリスク
実装上の考慮事項
フルスタックサイロモデルを効果的に実装するためには、以下の点に注意する必要があります:
-
プロビジョニングの自動化:
- Infrastructure as Code(IaC)を活用した環境の一貫した再現
- テナントオンボーディングプロセスの完全自動化
- リソーステンプレートの標準化とバージョン管理
-
運用管理の効率化:
- 集中監視と分散デプロイのバランス
- アップデートと変更管理の複雑性への対応
- 共通コアとテナント固有設定の分離
-
コスト管理:
- 未使用リソースの最適化
- テナントごとの料金体系とコスト配分
- リソース使用効率の測定とフィードバック
-
移行戦略:
- サイロからプールへの段階的移行パス(必要に応じて)
- ハイブリッドアプローチの検討(一部コンポーネントのみサイロ化)
- スケーリング戦略と成長計画の整合性確保
フルスタックサイロモデルは、最大限の分離とセキュリティを求める環境に最適ですが、リソース効率とスケーラビリティに関するトレードオフを慎重に評価する必要があります。このモデルは特に、高い規制要件を持つ業界や、プレミアムティアのエンタープライズ顧客向けサービスで広く採用されています。
テナント毎のアカウントモデル
テナント毎のアカウントモデルは、フルスタックサイロモデルの最も強力な形態で、各テナントに完全に独立したクラウドアカウント(AWS、Azure、GCPなど)を割り当てる方式です。これは最高レベルの分離とセキュリティを提供する一方で、運用の複雑さとコストが増大する特徴があります。
テナント毎のアカウントモデルの基本概念
このモデルでは、各テナントは完全に独立したアカウントを持ち、そこに専用のインフラストラクチャとアプリケーションスタックがデプロイされます。例えばAWSの場合、テナントごとに独立したAWSアカウントを作成し、Organizations機能を使用して一元管理します。
このアプローチが検討される主な理由は以下の通りです:
- 完全なリソース分離:テナントが完全に独立したインフラを求める場合
- ノイジーネイバーの完全排除:あるテナントのリソース使用が他テナントに影響を与える可能性を排除
- 厳格なデータ分離要件:規制やコンプライアンス上、データの完全な分離が必要な場合
- カスタムセキュリティポリシー:テナントごとに異なるセキュリティ設定が必要な場合
- 専用リソース制限:各テナントに独自のリソース制限を設定する必要がある場合
実装上の重要ポイント
-
アカウント管理の自動化
- AWS Organizationsなどを活用した多数のアカウント一元管理
- Service Control Policies (SCP)によるアカウント間の一貫したポリシー適用
- 自動化されたアカウントプロビジョニングとベースライン設定
-
サービス間通信の設計
- アカウント間のネットワーク接続(VPC Peering、AWS Transit Gatewayなど)
- クロスアカウントロールとアクセス管理
- 適切な粒度のRBAC(Role-Based Access Control)実装が不可欠
- 特に外部リソースとサイロモデル間の通信では、きめ細やかなRBACを構築しないと複雑さが増大
- アクセス権限の最小権限原則の適用と定期的な監査
-
統一されたデプロイパイプライン
- マルチアカウントへの一貫したデプロイメカニズム
- Infrastructure as Code(IaC)の徹底活用
- 変更管理と環境整合性の維持
-
集中監視と管理
- 複数アカウントにまたがるログ集約
- クロスアカウントメトリクス収集
- 統合アラート管理システム
メリットとデメリット
メリット:
- 最高レベルのセキュリティ分離(アカウントレベルでの完全な分離)
- テナントごとに個別のリソース制限とクォータ設定が可能
- 請求の明確な分離と詳細なコスト配分
- 規制要件への対応が容易(各テナントの環境を独立して監査可能)
- 障害の影響範囲が単一テナントに限定される
デメリット:
- 複数アカウントの管理による運用オーバーヘッドの増大
- テナント数に比例したインフラコストの上昇
- リソース使用効率の低下(テナント間でのリソース共有が困難)
- テナントオンボーディングの複雑化
- テナントごとに規定の制限値を設ける必要がある場合、オンボーディングの完全自動化が困難になる
- アカウント作成やベースライン設定に手動介入が必要になるケースがある
- テナント間のデータや機能共有が複雑になる
実装パターンとベストプラクティス
-
ハブアンドスポークモデル
- 中央管理アカウント(ハブ)からテナントアカウント(スポーク)を統制
- 共有サービス(監視、セキュリティ、デプロイパイプラインなど)をハブに配置
- テナント固有のリソースをスポークに配置
-
標準化とテンプレート化
- テナントアカウントの標準構成を定義(CloudFormation、Terraform)
- デプロイの自動化と一貫性確保
- テナントオンボーディングの標準プロセス確立
-
アクセス管理の最適化
- フェデレーションIDによる統合アクセス管理
- クロスアカウント役割の適切な設計
- 権限昇格の防止メカニズム
適したユースケース
テナント毎のアカウントモデルは、以下のような状況で特に適しています:
- 高額・ハイエンドのSaaSサービス:テナントごとの専用環境コストを正当化できる
- 金融・医療・政府系システム:厳格なコンプライアンス要件がある業界
- 大企業向けエンタープライズSaaS:高度なカスタマイズとセキュリティ要件がある
- マルチリージョン/マルチクラウド要件:地理的・法規制的な要因でデータの配置場所が制限される
実装上の注意点
テナント毎のアカウントモデルを効果的に実装するには以下の点に注意が必要です:
-
一元管理の仕組み
- マルチアカウント環境での一貫したガバナンス確立
- 中央管理ツールへの投資(CloudFormation StackSets、AWSコントロールタワーなど)
-
コスト管理戦略
- アカウント固定費の最適化
- 未使用リソースの定期的な特定と削減
- コスト配分と課金モデルの最適化
-
運用効率の向上
- 運用タスクの自動化(パッチ管理、バックアップ、スケーリングなど)
- セルフサービスポータルによるテナント管理の効率化
- 標準化された運用手順の確立
-
スケーリング戦略
- テナント数増加に伴う管理複雑性への対応
- 自動化とオーケストレーションの強化
- 組織構造と運用プロセスの最適化
テナント毎のアカウントモデルは、基本的にフルスタックのサイロモデルの延長線上に位置し、テナントのリソースを同じアカウント内にまとめるのではなく、アカウントレベルでさらに分離するアプローチです。最高レベルの分離とセキュリティを求めるケースや、法的・規制的要件が厳しい環境で特に価値を発揮します。
テナント毎のVPCモデル
単一のAWSアカウント内で、テナントごとに独立したVPCを構築するモデルです。このモデルは、ネットワークレベルの分離を実現しながら、アカウント管理の複雑さを軽減できる特徴を持ちます。
アーキテクチャ概要
テナント毎のVPCモデルでは、以下のような構成を取ります:
+-------------------+
| 管理VPC (共有) |
| |
| ・監視サービス |
| ・管理コンソール |
| ・デプロイツール |
+--------+----------+
|
| Transit Gateway
|
+----------------+ +---------+---------+ +----------------+
| テナントA VPC | | テナントB VPC | | テナントC VPC |
| | | | | |
| ・専用EC2 | | ・専用EC2 | | ・専用EC2 |
| ・専用RDS +--------+ ・専用RDS +--------+ ・専用RDS |
| ・専用S3バケット| | ・専用S3バケット | | ・専用S3バケット|
+----------------+ +------------------+ +----------------+
この図は、単一のAWSアカウント内で複数のテナント専用VPCを作成し、Transit Gatewayなどを使って相互接続する構成を示しています。各テナントは独自のVPC内に専用のコンピューティングリソース(EC2)やデータベース(RDS)、ストレージ(S3)を持ち、共有の管理VPCから一元的に管理・監視される構造になっています。
テナント毎のVPCモデルの特徴と実装
特徴と利点:
- ネットワークレベルの完全な分離を実現し、テナント間の通信を完全に制御できます
- セキュリティグループによる細かなアクセス制御が可能で、各テナントのセキュリティ要件に柔軟に対応できます
- テナントごとのネットワーク設定をカスタマイズできるため、特定のテナントの要件に合わせた最適化が可能です
- アカウント管理の複雑さを軽減しつつ、ネットワークレベルの分離を実現できる点が大きな利点です
実装上の注意点:
- VPCピアリングの管理は慎重に行う必要があります。特に、テナント間の通信が必要な場合、適切なルーティング設定が不可欠です
- ルートテーブルの設定は、各テナントのネットワーク要件に応じて最適化する必要があります
- セキュリティグループの設計は、最小権限の原則に基づいて行い、不要なアクセスを制限する必要があります
- ネットワークACLの設定は、VPCレベルでの追加のセキュリティレイヤーとして機能し、より細かなアクセス制御を実現します
実装パターン例
1. スターパターン(Transit Gateway中心)
+------------------+
| Transit Gateway |
+--------+---------+
|
+-------------------+|+-------------------+
| | |
+---------v---------+ +--------v---------+ +--------v---------+
| テナントA VPC | | テナントB VPC | | テナントC VPC |
| | | | | |
| アベイラビリティ | | アベイラビリティ | | アベイラビリティ |
| ゾーンA ゾーンB | | ゾーンA ゾーンB | | ゾーンA ゾーンB |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
| | EC2 | | EC2 | | | | EC2 | | EC2 | | | | EC2 | | EC2 | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
| | | | | | | | | | | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
| | RDS | | RDS | | | | RDS | | RDS | | | | RDS | | RDS | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
+-------------------+ +-------------------+ +-------------------+
このパターンでは、AWS Transit Gatewayをハブとして各テナントVPCをスポークとして接続します。中央集権的な接続管理が可能で、VPCピアリングの複雑さを軽減できます。
2. 共有サービスパターン
+-------------------+ +-------------------+
| 共有サービスVPC | | 管理VPC |
| | | |
| ・認証サービス +--------+ ・モニタリング |
| ・ログ集約 | | ・バックアップ |
| ・APIゲートウェイ | | ・デプロイツール |
+--------+----------+ +-------------------+
|
| VPCピアリング/Transit Gateway
|
+--------+---------+ +------------------+
| テナントA VPC | | テナントB VPC |
| | | |
| ・アプリケーション| | ・アプリケーション|
| ・データベース +----------+ ・データベース |
| ・専用ストレージ | | ・専用ストレージ |
+------------------+ +------------------+
このパターンでは、認証やログ集約などの共通サービスを専用VPCに配置し、各テナントVPCからアクセスする構成を取ります。共通機能の重複を避けつつ、テナント固有のリソースは分離を維持できます。
テナント毎のVPCモデルの選択基準
このモデルは以下のような状況に適しています:
- 中規模のSaaSサービス:テナント数が数十~数百程度で、各テナントに対する分離要件が高い場合
- 規制要件が中程度:完全なアカウント分離までは必要ないが、ネットワークレベルの分離が求められる場合
- 運用効率の最適化:単一アカウントでの管理効率を維持しつつ、高いセキュリティ分離を実現したい場合
- コスト効率の最適化:テナント毎のアカウントモデルよりコスト効率を高めたい場合
テナント毎のVPCモデルは、アカウントモデルとプールモデルの中間に位置し、分離性とコスト効率のバランスが取れたアプローチとして、多くのSaaSプロバイダーに採用されています。
フルスタックのプールモデル
リソースを共有しながら、テナントごとの分離を実現するモデルです。このモデルは、高いリソース効率と運用コストの削減を実現できる一方で、テナント間の分離を論理的に管理する必要があります。
フルスタックプールモデルの基本概念
フルスタックのプールモデルでは、インフラストラクチャからアプリケーションまで、すべてのリソースを複数のテナントで共有します。これにより、リソース利用効率の最大化とコスト削減が可能になりますが、テナント分離を確実に実装する必要があります。
+----------------------------------------+
| 共有インフラストラクチャ |
| |
| +----------------------------------+ |
| | 共有アプリケーション | |
| | | |
| | +------------------------+ | |
| | | テナントコンテキスト管理 | | |
| | +------------------------+ | |
| | | | |
| | +----------v------------+ | |
| | | リクエスト処理 | | |
| | | (テナントID解決) | | |
| | +----------+------------+ | |
| | | | |
| | +----------v------------+ | |
| | | テナント固有処理 | | |
| | | (データフィルタリング) | | |
| | +------------------------+ | |
| +----------------------------------+ |
| |
| +----------------------------------+ |
| | 共有データストア | |
| | (テナントIDによる論理分離) | |
| +----------------------------------+ |
+----------------------------------------+
この図は、共有インフラストラクチャ上に構築された共有アプリケーションがどのようにテナントコンテキストを管理し、各リクエストを適切に処理するかを示しています。
テナントコンテキストの管理
プール化されたリソースにおけるテナントコンテキスト管理は、このモデルの中心的な課題です。
テナントコンテキストの処理フロー:
- リクエスト受信: APIゲートウェイやロードバランサーがリクエストを受け取る
- テナント識別: リクエストヘッダー、JWT、URL、クエリパラメータなどからテナントIDを抽出
- コンテキスト生成: テナントIDを基に、権限、設定、リソース制限などを含むコンテキストを生成
- コンテキスト伝播: マイクロサービス間でテナントコンテキストを伝播(HTTPヘッダー、相関ID等)
- テナント固有処理: テナントコンテキストに基づいたデータアクセスやビジネスロジックの適用
サイロモデルでは、プロビジョニングとデプロイの段階でテナントコンテキストを設定できます。これは、デプロイ後にリソースを使用するテナントが変わることがないためです。一方、プールモデルでは各リクエスト処理時にテナントコンテキストを動的に判断する必要があります。
実装パターン
1. テナントIDベースのデータ分離パターン
+------------------+
| 共有データベース |
+------------------+
| テーブル |
+------------------+
| tenant_id | data |
|-----------|------|
| A | ... |
| B | ... |
| A | ... |
| C | ... |
+------------------+
このパターンでは、すべてのテナントデータを同じテーブルに格納し、各レコードにテナントIDを含めます。クエリにはテナントIDによるフィルタリング条件が常に含まれます。
2. ミドルウェアベースのコンテキスト伝播パターン
クライアント
|
| リクエスト (Header: X-Tenant-ID: A)
v
+---------------+
| APIゲートウェイ |
+---------------+
|
| コンテキスト抽出・検証
v
+---------------------------+
| テナントコンテキストミドルウェア |
+---------------------------+
|
| コンテキスト付与
v
+---------------+ +---------------+ +---------------+
| マイクロサービス1 | --> | マイクロサービス2 | --> | マイクロサービス3 |
+---------------+ +---------------+ +---------------+
このパターンでは、APIゲートウェイやミドルウェアがテナントコンテキストを抽出し、すべてのマイクロサービス間でコンテキストを伝播します。各サービスはこのコンテキストを使用してテナント固有のロジックやデータフィルタリングを適用します。
フォールトトレラント戦略
フルスタックのプールモデルを採用するチームは、マイクロサービスやコンポーネントが局所的な問題の影響範囲を限定できるようなフォールトトレラント戦略に重点を置きます。
主要なフォールトトレラント戦略:
-
サービスの分離:
- マイクロサービスアーキテクチャの採用により、障害の影響範囲を局所化できます
- サービス間の疎結合により、一つのサービスの障害が他に波及することを防ぎます
- 各サービスは独立してスケールと復旧が可能です
-
サーキットブレーカーパターン:
サービスA ---> [サーキットブレーカー] ---> サービスB | v フォールバック処理
- 依存サービスの障害を検出し、一時的に接続を遮断
- リクエストのタイムアウトやエラー率の閾値を設定
- 半開状態でのリトライによる自動復旧
- フォールバック処理の実装による代替応答
-
テナント分離の保証:
- テナントごとのリソース制限(レート制限、クォータ)
- リソース使用量の監視と自動スケーリング
- 単一テナントの過剰な負荷がシステム全体に影響しないよう保護
-
冗長設計:
クライアント | v +----------+ | ロードバランサー | +----------+ / \ / \
+—–+ +—–+
|複製1 | |複製2 |
+—–+ +—–+
| |
v v
+—–+ +—–+
| DB1 | | DB2 |
+—–+ +—–+
- サービスの複数インスタンス配置
- データベースのレプリケーション
- マルチリージョンデプロイメント
5. **監視と自動回復**:
- 包括的な監視とアラート
- ヘルスチェックによる問題検出
- 自動スケーリングによる負荷分散
- 自動再起動とフェイルオーバー
#### プールモデルの適用基準
フルスタックのプールモデルは以下のような状況に適しています:
1. **リソース効率が最優先**:
- スタートアップや予算制約のあるプロジェクト
- 利用率の変動が大きいワークロード
- コスト最適化が重要な市場セグメント
2. **大規模テナントベース**:
- 数百〜数千のテナントを持つSaaS
- SMB市場をターゲットとした低価格サービス
- コンシューマー向けアプリケーション
3. **標準化されたサービス**:
- カスタマイズが限定的なサービス
- セルフサービス型のオンボーディング
- 共通機能の共有が有益なケース
4. **迅速なスケーリング要件**:
- 急速な成長が予想されるビジネス
- 季節変動や需要変動への対応
- 弾力的なキャパシティ管理が必要な場合
#### 実装上の注意点
フルスタックのプールモデルを成功させるためには、以下の点に注意が必要です:
1. **セキュリティとデータ分離**:
- 徹底したアクセス制御メカニズム
- データ漏洩防止策の実装
- テナント間の分離テスト
2. **パフォーマンス管理**:
- ノイジーネイバー問題への対策
- リソース使用量の監視と制限
- スロットリングとレート制限の適用
3. **運用の複雑性**:
- 共有環境でのデバッグ難易度
- バージョン管理とアップグレード戦略
- 監視とトレーサビリティの確保
フルスタックのプールモデルは、適切に実装された場合、最もコスト効率が高く、スケーラブルなSaaSアーキテクチャとなりますが、テナント分離とセキュリティの確保には特に注意を払う必要があります。
### ノイジーネイバー
マルチテナント環境における「ノイジーネイバー問題」とは、特定のテナントが過剰にリソースを消費することで、同じインフラストラクチャを共有している他のテナントのパフォーマンスに悪影響を与える現象を指します。この問題はプール型のデプロイモデルにおいて特に顕著であり、SaaSプロバイダーにとって重要な課題となっています。
#### ノイジーネイバー問題の原因
ノイジーネイバー問題が発生する主な原因には以下のようなものがあります:
1. **リソースの過剰使用**
- CPU、メモリ、ネットワーク帯域幅などの共有リソースの過剰消費
- バースト的なトラフィックパターンや予測不能な使用パターン
- バックグラウンドジョブやETL処理などの重いワークロード
2. **アーキテクチャ上の制約**
- 適切なリソース分離メカニズムの欠如
- スケーリングポリシーの不備
- モニタリングとアラートの不足
3. **契約上の問題**
- SLA(サービスレベル合意)の曖昧さ
- 適切な使用制限の未設定
- 公平なリソース配分ポリシーの欠如
#### 対策と軽減策
ノイジーネイバー問題に対処するための主な戦略には以下のようなものがあります:
1. **リソース制限とクォータの設定**
+———————+
| テナントリソース制限 |
+———————+
| ・CPU: 最大60% |
| ・メモリ: 8GB |
| ・DB接続数: 100 |
| ・リクエスト/秒: 1000|
+———————+
- テナントごとにリソース上限を設定(CPU、メモリ、ディスクI/O、ネットワーク)
- レート制限やスロットリングの実装(API呼び出し回数、DB接続数など)
- 公平なスケジューリングアルゴリズムの採用
2. **動的リソース管理**
使用率モニタリング → 閾値超過検出 → 自動スケーリング/スロットリング → 通知
- リアルタイムモニタリングと自動スケーリング
- 予測型リソース割り当て(使用パターンの分析に基づく)
- ワークロードの優先順位付けと調整
3. **アーキテクチャレベルの対策**
+——————-+ +——————-+
| 高優先度テナント | | 標準テナント |
| リソースプール | | リソースプール |
+——————-+ +——————-+
| |
| |
+——————-+ +——————-+
| 専用/分離リソース | | 共有リソース |
+——————-+ +——————-+
- テナント間の物理的または論理的な分離の強化
- 重要なテナント向けの専用リソースの提供
- ハイブリッドデプロイモデルの採用(一部テナントをサイロ化)
4. **データベース特有の対策**
- 接続プーリングとコネクション制限
- クエリの最適化と実行計画の監視
- 読み取り専用レプリカの活用
- バックグラウンドジョブのスケジューリング最適化
5. **契約とコミュニケーション**
- 明確なSLAとリソース使用制限の設定
- 透明性のあるモニタリングダッシュボードの提供
- 使用パターンの異常に関する自動通知
- 使用量ベースの課金モデルの実装
#### テナントティアリングとノイジーネイバー
ノイジーネイバー問題への効果的なアプローチとして、テナントのティアリング(階層化)があります:
+————————+
| エンタープライズティア |
+————————+
| ・専用インスタンス |
| ・高いリソース上限 |
| ・優先的なサポート |
+————————+
↑
+————————+
| ビジネスティア |
+————————+
| ・部分的な分離 |
| ・中程度のリソース上限 |
| ・標準サポート |
+————————+
↑
+————————+
| スタンダードティア |
+————————+
| ・完全共有リソース |
| ・厳格なリソース上限 |
| ・セルフサービス |
+————————+
このような階層化により、より高いティアのテナントはノイジーネイバー問題の影響を受けにくくなります。また、使用パターンの異なるテナントを適切に分散配置することで、リソース使用の平準化を図ることも重要です。
#### 実装例:Kubernetes環境でのノイジーネイバー対策
Kubernetes環境では、以下のようなメカニズムを活用できます:
1. **Resource Quotas**:ネームスペースごとにCPU、メモリなどのリソース制限を設定
2. **Limit Ranges**:ポッド単位でのデフォルトのリソース制限を定義
3. **Pod Priority and Preemption**:優先度に基づくスケジューリングと割り込み
4. **Quality of Service (QoS) Classes**:Guaranteed、Burstable、BestEffortの各クラスによる優先度設定
5. **Pod Disruption Budgets**:サービス中断を制限するためのポリシー
#### モニタリングの重要性
ノイジーネイバー問題を効果的に管理するには、包括的なモニタリングが不可欠です:
+——————–+ +——————–+ +——————–+
| リソース使用状況 | | パフォーマンス指標 | | 異常検出 |
| モニタリング | | トラッキング | | アラート |
+——————–+ +——————–+ +——————–+
| ・CPU/メモリ使用率 | | ・レイテンシ | | ・閾値ベース |
| ・I/O操作 | | ・スループット | | ・異常パターン検出 |
| ・ネットワーク帯域 | | ・エラーレート | | ・予測モデル |
+——————–+ +——————–+ +——————–+
各テナントのリソース使用状況とパフォーマンス指標を常に監視し、異常があれば早期に検出・対応することが重要です。また、過去のデータを分析して将来のリソース要件を予測することも有効な戦略となります。
ノイジーネイバー問題は完全に排除することは難しいですが、適切なアーキテクチャ設計、リソース管理、モニタリング、そしてティアリング戦略を組み合わせることで、その影響を最小限に抑えることが可能です。
### サンプルアーキテクチャ
マルチテナントSaaSシステムの構築には様々なアプローチがありますが、ここでは3つの代表的なアーキテクチャパターンを紹介します。これらのサンプルは、異なる要件や制約に対応するための参考となるでしょう。
#### 1. フルスタック・プール型マイクロサービスアーキテクチャ
このアーキテクチャは、リソース効率と運用コストの最適化を重視したモデルです。すべてのテナントがインフラストラクチャリソースを共有し、テナント分離はアプリケーションレベルで実現します。
+-------------------+
| API Gateway |
| (テナントルーティング) |
+-------------------+
|
+----------------------------------+
| |
+------------------------+ +------------------------+
| 認証・認可サービス | | テナント管理サービス |
| (テナントコンテキスト) | | |
+------------------------+ +------------------------+
| |
+------------------------+ +------------------------+
| ビジネスサービス群 | | データサービス群 |
| (マイクロサービス) | | (データアクセス層) |
+------------------------+ +------------------------+
|
+-------------------+
| 共有データストア |
| (論理的分離) |
+-------------------+
**特徴:**
- API Gatewayがテナント識別とルーティングを担当
- すべてのサービスは共有インフラストラクチャ上で動作
- データストアは論理的な分離(テナントIDによるフィルタリング)
- スケーラビリティ重視の水平分散アーキテクチャ
- Kubernetes, AWS ECS, Azure Container Instancesなどで実装可能
**適用シナリオ:**
- 数百〜数千の中小規模テナントを持つSaaS
- コスト効率が重要な市場セグメント
- データ分離要件が比較的緩やかなケース
#### 2. ハイブリッドサイロ型アーキテクチャ
このアーキテクチャは、データプライバシーと分離の要件が高いながらも、運用効率を維持したい場合に適しています。コンピューティングリソースは共有しつつ、データストアはテナントごとに分離する方式です。
+------------------------+
| 統合管理コンソール |
| (コントロールプレーン) |
+------------------------+
|
+------------------------+
| API Gateway |
| (テナントルーティング) |
+------------------------+
|
+--------------------------------------------------+
| |
+—————-+ +—————-+ +—————-+
| マイクロサービス | | マイクロサービス | | マイクロサービス |
| クラスタ | | クラスタ | | クラスタ |
+—————-+ +—————-+ +—————-+
| | |
+—————-+ +—————-+ +—————-+
| テナントA DB | | テナントB DB | | テナントC DB |
| (専用DB) | | (専用DB) | | (専用DB) |
+—————-+ +—————-+ +—————-+
**特徴:**
- アプリケーションサービスは共有リソース上で動作
- データベースはテナントごとに専用インスタンス
- コントロールプレーンで一元管理
- 自動プロビジョニングと監視機能
- AWS RDS, Azure SQL, GCP Cloud SQLなどで専用DBを実装
**適用シナリオ:**
- データプライバシーとセキュリティが重要な業界(金融、医療など)
- 異なる地域のデータ主権要件に対応する必要がある場合
- テナントごとのデータカスタマイズ要件が高いケース
#### 3. エンタープライズ向けマルチアカウントアーキテクチャ
このアーキテクチャは、最大限の分離と専用リソースを提供する必要がある場合に適しています。各テナントに専用のクラウドアカウント(またはVPC)を割り当て、完全な分離を実現します。
+-------------------------------+
| 中央管理アカウント |
| (IAM, 監視, デプロイパイプライン) |
+-------------------------------+
|
+--------------------------------------------------+
| | |
+—————-+ +—————-+ +—————-+
| テナントA アカウント | | テナントB アカウント | | テナントC アカウント |
+—————-+ +—————-+ +—————-+
| | |
+—————-+ +—————-+ +—————-+
| アプリケーション | | アプリケーション | | アプリケーション |
| スタック | | スタック | | スタック |
+—————-+ +—————-+ +—————-+
| | |
+—————-+ +—————-+ +—————-+
| データストア | | データストア | | データストア |
| (専用) | | (専用) | | (専用) |
+—————-+ +—————-+ +—————-+
**特徴:**
- テナントごとに独立したクラウドアカウントまたはVPC
- 完全な物理的/論理的分離
- 中央管理アカウントからの統一的な管理
- IaC(Infrastructure as Code)による自動プロビジョニング
- AWS Organizations, Azure Management Groups, GCP Foldersなどで実装
**適用シナリオ:**
- エンタープライズ向け高額SaaS
- 規制要件の厳しい業界(政府、防衛、医療など)
- テナントごとのカスタマイズ要件が非常に高いケース
- ノイジーネイバー問題を完全に排除したいケース
#### 4. サーバーレス・マイクロサービスアーキテクチャ
このアーキテクチャは、運用オーバーヘッドの最小化とコスト効率を重視したモデルです。サーバーレス技術を活用してインフラストラクチャの管理を不要にし、従量課金モデルを最大限に活用します。
+------------------------+
| CDN / フロントエンド |
+------------------------+
|
+------------------------+
| API Gateway |
| (テナントルーティング) |
+------------------------+
|
+--------------------------------------------------+
| | | |
+————+ +————+ +————+ +————+
| Lambda関数 | | Lambda関数 | | Lambda関数 | | Lambda関数 |
| (サービスA) | | (サービスB) | | (サービスC) | | (サービスD) |
+————+ +————+ +————+ +————+
| | | |
+————+ +————+ +————+ +————+
| DynamoDB | | Aurora | | Elasticsearch | | S3バケット |
| テーブル | | Serverless | | ドメイン | | |
+————+ +————+ +————+ +————+
**特徴:**
- インフラストラクチャ管理が不要
- 使用量に応じた自動スケーリング
- イベント駆動型アーキテクチャ
- 従量課金モデルでコスト効率が高い
- AWS Lambda + DynamoDB, Azure Functions + Cosmos DB, GCP Cloud Functions + Firestoreなどで実装
**適用シナリオ:**
- 変動するワークロードを持つSaaS
- インフラストラクチャ管理の人的リソースが限られているスタートアップ
- 迅速な市場投入と実験が必要なケース
#### 5. コンテナベース・ポッドアーキテクチャ
このアーキテクチャは、テナントの分離とリソース共有のバランスを取りたい場合に適しています。テナントをグループ(ポッド)に分割し、各ポッドに適切なリソースを割り当てます。
+------------------------+
| マルチテナント管理層 |
| (プロビジョニング/監視) |
+------------------------+
|
+--------------------------------------------------+
| | |
+—————-+ +—————-+ +—————-+
| ポッド1 | | ポッド2 | | ポッド3 |
| (テナントグループA) | | (テナントグループB) | | (テナントグループC) |
+—————-+ +—————-+ +—————-+
| | |
+—————-+ +—————-+ +—————-+
| アプリケーション | | アプリケーション | | アプリケーション |
| スタック | | スタック | | スタック |
+—————-+ +—————-+ +—————-+
| | |
+—————-+ +—————-+ +—————-+
| データストア | | データストア | | データストア |
| (ポッド共有) | | (ポッド共有) | | (ポッド共有) |
+—————-+ +—————-+ +—————-+
**特徴:**
- テナントを類似した特性や要件に基づいてグループ化
- ポッドごとに適切なリソース割り当て
- ポッド内ではリソースを共有
- ポッド間は分離
- 段階的なスケーリングとアップグレードが可能
- Kubernetes, OpenShift, Anthos, EKSなどで実装可能
**適用シナリオ:**
- テナント数とリソース要件が成長しているSaaS
- テナントの特性や要件に多様性がある場合
- ノイジーネイバー問題の影響を制限したいケース
- 地域やティアに基づいてテナントを分割したいケース
これらのアーキテクチャパターンは、単独で使用することも、ハイブリッドで組み合わせることも可能です。実際のSaaSシステム設計では、ビジネス要件、技術的制約、運用モデル、そしてスケーリング戦略に基づいて、最適なアーキテクチャを選択または組み合わせることが重要です。また、SaaSシステムは時間と共に進化するため、将来の変更に対応できる柔軟性も考慮すべき重要な要素です。
### ポッドのデプロイモデル
デプロイの選択肢は、アプリケーションをどこに配置するのか、環境上の制約にどう対処するのか、SaaSビジネスの規模や顧客層に合わせてどう変化させる必要があるのか、よって決まる。
ポッドモデルは、ティアリングにおいて、テナントが別プランへ切り替える時の柔軟性を持たせることができる一方で、テナントの稼働率とインフラストラクチャリソースの最適化を最大限に実現できない可能性がある。
## SaaS詳細編
### 4章 オンボーディングとアイデンティティ
コントロールプレーンを稼働させるための基本事項
SaaS環境を稼働するために必要なすべての構造を即座に起動できるスクリプトと自動化を作成することが必要。これは、ベースライン環境という。
* 管理コンソールの実装
* テナントのティアリング
* 認証方法
* ポリシーの管理方法
* 分離の構成方法
* ルーティング方法
タイムトゥバリューとは、顧客がサインアップしてからSaaS製品の実際の生産性と価値を実感するまでに要する時間を指す。
オンボーディングはサービス体験の一部なので、まずはオンボーディング、テナントを作ることを優先しないと後で困る。なぜか。
オンボーディングを構成する要素は以下の通り。
* デプロイ
* アイデンティティ
* ルーティング
* ティアリング戦略
まず、テナントの識別子をさくせいする
ティアベースのオンボーディング
継続的にデプロイを成功させるためには、各リソースを追跡する必要がある。例えば、テナント1とテナント2のプレミアムティアのサイロと、その他のテナントと共有されているベーシックティアのプール化されたインスタンスに、注文サービスを同時にデプロイするケース。どうやるか。
オンボーディング体験で、各テナントのリソースの配置場所とアイデンティティを収集し、記録することで対処する。詳しくはEKS SaaSとサーバーレスSaaSの章で話してくれるらしい。
オンボーディングプロセスで何らかの障害が発生した場合。例えばテナントを登録した時に請求情報を請求プロバイダーへリクエストするとする。一連の請求作成リクエストを一つのトランザクションで完結させないで、非同期な処理、例えば非同期キューを導入する。そうすれば、一部のステップ(今回は請求作成)が障害で失敗したとしても、オンボーディングプロセスを阻害せずに済む。請求サービスは失敗を検知して再施行するだけ。
SaaSアイデンティティの作成
テナントは一般的に組織や企業であることが多い。そのため、従業員もSaaSへ登録される。従業員がどのテナントに所属しているのか、をオンボーディングのときに作成する。その際、OAuthとOpen ID Connectの仕様に準拠するSaaSが多い。
一般的に、OIDC準拠のアイデンティティプロバイダーに対して認証を行うと、認証のたびにアイデンティティートークンとアクセストークンが返される。これらが、後続の認可に使用されるすべての認証コンテキストを保持するJWTとして定義される。


1. ユーザーがWebアプリケーションのログイン画面で認証リクエストをする。
2. Webアプリケーションがアイデンティティプロバイダーへ認証リクエストを送る
3. アイデンティティプロバイダーが標準トークン(JWTトークン)を返す
4. バックエンドサービスへJWTをBearerトークンとしたリクエストが送信される
カスタムトークン
もう一つ、ログイン時にアイデンティティプロバイダーからテナントコンテキストなしのJWTを受け取り、初回にリクエストしたマイクロサービスがテナントマッピングシステムへJWTを投げて、tenantIdを使い回すという方法もある。が、この方法を採用すると、毎回テナントマッピングシステムを経由する必要があり、テナントが増えるにつれてビジネス価値とは関係のないテナントマッピングシステムの最適化業務が発生する将来が見えているため、あまりおすすめではないとのこと。
フェデレーションSaasアイデンティティ
SaaSを導入する顧客が、社内アイデンティティプロバイダーベンダーに業務上依存している場合、SaaS管理下にある単一のIDPのみでは認証を賄いきれない。
### 5章 テナント管理
テナント管理サービスがコントロールプレーン体験にどのように組み込まれるのかを見ていく。テナントのライフサイクルの管理をどのように設計するか、という側面が大事になってくる。
**テナント管理の基礎**
* コアテナント属性
テナント識別子、状態(有効,無効)、ティア、会社名、アカウント開設状況、最終ログイン日など
* テナントアイデンティティ構成
テナント認証情報。MFA、パスワードポリシー、アイデンティティプロバイダーの割り当て、他のアイデンティティ関連の設定。URLも含む。
テナントルーティング構成
* インフラストラクチャ構成
**テナントライフサイクルの管理**
* テナントの有効化/無効化
テナントが無効化された時、そのテナントがシステムにアクセスできないように制御する方法を検討したりする。例えば、請求が未払いの時、請求の問題がg解決されるまでの間、どのような方針を取るかがある。一定期間はテナントへメールを送り、ある期間で無効化させるとかが考えられる。
一番理想的なのは、テナントが無効化された時に、請求プロバイダーがイベントを生成すること。そうでないと、テナントの状態変化を定期的に監視する何らかのプロセスを立ち上げないといけなくなる。つまり、未払いイベントを請求プロバイダーが生成し、請求システムへ通知する。請求システムがトリガーされて、テナント管理サービスを呼び出し、テナントの無効化をリクエストする。サービスはテナントの状態を非アクティブに更新し、テンアントに関連する全てのユーザーの認証を拒否することで無効化を実現することができる。
ユーザー一人ひとりのステータスを非アクティブに更新することは大変なので、ユーザーグループを設けて、そこを非アクティブにするのが、大抵の場合は効率とされている。
現在ログインしているユーザーに対してどう対処するのか。アクティブなセッションを全て終了できるようにする、という方法が一般的に好まれている。
重要なのは、テナントの状態はテナント管理サービスによって一元管理されなければないらないということ。SSoTとしてみなし、状態の変化による影響をシステム内の関連する要素と確実に確実に同期する事が大事。
* テナントの廃止
アーカイブするか、完全に削除するかは、バランス感覚に委ねられる。ビジネス、コスト、複雑性のトレードオフになる。
完全廃止する場合、システム管理者からの廃止リクエストをトリガーとして、請求情報、その他リソースを削除する。この際、ストレージがプール化されている場合、他のテナントと一緒に保存されているデータを特定し、選択的に削除できる必要がある。各種テーブルにはテナントのGUIDが振ってあり、それぞれのテーブルに存在するレコードを漏れなく消す作業は、大変。一般的に、負荷の低い非同期プロセスとして実行できればテナントへの影響を抑える事ができる。
**テナントのティアの切り替え**
ティアごとにどのような機能を分けているのかに応じて、複雑になる事がある。ティア毎の違いがスループットと機能だけの場合、機能フラグと、スロットリングポリシーを設定するだけで済む。テナント
これで、テナントの表示と管理に必要な要素がすべて出揃った。
## 6章 テナントの認証とルーティング
マルチテナント環境のしょうめんげんかんをつくる。いずれのテナント認証方法を採用したとしても、最終的にはアイデンティティプロバイダーがサポートするOAuthとOIDCの仕様に準拠することになるが、マルチテナント環境における全体的なアイデンティティのスキーマにテナントがどのように割り当てられるかによって、フローへの取り組み方が変わる。
* ドメインでテナントを識別するケース

* テナント毎のサブドメインモデル
* テナント毎のバニティドメインモデル
> バニティドメインとは、個人、ブランド、または特定の目的を表現するために特別にカスタマイズされたウェブアドレスを指します
[https://www.vpnunlimited.com/jp/help/cybersecurity/vanity-domain?srsltid=AfmBOooN9IML2Ek1\_cztppnxJeF1twHSJxa-f2KG6Awrt07SKsrV8rRK](https://www.vpnunlimited.com/jp/help/cybersecurity/vanity-domain?srsltid=AfmBOooN9IML2Ek1_cztppnxJeF1twHSJxa-f2KG6Awrt07SKsrV8rRK)
**認証フロー**
共通のドメインを用意して、テナントの識別をコントロールプレーン内に置いたIdPで行うアーキテクチャもある。このアーキテクチャは、個々のテナントに対して固有のアイデンティティ構造を用意できる。認証フローにおけるテナントコンテキストを解決する方法、ユーザーのメールアドレスのドメインを使用する方法があるが、ユーザーがさまざまなメアドのドメインを持つ場合に困る。
DBレベルで識別する方法もある。メアドとtenantIdを1レコード内に管理する。
**典型的な認証フロー**
step1 テナントユーザーがW ebアプリケーションはアクセス
2 認証してもらうためにIdPへ転送される
3 ユーザーが認証に成功すると、IdPは認証と認可の情報を提供するトークンを返す
4 IdPは認証済みのユーザーとしてWebアプリケーションに再アクセスさせる。
5 この認証コンテキストを使用して、1つまたは複数の後続マイクロサービスを呼び出す
* SaaSにおける認証フローに間接層を入れる

* フェデレーション認証
アイデンティティの情報が広範囲に分散された時に複雑なフェデレーション認証内容になる。
* 認証済みテナントのルーティング

**サーバレスのテナントルーティング**

メリット
デメリット
対応策
**コンテナのテナントルーティング**

メリット
デメリット
対応策
### 第7章 マルチテナントサービスの構築
これまではコントロールプレーンについて見てきたから、今回からはアプリケーションプレーンを深掘りしていく。
**従来のサービス**
従来のアプリケーションは、すべての動作環境が個別にインストール、デプロイ、管理されている。よって、サービス全体が完全に個々のこきゃくせんよつになっている。最重要要件は、単一の顧客が要求する拡張性、パフォーマンス、および耐障害性の要件を満たすことができるサービス群を用意すること。
**プール型マルチテナント環境**
[]()
サイロ化されたサービスとプール化されたサービスをどう混在させるかが焦点になる。できるだけプール化させると、複雑度が緩和される。
コンピューティング技術の影響
* コンテナ
デプロイの単位はコンテナ。
* サーバレス
デプロイの単位は各サービス。きめ細やかなリソース配分ができる。
ストレージに関する考慮事項
顧客が共有ストレージのリソースを取り合う場合、ある顧客が数100万クエリを単一インスタンスへ発行した場合、ノイジーネイバー問題が発生するかもしれない。
メトリクスを用いた設計の分析

データ分割とアクセスに使用する戦略と、テナント分離を実現するために使用する戦略の間には、明確な線を引くことが重要。
### 第8章 データパーティショニング
プールデータパーティショニング戦略と、サイロデータパーティショニング戦略について検討していく。
検討項目
マルチテナントのモデルで各ストレージ体験がどのように機能するか、が大事
**Blast Radius:**
障害やセキュリティインシデントから生じる可能性のある損害や影響の範囲
分離とはデータの保存方法を超えた強制力のあるレイヤーを意味する。そのため、データがサイロ化されているかプール化されているかに関わらず、データへのアクセスを制限し、その範囲を設定する。
一般的にどのデータパーティショニングモデルが特定のワークロードに適しているかわからないときは、プールモデルをデフォルトにするといい。
**ライトサイジングの課題**
時間帯によってでコンピューティングの利用量は変わる。適したサイズかどうかを判断するための変数が、どちらを選ぶかによって変わる。
対策としていくつか考えられる
スロットリングとスループット戦略を取る。
サーバレスストレージ戦略を取る。
### 第12章 EKS SaaS
kubernatesとは
EKSが出来ること

[https://youtu.be/E5TEqZhS0D0?feature=shared](https://youtu.be/E5TEqZhS0D0?feature=shared)
### 生成AIとマルチテナント
SaaSアプリケーション(テナント)
注入されたコンテキスト(RAG)
基礎モデルのカスタマイズ(ファインチューニング)
生成AIサービス(Bedrock, OpenAI)
モデル(LLM)

やはり、SaaSプロダクトにLLMを組み込む場合、どのテナントによるリクエストなのかを識別し、テナントに合わせたコンテキストを元にレスポンスを作成すること、が論点になってくる。
生成AIアーキテクチャにおいて、この構成をどのように作成し、分離、表現、そしてルーティングするか、を決めることが大事。
各テナントのドメインに応じた生成AI体験に固有のリファインメントを入れること。
覚えておくべきことは、生成AI体験の可能性が広いということ。
LLMをテナントコンテキストで強化する方法がある一方で、AI/MLモデルを個別のテナントごとに持つ、というアイデアもある。
**テナント固有のリファインメントの導入**
* RAG

LLMの外部でリクエストを前処理する。
* ファインチューニング
LLMの動作を変更する。新しいコンテキストデータを用いて環境をトレーニングする。(PEFT)

個別テナントに適用するトレーニングか、すべてのテナントに適用する汎用的なトレーニングか。

### 生成AIがマルチテナントアーキテクチャ全体に新たな特性をもたらす可能性のある分野
* オンボーディング

* ノイジーネイバー
多くのシナリオでは、過剰なトラフィックを発生させているテナントをノイジーネイバーと見なしている。
生成AIのワークロードでは、トークンの数ゆ個々のリクエストの複雑性を評価できる構成を導入する必要がある。たとえば、生成AIサービスが含まれているプランを選択したテナントにSLAを提供するなど。
SLAを設定するということは、データの可視化が必須化されるということになる。
* テナント分離
マルチテナント環境にデータを追加するときは、データをテナント間のアクセスから保護する方法をかんがえなきゃいけない。
