次の方法で共有

マルチテナント機能と Azure Cosmos DB

  • [アーティクル]

この記事では、マルチテナント システムに使用できる Azure Cosmos DB の機能について説明します。 マルチテナント ソリューションで Azure Cosmos DB を使用する方法に関するガイダンスと例を提供します。

マルチテナントの要件

マルチテナント ソリューションを計画する場合、次の 2 つの重要な要件があります。

  • テナント間の強力な分離を確保し、テナントを必要とするユーザーに対する厳格なセキュリティ要件を満たすのに役立ちます。
  • テナントあたりの低コストを維持します。 プロバイダーは、アプリケーションを実行するためのコストが、スケーリングに応じて持続可能なままであることを確認します。

多くの場合、これら 2 つのニーズは競合し、トレードオフが生じる可能性があります。ここで、どちらか一方に優先順位を付ける必要があります。 この記事のガイダンスは、これらのニーズに対処するために行う必要があるトレードオフをより深く理解するのに役立ちます。 この記事は、マルチテナント ソリューションを設計するときに情報に基づいた意思決定を行うことができるように、これらの考慮事項を理解するのに役立ちます。

分離モデル

テナント間で必要な分離レベルを決定します。 Azure Cosmos DB ではさまざまな分離モデルがサポートされていますが、ほとんどのソリューションでは、次のいずれかの方法を使用することをお勧めします。

  • テナントごとのパーティション キーは、多くの場合、サービスとしての企業間ソフトウェア (B2C SaaS) ソリューションなど、完全なマルチテナント ソリューションに使用されます。
  • テナントごとのデータベース アカウントは、多くの場合、企業間 (B2B) SaaS ソリューションに使用されます。

最適な分離モデルを選択するには、ビジネス モデルとテナントの要件を検討してください。 たとえば、ビジネスが製品やサービスを個々の顧客に直接販売する一部の B2C モデルでは、強力なパフォーマンスの分離が優先されない場合があります。 ただし、B2B モデルでは、強力なセキュリティとパフォーマンスの分離に優先順位を付け、テナントに独自のプロビジョニング済みデータベース アカウントが必要になる場合があります。

複数のモデルを組み合わせて、さまざまな顧客のニーズに合わせることもできます。 たとえば、企業の顧客に販売する B2B SaaS ソリューションを構築し、潜在的な新規顧客に無料試用版を提供するとします。 強力なセキュリティと分離の保証を必要とする有料のエンタープライズ テナントには、別のデータベース アカウントをデプロイできます。 また、データベース アカウントを共有し、パーティション キーを使用して試用版の顧客を分離することもできます。

テナントごとのパーティション キー モデルとテナントごとのデータベース アカウント モデルは、マルチテナント ソリューションの最も一般的な分離モデルです。 これらのモデルは、テナントの分離とコスト効率の最適なバランスを提供します。

テナントごとのパーティション キー モデル

パーティション キーによってテナントを分離する場合、スループットはテナント間で共有され、同じコンテナー内で管理されます。

Note

要求ユニット (RU) は、データベース操作またはクエリのコストの論理的な抽象化です。 通常は、ワークロードに対して定義された 1 秒あたりの要求ユニット数 (RU/秒) をプロビジョニングします。これは、 throughput と呼ばれます。

メリット

  • コスト効率: テナント ID でパーティション分割された 1 つのコンテナーにすべてのテナントを配置します。 このアプローチには、複数のテナント間で RU をプロビジョニングして共有する課金対象のリソースが 1 つだけ存在します。 通常、このモデルは、テナントごとに個別のアカウントを持つよりも、コスト効率が高く、管理が容易です。

  • 管理の簡素化: 管理する Azure Cosmos DB アカウントが少なくなります。

