適用対象: 
Cassandra
すべてのデータベース操作のコストは Azure Cosmos DB によって正規化され、要求ユニット (RU) によって表されます。 要求ユニットは、Azure Cosmos DB によってサポートされるデータベース操作を実行するために必要な CPU、IOPS、メモリなどのシステム リソースを抽象化する、パフォーマンスの通貨です。
Azure Cosmos DB for Apache Cassandra の操作は、テーブルのスループット制限 (RU 数) を超えると、レート制限 (OverloadedException/429) エラーで失敗することがあります。 これは、ここで説明されているように、クライアント側で処理できます。 レート制限エラーによる障害を処理するためのクライアント再試行ポリシーを実装できない場合は、サーバー側の再試行 (SSR) 機能を使用して、テーブルのスループット制限を超える操作を、短い遅延の後で自動的に再試行できます。 これはアカウント レベルの設定であり、アカウントのすべてのキー スペースとテーブルに適用されます。
Azure ポータルの使用
Azure portal にサインインします。
Azure Cosmos DB for Apache Cassandra アカウントに移動します。
[設定] セクションの下にある [機能] ペインにアクセスします。
[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 EnableCassandra DisableRateLimitingResponses次のコマンドは、機能の一覧から を削除することによって、データベース アカウント内のすべてのテーブルに対してサーバー側の再試行を
DisableRateLimitingResponsesにします。 この変更が有効になるまで、最大 15 分かかる場合があります。az cosmosdb update --name accountname --resource-group resourcegroupname --capabilities EnableCassandra
よく寄せられる質問
要求はどのように再試行されますか。
要求は、60 秒のタイムアウトに達するまで継続的に (何度も繰り返し) 再試行されます。 タイムアウトに達した場合、クライアントはそれに応じて読み取りまたは書き込みのタイムアウト エラーを受け取ります
SSR が最も役に立つのはどのようなときですか?
サーバー側の再試行 (SSR) は、スロットル エラーを回避できる 1 分未満の短い期間で急激なスパイクが発生した場合に最も役立ちます。 作業負荷が増加し、指定された RU を常に上回る場合、SSR はあまり役に立ちません。 RU を適切に増やすことをお勧めします。
クライアント側ではどのような設定が推奨されますか?
SSR が有効になった後、クライアント アプリは、サーバーの再試行 60 秒の設定を超えて読み取りタイムアウトを増やす必要があります。 念のため、90 秒にすることをお勧めします。
コード サンプル Driver3
SocketOptions socketOptions = new SocketOptions()
.setReadTimeoutMillis(90000);
コード サンプル Driver4
ProgrammaticDriverConfigLoaderBuilder configBuilder = DriverConfigLoader.programmaticBuilder()
.withDuration(DefaultDriverOption.REQUEST_TIMEOUT, Duration.ofSeconds(90));
サーバー側の再試行の影響はどのように監視するのですか。
[Azure Cosmos DB メトリック] ウィンドウでは、サーバー側で再試行されたレート制限エラー (429) を確認できます。 SSR が有効になっている場合、これらのエラーは処理され、サーバー側で再試行されるため、クライアントには送信されません。
Azure Cosmos DB リソース ログ内で、estimatedDelayFromRateLimitingInMilliseconds を含むログ エントリを検索することができます。
サーバー側の再試行を適用すると、整合性レベルに影響がありますか。
サーバー側の再試行は、整合性レベルには影響しません。 レートが制限されている場合、要求はサーバー側で再試行されます (エラー 429)。
クライアントに返される可能性のある種類のエラーは、サーバー側の再試行の影響を受けますか。
いいえ。サーバー側の再試行の影響を受けるのは、レート制限エラー (429) のみであり、これらはサーバー側で再試行されます。 この機能を使用すると、クライアント アプリケーション内でレート制限エラーを処理しなくてもよくなります。 その他のエラーはすべてクライアントに送信されます。
次の手順
一般的なエラーのトラブルシューティングの詳細については、次の記事を参照してください。
Azure Cosmos DB でのスループットのプロビジョニングについては、次の記事を参照してください。