Azure Cosmos DB コンテナーまたはアカウントの正規化された RU/秒を監視する方法

適用対象: NoSQL MongoDB カサンドラ グレムリン 表

Azure Monitor for Azure Cosmos DB では、アカウントを監視したり、ダッシュボードを作成したりするためのメトリック ビューが提供されています。 Azure Cosmos DB メトリックは、既定で収集されます。 この機能では、明示的に何かを有効または構成する必要はありません。

メトリック定義

正規化された RU 消費量 は、データベースまたはコンテナーでプロビジョニングされたスループットの使用率を測定するために使用される 0% から 100% までのメトリックです。 メトリックは 1 分間隔で出力され、時間間隔内のすべてのパーティション キー範囲における 1 秒あたりの最大要求ユニット数 (RU/秒) 使用率として定義されます。 各パーティション キー範囲は 1 つの物理パーティションにマップされ、指定可能なハッシュ値の範囲のデータを保持するように割り当てられます。 一般に、正規化された RU の割合が高いほど、プロビジョニングされたスループットを利用できます。 このメトリックを使うと、データベースまたはコンテナーの個々のパーティション キー範囲の使用率を見ることもできます。

たとえば、コンテナーで自動スケーリングの最大スループットを 20,000 RU/s (2,000 から 20,000 RU/s のスケール) に設定してあり、2 つのパーティション キー範囲 (物理パーティション) P1 と P2 があるとします。 Azure Cosmos DB では、プロビジョニングされたスループットがすべてのパーティション キー範囲に均等に分散されるため、 P1 と P2 はそれぞれ 1000 から 10,000 RU/秒の間でスケーリングできます。 ある 1 分の間隔で、特定の秒で P1 が 6,000 RU を消費し、 P2 が 8,000 RU を消費したとします。 P1 の正規化された RU 消費量は 60%、P2 は 80% です。 コンテナー全体の正規化された RU 消費量全体は MAX(60%, 80%) = 80% です。

操作の種類と共に 1 秒あたりの要求ユニットの消費量を確認したい場合は、オプトイン 診断ログ を使用して PartitionKeyRUConsumption テーブルに対してクエリを実行できます。 アプリケーションが Azure Cosmos DB リソースで実行している操作と状態コードの概要を確認するには、組み込みの Azure Monitor Total Requests (API for NoSQL)、 Mongo Requests、 Gremlin Requests、または Cassandra Requests メトリックを使用できます。 後で、これらの要求を 429 状態コードでフィルター処理し、 操作の種類で分割できます。

正規化された RU/秒が高い場合に想定して実行する内容

正規化された RU 消費量が特定のパーティション キー範囲に対して 100% に達し、クライアントがその特定のパーティション キー範囲に対して 1 秒の時間枠で要求を行った場合、レート制限エラー (429) を受け取ります。

これは必ずしもリソースに問題があることを意味するとは限りません。 既定では、Azure Cosmos DB クライアント SDK とデータ インポート ツール (Azure Data Factory や Bulk Executor ライブラリなど) は、429 で要求を自動的に再試行します。 通常は、9 回まで再試行します。 その結果、メトリックに 429 が表示されることがありますが、これらのエラーがアプリケーションに返されていない可能性もあります。

一般的に、運用ワークロードで、要求の 1 から 5% で 429 が発生し、エンド ツー エンドの待機時間が許容範囲内である場合、これは RU/秒が完全に利用されているという正常な兆候です。 この場合、正規化された RU 消費量メトリックが 100% に達するということは、特定の 1 秒において、少なくとも 1 つのパーティション キー範囲でそのプロビジョニング済みスループットがすべて使われたことを意味します。 429 の全体的なレートがまだ低いため、これは許容されます。 ユーザーによる対処は不要です。

データベースまたはコンテナーに対する要求の割合が 429s になったかどうかを判断するには、Azure Cosmos DB アカウントから Insights>Requests>Total Requests by Status Code に移動します。 フィルター処理して、特定のデータベースとコンテナーを表示します。 Gremlin 用 API の場合は、Gremlin 要求数メトリックを使います。

正規化された RU 消費量メトリックが複数のパーティション キー範囲で一貫して 100% であり、429 のレートが 5% を超える場合は、スループットを増やすことをお勧めします。 負荷の大きい操作とそのピーク使用率を確認するには、Azure Monitor のメトリックと Azure Monitor の診断ログを使います。 ベスト プラクティスについては、 プロビジョニングされたスループット (RU/秒) のスケーリングに関するベスト プラクティスを参照してください。