トレードオフ

  • リソースの競合: 同じコンテナー内にあるテナント間で共有スループット (RU/秒) が発生すると、ピーク使用時に競合が発生する可能性があります。 この競合により、テナントのワークロード 高いか重複している場合 近隣の問題やパフォーマンスの問題が発生する可能性があります。 この分離モデルは、1 つのテナントで保証された RU を必要とし、スループットを共有できるワークロードに使用します。

  • 制限付き分離: この方法では、物理的な分離ではなく、論理的な分離が指定されます。 パフォーマンスやセキュリティの観点からは、厳密な分離要件を満たしていない可能性があります。

  • 柔軟性が低い: パーティション キーまたはデータベースまたはコンテナーで分離する場合、各テナントのアカウント レベルの機能 (geo レプリケーション、ポイントインタイム リストア、カスタマー マネージド キーなど) をカスタマイズすることはできません。

マルチテナント向けの Azure Cosmos DB 機能

  • スループットを制御する: パーティション キーを使用してテナントを分離するときに、ノイズの多い近隣の問題を制御するのに役立つ機能を調べます。 Java SDK で、throughput 再割り当て、バースト容量、throughput 制御などの機能を使用します。

  • 階層パーティション キー: Azure Cosmos DB を使用して、各論理パーティションのサイズを最大 20 GB まで増やすことができます。 単一のテナントで 20 GB を超えるデータを格納する必要がある場合、複数の論理パーティションにデータを分散することを検討してください。 たとえば、 Contosoのパーティション キーを 1 つ持つ代わりに、 Contoso1 や Contoso2など、テナントに対して複数のパーティション キーを作成してパーティション キーを分散できます。

    テナントのデータを照会する場合は、 WHERE IN 句を使用してすべてのパーティション キーを照合できます。 階層的パーティション キーを使用してテナントのカーディナリティが高い場合は、20 GB を超えるストレージを大規模なテナントに提供することもできます。 この方法では、テナントごとに合成パーティション キーまたは複数のパーティション キー値を使用する必要はありません。

    パーティション キー別にテナントを分離するワークロードがあるとします。 1 つのテナント Contoso は、他のテナントよりも大きく書き込み負荷が高く、サイズが拡大し続けています。 このテナントのデータをより多く取り込むことができないリスクを回避するために、階層パーティション キーを使用できます。 最初のレベル キーとして TenantID を指定し、UserId のように 2 番目のレベルを追加します。 TenantIDとUserIDの組み合わせで、20 GB の制限を超える論理パーティションを生成することが予想される場合は、SessionIDなどの別のレベルにさらにパーティション分割できます。 TenantIDまたはTenantIDとUserIDの両方を指定するクエリは、関連するデータを含む物理パーティションのサブセットにのみ効果的にルーティングされるため、完全なファンアウト クエリを回避できます。 コンテナーに 1,000 個の物理パーティションがあり、特定の TenantId 値が 5 つの物理パーティションにのみ存在する場合、クエリは関連する物理パーティションの数が少ない方にルーティングされます。

    最初のレベルのカーディナリティが十分に高くなく、パーティション キーの論理パーティションの上限が 20 GB に達した場合は、階層パーティション キーではなく合成パーティション キーを使用することを検討してください。

テナントごとのデータベース アカウント モデル

データベース アカウントによってテナントを分離する場合、各テナントには、データベース レベルまたはコンテナー レベルで独自のスループットがプロビジョニングされます。

メリット

  • 高い分離: この方法では、一意のテナントごとに RU がプロビジョニングされている専用の Azure Cosmos DB アカウントとコンテナーが原因で競合や干渉が回避されます。

  • カスタム サービス レベル アグリーメント (SLA): 各テナントには独自のアカウントがあるため、スループットのために各テナントのデータベース アカウントを個別に調整できるため、特定のカスタマイズされたリソース、顧客向けの SLA、保証を提供できます。

  • セキュリティの強化: 物理的なデータ分離は、お客様がテナントごとにアカウント レベルでカスタマー マネージド キーを有効にできるため、堅牢なセキュリティを確保するのに役立ちます。 各テナントのデータは、同じコンテナ内ではなく、アカウント別に分離されます。

  • 柔軟性: テナントでは、geo レプリケーション、ポイントインタイム リストア、カスタマー マネージド キーなどのアカウント レベルの機能を必要に応じて有効にすることができます。

