Azure Cosmos DB for MongoDB の操作のレート制限エラーを回避する
適用対象: MongoDB
Azure Cosmos DB for MongoDB の操作は、コレクションのスループット制限 (RU) を超えると、レート制限が発生する可能性があり、その結果 mongo 要求メトリックで 16500 エラーが発生します。
サーバー側の再試行 (SSR) を有効にして、操作の再試行を自動化します。 SSR を使用すると、アカウント内のすべてのコレクションに対して短い待ち時間で要求が再試行されます。 60 秒のタイムアウトに達すると、クライアントに ExceededTimeLimit 例外 (50) が返されます。
Azure ポータルの使用
Azure portal にサインインします。
Azure Cosmos DB for MongoDB アカウントに移動します。
[設定] セクションの下にある [機能] ペインにアクセスします。
[Server Side Retry](サーバー側の再試行) を選択します。
[有効化] をクリックして、アカウント内のすべてのコレクションに対してこの機能を有効にします。
Azure CLI の使用
ご利用のアカウントで SSR が既に有効になっているかどうかを確認します。
az cosmosdb show --name accountname --resource-group resourcegroupname
ご利用のデータベース アカウント内のすべてのコレクションに対して SSR を有効にします。 この変更が有効になるまで、最大 15 分かかる場合があります。
az cosmosdb update --name accountname --resource-group resourcegroupname --capabilities EnableMongo DisableRateLimitingResponses
次のコマンドは、機能の一覧から
DisableRateLimitingResponses
を削除することによって、データベース アカウント内のすべてのコレクションに対してサーバー側の再試行を無効にします。 この変更が有効になるまで、最大 15 分かかる場合があります。az cosmosdb update --name accountname --resource-group resourcegroupname --capabilities EnableMongo
よく寄せられる質問
サーバー側の再試行の影響はどのように監視するのですか。
Azure Cosmos DB リソース ログ内で、estimatedDelayFromRateLimitingInMilliseconds を含むログ エントリを検索することができます。
サーバー側の再試行を適用すると、整合性レベルに影響がありますか。
サーバー側の再試行を適用しても、要求の整合性に影響はありません。 要求は、レート制限を受けた場合、サーバー側で再試行されます。
クライアントに返される可能性のある種類のエラーは、サーバー側の再試行の影響を受けますか。
いいえ。サーバー側の再試行の影響を受けるのは、レート制限エラーのみであり、これらはサーバー側で再試行されます。 この機能を使用すると、クライアント アプリケーション内でレート制限エラーを処理しなくてもよくなります。 他のエラーはすべて、クライアントに返されます。
次の手順
一般的なエラーのトラブルシューティングの詳細については、次の記事を参照してください。
Azure Cosmos DB に移行する容量計画を実行しようとしていますか? 容量計画のために、既存のデータベース クラスターに関する情報を使用できます。
- パーティション間でスループットを再分散する方法については、「パーティション間でスループットを再分散する方法」を確認してください
- 既存のデータベース クラスター内の仮想コアとサーバーの数のみがわかっている場合は、仮想コア数または仮想 CPU 数を使用した要求ユニットの見積もりに関するページを参照してください
- 現在のデータベース ワークロードに対する通常の要求レートがわかっている場合は、Azure Cosmos DB Capacity Planner を使用した要求ユニットの見積もりに関するページを参照してください