レート制限エラーを確認する
状態コード 429 は、要求率が大きすぎるという例外が発生した場合に返されます。 この状態コードは、Azure Cosmos DB に対する要求がレート制限されていることを示します。
プロビジョニング済みのスループットが使用される場合、ワークロードに対しては、1 秒あたりの要求ユニット数 (RU/秒) が設定されます。 サービスに対する操作 (読み取り、書き込み、クエリ) を実行すると、要求ユニット (RU) が消費されます。 操作を実行する際、1 秒の間に、プロビジョニング済みの RU/秒よりも多くの RU が消費された場合には、Azure Cosmos DB によって 429 例外が返されます。 それでは、この例外が発生する 3 種類の理由について見ていきましょう。
要求率が大きいです
429 例外の最も一般的な原因は、要求率が大きいことです。 [要求] タブにある Azure Cosmos DB Insight レポート Total Request by Status Code で、この例外の発生件数を確認してください。データベースで成功した要求に対する 429 例外の割合を確認します。
既定では、Azure Cosmos DB SDK は 429 例外を 10 回再試行してから、429 例外をアプリケーションに返します。 SDK の再試行回数を超えると、アプリケーションにエラーが返されます。 理想的には、応答の x-ms-retry-after-ms ヘッダーを調べてヒントとして使い、要求を再試行する前に待機する時間を決定できます。 もう 1 つの方法はエクスポネンシャル バックオフ アルゴリズムであり、429 例外に対する再試行の間隔を長くするようにクライアントを構成します。
グラフを分析してみて、429 例外を生成しているワークロード要求が 1% から 5% である場合、エンドツーエンドの待機時間が許容範囲であれば、特にアクションは必要ありません。 例外の発生率がこの程度の小さな割合であれば、RU/秒の使用率は正常と判断できます。
ただし、429 例外の発生率が 5% を超えている場合は、ホット パーティションが原因で例外が発生している可能性があります。 比較的少数の論理パーティション キーによって、1 秒あたりの合計要求ユニット数の大部分が消費されている場合は、ホット パーティションが発生している可能性があります。 ホット パーティションが発生すると、複数のパーティション間でスループットが適切に分散されないことにより、429 例外が発生する可能性があります。
429 例外の割合の監視に加え、これらと共に監視すべきもう 1 つの重要なメトリックは、要求の平均待ち時間です。 サービスつまりアプリケーションが 429 例外のために要求を再試行すると、操作が完了するまで待つ必要があるため、待ち時間が長くなります。 この値が長すぎてアプリケーションで許容できない場合は、原因がホット パーティションによるものでないなら、同時実行操作の量を処理するためにコンテナーのスループットを増やすことが必要になる可能性があります。
ホット パーティションが発生しているかどうかを確認するには、[スループット] タブにある Azure Cosmos DB Insight レポート Normalized RU Consumption (%) By PartitionKeyRangeID を調べます。このレポートでは、PartitionKeyRangeID が各物理パーティションを示しています。 このグラフで、消費量が非常に多い物理パーティションがある場合は、それがホット パーティションである可能性があります。 その物理パーティションが常に100%の状態を維持している一方で、他の物理パーティションはほとんど常にそれよりも大幅に低い割合である場合、それが特に当てはまります。
429 例外の原因となっている要求の種類を特定したい場合は、Azure 診断ログでクエリを実行することで、RU の消費数を要求の種類別に確認することができます。 次のサンプル クエリは、429 例外が発生する操作について、操作あたりの毎分平均 RU を返します。
AzureDiagnostics
| where TimeGenerated >= ago(24h)
| where Category == "DataPlaneRequests"
| summarize throttledOperations = dcountif(activityId_g, statusCode_s == 429), totalOperations = dcount(activityId_g), totalConsumedRUPerMinute = sum(todouble(requestCharge_s)) by databaseName_s, collectionName_s, OperationName, requestResourceType_s, bin(TimeGenerated, 1min)
| extend averageRUPerOperation = 1.0 * totalConsumedRUPerMinute / totalOperations
| extend fractionOf429s = 1.0 * throttledOperations / totalOperations
| order by fractionOf429s desc
この種の 429 例外に対する解決策としては、次の方法が考えられます。
- ホット パーティションが原因で 429 例外が発生していると判断できる場合は、パーティション キーを変更することを検討してください。 これを実現するには、新しいパーティション キーを使って新しいコンテナーにデータを移行します。 これを行う方法については、オプションについてのドキュメントを参照してください。
- 例外の原因がホット パーティションでない場合は、コンテナーの RU/秒 を増やすことで解決できる可能性があります。
- ドキュメントのクエリ要求で例外が発生している場合は、RU 負荷の高いクエリをトラブルシューティングしてください。
メタデータ要求のレート制限
大量のメタデータ操作を実行すると、429 例外が発生する可能性があります。 メタデータ操作とは、データベースまたはコンテナーを一覧表示、作成、変更、または削除する操作のことです。 また、現在プロビジョニングされているスループットを照会する操作なども、これに該当する可能性があります。
[システム] タブにある、Azure Cosmos DB Insight レポート Metadata Requests That Exceeded Capacity (429s) で、この種類の 429 例外の発生件数を確認してください。
この種類の要求が原因で 429 例外が発生している場合、プロビジョニング済みの RU/秒を増やすことはお勧めできません。 プロビジョニング済みの RU/秒を増やしても、例外の発生に影響はありません。 メタデータ要求については、システム予約による RU 制限があります。
メタデータ要求が原因で発生した 429 例外については、次の解決方法が考えられます。
- メタデータ要求をより低いレートで実行するためのバックオフ ポリシーを実装することを検討する。
- アプリケーションの有効期間中を通じて、単一の CosmosClient インスタンスを使います。
- アプリケーション内でデータベースとコンテナーの名前をキャッシュします。
一時的なサービス エラーに起因するレート制限
この種類の要求が原因で 429 例外が発生している場合、プロビジョニング済みの RU/秒を増やすことはお勧めできません。 プロビジョニング済みの RU/秒を増やしても、例外の発生に影響はありません。 要求を再試行することが、推奨される唯一の解決方法です。例外が引き続き発生する場合は、Azure portal からサポート チケットを開いてください。 一時的なサービス エラーは、429 エラーの発生時とほぼ同時に報告される場合もあります。