トレードオフ

  • 管理の強化: 複数の Azure Cosmos DB アカウントを管理するため、このアプローチはより複雑になります。

  • コストが高い: アカウントが増えるということは、各テナントのアカウント内で、データベースやコンテナーなどの各リソースにスループットをプロビジョニングする必要があることを意味します。 リソースが RU をプロビジョニングするたびに、Azure Cosmos DB のコストが増加します。

  • クエリの制限事項: すべてのテナントが異なるアカウントに存在するため、複数のテナントに対してクエリを実行するアプリケーションでは、アプリケーションのロジック内で複数の呼び出しが必要になります。

マルチテナント向けの Azure Cosmos DB 機能

  • セキュリティ機能: このモデルは、 Azure RBAC を介してデータ アクセスのセキュリティ分離を強化します。 このモデルでは、 customer マネージド キーを使用して、テナント レベルでデータベース暗号化セキュリティを分離することもできます。

  • カスタム構成: テナントの要件に従って、データベース アカウントの場所を構成できます。 また、各テナントの要件に合わせて、geo レプリケーションやカスタマー マネージド暗号化キーなどの Azure Cosmos DB 機能の構成を調整できます。

テナントごとに専用の Azure Cosmos DB アカウントを使用する場合は、Azure サブスクリプションあたりの Azure Cosmos DB アカウントの 最大数を考慮してください。

分離モデルの完全な一覧

ワークロードの必要性 テナント当たりのパーティション キー (推奨) テナントごとのコンテナー (共有スループット) テナントごとのコンテナー (専用スループット) テナントごとのデータベース テナントごとのデータベース アカウント (推奨)
テナント間のクエリ 簡単 (コンテナーはクエリの境界として機能します) 硬調 硬調 硬調 硬調
テナント密度 高 (テナントあたりのコストが最も低い) Medium 低 低 低
テナント データの削除 簡単 簡単 (テナントが離れたときにコンテナーを削除) 簡単 (テナントが離れたときにコンテナーを削除) 簡単 (テナントが離れたときにデータベースを削除) 簡単 (テナントが離れたときにデータベースを削除)
データ アクセス セキュリティの分離 アプリケーション内で実装する必要がある コンテナー RBAC コンテナー RBAC データベース RBAC RBAC
geo レプリケーション テナントごとの geo レプリケーションが不可能 要件に基づいてデータベース アカウント内でテナントをグループ化 要件に基づいてデータベース アカウント内でテナントをグループ化 要件に基づいてデータベース アカウント内でテナントをグループ化 要件に基づいてデータベース アカウント内でテナントをグループ化
ノイズの多い隣人の防止 いいえ いいえ イエス イエス イエス
新規テナント作成時の待機時間 即時 速い 速い Medium 低速
データ モデリングの利点 なし エンティティコロケーション エンティティコロケーション テナント エンティティをモデル化する複数のコンテナー テナントをモデル化する複数のコンテナーとデータベース
暗号化キー すべてのテナントで同じ すべてのテナントで同じ すべてのテナントで同じ すべてのテナントで同じ テナントごとのカスタマー マネージド キー
スループット要件 >テナントあたり 0 RU >テナントあたり 100 RU >テナントあたり 100 RU 以上 (自動スケーリングのみ、それ以外の場合は >テナントあたり 400 RU 以上) >テナントあたり 400 RU >テナントあたり 400 RU
ユース ケースの例 B2C アプリ B2B アプリの Standard オファー B2B アプリの Premium オファー B2B アプリの Premium オファー B2B アプリの Premium オファー

テナントごとのコンテナー モデル

テナントごとに専用のコンテナーをプロビジョニングすることができます。 専用コンテナーは、テナントに格納するデータを 1 つのコンテナーに結合できる場合に適しています。 このモデルは、テナントごとのパーティション キー モデルよりも高いパフォーマンス分離を提供します。 また、 Azure RBACによるデータ アクセスのセキュリティ分離も強化されます。

