Azure Cosmos DB for Apache Cassandra の操作のレート制限エラーを回避する

[アーティクル]
08/15/2024

適用対象: 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 Cosmos DB for Apache Cassandra のサーバー側の再試行機能のスクリーンショット

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 の Cassandra 用 API での一般的な問題のトラブルシューティング

Azure Cosmos DB でのスループットのプロビジョニングについては、次の記事を参照してください。

次の方法で共有