翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

再試行動作

再試行動作には、SDK が AWS のサービスへのリクエストによる障害からの回復を試みるかに関する設定が含まれます。

standard 再試行モードとadaptive再試行モードの選択

の使用が により適していることが確実でない限り、standard再試行モードを使用することをお勧めしますadaptive。

adaptive モードを使用する場合、アプリケーションはスロットリングされる可能性のある各リソースを中心に設計されたクライアントを構築する必要があります。この場合、リソースは、各 について考えるよりも細かく調整されます AWS のサービス。 は、リクエストのスロットリングに使用する追加のディメンションを持つ AWS のサービス ことができます。Amazon DynamoDB サービスを例として使用しましょう。DynamoDB は、 AWS リージョン とアクセスされるテーブルを使用してリクエストを調整します。つまり、コードがアクセスしているテーブルの 1 つが、他のテーブルよりもスロットリングされている可能性があります。コードが同じクライアントを使用してすべてのテーブルにアクセスし、それらのテーブルの 1 つへのリクエストがスロットリングされた場合、アダプティブ再試行モードではすべてのテーブルのリクエストレートが低下します。コードは、R egion-and-table ペアごとに 1 つのクライアントを持つように設計する必要があります。adaptive モードの使用時に予期しないレイテンシーが発生した場合は、使用しているサービスの特定の AWS ドキュメントガイドを参照してください。

再試行モードの実装の詳細

以下は、standard と adaptive 再試行モードの両方の大まかな擬似コードです。

MakeSDKRequest() {
  attempts = 0
  loop {
    GetSendToken()
    response = SendHTTPRequest()
    RequestBookkeeping(response)
    if not Retryable(response)
      return response
    attempts += 1
    if attempts >= MAX_ATTEMPTS:
      return response
    if not HasRetryQuota(response)
      return response
    delay = ExponentialBackoff(attempts)
    sleep(delay)
  }
}

擬似コードで使用されるコンポーネントの詳細は次のとおりです。

GetSendToken:

トークンバケットは adaptive リトライモードでのみ使用されます。トークンバケットでは、リクエストを開始するためにトークンを用意しておく必要があるため、リクエストレートが最大になります。SDK クライアントは、リクエストを迅速に失敗させるか、トークンが使用可能になるまでブロックするように設定できます。

クライアント側のレート制限は、最初は、トークンの許容量を上限とする任意のレートでリクエストを送信できるようにするアルゴリズムです。ただし、スロットリングされたレスポンスが検出されると、クライアント rate-of-request はそれに応じて制限されます。また、応答の受信が正常に終了すると、それに応じてトークンの許容量が増加します。

アダプティブレート制限を使用すると、 SDKs は の容量をより適切に対応するために、リクエストの送信速度を遅くすることができます AWS のサービス。

SendHTTPRequest:

ほとんどの AWS SDKs は、接続プールを使用する HTTP ライブラリを使用して、HTTP リクエストを行うときに既存の接続を再利用できるようにします。通常、スロットリングエラーが原因でリクエストを再試行すると、接続は再利用されます。一時的なエラーが原因で再試行しても、リクエストは再利用されません。

RequestBookkeeping:

リクエストが正常に終了したら、再試行クォータを更新する必要があります。adaptive 再試行モードの場合のみ、maxsendrate 状態変数は受信した応答の種類に基づいて更新されます。

Retryable:

このステップでは、以下に基づいて応答を再試行できるかどうかを判断します。

一時的なエラー（HTTP ステータスコード 400、408、500、502、503、504）とスロットリングエラー（HTTP ステータスコード 400、403、429、502、503、509）はすべて再試行される可能性があります。SDK の再試行動作は、エラーコードまたはサービスからのその他のデータと組み合わせて決定されます。

MAX_ATTEMPTS:

config ファイル設定または環境変数によって指定されます。

HasRetryQuota

このステップでは、トークンを再試行クォータバケットで使用できるようにすることで、再試行リクエストをスロットルします。リトライクォータバケットは、正常に終了する可能性が低い再試行を防ぐためのメカニズムです。これらのクォータは SDK に依存し、多くの場合クライアントに依存し、場合によってはサービスエンドポイントにも依存します。利用可能な再試行クォータトークンは、さまざまな理由でリクエストが失敗すると削除され、成功すると補充されます。トークンがなくなると、再試行ループは終了します。

ExponentialBackoff

再試行可能なエラーの場合、再試行遅延は台形型エクスポネンシャルバックオフを使用して計算されます。SDK はジッター付きの切り捨て二進エクスポネンシャルバックオフを使用します。次のアルゴリズムは、i リクエストに対する応答の休止時間（秒単位）がどのように定義されているかを示しています。

seconds_to_sleep_i = min(b*r^i, MAX_BACKOFF)

前述のアルゴリズムでは、以下の値が適用されます。

b = random number within the range of: 0 <= b <= 1

r = 2

ほとんどの SDK では MAX_BACKOFF = 20 seconds です。確認のため、特定の SDK ガイドまたはソースコードを参照してください。

AWS SDKsとの互換性

以下の SDK は、このトピックで説明する機能と設定をサポートします。部分的な例外があれば、すべて記載されています。JVM システムプロパティ設定は、 AWS SDK for Java と AWS SDK for Kotlin でのみサポートされます。