次の方法で共有

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

  • [アーティクル]

このページでは、マルチテナント システムで作業する際に便利な Azure Cosmos DB の機能のいくつかについて説明します。 また、マルチテナント ソリューションで Azure Cosmos DB を使用する方法のガイダンスと例にもリンクしています。

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

パーティション分割

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

マルチテナント ソリューションのパフォーマンスを向上させるためには、 階層パーティション キー の使用について検討することを推奨します。 階層パーティション キーを使用すると、複数の値を含むパーティション キーを作成できるようになります。 たとえば、テナント識別子と格納するデータの型を含む階層パーティション キーを使用することができます。 この方法では、パーティション キー値あたり 20 GB の論理パーティション制限を超えてスケーリングできます。

詳細情報:

要求ユニットの管理

Azure Cosmos DB の価格モデルは、プロビジョニングまたは使用する 1 秒あたりの "要求ユニット" の数に基づいています。 要求ユニットは、データベース操作またはクエリのコストを論理的に抽象化したものです。 通常、ワークロードに対して定義されている 1 秒あたりの要求ユニット数をプロビジョニングしますが、これを "スループット" と呼びます。 Azure Cosmos DB には、スループットのプロビジョニング方法に関するいくつかのオプションが用意されています。 マルチテナント環境では、この選択によって Azure Cosmos DB リソースのパフォーマンスと価格が決まります。

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

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

注意

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

各テナントに関連付けられるコストを監視および管理するために、Azure Cosmos DB API を使用するすべての操作では、要求ユニットが消費されます。 この情報を使用して、各テナントで消費される実際の要求ユニットを集計して比較し、パフォーマンス特性が異なるテナントを識別できます。

詳細情報:

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

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

詳細情報:

分離モデル

Azure Cosmos DB を使用するマルチテナント システムを運用する場合は、使用する分離レベルを決定する必要があります。 企業間 (B2B) とは、企業に対して販売することを指します。 企業-消費者間 (B2C) とは、製品またはサービスを利用する個人顧客に直接販売することを指します。 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 Cosmos DB のパーティション分割のサポートを利用できます。 テナントごとに別々のパーティション キーを使用することにより、1 つのテナントのデータを簡単にクエリできます。 複数のテナントにわたってクエリを実行することもできます (それらが別々のパーティションにある場合でも)。 ただし、クロスパーティション クエリには、単一パーティション クエリよりも高い要求ユニット (RU) コストがかかります。

この方法は、各テナントに格納されるデータ量が少ない場合に適しています。 無料レベルを含む価格モデルの構築や、企業-消費者間 (B2C) ソリューションの場合、これがよい方法となる場合があります。 一般に、共有コンテナーを使用すると、テナントの最大密度が実現されるため、テナントあたりの料金は最も低くなります。

コンテナーのスループットを考慮することが重要です。 すべてのテナントによってコンテナーのスループットが共有されるため、テナントのワークロードが大きかったり重複したりすると、うるさい隣人の問題によってパフォーマンスの問題が発生する場合があります。 この問題は、テナントのサブセットを別々のコンテナーにグループ化し、各テナント グループの使用パターンに互換性を持たせることで軽減されることがあります。 または、ハイブリッド マルチテナント モデルとシングルテナント モデルを検討することもできます。 小規模なテナントを共有パーティション分割コンテナーにグループ化し、大規模な顧客には専用コンテナーを提供します。 また、Java SDK には、スループットの再割り当て、バースト容量、スループット制御など、テナントをパーティションごとにモデル化する際にノイズの多い近隣の問題を制御するための機能が用意されています。

また、各論理パーティションに格納するデータ量を考慮することも重要です。 Azure Cosmos DB では、各論理パーティションを最大 20 GB まで拡張できます。 単一のテナントで 20 GB を超えるデータを格納する必要がある場合、複数の論理パーティションにデータを分散することを検討してください。 たとえば、Contoso という 1 つのパーティションキーを使用するのではなく、 や などテナントの複数のパーティション キーを作成することによってパーティション キーを "Contoso1ソルト化するContoso2" こともできます。 テナントのデータに対してクエリを実行する場合は、WHERE IN 句を使用して、すべてのパーティション キーを照合できます。 階層パーティション キーを利用することで、20 GB を超えるストレージを持つ大規模なテナントにも対応することができます。テナントごとに合成パーティション キーや複数のパーティション キー値を使用する必要はありません。

