"要求率が大きすぎる" (429) 例外を診断してトラブルシューティングする

適用対象: NoSQL

"要求率が大きすぎる" という例外 (エラー コード 429) は、Azure Cosmos DB に対する要求がレート制限されていることを示します。

この記事には、NoSQL 用 API のさまざまな 429 状態コード エラーの既知の原因と解決策が記載されています。 MongoDB 用 API を使用している場合は、MongoDB 用 API の一般的な問題のトラブルシューティングを参照してください。

プロビジョニングされたスループットを使用する場合は、ワークロードに必要な、1 秒あたりの要求ユニット数 (RU/秒) で測定されるスループットを設定します。 読み取り、書き込み、クエリなどのサービスに対するデータベース操作では、一定量の要求ユニット (RU) が消費されます。 詳細については、要求ユニットに関する記事を参照してください。

1 秒間に、操作がプロビジョニングされた要求ユニットを超える量を消費した場合、Azure Cosmos DB は 429 例外を返します。 1 秒ごとに、使用可能な要求ユニットの数がリセットされます。

RU/秒を変更するアクションを実行する前に、レート制限の根本原因を理解し、基になる問題に対処することが重要です。

さまざまな種類の 429 例外に対応するさまざまなエラー メッセージがあります。

• 要求率が大きい。 より多くの要求ユニットが必要になる可能性があるため、変更は行われませんでした。
• The request didn't complete due to a high rate of metadata requests. (メタデータ要求率が高いため、要求が完了しませんでした。)
• The request didn't complete due to a transient service error. (一時的なサービス エラーのために要求が完了しませんでした。)

要求率が大きいです

これは最も一般的なシナリオです。 これは、データに対する操作によって消費される RU が、プロビジョニングされた RU/秒の数を超えた場合に発生します。 手動スループットを使用している場合、これは、プロビジョニングされた手動スループットよりも多くの RU/秒を消費する場合に発生します。 自動スケールを使用している場合は、プロビジョニングされた最大 RU/秒を超える使用量が発生します。 たとえば、手動スループット 400 RU/秒でプロビジョニングされたリソースがある場合、1 秒間に 400 を超える要求ユニットを消費すると 429 が表示されます。 自動スケーリングの最大 RU/秒が 4,000 RU/秒 (400 RU/秒から 4,000 RU/秒の間でスケーリング) のリソースがプロビジョニングされている場合、1 秒で 4,000 を超える要求ユニットを消費すると 429 応答が表示されます。

手順 1: メトリックを調べて、429 エラーが発生した要求のパーセンテージを確認する

429 エラー メッセージが表示されるということは、必ずしもデータベースまたはコンテナーに問題があることを意味するわけではありません。 手動スループットと自動スケーリングスループットのどちらを使用しても、429 応答のごく一部は通常であり、プロビジョニングした RU/秒を最大化していることを示しています。

調査方法

429 応答が発生したデータベースまたはコンテナーに対する要求のパーセンテージを、成功した要求の総数と比較して特定します。 Azure Cosmos DB アカウントから [分析情報]>[要求]>[状態コードごとの要求の合計数] に移動します。 フィルター処理して、特定のデータベースとコンテナーを表示します。

Azure Cosmos DB クライアント SDK とデータ インポート ツール (Azure Data Factory、バルク エグゼキューター ライブラリなど) は、429 が発生すると、既定では要求を自動的に再試行します。 通常は、9 回まで再試行します。 その結果、メトリックに 429 件の応答が表示されますが、これらのエラーがアプリケーションに返されていない可能性もあります。

推奨される解決策

一般に、運用ワークロードの 場合、429 応答で 1 から 5% の要求が表示され、エンド ツー エンドの待機時間が許容される場合、これは RU/秒が完全に利用されていることを示す正常な兆候です。 必要な操作はありません。 それ以外の場合は、次のトラブルシューティング手順に進みます。

自動スケーリングを使用している場合は、RU/s が最大 RU/s までスケーリングされていなくても、データベースまたはコンテナーに 429 応答が表示される可能性があります。 詳細については、「 自動スケーリングの要求レートが大きい」セクションを参照してください。