正規化された RU が 100%に達したという理由だけで、429 のレート制限エラーが発生するとは限りません。 これは、正規化された RU が、すべてのパーティション キー範囲の最大使用量を表す単一の値であるためです。 1 つのパーティション キー範囲がビジー状態である可能性がありますが、他のパーティション キー範囲は問題なく要求を処理できます。 たとえば、パーティション キー範囲内のすべての RU/秒を消費するストアド プロシージャのような単一の操作によって、正規化された RU 消費メトリックが急激に短時間で上昇することがあります。 このような場合、全体的な要求レートが低い場合や、異なるパーティション キー範囲の他のパーティションに対して要求が行われた場合、すぐにレート制限エラーが発生することはありません。

詳細については、「 429 例外の診断とトラブルシューティング」を参照してください。

ホット パーティションを監視する方法

正規化された RU 消費量メトリックを使って、ワークロードにホット パーティションがあるかどうかを監視できます。 ホット パーティションが発生するのは、要求量の多さが原因で、1 つ以上の論理パーティション キーによって消費される RU/秒の合計量が不均衡な場合です。 この原因として考えられるのは、要求を均等に分散させないパーティション キーの設計です。 その結果、多くの要求が「ホット」となる論理パーティションの小さなサブセット（すなわちパーティションキーの範囲）に集中して送信されることが起こります。 論理パーティションのすべてのデータは 1 つのパーティション キー範囲に存在し、合計 RU/秒はすべてのパーティション キー範囲に均等に分散されるため、ホット パーティションでは 429 秒になり、スループットが非効率的に使用される可能性があります。

ホット パーティションを識別する方法

ホット パーティションがあるかどうかを確認するには、[分析情報]>[スループット]>[Normalized RU Consumption (%) By PartitionKeyRangeID]\(PartitionKeyRangeID ごとの正規化された RU 消費量 (%)\) に移動します。 フィルター処理して、特定のデータベースとコンテナーを表示します。

各 PartitionKeyRangeId は、1 つの物理パーティションにマップされます。 正規化された RU 消費量が他のパーティションよりも高い PartitionKeyRangeId がある場合 (たとえば、1 つは一貫して 100%で、他のパーティションは 30% 以下)、これはホット パーティションの兆候である可能性があります。

最大 RU/秒を消費する論理パーティションを識別するには、「 ホット パーティションを識別する方法」を参照してください。

RU消費の正規化とオートスケール

正規化された RU 消費量メトリックは、少なくとも 1 つのパーティション キー範囲が、時間間隔内の 1 秒ごとに割り当てられたすべての RU/秒を使用する場合、100% と表示されます。 よくある質問の 1 つは、正規化された RU 消費量が 100% であるのに、Azure Cosmos DB の自動スケーリングで RU/s が最大スループットにスケーリングされなかったのはなぜか、というものです。

自動スケーリングを使用すると、5 秒間隔で、継続して連続した期間だけ、正規化された RU 消費量が 100% になる場合に、Azure Cosmos DB で RU/s が最大スループットにスケーリングされます。 これは、単一の瞬間的なスパイクが不要なスケーリングとコストの増加に結びつかないようにすることで、スケーリング ロジックがユーザーにとってコストに優しいことを保証するために行われます。 瞬間的な急増が発生した場合は、通常、以前にスケーリングされた RU/秒より大きく、最大 RU/秒より小さい値にスケールアップされます。

たとえば、自動スケーリングの最大スループットが 20,000 RU/秒 (2000 から 20,000 RU/秒の間でスケーリング) と 2 つのパーティション キー範囲を持つコンテナーがあるとします。 各パーティション キー範囲は、1,000 から 10,000 RU/s の範囲でスケーリングできます。 自動スケーリングでは必要なすべてのリソースが事前にプロビジョニングされるため、いつでも最大 20,000 RU/s を使用できます。

次に、トラフィックが断続的に急増しているとします。

1 秒間、パーティション 1 は 10,000 RU/秒に急上昇し、次の 4 秒間は 1,000 RU/秒に低下します。