ソリューションの運用面と、テナントのライフサイクルのさまざまなフェーズについて考慮します。 たとえば、あるテナントが専用の価格レベルに移行する場合、データを別のコンテナーに移動する必要が生じる可能性が高くなります。 あるテナントがプロビジョニング解除される場合、コンテナーに対して delete クエリを実行してデータを削除する必要があり、大規模なテナントでは、このクエリの実行中に大量のスループットが消費される可能性があります。

テナントごとのコンテナー

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

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

または、コンテナーごとに専用のスループットをプロビジョニングすることもできます。 このアプローチは、大規模なテナントや、ノイズの多い隣人の問題が発生するおそれのあるテナントに適しています。 ただし、各テナントのベースライン スループットは高くなるため、このモデルの最小要件とコストへの影響について検討してください。

テナント データ モデルに複数のエンティティが必要な場合は、すべてのエンティティが同じパーティション キーを共有できる限り、同じコンテナーに併置できます。 ただし、テナント データ モデルがより複雑で、同じパーティション キーを共有できないエンティティが必要な場合は、以下のテナントごとのデータベース モデルまたはテナントごとのデータベース アカウント モデルを検討してください。 詳細なガイダンスについては、「実際の例を使用して Azure Cosmos DB でデータをモデル化およびパーティション分割する方法」の記事を参照してください。

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

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

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

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

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

Azure Cosmos DB では、テナントごとに別々のデータベース アカウントをプロビジョニングできます。これにより、最大レベルの分離が実現されますが、密度は最も低くなります。 このモデルは、上記のテナントごとのコンテナー モデルとテナントごとのデータベース モデルと同様に、テナントごとのパーティション キー モデルよりも優れたパフォーマンス分離を実現します。 また、Azure RBAC によるデータ アクセスのセキュリティ分離も強化されます。 さらに、このモデルでは、カスタマー マネージド キーによってテナント レベルでデータベース暗号化セキュリティが分離されます。

1 つのデータベース アカウントを 1 つのテナント専用とするため、ノイズの多い隣人の問題の影響を受けません。 テナントの要件に従って、データベース アカウントの場所を構成できます。 また、各テナントの要件に合わせて、geo レプリケーションやカスタマー マネージド暗号化キーなどの Azure Cosmos DB 機能の構成を調整できます。 テナントごとに専用の Azure Cosmos DB アカウントを使用する場合は、Azure サブスクリプションごとの Azure Cosmos DB アカウントの最大数を考慮してください。

このモデルを使用する場合は、アプリケーションで新しいテナントを生成するのに必要な速度を考慮する必要があります。 Azure Cosmos DB でのアカウント作成には数分かかる場合があるため、アカウントを事前に作成する必要がある場合があります。 このアプローチが実行可能でない場合は、テナントごとのデータベース モデルを検討してください。

テナントが共有アカウントから専用の Azure Cosmos DB アカウントに移行することを許可する場合は、古いアカウントと新しいアカウントの間でテナントのデータを移動するために使用する移行アプローチを検討してください。

ハイブリッド アプローチ

さまざまなテナントの要件と使用する価格モデルに合わせて、上記の方法を組み合わせることができます。 次に例を示します。

  • すべての無料試用版のお客様を共有コンテナー内にプロビジョニングし、テナント ID または合成キー パーティション キーを使用する。
  • テナントごとに専用のコンテナーをデプロイし、データベースに対して共有スループットを使用する有料の Bronze レベルを提供する。
  • テナントのコンテナーに対して専用のスループットをプロビジョニングする、より上位の Silver レベルを提供する。
  • 最高の Gold レベルを提供し、テナントに対して専用のデータベース アカウントを提供する。これにより、テナントでデプロイの地理的な場所も選択できるようになります。

共同作成者

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

プリンシパルの作成者:

  • Paul Burpo | FastTrack for Azure のプリンシパル カスタマー エンジニア
  • John Downs | FastTrack for Azure のプリンシパル カスタマー エンジニア

その他の共同作成者:

  • 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 について確認してください。

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