Azure Cosmos DB におけるスループットのプロビジョニングの概要
適用対象: 
NoSQL MongoDB Cassandra Gremlin Table
Azure Cosmos DB では、データベースとコンテナーでプロビジョニング済みのスループットを設定できます。 プロビジョニング済みスループットには、標準 (手動) と自動スケールの 2 種類があります。 この記事では、プロビジョニング済みスループットのしくみについて概説します。
Azure Cosmos DB データベースは、一連のコンテナーの管理の単位です。 データベースは、スキーマに依存しない一連のコンテナーで構成されます。 Azure Cosmos DB コンテナーは、スループットとストレージの両方のスケーラビリティの単位です。 コンテナーは、Azure リージョン内の一連のマシン全体で水平方向にパーティション分割され、Azure Cosmos DB アカウントに関連付けられているすべての Azure リージョンに分散されます。
Azure Cosmos DB では、2 つの細分性でスループットをプロビジョニングできます。
- Azure Cosmos DB コンテナー
- Azure Cosmos DB データベース
コンテナーでスループットを設定する
Azure Cosmos DB コンテナーに対してプロビジョニングされたスループットは、そのコンテナー専用に予約されます。 コンテナーは、常にプロビジョニング済みスループットを受け取ります。 コンテナーのプロビジョニング済みスループットは、SLA によって料金が保証されます。 コンテナーで標準 (手動) スループットを構成する方法については、「Azure Cosmos DB コンテナー上でのスループットをプロビジョニングする」を参照してください。 コンテナーで自動スケール スループットを構成する方法については、「自動スケーリングのスループットをプロビジョニングする」を参照してください。
コンテナー上にプロビジョニング済みのスループットに関する設定は、最も頻繁に使用されるオプションです。 要求ユニット (RU) を使用して任意の量のスループットをプロビジョニングすることにより、コンテナーのスループットをエラスティックにスケーリングできます。
コンテナーに対してプロビジョニングされたスループットは、物理パーティション間に均等に分散されます。また、パーティション キーが適切で、論理パーティションが物理パーティションに均等に分散されているとすると、スループットはコンテナーのすべての論理パーティション間にも均等に分散されます。 論理パーティションのスループットを選択的に指定することはできません。 コンテナーの 1 つ以上の論理パーティションが物理パーティションによってホストされているため、物理パーティションはそのコンテナーにのみ属し、そのコンテナーにプロビジョニングされたスループットをサポートします。
論理パーティションで実行されているワークロードの消費量が、基になる物理パーティションに割り当てられているスループットより多い場合、ユーザーの操作がレート制限される可能性があります。 1 つの論理パーティションの要求数が、他のパーティション キー値よりも不釣り合いに多い場合は、ホット パーティションと呼ばれるものが発生します。
レートの制限が発生した場合は、コンテナー全体のプロビジョニング済みスループットを増やすか、操作を再試行することができます。 また、ストレージと要求の量を均等に配布するパーティション キーを選択したことを確認する必要があります。 パーティション分割の詳細については、「Azure Cosmos DB でのパーティション分割と水平スケーリング」を参照してください。
コンテナーのパフォーマンスを予測できるようにしたい場合は、コンテナーの単位でスループットを構成することをお勧めします。
次のイメージは、物理パーティションによって、コンテナーの 1 つ以上の論理パーティションをホストする方法を示しています。
データベースでスループットを設定する
Azure Cosmos DB データベースでスループットをプロビジョニングすると、スループットはデータベースのすべてのコンテナー (共有データベース コンテナーと呼ばれます) で共有されます。 例外は、データベース内の特定のコンテナーでプロビジョニング済みスループットを指定した場合です。 データベースレベルのプロビジョニング済みスループットを複数のコンテナーで共有することは、マシンのクラスター上でデータベースをホストすることと似ています。 データベース内のすべてのコンテナーによって、マシンで使用可能なリソースが共有されるため、必然的に、特定のコンテナーで予想どおりのパフォーマンスを得ることはできません。 データベース上のプロビジョニング済みスループットを構成する方法については、Azure Cosmos DB データベース上のプロビジョニング済みスループットの構成に関するページを参照してください。 データベースで自動スケール スループットを構成する方法については、「自動スケーリングのスループットをプロビジョニングする」を参照してください。
データベース内のすべてのコンテナーによってプロビジョニング済みスループットが共有されるため、Azure Cosmos DB データベースでは、そのデータベース内の特定のコンテナーに対して、予測可能なスループットは保証されません。 特定のコンテナーが受け取ることができるスループットの部分は、次に依存します。
- コンテナーの数。
- さまざまなコンテナーのパーティション キーの選択。
- コンテナーのさまざまな論理パーティション間のワークロードの分散。
複数のコンテナーでスループットを共有するが、スループットを特定のコンテナー専用にしたくない場合は、データベースでスループットを構成することをお勧めします。
次に、データベース レベルでスループットをプロビジョニングすることが望ましい例を示します。
データベースのプロビジョニング済みスループットを一連のコンテナーで共有することは、マルチテナント アプリケーションに便利です。 各ユーザーを、個別の Azure Cosmos DB コンテナーによって表すことができます。
一連のコンテナーでデータベースのプロビジョニング済みスループットを共有することは、ホストされている NoSQL データベース (MongoDB、Cassandra など) を、VM のクラスターやオンプレミスの物理サーバーから、Azure Cosmos DB へ移行する場合に便利です。 Azure Cosmos DB データベースで構成されているプロビジョニング済みスループットは、MongoDB や Cassandra クラスターのコンピューティング キャパシティと論理的に同等のものである (ただしコスト効率や柔軟性が高い) と考えてください。
スループットがプロビジョニング済みのデータベース内に作成されるコンテナーはすべて、パーティション キーを使用して作成する必要があります。 特定の時点で、データベース内のコンテナーに割り当てられているスループットは、そのコンテナーのすべての論理パーティションに分散されます。 データベースに対して構成されたプロビジョニング済みスループットを共有するコンテナーがある場合は、特定のコンテナーや論理パーティションにスループットを選択して適用することはできません。
論理パーティションのワークロードによって、特定の論理パーティションに割り当てられている量より多くのスループットが消費されている場合、ユーザーの操作のレートが制限されます。 レートの制限が発生した場合は、データベース全体のスループットを増やすか、または操作を再試行することができます。 パーティション分割の詳細については、論理パーティションに関するページをご覧ください。
共有スループット データベース内のコンテナーは、そのデータベースに割り当てられたスループット (RU/秒) を共有します。 標準 (手動) のプロビジョニングされたスループットを使用すると、データベースで 400 RU/秒以上のコンテナーを最大 25 個使用できます。 自動スケールのプロビジョニング済みスループットでは、自動スケールの最小値を 1000 RU/秒 (100 から 1000 RU/秒の間でスケール可能) にして、1 つのデータベース内に最大 25 個のコンテナーを作成できます。
Note
2020 年 2 月に、共有スループット データベースに最大 25 個のコンテナーを含めることを可能にする変更が導入されました。これにより、コンテナー全体のスループットの共有が向上しています。 最初の 25 個のコンテナーの後は、専用スループットでプロビジョニングされている場合に限り、さらにコンテナーを追加できます。これは、データベースの共有スループットとは異なります。
Azure Cosmos DB アカウントに >=25 個のコンテナーを持つ共有スループット データベースが既に含まれている場合、そのアカウントおよび同じ Azure サブスクリプション内の他のすべてのアカウントは、この変更から除外されます。 フィードバックや質問がある場合は、製品サポートにお問い合わせください。
ワークロードでデータベース内のすべてのコレクションを削除および再作成する必要がある場合は、空のデータベースを削除し、コレクションの作成前に新しいデータベースを再作成することをお勧めします。 次の図は、物理パーティションで、データベース内のさまざまなコンテナーに属する 1 つ以上の論理パーティションをホストできる方法を示しています。
データベースとコンテナーでスループットを設定する
2 つのモデルを組み合わせることができます。 データベースとコンテナーの両方でスループットをプロビジョニングできます。 次に示すのは、Azure Cosmos DB データベースとコンテナーで標準 (手動) のプロビジョニング済みスループットをプロビジョニングする方法の例です。
"K" RU の標準 (手動) プロビジョニング済みスループットで、Z という名前の Azure Cosmos DB データベースを作成できます。
次に、データベース内に A、B、C、D、E という名前の 5 つのコンテナーを作成します。 コンテナー B を作成するときに、必ず [Provision dedicated throughput for this container](このコンテナーの専用スループットをプロビジョニングする) オプションを有効にし、このコンテナーにプロビジョニングされているスループットの "P" RU を明示的に構成します。 共有および専用のスループットを構成できるのは、データベースとコンテナーを作成する場合のみになります。
"K" RU/秒のスループットは、A、C、D、E の 4 つのコンテナーにわたって共有されます。使用可能なスループットの正確な量は、A、C、D、E のそれぞれで異なります。 個々のコンテナーのスループットに対する SLA はありません。
コンテナー B では常に "P" RU/秒のスループットが保証されます。 それは SLA によって裏付けられます。
Note
プロビジョニングされたスループットがあるコンテナーを共有データベース コンテナーに変換することはできません。 逆に、共有データベース コンテナーを専用のスループットを持つように変換することはできません。 目的のスループット設定を使用して、データをコンテナーに移動する必要があります。 (NoSQL、MongoDB、Cassandra API のコンテナー コピー ジョブが、このプロセスに役立ちます。)
データベースまたはコンテナーのスループットを更新する
Azure Cosmos DB コンテナーまたはデータベースを作成した後に、プロビジョニング済みのスループットを更新できます。 データベースまたはコンテナーで構成できる最大のプロビジョニング済みスループットに制限はありません。
現在のプロビジョニング済みのスループット
コンテナーまたはデータベースのプロビジョニング済みのスループットを取得するには、Azure portal または SDK を使用します。
- .NET SDK では Container.ReadThroughputAsync。
- Java SDK では CosmosContainer.readThroughput。
また、これらのメソッドの応答には、コンテナーまたはデータベースの最小のプロビジョニング済みスループットも含まれます。
- .NET SDK では ThroughputResponse.MinThroughput。
- Java SDK では ThroughputResponse.getMinThroughput()。
実際の最小 RU/秒は、アカウントの構成によって異なる場合があります。 詳細については、「自動スケールのFAQ」 を参照してください。
プロビジョニング済みのスループットの変更
コンテナーまたはデータベースのプロビジョニング済みのスループットをスケーリングするには、Azure portal または SDK を使用します。
- .NET SDK では Container.ReplaceThroughputAsync。
- Java SDK では CosmosContainer.replaceThroughput。
プロビジョニング済みのスループットを低くする場合は、最低値までそれを行うことができます。
プロビジョニング済みのスループットを高くする場合、ほとんど常にその操作は瞬時に行われます。 ただし、必要なリソースをプロビジョニングするシステム タスクが原因で、操作により長い時間がかかる場合があります。 この場合、この操作の進行中にプロビジョニング済みのスループットを変更しようとすると、別のスケーリング操作が進行中であることを示すエラー メッセージを含む HTTP 423 応答が生成されます。
詳細については、プロビジョニングされたスループット (RU/秒) のスケーリングに関するベスト プラクティスに関する記事を参照してください。
Note
プロビジョニング済みスループットの大幅な増大を必要とする非常に大きなインジェスト ワークロードを計画している場合、スケーリング操作には SLA がなく、前の段落で説明したように、増大度が大きいと長い時間がかかる可能性があることに注意してください。 事前に計画を立て、ワークロードが開始される前にスケーリングを開始し、以下の方法を使用して進行状況を確認することをお勧めします。
スケーリングの進行状況をプログラムで確認するには、現在のプロビジョニング済みのスループットを読み取り、次のものを使用します。
- .NET SDK では ThroughputResponse.IsReplacePending。
- Java SDK では ThroughputResponse.isReplacePending()。
Azure Monitor メトリックを使用して、プロビジョニングされたスループット (RU/秒) とリソース上のストレージの履歴を表示できます。
モデルの比較
次の表は、標準 (手動) のスループットをデータベースでプロビジョニングする場合と、コンテナーでプロビジョニングする場合とでの比較を示したものです。
| パラメーター | データベースでの標準 (手動) スループット | コンテナーでの標準 (手動) スループット | データベースでの自動スケール スループット | コンテナーでの自動スケール スループット |
|---|---|---|---|---|
| エントリ ポイント (最小 RU/秒) | 400 RU/秒。 コンテナーあたりの最小 RU/秒が設定されていないコンテナーを最大 25 個使用できます。 | 400 | 100 - 1,000 RU/秒の間の自動スケーリング。 コンテナーあたりの最小 RU/秒が設定されていないコンテナーを最大 25 個使用できます。 | 100 - 1,000 RU/秒の間の自動スケーリング。 |
| コンテナーあたりの最小 RU/秒 | -- | 400 | -- | 100 - 1,000 RU/秒の間の自動スケーリング |
| 最大 RU | 無制限、データベース上。 | 無制限、コンテナー上。 | 無制限、データベース上。 | 無制限、コンテナー上。 |
| 特定のコンテナーに割り当てられた、または使用可能な RU | 保証はありません。 特定のコンテナーに割り当てられる RU は、プロパティに依存します。 スループットを共有するコンテナーのパーティション キーの選択、ワークロードの分散、コンテナーの数などのプロパティです。 | コンテナー上に構成されるすべての RU は、そのコンテナー専用に予約されます。 | 保証はありません。 特定のコンテナーに割り当てられる RU は、プロパティに依存します。 スループットを共有するコンテナーのパーティション キーの選択、ワークロードの分散、コンテナーの数などのプロパティです。 | コンテナー上に構成されるすべての RU は、そのコンテナー専用に予約されます。 |
| コンテナーの最大ストレージ | 無制限。 | 無制限 | 無制限 | 無制限 |
| コンテナーの論理パーティションあたりの最大スループット | 10,000 RU/秒 | 10,000 RU/秒 | 10,000 RU/秒 | 10,000 RU/秒 |
| コンテナーの論理パーティションあたりの最大ストレージ (データ + インデックス) | 20 GB | 20 GB | 20 GB | 20 GB |
次のステップ
- 論理パーティションの詳細を確認する。
- Azure Cosmos DB コンテナーで標準 (手動) のスループットをプロビジョニングする方法について学習する。
- Azure Cosmos DB データベースで標準 (手動) のスループットをプロビジョニングする方法について学習する。
- Azure Cosmos DB データベースまたはコンテナー上で自動スケーリングのスループットをプロビジョニングする方法を確認する。
- Azure Cosmos DB への移行のための容量計画を実行しようとしていますか? 容量計画のために、既存のデータベース クラスターに関する情報を使用できます。
- 既存のデータベース クラスター内の仮想コアとサーバーの数のみがわかっている場合は、仮想コア数または仮想 CPU 数を使用した要求ユニットの見積もりに関するページを参照してください
- 現在のデータベース ワークロードに対する通常の要求レートがわかっている場合は、Azure Cosmos DB Capacity Planner を使用した要求ユニットの見積もりに関するページを参照してください