翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
再試行動作
再試行動作には、 へのリクエストによる障害からの復旧SDKs方法に関する設定が含まれます AWS サービス。
この機能を設定するには、以下のように使用します。
retry_mode
- 共有 AWSconfig
ファイル設定AWS_RETRY_MODE
- 環境変数aws.retryMode
- JVMシステムプロパティ: Java/Kotlin のみ-
SDK またはデベロッパーツールが再試行を試みる方法を指定します。
デフォルト値: この値は に固有ですSDK。特定のSDKガイドまたは SDKのコードベースでデフォルトの を確認してください
retry_mode
。有効値:
-
standard
– (推奨) 全体で推奨される再試行ルールのセット AWS SDKs。このモードには、再試行されるエラーの標準セットが含まれており、再試行回数を自動的に調整して可用性と安定性を最大化します。このモードは、マルチテナントアプリケーションで安全に使用できます。max_attempts
が明示的に設定されていない限り、このモードでのデフォルトの最大試行回数は 3 回です。 -
adaptive
– 標準モードの機能やクライアント側の自動レート制限を含む、特殊なユースケースにのみ適した再試行モード。この再試行モードは、アプリケーションテナントを分離するように注意しない限り、マルチテナントアプリケーションにはお勧めしません。詳細については、「standard 再試行モードとadaptive再試行モードの選択」を参照してください。このモードは実験的であり、将来的に動作が変わる可能性があります。 -
legacy
– (非推奨) に固有の SDK (特定のSDKガイドまたは SDKのコードベースを確認してください)。
-
max_attempts
- 共有 AWSconfig
ファイル設定AWS_MAX_ATTEMPTS
- 環境変数aws.maxAttempts
- JVMシステムプロパティ: Java/Kotlin のみ-
1 回のリクエストで行う最大試行回数を指定します。
デフォルト値:この値が指定されていない場合、デフォルトは
retry_mode
の設定の値によって異なります。-
retry_mode
が の場合legacy
– に固有のデフォルト値を使用します SDK (max_attempts
デフォルトについては、特定のSDKガイドまたは SDKのコードベースを確認してください)。 -
retry_mode
がstandard
の場合 – 3 回試行します。 -
retry_mode
がadaptive
の場合 – 3 回試行します。
有効な値: 0 より大きい数値。
-
standard
再試行モードとadaptive
再試行モードの選択
の使用が により適していることが確実でない限り、standard
再試行モードを使用することをお勧めしますadaptive
。
注記
adaptive
モードは、バックエンドサービスがリクエストをスロットリングするスコープに基づいてクライアントをプールすることを前提としています。これを行わないと、両方のリソースに同じクライアントを使用している場合、1 つのリソースのスロットリングにより、無関係なリソースのリクエストが遅延する可能性があります。
標準 | アダプティブ |
---|---|
アプリケーションのユースケース: すべて。 | アプリケーションのユースケース:
|
サーキットブレークをサポートして、停止中に SDKが再試行するのを防ぎます。 | サーキットブレークをサポートして、停止中に SDKが再試行するのを防ぎます。 |
障害発生時にジッターされたエクスポネンシャルバックオフを使用します。 | 動的バックオフ期間を使用して、レイテンシーが増加する可能性と引き換えに、失敗したリクエストの数を最小限に抑えるように試みます。 |
最初のリクエストの試行を遅らせず、再試行のみを行います。 | 最初のリクエスト試行をスロットリングまたは遅延させることができます。 |
adaptive
モードを使用する場合、アプリケーションはスロットリングされる可能性のある各リソースを中心に設計されたクライアントを構築する必要があります。この場合、リソースは、各 について考えるよりも細かく調整されます AWS サービス。 は、リクエストのスロットリングに使用する追加のディメンションを持つ AWS サービス ことができます。Amazon DynamoDB サービスを例として使用しましょう。DynamoDB は、 AWS リージョン とアクセスされるテーブルを使用してリクエストを調整します。つまり、コードがアクセスしている 1 つのテーブルは、他のテーブルよりもスロットリングされる可能性があります。コードが同じクライアントを使用してすべてのテーブルにアクセスし、それらのテーブルの 1 つへのリクエストがスロットリングされた場合、アダプティブ再試行モードでは、すべてのテーブルのリクエストレートが低下します。コードは、R egion-and-table ペアごとに 1 つのクライアントを持つように設計する必要があります。adaptive
モードの使用時に予期しないレイテンシーが発生した場合は、使用しているサービスの特定の AWS ドキュメントガイドを参照してください。
再試行モードの実装の詳細
は AWS SDKs、トークンバケットadaptive
再試行モードの場合) を決定します。では、SDK再試行トークンバケットとリクエストレートトークンバケットの 2 つのトークンバケットが使用されます。
-
再試行トークンバケットは、停止中にアップストリームサービスとダウンストリームサービスを保護するために、 がSDK一時的に再試行を無効にする必要があるかどうかを判断するために使用されます。トークンは再試行する前にバケットから取得され、リクエストが成功するとトークンはバケットに返されます。再試行時にバケットが空の場合、 SDK はリクエストを再試行しません。
-
リクエストレートトークンバケットは、リクエストの送信レートを決定するために
adaptive
、再試行モードでのみ使用されます。トークンはリクエストの送信前にバケットから取得され、サービスによって返されるスロットリングレスポンスに基づいて動的に決定されたレートでバケットに返されます。
以下は、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場合があります。バケット内のトークンは、クライアントが受信したスロットリングレスポンスの数に基づいて動的に決定されるレートで補充されます。
SendHTTPRequest
:
このステップでは、 リクエストを に送信します AWS。ほとんどの AWS SDKs は、HTTPリクエストを行うときに接続プールを使用して既存の接続を再利用する HTTPライブラリを使用します。通常、スロットリングエラーが原因でリクエストが失敗した場合、接続は再利用されますが、一時的なエラーが原因でリクエストが失敗した場合は再利用されません。
RequestBookkeeping
:
リクエストが成功すると、トークンがトークンバケットに追加されます。adaptive
再試行モードのみの場合、リクエストレートトークンバケットのフィルレートは、受信したレスポンスのタイプに基づいて更新されます。
Retryable
:
このステップでは、以下に基づいて応答を再試行できるかどうかを判断します。
-
HTTP ステータスコード。
-
サービスから返されたエラーコード。
-
接続エラー。サービスからのHTTP応答を受信しない SDK が受信したエラーとして定義されます。
一時的なエラー (HTTPステータスコード 400、408、500、502、503、504) とスロットリングエラー (HTTPステータスコード 400、403、429、502、503、509) はすべて再試行される可能性があります。SDK 再試行動作は、エラーコードまたはサービスからの他のデータと組み合わせて決定されます。
MAX_ATTEMPTS
:
デフォルトの最大試行回数は、 retry_mode
設定によって上書きされない限り、 max_attempts
設定によって設定されます。
HasRetryQuota
このステップでは、再試行トークンバケットからトークンを取得します。再試行トークンバケットが空の場合、リクエストは再試行されません。
ExponentialBackoff
再試行可能なエラーの場合、再試行遅延は台形型エクスポネンシャルバックオフを使用して計算されます。は、ジッターで切り捨てられたバイナリエクスポネンシャルバックオフSDKsを使用します。次のアルゴリズムは、i
リクエストに対する応答の休止時間(秒単位)がどのように定義されているかを示しています。
seconds_to_sleep_i = min(b*r^i, MAX_BACKOFF)
前述のアルゴリズムでは、以下の値が適用されます。
b = random number within the range of: 0 <= b <= 1
r = 2
MAX_BACKOFF = 20 seconds
ほとんどの では ですSDKs。確認については、特定のSDKガイドまたはソースコードを参照してください。
との互換性 AWS SDKs
このトピックで説明されている機能と設定SDKsを以下に示します。部分的な例外があれば、すべて記載されています。JVM システムプロパティ設定は、 AWS SDK for Java と AWS SDK for Kotlin のみでサポートされます。
SDK | サポート | 注意または詳細情報 |
---|---|---|
AWS CLI v2 | あり | |
SDK C++ 用 | あり | |
SDK Go V2 用 (1.x) |
あり | |
SDK Go 1.x (V1) 用 | なし | |
SDK for Java 2.x | あり | |
SDK for Java 1.x | あり | JVM システムプロパティ: com.amazonaws.sdk.maxAttempts の代わりに を使用しaws.maxAttempts 、 com.amazonaws.sdk.retryMode の代わりに を使用しますaws.retryMode 。 |
SDK JavaScript 3.x 用 | あり | |
SDK JavaScript 2.x の場合 | なし | 最大再試行回数、ジッターを伴うエクスポネンシャルバックオフ、再試行バックオフのカスタムメソッドのオプションをサポートします。 |
SDK Kotlin 用 | あり | |
SDK の 。NET 3.x | あり | |
SDK 3.x PHP 用 | あり | |
SDK for Python (Boto3) |
あり | |
SDK Ruby 3.x 用 | あり | |
SDK Rust 用 | あり | |
のツール PowerShell | あり |