Azure Cosmos DB の要求ユニット
適用対象: 
NoSQL MongoDB Cassandra Gremlin Table
Azure Cosmos DB では、多くの API (SQL、MongoDB、Cassandra、Gremlin、Table など) がサポートされています。 各 API には、固有のデータベース操作のセットがあります。 これらの操作の範囲は、単純なポイント読み取り/書き込みから、複雑なクエリにまで及びます。 各データベース操作は、それらの操作の複雑さに基づいて、システム リソースを消費します。
Azure Cosmos DB は、要求ユニット (略して RU) を使ってすべてのデータベース操作のコストを正規化し、スループット (1 秒あたりの要求ユニット、RU/s) に基づいてコストを測定します。
要求ユニットは、Azure Cosmos DB によってサポートされるデータベース操作を実行するために必要な CPU、IOPS、メモリなどのシステム リソースを抽象化する、パフォーマンスの通貨です。 データベース操作が書き込み、ポイント読み取り、またはクエリのいずれの場合でも、操作は常に RU で測定されます。 たとえば、1 KB 項目のポイント読み取り (ID とパーティション キー値によって単一項目をフェッチする) は、どの API を使って Azure Cosmos DB コンテナーとやり取りするかに関係なく、1 要求ユニット (1 RU) です。 Azure Cosmos DB Capacity Calculator を使って、スループット コストをモデル化できます。
次の図では、RU の高度な概念を示します。
容量を管理および計画するために、Azure Cosmos DB では、特定のデータセットに対する特定のデータベース操作の RU の数が決定的であることが確認されます。 応答ヘッダーを調べて、すべてのデータベース操作が消費する RU の数を追跡できます。 RU 使用量に影響を与える要因とアプリケーションのスループット要件を理解したら、費用対効果の高い方法でアプリケーションを実行できます。
使用している Azure Cosmos DB アカウントの種類によって、使用した RU に対する課金方法が決まります。 アカウントを作成できるモードには次の 3 つがあります。
プロビジョニング スループット モード: このモードでは、アプリケーションの RU の数を秒単位で、増分 100 RU/秒で割り当てます。 アプリケーション用にプロビジョニング済みスループットをスケーリングするために、いつでも RU の値を増やしたり減らしたりできます (100 RU 単位での増減)。 変更は、プログラムまたは Azure portal を使用して行うことができます。 ユーザーは、1 秒あたりにプロビジョニングした RU の数に対して時間単位で課金されます。 詳細については、プロビジョニング スループットに関する記事を参照してください。
次の 2 つの別個の粒度でスループットをプロビジョニングできます。
- コンテナー: 詳しくは、Azure Cosmos DB コンテナーへのスループットのプロビジョニングに関するページを参照してください。
- データベース: 詳しくは、Azure Cosmos DB データベースへのスループットのプロビジョニングに関するページを参照してください。
サーバーレス モード: このモードでは、Azure Cosmos DB アカウントでリソースを作成するときに、スループットを割り当てるする必要はありません。 請求期間が終了すると、データベース操作で使用した要求ユニットの数に対して課金されます。 詳細については、サーバーレス スループットに関する記事をご覧ください。
自動スケーリング モード: このモードでは、使用状況に基づいて、データベースまたはコンテナーのスループット (RU/秒) を自動的かつ瞬時にスケーリングできます。 このスケーリング操作は、ワークロードの可用性、待機時間、スループット、パフォーマンスに影響しません。 このモードは、変動し予測できないトラフィック パターンを持ち、かつハイ パフォーマンスとスケーリングに対する SLA を必要とするミッション クリティカルなワークロードに最適です。 詳細については、自動スケーリングのスループットに関する記事を参照してください。
要求ユニットの考慮事項
ワークロードに使用される RU 数を推定するときは、次の要因を考慮してください。
アイテムのサイズ:アイテムのサイズが増加すると、そのアイテムの読み取りまたは書き込みのために消費される RU の数も増加します。
アイテムのインデックス付け:既定では、アイテムごとにインデックスが自動的に作成されます。 コンテナー内の一部のアイテムにインデックスを作成しないように選択すると、消費される RU は少なくなります。
アイテム プロパティの数:すべてのプロパティで既定のインデックス作成を実行した場合、アイテム プロパティの数が増加すると、アイテムを書き込むために消費される RU の数が増加します。
インデックス付きプロパティ:各コンテナーのインデックス ポリシーによって、既定でインデックスが作成されるプロパティが決まります。 書き込み操作の RU 消費量を削減するには、インデックス付きプロパティの数を制限します。
データの一貫性:強力な有界整合性制約の整合性レベルでは、他の緩和された整合性レベルの場合と比べて、読み取り操作の実行中に約 2 倍の RU が消費されます。
読み取りの種類: ポイント読み取りは、クエリよりも RU のコストが低くなります。
クエリのパターン:クエリの複雑さは、操作のために消費される RU の数に影響を与えます。 クエリ操作のコストに影響する要因は次のとおりです。
- クエリ結果の数
- 述語の数
- 述語の性質
- ユーザー定義関数の数
- ソース データのサイズ
- 結果セットのサイズ
- プロジェクション
同じデータに対する同じクエリによって、繰り返しの実行で常に同じ数の RU のコストがかかります。
スクリプトの使用:クエリと同様に、ストアド プロシージャとトリガーは、実行される操作の複雑さに基づいて RU を消費します。 アプリケーションを開発する場合は、要求使用量ヘッダーを調べて、各操作で消費される RU 量をより深く理解してください。
要求ユニットと複数のリージョン
Azure Cosmos DB コンテナー (またはデータベース) で 'R' 個の RU をプロビジョニングすると、Azure Cosmos DB は、Azure Cosmos DB アカウントに関連付けられた "各リージョン" で 'R' 個の RU を確実に利用できるようにします。 特定のリージョンに RU を選択的に割り当てることはできません。 Azure Cosmos DB コンテナー (またはデータベース) でプロビジョニングされた RU は、Azure Cosmos DB アカウントに関連付けられているすべてのリージョンでプロビジョニングされます。
Azure Cosmos DB コンテナーが 'R' 個の RU が構成され、Azure Cosmos DB アカウントに関連付けられている 'N' 個のリージョンが関連付けられていると仮定すると、このコンテナーでグローバルに使用可能な RU の合計は R x N になります。
選択した整合性モデルもスループットに影響します。 整合性レベルが比較的緩やかな場合 (セッション、一貫性のあるプレフィックス、そして最終的な一貫性)、比較的強固な場合 (限定された古さまたは強い一貫性) と比べ、ほぼ 2 倍の読み取りスループットを得ることができます。