よくある質問の 1 つは、"Azure Monitor メトリックには 429 応答が表示されるが、自分のアプリケーションの監視では表示されないのはなぜか" です。Azure Monitor メトリクスで 429 応答が表示されるが、自分のアプリケーションには表示されない場合、その理由は、Azure Cosmos DB クライアント SDK automatically retried internally on the 429 responses と要求が、後続の再試行に既定で引き継がれることです。 その結果、429 状態コードがアプリケーションに返されません。 このような場合は、全体の割合が 1 から 5% であり、エンドツーエンドの待機時間がアプリケーションの許容範囲内であると仮定すると、通常、429 応答の全体的な割合は極小なので、無視しても安全です。

手順 2: ホット パーティションが発生しているかどうかを特定する

ホット パーティションが発生するのは、要求量の多さが原因で、1 つ以上の論理パーティション キーによって消費される RU/秒の合計量が不均衡な場合です。 この原因として考えられるのは、要求を均等に分散させないパーティション キーの設計です。 その結果、多くの要求が、ホットになる論理パーティション（物理パーティションを含意します）の小さなサブセットに指向されます。 論理パーティションのすべてのデータは 1 つの物理パーティションに存在し、合計 RU/秒は物理パーティション間で均等に分散されるため、ホット パーティションでは 429 応答が発生し、スループットが非効率的に使用される可能性があります。

ホット パーティションの原因となるパーティション分割戦略の例を次に示します。

• dateでパーティション分割された書き込み負荷の高いワークロード用の IoT デバイス データを格納するコンテナーがあります。 1 つの日付のすべてのデータは、同じ論理パーティションと物理パーティションに存在します。 毎日書き込まれるすべてのデータは同じ日付であるため、毎日ホット パーティションになります。

  • 代わりに、このシナリオでは、id (GUID またはデバイス ID) などのパーティション キー、またはとidを組み合わせたdateにより、値のカーディナリティが高くなり、要求ボリュームの分散が向上します。

• tenantIdによってパーティション分割されたコンテナーを持つマルチテナント シナリオがあります。 1 つのテナントが他のテナントよりもはるかにアクティブな場合は、ホット パーティションが発生します。 たとえば、最大のテナントのユーザー数が 100,000 人で、ほとんどのテナントのユーザー数が 10 人未満の場合、tenantID でパーティション分割すると、ホット パーティションが発生します。

  • この前述のシナリオでは、UserId などのより詳細なプロパティによってパーティション分割された、最大テナント用の専用コンテナーを使用することを検討します。

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

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

各 PartitionKeyRangeId は、1 つの物理パーティションにマップされます。 正規化された RU 消費量が他のパーティションよりもはるかに高い PartitionKeyRangeId がある場合 (たとえば、1 つは一貫して 100%で、他のパーティションは 30% 以下)、これはホット パーティションの兆候である可能性があります。 正規化された RU 消費量メトリックの詳細については、「 Azure Cosmos DB コンテナーまたはアカウントの正規化された RU/秒を監視する方法」を参照してください。

最も RU/秒を消費する論理パーティション キーを確認するには、 Azure 診断ログを使用します。 このサンプル クエリでは、各論理パーティション キーで 1 秒間に消費された合計要求ユニット数が合計されます。

 CDBPartitionKeyRUConsumption
 | where TimeGenerated >= ago(24hour)
 | where CollectionName == "CollectionName"
 | where isnotempty(PartitionKey)
 // Sum total request units consumed by logical partition key for each second
 | summarize sum(RequestCharge) by PartitionKey, OperationName, bin(TimeGenerated, 1s)
 | order by sum_RequestCharge desc

 AzureDiagnostics
 | where TimeGenerated >= ago(24hour)
 | where Category == "PartitionKeyRUConsumption"
 | where collectionName_s == "CollectionName"
 | where isnotempty(partitionKey_s)
 // Sum total request units consumed by logical partition key for each second
 | summarize sum(todouble(requestCharge_s)) by partitionKey_s, operationType_s, bin(TimeGenerated, 1s)
 | order by sum_requestCharge_s desc

このサンプル出力は、特定の分で、 Contoso の 値が約 12,000 RU/秒の論理パーティション キーが消費され、 Fabrikam 値を持つ論理パーティション キーが 600 RU/秒未満で消費されたことを示しています。 レート制限が発生した期間中にこのパターンが一貫して見られる場合、これはホット パーティションを示します。

推奨される解決策

適切なパーティション キーを選択する方法に関するガイダンスを確認します。

レート制限された要求のパーセンテージが高く、ホット パーティションがない場合:

• クライアント SDK、Azure portal、PowerShell、CLI、または ARM テンプレートを使用して、データベースまたはコンテナーの RU/秒を増や すことができます。 「プロビジョニングされたスループットのスケーリングに関するベスト プラクティス」に従って、設定する適切な RU/s を決定します。

レート制限された要求のパーセンテージが高く、根底にホット パーティションがある場合:

• 長期的には、コストとパフォーマンスを最大限に高めるには、 パーティション キーの変更を検討してください。 パーティション キーは更新できないため、この場合、異なるパーティション キーを持つ新しいコンテナーにデータを移行する必要があります。 Azure Cosmos DB では、この目的のためにライブ データ移行ツールがサポートされています。
• 短期的には、リソースの全体的な RU/秒を一時的に増やして、ホット パーティションのスループットを増やすことができます。 これは、RU/秒のオーバープロビジョニングとコストの増加につながるため、長期的な戦略としては推奨されません。
• 短期的には、スループットを パーティション間で再配布 (プレビュー) して、ホットな物理パーティションに RU/秒を割り当てることができます。 これは、ホット物理パーティションが予測可能で、かつ一貫性がある場合にのみ推奨されます。

手順 3: 429 応答を返す要求を特定する

429 応答が発生する要求を調査する方法

Azure 診断ログを使用して、429 応答を返す要求と、それらによって消費された RU の数を特定します。 このサンプル クエリでは、分レベルで集計されます。

 CDBDataPlaneRequests
 | where TimeGenerated >= ago(24h)
 | summarize throttledOperations = dcountif(ActivityId, StatusCode == 429), totalOperations = dcount(ActivityId), totalConsumedRUPerMinute = sum(RequestCharge) by DatabaseName, CollectionName, OperationName, RequestResourceType, bin(TimeGenerated, 1min)
 | extend averageRUPerOperation = 1.0 * totalConsumedRUPerMinute / totalOperations
 | extend fractionOf429s = 1.0 * throttledOperations / totalOperations
 | order by fractionOf429s desc

 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

たとえば、このサンプル出力は、ドキュメント作成要求の 30% がレート制限され、各要求が平均 17 RU を消費したことを示しています。

推奨される解決策

Azure Cosmos DB Capacity Planner を使用する

Azure Cosmos DB Capacity Planner を使用して、ワークロード (操作の量と種類、およびドキュメントのサイズ) に基づいて、プロビジョニングされる最高のスループットを把握できます。 サンプル データを提供することで、計算をさらにカスタマイズし、いっそう正確に見積もることができます。

ドキュメントの作成、置換、またはアップサート要求での 429 応答

NoSQL 用 API の既定では、すべてのプロパティに既定でインデックスが付けられます。 必要なプロパティにのみインデックスを付けるようにインデックス作成ポリシーを調整します。 これにより、作成ドキュメント操作ごとに必要な RU が減り、429 応答が表示される可能性が低くなります。また、プロビジョニングされた RU/秒の量が同じ場合に 1 秒あたりに高い操作を実現できます。

ドキュメントのクエリ要求での 429 応答

ガイダンスに従って、 RU 料金が高いクエリのトラブルシューティングを行います。

ストアド プロシージャの実行での 429 応答

ストアド プロシージャは、パーティション キー値に対する書き込みトランザクションが必要な操作に適しています。 多くの読み取りまたはクエリ操作では、ストアド プロシージャを使用しないことをお勧めします。 最適なパフォーマンスを実現するために、これらの読み取りまたはクエリ操作は、Azure Cosmos DB SDK を使用してクライアント側で実行する必要があります。

自動スケーリングで要求率が高い

この記事のすべてのガイダンスは、手動と自動スケーリングの両方のスループットに適用されます。

自動スケールを使用する場合、"自動スケーリングで 429 件の応答を表示することはできますか" という一般的な質問が発生します。

答えは 「はい」です。 これが発生する可能性がある主なシナリオは 2 つあります。

シナリオ 1: 消費された RU/秒全体がデータベースまたはコンテナーの最大 RU/秒を超えると、サービスはそれに応じて要求を調整します。 これは、手動でプロビジョニングされた、データベースまたはコンテナーのスループット全体を超えることに似ています。

シナリオ 2: ホット パーティションがある場合、つまり、他のパーティション キー値と比べて要求量が大きい論理パーティション キー値は、基になる物理パーティションが RU/秒の予算を超える可能性があります。 ベスト プラクティスとして、ホット パーティションを回避するには、ストレージとスループットの両方が均等に分散される適切なパーティション キーを選択します。 これは、手動スループットの使用時にホット パーティションが発生している場合と似ています。

