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