同時に、パーティション 2 は 8,000 RU/秒に急上昇し、次の 4 秒間は 1,000 RU/秒に低下します。

メトリックの動作は次のとおりです。

正規化された RU 消費量 (すべてのパーティションの中でのインターバルごとの最大使用量を示します) は、パーティション 1 がその最大値に 1 秒間達したため、100% 使用率を示しています。

ただし、 プロビジョニングされたスループットと自動スケーリングされた RU メトリック は、1 秒のスパイクのためだけに最大 RU/秒にスケールアップされません。 コスト効率が高い 5 秒間隔に基づいてスケーリングされます。 そのため、前の例では、パーティション 1 とパーティション 2 の RU 消費量は、5 秒の間隔に基づいて 10,000 RU/秒に達しません。

その結果、自動スケーリングが最大までスケーリングされなかった場合でも、その急激に変動する秒間に使用可能な合計 RU/秒を利用できました。 RU/秒の消費量を確認するには、オプトイン診断ログ機能を使用して、すべてのパーティション キー範囲で 1 秒あたりのレベルで RU/秒の全体的な消費量を照会できます。

CDBPartitionKeyRUConsumption
| where TimeGenerated >= (todatetime('2022-01-28T20:35:00Z')) and TimeGenerated <= todatetime('2022-01-28T20:40:00Z')
| where DatabaseName == "MyDatabase" and CollectionName == "MyContainer"
| summarize sum(RequestCharge) by bin(TimeGenerated, 1sec), PartitionKeyRangeId
| render timechart

一般的に、自動スケーリングを使う運用ワークロードでは、要求の 1% から 5% で 429 が発生し、エンド ツー エンドの待機時間が許容範囲内である場合、これは RU/s が完全に利用されているという正常な兆候です。 正規化された RU 消費量が 100% に達し、自動スケールが最大 RU/秒にスケールアップしない場合でも、全体的なレートは 429 秒と低いため、これは問題ありません。 必要な操作はありません。

正規化された要求ユニット消費量メトリックを表示する

1. Azure portal にサインインします。

2. 左側のナビゲーション バーから [監視] を選択し、[メトリック] を選択します。

   

3. [メトリック] ウィンドウから、[リソースの選択] を選択し、必要なサブスクリプションとリソース グループを選択します。 [リソースの種類] では、[Azure Cosmos DB accounts]\(Azure Cosmos DB アカウント\) を選択し、既存の Azure Cosmos DB アカウントの一つを選択し、[適用] を選択します。

   

4. 次に、使用可能なメトリックの一覧からメトリックを選択できます。 要求ユニット、ストレージ、待機時間、可用性、Cassandra などに固有のメトリックを選択できます。 この一覧で使用可能なすべてのメトリックの詳細については、「カテゴリ別のメトリック」の記事を参照してください。 この例では、[Normalized RU Consumption]\(正規化された RU 消費量\) メトリックを選択し、集計値として [最大] を選択します。

   これらの詳細に加えて、メトリックの [時間の範囲] と [時間の粒度] を選択することもできます。 最大で、過去 30 日間のメトリックを表示できます。 フィルターを適用すると、そのフィルターに基づいてグラフが表示されます。

   

正規化された RU 消費量メトリックのフィルター

メトリックと、特定の CollectionName、DatabaseName、PartitionKeyRangeID、Region によって表示されるグラフをフィルターすることもできます。 メトリックをフィルター処理するには、[ フィルターの追加] を選択し、 CollectionName や関心のある対応する値などの必要なプロパティを選択します。 これで、グラフには、選択した期間中のコンテナーの正規化された RU 消費量メトリックが表示されます。

[Apply splitting]\(分割の適用\) オプションを使用すると、メトリックをグループ化できます。 共有スループット データベースの場合、正規化された RU メトリックではデータベースの粒度でのみデータが表示され、コレクションごとのデータは表示されません。 そのため、共有スループット データベースでは、コレクション名による分割を適用してもデータは表示されません。

次の図に示すように、各コンテナーの正規化された要求ユニット消費量のメトリックが表示されます。

次のステップ

• Azure Monitor Log Analytics 診断設定を使用して Azure Cosmos DB データを監視する
• Azure Cosmos DB コントロール プレーン操作を監査する方法
• Azure Cosmos DB の要求率が大きすぎる (429) 例外を診断してトラブルシューティングする