ソリューション内でテナントをどのように取り扱うかについては、多くの方法が考えられます。 アプローチは、テナント間でリソースを共有するかどうかと共有する方法によって異なります。 直感的に言えば、リソースの共有を避けたいと思うかもしれませんが、ビジネスの規模が拡大し、テナントを増やすと、そのアプローチはすぐに高価になります。
マルチテナントのさまざまなモデルを検討するときは、まず、組織のテナントを定義する方法、ビジネス ドライバーの概要、ソリューションのスケーリング方法を検討することをお勧めします。 この記事では、技術的な意思決定者がテナント モデルとそのトレードオフを評価するのに役立つガイダンスを提供します。
テナントを定義する
まず、組織の テナント を定義する必要があります。 顧客が誰であるか、サービスを受け取るユーザーを検討します。 次の 2 つの一般的なモデルがあります。
企業間 (B2B): 顧客が他の組織である場合は、テナントをそれらの顧客にマップする可能性があります。 ただし、顧客がチームや部門などの部門を持っているかどうか、また、顧客が複数の国や地域にプレゼンスを持っているかどうかを検討します。 これらのサブグループに対して異なる要件がある場合は、単一の顧客を複数のテナントにマップする必要がある場合があります。 同様に、顧客は、開発環境と運用環境を互いに分離し続けることができるように、サービスの 2 つのインスタンスを維持したい場合があります。 通常、1 つのテナントには複数のユーザーがいます。 たとえば、顧客のすべての従業員は、単一のテナント内のユーザーになります。
企業間 (B2C): 顧客がコンシューマーである場合、多くの場合、顧客、テナント、ユーザーを関連付ける方が複雑になります。 シナリオによっては、各消費者が個別のテナントになる場合もあります。 ただし、ソリューションを使用するのが家族、友人のグループ、クラブ、団体、またはデータに共同でアクセスして管理する必要があるその他のグループであるかどうかを考慮してください。 たとえば、音楽ストリーミング サービスで個人のユーザーと家族の両方をサポートし、それらを別々のテナントに分離する場合は、各アカウントの種類をそれぞれ異なる方法で扱うかもしれません。
お客様の "テナント" の定義は、ソリューションを設計する際に、考慮または重視する必要があるいくつかの点に影響します。 たとえば、次の種類のテナントについて考えてみます。
テナントが個人または家族である場合は、個人データの処理方法と、サービスを提供する各管轄区域のデータ主権法について検討する必要があります。
テナントが企業の場合は、規制コンプライアンスとデータの分離に関する顧客の要件に留意する必要がある場合があります。 アップタイムやサービスの可用性など、指定されたサービス レベル目標 (SLO) を満たしていることを確認します。
使用するモデルを決定する
テナント モデルの選択は、技術的な決定だけではありません。 これは商業上の決定でもあります。 次の質問を検討する必要があります。
ビジネス目標: 各テナントのコストを削減するか、テナントエクスペリエンスを最大化するかは、戦略的な目標に合わせて調整するかを検討します。
コンプライアンス： 顧客があらゆる形式のマルチテナントを受け入れるかどうかを検討します。 各マルチテナント モデルは、コンプライアンス要件や顧客のコンプライアンス要件にどのように影響しますか?
規模： シングルテナント ソリューションが将来の成長の願望に合わせてスケーリングできるかどうかを検討します。
オートメーション： 運用チームの規模と、自動化できるインフラストラクチャ管理の量を検討します。
サービス レベル アグリーメント (SLA): 顧客が SLA を満たすことを期待しているかどうか、またはターゲットとする SLA があるかどうかを検討します。
多数の顧客に合わせて事業を拡大することが予想される場合は、共有インフラストラクチャをデプロイすることが重要になります。 それ以外の場合は、増え続ける大規模なリソース インスタンスを維持する必要があります。 テナントごとに専用のサブスクリプションをプロビジョニングして使用しない限り、顧客ごとに個々の Azure リソースをデプロイすることは持続できない可能性があります。 複数のテナントで同じ Azure サブスクリプションを共有すると、 Azure リソースのクォータと制限 が適用される可能性があり、これらのリソースをデプロイおよび再構成するための運用コストは、新しい顧客ごとに増加します。
逆に、事業の顧客が少数になることが予想される場合は、各顧客専用のシングルテナント リソースを使用することを検討した方がよい場愛もあります。 また、顧客の分離要件が高い場合は、コストは余計にかかりますが、シングルテナント インフラストラクチャのアプローチが適している可能性があります。
テナントとデプロイ
次に、論理テナントとデプロイを区別する必要があるかどうかを判断する必要があります。
例として、音楽ストリーミング サービスについて考えてみます。 最初は、数千人または数万人のユーザーを簡単に処理できるソリューションを構築できます。 ただし、組織の成長が続く中で、新しい顧客の需要に合わせてスケーリングするには、ソリューションまたはそのコンポーネントの一部を複製する必要がある場合があります。 このタスクを実行するには、ソリューションの特定のインスタンスに特定の顧客を割り当てる方法を決定する必要があります。 顧客をランダムに、地理的に割り当てるか、1 つのインスタンスをいっぱいにしてから、別のインスタンス ( ビンパッキングとも呼ばれます) を開始することで割り当てることができます。 ただし、トラフィックを適切な場所にルーティングできるように、顧客とデータとアプリケーションが存在するインフラストラクチャの記録を保持する必要がある可能性があります。 この例では、各顧客を個別のテナントとして表し、データを含むデプロイにユーザーをマップします。 この方法では、テナントとデプロイの間に一対多のリレーションシップが作成され、独自の判断でデプロイ間でテナントを移動できます。
これに対し、法律事務所向けのクラウド ソフトウェアを作成する会社について考えてみます。 顧客は、規制要件へのコンプライアンスを維持するために、独自の専用インフラストラクチャを必要とする可能性があります。 そのため、ソリューションの多数の異なるインスタンスをデプロイして管理する準備を最初から行う必要があります。 この例では、デプロイには常に 1 つのテナントを格納し、テナントはその専用のデプロイにマップされます。
テナントとデプロイの主な違いは、分離の適用方法にあります。 複数のテナントで 1 つのデプロイ (インフラストラクチャのセット) を共有するときには、通常、アプリケーション コードとデータベース内のテナント識別子に依存して各テナントのデータを分離します。 テナントに独自の専用デプロイがある場合、テナントには独自のインフラストラクチャがあるため、コードがマルチテナント環境を考慮することはあまり重要でない場合があります。
デプロイは、スーパーテナントまたはスタンプと呼ばれることがあります。
特定のテナントに対する要求を受け取ったら、次の図に示すように、そのテナントのデータを保持するデプロイにマップする必要があります。
詳細については、「要求をテナントにマップする」を参照してください。
テナントの分離
マルチテナント アーキテクチャ設計における最大の考慮事項の 1 つは、各テナントに必要な分離レベルです。 分離は、次の構成を参照できます。
アプリケーションの個別のインスタンスとテナントごとに個別のデータベースを含む単一の共有インフラストラクチャを持つ。
一部の一般的なリソースを共有しつつ、その他のリソースをテナントごとに分離すること。
個別の物理インフラストラクチャにデータを保持すること。 クラウドでは、この構成ではテナントごとに個別の Azure リソースが必要になる場合があります。 極端なシナリオでは、 専用ホストを使用して個別の物理インフラストラクチャをデプロイする必要がある場合もあります。
分離を個別のプロパティとして表示する代わりに、スペクトルと見なします。 要件に応じて、同じアーキテクチャ内の他のコンポーネントよりも分離された、または分離が少ないアーキテクチャのコンポーネントをデプロイできます。 次の図は、分離の連続性を示しています。
分離のレベルは、アーキテクチャの多くの側面に影響します。
安全： 複数のテナント間でインフラストラクチャを共有する場合は、応答を別のテナントに返すときに、あるテナントのデータにアクセスしないように注意してください。 ID 戦略の強力な基盤が必要であり、認可プロセス内でテナントとユーザー ID の両方を考慮する必要があります。
費用： 複数のテナントで共有インフラストラクチャを使用できるため、コストが低くなります。
パフォーマンス： インフラストラクチャを共有すると、リソースの消費が速くなる可能性があるため、システムのパフォーマンスが低下する可能性があります。 通常とは異なる使用パターンを持つテナントは、パフォーマンスの問題を悪化させる可能性があります。
確実： 1 つの共有インフラストラクチャ セットを使用する場合、1 つのコンポーネントに問題が発生すると、すべてのテナントが停止する可能性があります。
個々のテナントのニーズに対する応答性: 1 つのテナント専用のインフラストラクチャをデプロイすると、リソースの構成をその特定のテナントの要件に合わせて調整できる場合があります。 また、この機能を価格モデルで検討して、顧客が分離デプロイに対してより多くの料金を支払えるようにすることもできます。
ソリューション アーキテクチャは、分離のために使用できるオプションに影響を与える可能性があります。 たとえば、次の 3 層ソリューション アーキテクチャを考えてみましょう。
ユーザー インターフェイス層は、共有マルチテナント Web アプリである可能性があります。 すべてのテナントが 1 つのホスト名にアクセスします。
中間層は、共有メッセージ キューを持つ共有アプリケーション層にすることができます。
データ層は、分離されたデータベース、テーブル、または BLOB コンテナーにすることができます。
階層ごとに異なるレベルの分離を使用できます。 共有する内容と、コスト、複雑さ、顧客の要件、Azure のクォータと制限に達する前にデプロイできるリソースの数など、いくつかの要因に基づいて何を分離するかを決定する必要があります。
一般的なテナント モデル
要件を確立したら、いくつかの一般的なテナント モデルと対応するデプロイ パターンに対してそれらを評価しましょう。
自動シングルテナント デプロイ
自動シングルテナント デプロイ モデルでは、次の例に示すように、テナントごとに専用のインフラストラクチャ セットをデプロイします。
アプリケーションは、各テナントのリソースのデプロイを開始および調整する役割を担います。 通常、このモデルを使用するソリューションでは、コードとしてのインフラストラクチャまたは Azure Resource Manager API が広範囲に使用されます。 この方法は、顧客ごとに完全に個別のインフラストラクチャをプロビジョニングする必要があるときに使用できます。 デプロイを計画するときは、 デプロイ スタンプ パターン の使用を検討してください。
利点: この方法の主な利点は、各テナントのデータが分離されることです。これにより、偶発的な漏洩のリスクが軽減されます。 このセーフガードは、規制コンプライアンスのオーバーヘッドが高い顧客にとって重要な場合があります。 また、テナントは、 ノイズの多い近隣 の問題とも呼ばれる、お互いのシステム パフォーマンスに影響を与える可能性はほとんどありません。 更新と変更はテナント間で徐々にロールアウトすることができるため、システム全体の障害が発生する可能性が減ります。
リスク： この方法を使用すると、テナント間でインフラストラクチャを共有しないため、コスト効率が低くなります。 1 つのテナントに特定のインフラストラクチャ コストが必要な場合、100 テナントでは、そのコストの 100 倍が必要な可能性があります。 また、新しい構成やソフトウェア更新プログラムの適用など、継続的なメンテナンスには時間がかかる場合があります。 運用プロセスを自動化することと、環境全体で変更を段階的に適用することを検討してください。 また、フリート全体でのレポートや分析など、他のデプロイ間操作についても検討する必要があります。 複数のデプロイにわたってデータのクエリと操作を行う方法を計画します。
完全なマルチテナント デプロイ
逆に、すべてのコンポーネントが共有される完全にマルチテナントデプロイを検討できます。 次の図に示すように、デプロイして維持するインフラストラクチャ セットは 1 つだけであり、すべてのテナントでこれを使用します。
利点： このモデルは、共有コンポーネントを含むソリューションを運用する方が、テナントごとに個々のリソースを使用するよりもコストが低いため、魅力的です。 増加した負荷に対応するために、より高いレベルまたは SKU のリソースをデプロイする必要がある場合でも、全体的なデプロイ コストは多くの場合、シングルテナント リソースのセットのコストよりも少なくなります。 また、ユーザーまたはテナントがデータを別のテナントに移動する必要がある場合は、テナント識別子とキーを更新でき、2 つの個別のデプロイ間でデータを移行する必要がない場合があります。
リスク:
テナントごとにデータを分離し、テナント間でデータが漏洩しないようにしてください。 シャーディング データの管理が必要になる場合があります。 また、個々のテナントがシステム全体に与える影響を考慮する必要がある場合もあります。 たとえば、大規模なテナントで高負荷のクエリまたは操作を実行しようとした場合、他のテナントに影響する可能性があります。
この情報が重要な場合は、 Azure のコストを追跡してテナントに関連付ける方法を決定します。
1 セットのリソースを更新するだけで済むため、1 つのデプロイを使用してメンテナンスを簡略化できます。 ただし、多くの場合、変更が顧客ベース全体に影響を与える可能性があるため、リスクが高まります。
スケールを検討する必要が生じることもあります。 インフラストラクチャのセットを共有している場合は、Azure リソースのスケールの上限に到達する可能性が高くなります。 たとえば、ソリューションの一部としてストレージ アカウントを使用する場合、スケールが増加すると、そのストレージ アカウントに対する要求の数が、ストレージ アカウントで処理できる上限に達する可能性があります。 リソース クォータの制限に達しないように、複数の AKS クラスターやストレージ アカウントなど、リソースの複数のインスタンスのプールをデプロイできます。 また、複数の Azure サブスクリプションにデプロイしたリソース間にテナントを分散したりすることも検討できます。
1 つのデプロイをスケーリングできる距離には制限があり、スケーリングのコストが非線形に増加する可能性があります。 たとえば、大規模に実行する共有データベースが 1 つある場合は、そのスループットを使い果たし、需要に対応するためにスループットを向上させるために、より多くの料金を支払う必要があります。
垂直方向にパーティション分割されたデプロイ
このようなスケールの極端な状態のいずれかを選ぶ必要はありません。 代わりに、次のアプローチを使用してテナントを垂直方向にパーティション分割できます。
シングルテナント デプロイとマルチテナント デプロイを組み合わせて使用します。 たとえば、顧客のデータ層とアプリケーション層のほとんどがマルチテナント インフラストラクチャに配置されているが、より高いパフォーマンスまたはデータ分離を必要とする顧客向けにシングルテナント インフラストラクチャをデプロイする場合があります。
ソリューションの複数のインスタンスを地理的にデプロイし、各テナントを特定のデプロイにマップします。 この方法は、異なる地域にテナントがある場合に有効です。
次の例は、一部のテナント用の共有デプロイと、その他のテナント用のシングルテナント デプロイを示しています。
利点： インフラストラクチャの一部を引き続き共有するため、共有マルチテナント デプロイを使用する場合のコスト上の利点の一部を得ることができます。 試用版を使用してサービスを評価している顧客のように、特定の顧客に対して低コストの共有リソースをデプロイできます。 シングルテナントデプロイを使用するために顧客に高い料金を請求することもできます。これは、コストの一部を回復するのに役立ちます。
リスク: コードベースは、マルチテナント デプロイとシングルテナント デプロイの両方をサポートするように設計する必要があります。 デプロイ間の移行を許可することを計画している場合は、顧客をマルチテナント デプロイから独自のシングルテナント デプロイに移行する方法を検討する必要があります。 また、システムの問題やアップグレードに関する情報を関連する顧客に伝えることができるように、各デプロイでどのテナントが存在するかを把握する必要もあります。
水平方向にパーティション分割されたデプロイ
デプロイを水平方向にパーティション分割することもできます。 水平方向のデプロイでは、いくつかの共有コンポーネントを持ちながら、他のコンポーネントをシングルテナント デプロイで保持します。 たとえば、次の図に示すように、1 つのアプリケーション層を構築し、テナントごとに個々のデータベースをデプロイできます。
利点： 水平方向にパーティション分割されたデプロイは、ノイズの多い近隣の問題を軽減するのに役立ちます。 特定のコンポーネントがシステムの負荷の大部分を引き起こすことを特定した場合は、テナントごとに個別のコンポーネントをデプロイできます。 たとえば、クエリの負荷が高いため、システムの負荷の大部分がデータベースによって占められる場合があります。 単一のテナントから大量の要求がソリューションに送信されると、データベースのパフォーマンスは低下する可能性があります。ただし、他のテナントのデータベースや、アプリケーション層などの共有コンポーネントは影響を受けません。
リスク： 水平方向にパーティション分割されたデプロイでは、コンポーネント 、特に 1 つのテナントが使用するコンポーネントの自動デプロイと管理を考慮する必要があります。
分離モデルをテストする
どちらの分離モデルを選択した場合でも、ソリューションをテストして、1 つのテナントのデータが誤って別のテナントに漏洩していないことを確認し、ノイズの 多い近隣 の結果が許容されることを確認してください。 実際の停止をシミュレートする障害を意図的に起こし、コンポーネントが誤動作してもソリューションが回復できるか検証するために、Azure Chaos Studio を使用するようにします。
貢献者達
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
主要著者:
- ジョン・ダウンズ |プリンシパル ソフトウェア エンジニア、Azure パターン & プラクティス
その他の共同作成者:
- チャド・キットテル |プリンシパル ソフトウェア エンジニア、Azure パターン & プラクティス
- Paolo Salvator | FastTrack for Azure のプリンシパル カスタマー エンジニア
- Arsen Vladimirskiy | FastTrack for Azure の主任顧客エンジニア
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。