テナントごとにコンテナーを使用する場合は、データベース レベルでスループットをプロビジョニングして、他のテナントとスループットを共有することを検討してください。 データベースの RU の 最小数と データベース内のコンテナーの maximum 数の制限を考慮してください。 また、テナントに保証されたレベルのパフォーマンスが必要かどうか、およびテナントが 不要な近隣の問題の影響を受けやすいかどうかを検討します。 データベース レベルでスループットを共有する場合、すべてのコンテナーのワークロードまたはストレージは比較的均一である必要があります。 それ以外の場合は、1 つ以上の大規模なテナントがある場合は、ノイズの多い近隣の問題が発生する可能性があります。 必要に応じて、ワークロード パターンに基づいて、これらのテナントを別のデータベースにグループ化することを計画します。

または、コンテナーごとに専用のスループットをプロビジョニングすることもできます。 この方法は、大規模なテナントや、 不要な近隣の問題のリスクがあるテナントに適しています。 ただし、各テナントのベースライン スループットは高いので、このモデルの最小要件とコストへの影響を考慮してください。

テナント データ モデルに複数のエンティティが必要であり、すべてのエンティティが同じパーティション キーを共有できる場合は、それらを同じコンテナーに併置できます。 ただし、テナント データ モデルがより複雑で、同じパーティション キーを共有できないエンティティが必要な場合は、テナントごとのデータベースモデルまたはテナント単位のデータベース アカウント モデルを検討してください。 詳細については、「 モデルと Azure Cosmos DB 上のデータのパーティション分割を参照してください。

コンテナーをテナント専用にすると、一般にライフサイクル管理が簡単になります。 共有スループット モデルと専用スループット モデル間でテナントを 移動できます。 また、テナントのプロビジョニングを解除すると、コンテナーをすばやく削除できます。

テナントごとのデータベース モデル

同じデータベース アカウント内のテナントごとにデータベースをプロビジョニングできます。 テナントごとのコンテナー モデルと同様に、このモデルでは、テナントごとのパーティション キー モデルよりもパフォーマンスの分離が向上します。 また、 Azure RBACによるデータ アクセスのセキュリティ分離も強化されます。

テナントごとのアカウント モデルと同様に、このアプローチでは最高レベルのパフォーマンス分離が提供されますが、テナント密度は最も低くなります。 各テナントで、テナントごとのコンテナー モデルで実現可能なよりも複雑なデータ モデルが必要な場合は、このオプションを使用します。 または、新しいテナントの作成を迅速に行う必要がある場合、またはオーバーヘッドを前もって解放する必要がある場合は、このアプローチに従います。 一部のソフトウェア開発フレームワークでは、テナントごとのデータベース モデルが、フレームワークがサポートするパフォーマンス分離の唯一のレベルである可能性があります。 このようなフレームワークでは、通常、エンティティ (コンテナー) レベルの分離とエンティティコロケーションはサポートされません。

マルチテナント機能をサポートする Azure Cosmos DB の機能

パーティション分割

Azure Cosmos DB コンテナーでパーティションを使用して、複数のテナントが共有するコンテナーを作成します。 通常は、テナント識別子をパーティション キーとして使用しますが、1 つのテナントに複数のパーティション キーを使用することも検討できます。 適切に計画されたパーティション分割戦略では、 シャーディング パターンが効果的に実装されます。 大規模なコンテナーがある場合、Azure Cosmos DB はテナントを複数の物理ノードに分散して、高度なスケールを実現します。

マルチテナント ソリューション パフォーマンスを向上させるために 階層的パーティション キーを検討してください。 階層パーティション キーを使用して、複数の値を含むパーティション キーを作成します。 たとえば、高カーディナリティ GUID などのテナント識別子を含む階層パーティション キーを使用して、ほぼ無制限の規模を実現できます。 または、クエリで頻繁に使用されるプロパティを含む階層パーティション キーを指定することもできます。 この方法は、クロスパーティション クエリを回避するのに役立ちます。 階層的パーティション キーを使用して、パーティション キー値あたり 20 GB の論理パーティション制限を超えてスケーリングし、コストの高いファンアウト クエリを制限します。