たとえば、20,000 RU/秒の最大スループット オプションを選択し、4 つの物理パーティションを含む 200 GB のストレージを使用している場合は、各物理パーティションを 5000 RU/秒まで自動スケーリングできます。 特定の論理パーティション キーにホット パーティションがあった場合は、その場所の、基になる物理パーティションが 5000 RU/s を超える (つまり、100% の正規化された使用率を超える) と、429 応答が表示されます。

これらのシナリオをデバッグするには、手順 1、手順 2、および手順 3 のガイダンスに従います。

もう 1 つの一般的な質問は、正規化された RU 消費量が 100% であるのに、なぜ、自動スケーリングで最大 RU/秒にスケーリングされなかったのか" です。

これは、通常、一時的または断続的に使用量が急増するワークロードで発生します。 自動スケーリングを使用すると、5 秒間隔で、継続して連続した期間だけ、正規化された RU 消費量が 100% になる場合に、Azure Cosmos DB で RU/s が最大スループットにスケーリングされます。 これは、ユーザーにとってコスト効率の高いスケーリング ロジックとなるように行われます。これによって、瞬間的な 1 回の急増による、不要なスケーリングの実行と、コストの増加が防止されるためです。 瞬間的な急増が発生した場合は、通常、以前にスケーリングされた RU/秒より大きく、最大 RU/秒より小さい値にスケールアップされます。 詳細については、「 正規化された RU 消費量と自動スケーリング」を参照してください。

メタデータ要求に対するレート制限

メタデータのレート制限は、データベース、コンテナー、またはその両方で大量のメタデータ操作を実行すると発生する可能性があります。 メタデータ操作には、以下が含まれます。

• コンテナーまたはデータベースの作成、読み取り、更新、または削除
• Azure Cosmos DB アカウントのデータベースまたはコンテナーを一覧表示する
• 現在プロビジョニングされているスループットを確認するためのオファーに対するクエリ

これらの操作にはシステム予約 RU の制限があるため、データベースまたはコンテナーのプロビジョニングされた RU/秒を増やすことは効果がなく、推奨されません。 コントロール プレーン サービスの制限に関するページを参照してください。

調査方法

[分析情報]>[システム]>[状態コードごとのメタデータ要求数] に移動します。 必要に応じて、フィルター処理して特定のデータベースとコンテナーを表示します。

推奨される解決策

• アプリケーションでメタデータ操作を実行する必要がある場合、これらの要求を低いレートで送信するために、バックオフ ポリシーを実装することを検討します。

• 静的な Azure Cosmos DB クライアント インスタンスを使用します。 DocumentClient または CosmosClient が初期化されると、Azure Cosmos DB SDK により、整合性レベル、データベース、コンテナー、パーティション、オファーに関する情報など、アカウントに関するメタデータがフェッチされます。 この初期化では、大量の RU が消費される可能性があり、頻繁に実行する必要があります。 単一 DocumentClient インスタンスを、お使いのアプリケーションの有効期間中に使用します。

• データベースとコンテナーの名前をキャッシュします。 構成からデータベースとコンテナーの名前を取得するか、開始時にそれらをキャッシュします。 ReadDatabaseAsync/ReadDocumentCollectionAsync や CreateDatabaseQuery/CreateDocumentCollectionQuery などの呼び出しは、システム予約 RU 制限から使用されるサービスへのメタデータ呼び出しになります。 これらの操作は、頻繁には実行しないでください。

一時的なサービス エラーによるレート制限

この 429 エラーは、要求で一時的なサービス エラーが発生した場合に返されます。 データベースまたはコンテナーで RU/秒を増やすことは効果がなく、推奨されません。

推奨される解決策

要求をやり直してください。 エラーが数分間続く場合は、Azure portal からサポート チケットを提出してください。

次の手順

• Azure Cosmos DB コンテナーまたはアカウントの正規化された RU/秒を監視する
• Azure Cosmos DB .NET SDK を使用するときの問題の診断とトラブルシューティング
• .NET v3 と .NET v2 のパフォーマンス ガイドラインについて説明します
• NoSQL アカウント用 API で Azure Cosmos DB Java SDK v4 を使用する場合の問題のトラブルシューティング
• Azure Cosmos DB Java SDK v4 のパフォーマンスに関するヒント