詳細については、次のリソースを参照してください。

RU の管理

Azure Cosmos DB の価格モデルは、プロビジョニングまたは使用する RU/秒の数に基づいています。 Azure Cosmos DB には、スループットをプロビジョニングするためのオプションがいくつか用意されています。 マルチテナント環境では、選択が Azure Cosmos DB リソースのパフォーマンスと価格に影響します。

パフォーマンスとセキュリティの分離を保証する必要があるテナントの場合は、データベース アカウントによってテナントを分離し、RU をテナントに割り当てることをお勧めします。 要件が厳しくないテナントの場合は、パーティション キーでテナントを分離することをお勧めします。 このモデルを使用して、テナント間で RU を共有し、テナントあたりのコストを最適化します。

Azure Cosmos DB の代替テナント モデルでは、共有データベース内のテナントごとに個別のコンテナーがデプロイされます。 Azure Cosmos DB を使用してデータベースの RU をプロビジョニングし、すべてのコンテナーが RU を共有できるようにします。 テナントのワークロードが基本的に重複しない場合、このアプローチによって運用コストを削減できます。 ただし、この方法は、 不要な近隣の問題の影響を受けやすくなります 単一のテナントのコンテナーが、プロビジョニングされた共有 RU の量を不均衡に消費する可能性があるためです。 この問題を軽減するには、まず、ノイズの多いテナントを特定します。 その後、オプションで特定のコンテナーに対してプロビジョニング スループットを設定することができます。 データベース内の他のコンテナーは引き続きスループットを共有しますが、うるさいテナントは独自の専用スループットを消費します。

Azure Cosmos DB には、断続的または予測不可能なトラフィックがあるワークロードに適したサーバーレス層も用意されています。 または、自動スケーリングを使用して、プロビジョニングされたスループットのスケーリングを指定するポリシーを構成することもできます。 また、Azure Cosmos DB のバースト容量を利用して、プロビジョニングされたスループット容量の使用量を最大化することもできます。それ以外の場合はレート制限によって制限されます。 マルチテナント ソリューションでは、これらすべてのアプローチを組み合わせて、さまざまな種類のテナントをサポートできます。

Note

Azure Cosmos DB の構成を計画するときは、 サービスのクォータと制限を考慮してください。

各テナントに関連付けられているコストを監視および管理するには、Azure Cosmos DB API を使用するすべての操作に使用される RU が含まれていることに注意してください。 この情報を使用して、各テナントが使用する実際の RU を集計および比較できます。 その後、異なるパフォーマンス特性を持つテナントを識別できます。

詳細については、次のリソースを参照してください。

カスタマー マネージド キー

テナントによっては、独自の暗号化キーの使用が必要になる場合があります。 Azure Cosmos DB では、カスタマー マネージド キー機能が提供されています。 この機能は、Azure Cosmos DB アカウントのレベルで適用します。 そのため、テナントに独自の暗号化キーが必要な場合は、専用の Azure Cosmos DB アカウントを使用してテナントをデプロイする必要があります。

詳細については、「Azure Key Vault で Azure Cosmos DB アカウントのカスタマー マネージド キーを構成する」を参照してください。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

  • タラ・バティア | Azure Cosmos DB プログラム マネージャー
  • Paul Burpo | FastTrack for Azure のプリンシパル カスタマー エンジニア
  • John Downs | プリンシパル ソフトウェア エンジニア

その他の共同作成者:

  • Mark Brown | Azure Cosmos DB のプリンシパル PM マネージャー
  • Deborah Chen | プリンシパル プログラム マネージャー
  • Theo van Kraay | Azure Cosmos DB シニア プログラム マネージャー
  • Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア
  • Thomas Weiss | プリンシパル プログラム マネージャー
  • Vic Perdana | クラウド ソリューション アーキテクト、Azure ISV

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

マルチテナント機能と Azure Cosmos DB について確認してください。

その他の Azure Cosmos DB アーキテクチャ シナリオの一部を参照してください。