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

再試行動作

一時的なエラーまたはスロットリングが原因で へのリクエストが AWS のサービス 失敗した場合、SDK は自動的にリクエストを再試行できます。このページでは、再試行の設定方法と内部での仕組みについて説明します。

再試行の設定

SDK が使用する再試行戦略と再試行回数を制御します。

再試行モードの選択

再試行モードは、リクエストが失敗した場合の SDK の動作を決定します。標準、アダプティブ、レガシーの 3 つのモードを使用できます。

標準モード (デフォルト)

標準モードでは、ジッターを使用したエクスポネンシャルバックオフを使用して、失敗したリクエストを再試行します。一時的なエラー (ネットワークタイムアウトなど) には短い遅延を使用し、スロットリングエラー ( など) には長い遅延を使用しますThrottlingException。

標準モードには、再試行クォータ、再試行ごとにトークンを差し引き、リクエストが成功したときにトークンを補充するトークンバケットが含まれます。使用可能なトークンを使い果たすと、SDK は再試行せずにエラーを返すため、成功する可能性が低い再試行を待つ代わりに、アプリケーションは迅速に失敗します。これにより、再試行トラフィックを減らすことで、サービスの中断をより迅速に解決できます。通常のオペレーション中、クォータは満杯のままで、効果はありません。再試行クォータは、最初のリクエストを遅延またはブロックしません。再試行のみが影響を受けます。詳細については、「再試行クォータ (トークンバケット)」を参照してください。

別のモードを選択する特定の理由がない限り、標準モードを使用します。

アダプティブモード

アダプティブモードには、標準モードのすべてのものに加えて、クライアント側のレートリミッターが含まれます。レートリミッターはスロットリングレスポンスを追跡し、SDK がリクエストを送信するレートを調整します。標準モードとは異なり、アダプティブモードは、スロットリングが検出されたときに再試行だけでなく、最初のリクエストを遅延またはブロックする可能性があります。

レートリミッターは SDK クライアントインスタンスごとに動作します。クライアントからのすべてのリクエストは、ターゲットとする API オペレーションまたはリソースに関係なく、同じレート制限を共有します。

アダプティブモードを使用するタイミング:

アダプティブモードを使用しない場合:

アダプティブモードは、一般的なデフォルトとしてお勧めしません。

レガシーモード

レガシーモードは、標準モードが導入される前に各 SDK が使用した再試行動作です。標準化された再試行クォータは含まれません。一部の SDKs (Java など) には、レガシーモードで独自の再試行クォータ実装がありますが、動作は SDKs 間で一貫性がありません。標準化されたクォータがない場合、クライアントはサービスの中断中も引き続きフルレートで再試行します。これにより、成功する可能性の低いリクエストのスレッドと接続が結び付けられ、サービスの復旧を遅らせる可能性のある負荷が追加されます。

レガシーモードは SDKsによって異なります。再試行回数、バックオフタイミング、再試行可能なエラーセット、スロットリング動作は言語によって異なります。レガシーの再試行動作に依存するコードは、SDKs 間で移動すると動作が異なる場合があります。

使用可能: Java、Python、Ruby、PHP、C++、CLI

.NET、Go、Kotlin、Rust、Swift、JavaScript では使用できません

下位互換性のためにレガシーモードがあります。現在レガシーモードを使用している場合は、標準モードに切り替えます。

設定を再試行する

以下の設定は再試行動作を制御します。環境変数、共有設定ファイル (~/.aws/config)、またはコード内のクライアント設定を使用して設定できます。

最大試行値 は、SDK が 1 回の初回リクエストと最大 2 回の再試行を行う3ことを意味します。再試行を完全に無効に1する最大試行回数を設定します。

設定の優先順位

複数の場所で同じ設定を指定すると、SDK は、最大値から最小値まで、次の優先順位を使用して値を解決します。

これは、標準の AWS SDK 設定の優先順位に従います。より高いレベルで設定された値は、常により低いレベルで設定された値を上書きします。たとえば、 を環境変数AWS_RETRY_MODE=adaptiveとして設定し、 retry_mode=standardで を設定すると~/.aws/config、SDK はアダプティブモードを使用します。

言語固有の設定

このページで説明されているクロス SDK 設定 (retry_mode および max_attempts) は、すべての SDKs。ただし、コードで再試行を設定するための API は言語によって異なります。カスタムバックオフ戦略、追加の再試行可能なエラー、再試行クォータの調整などの言語固有の設定オプションについては、 SDK の開発者ガイドを参照してください。

再試行の仕組み

このセクションでは AWS SDKs が失敗したリクエストを処理する方法について説明します。再試行をトリガーするエラー、SDK が試行間隔を待機する時間、再試行を停止する時間などです。

リクエストが失敗するとどうなるか

AWS SDK を介して API コールを行うと、SDK は次のシーケンスに従います。

SDK は、リクエストが成功するか、最大試行回数に達するか、再試行クォータが枯渇するか、再試行不可能なエラーが発生するまで、このループを繰り返します。プロセス全体は自動的に行われます。アプリケーションには、成功したレスポンスまたは最終エラーが表示されます。

再試行されるエラー

SDK は、失敗した各リクエストを、一時的、スロットリング、または再試行不可能な 3 つのカテゴリのいずれかに分類します。この分類は、SDK がリクエストを再試行するかどうかと、再試行するまでの待機時間を決定します。

分類は、サービスレスポンスのエラーコードと HTTP ステータスコードに基づいています。たとえば、エラーコードを持つ HTTP 400 RequestTimeoutは一時的なものとして分類され、再試行されます。を持つ HTTP 400 ValidationExceptionは再試行不可として分類され、すぐに返されます。

エラー分類

一時的なエラーは、短い基本遅延 (50 ミリ秒) で再試行されます。

スロットリングエラーは、より長い基本遅延 (1,000 ミリ秒) で再試行されます。

再試行不可能なエラー (AccessDeniedException、、 などResourceNotFoundException) ValidationExceptionは、すぐにコードに返されます。

スロットリングエラーは、レート制限のためにサービスがリクエストをアクティブに拒否したことを意味するため、SDK はサービスを再試行して容量を回復する時間を与えるまでより長く待機します。特定の遅延SDK が待機する期間については、「」を参照してください。

SDK が待機する期間

SDK は、完全なジッターでエクスポネンシャルバックオフを使用します。平均して、各再試行は最後の再試行よりも長く待機し、ランダム化によって複数のクライアントからのリクエストが分散されます。

エラータイプ別の基本遅延

基本遅延は、エラーが一時的かスロットリングかによって異なります。

バックオフ式

SDK は、次の式を使用して各再試行遅延を計算します。

delay = random(0, 1) × min(20,000 ms, base_delay × 2^retry)

説明は以下のとおりです。

最大バックオフ上限は 20 秒です。試行回数に関係なく、個々の遅延が 20 秒を超えることはありません。

実例

例 1: 一時的なエラー、最大試行回数 3

追加されたレイテンシーの合計は、両方の再試行で平均約 75 ミリ秒です。

例 2: スロットリングエラー、最大試行回数 3

追加されたレイテンシーの合計は、両方の再試行で平均約 1,500 ミリ秒です。

例 3: バックオフの上限に達した一時的なエラー

基本遅延が 50 ミリ秒の場合、キャッピング前の計算遅延は次のようになります。

この上限は、一時的なエラーに対して 10 回目の再試行 (11 回目の試行) で有効になります。ベースが 1,000 ミリ秒のスロットリングエラーの場合、上限は 6 回目の再試行時に有効になります。

ジッターが重要な理由

ランダム乗数はフルジッターと呼ばれます。これがないと、同時にエラーが発生したすべてのクライアントが同時に再試行し、再試行トラフィックのバースト (「群れの雷」問題) が発生します。フルジッターはバックオフウィンドウ全体に均等に再試行を分散するため、サービスは同期されたスパイクではなくリクエストの安定したトリクルを受け取ります。

たとえば、1,000 のクライアントがすべて同時に 503 を受け取るとします。フルジッターは、1,000 回すべてを正確に 50 ミリ秒で再試行するのではなく、最初の再試行を 50 ミリ秒のウィンドウに均等に分散します。

サーバー指向の再試行タイミング

エラーレスポンスに x-amz-retry-afterヘッダー AWS のサービス を含むものもあります。ヘッダー値はミリ秒単位の遅延です。このヘッダーが存在する場合、SDK はサーバー指定の遅延を使用し、計算されたバックオフ遅延の最小値と計算されたバックオフ遅延の最大値に 5,000 ミリ秒を加えた値にクランプします。計算されたバックオフ自体は 20 秒に制限されるため、有効なサーバー指向の最大遅延は 25 秒です。サービスはジッターすることが予想されるため、SDK はこの値にジッターを適用しません。これにより、サービスが容量が利用可能になると予想されるときに正確に通信できるようになります。

再試行クォータ (トークンバケット)

SDK は、成功したリクエストと失敗の比率を追跡する内部トークン予算を維持します。失敗が広範囲に及ぶと、予算は枯渇し、SDK はエラーを直接返します。成功する可能性が低い再試行を待つ代わりに、アプリケーションは迅速に失敗します。これにより、再試行トラフィックも減り、サービスの中断を迅速に解決できます。

再試行クォータの仕組み

トークン予算は満杯で開始されます。再試行するたびにトークンが差し引かれます。再試行が成功すると、SDK はその再試行で消費されたトークンを復元します。最初の試行でリクエストが成功すると (再試行不要）、SDK は 1 トークンを復元します。予算がゼロに達すると、SDK は再試行を停止し、コードに直接エラーを返します。

一時的な再試行のコストが高いほど、さまざまな障害パターンが反映されます。500 代などの一時的なエラーや接続の失敗は、多くの場合、サービス全体の問題を示します。このような状況では、継続的な再試行が成功する可能性はほとんどありません。これにより、通話にレイテンシーが追加され、クライアントリソースが結び付けられ、すべてのユーザーの復旧が遅れる可能性があります。スロットリングエラーは、リクエストが成功するまでにサービスにより多くの時間が必要であることを示します。SDK は再試行の間隔を長くして、成功の可能性を向上させます。

がクォータブロックを再試行するタイミング

再試行クォータはトークンを常に追跡しますが、予算が枯渇したときにのみ再試行をブロックします。通常のオペレーションでは、ほぼすべてのリクエストが成功し、予算は満杯のままになります。クォータは再試行に観測可能な影響を与えません。

再試行が成功すると、同じリクエストで以前に失敗した再試行のコストではなく、独自のトークンコスト (14 または 5 トークン) のみが復元されます。たとえば、最初の再試行が失敗し、2 回目の再試行が成功すると、予算は 14 トークン純減します。予算は、再試行が成功せずにすべての試行を枯渇させると速くドレインしますが、リクエストが成功する前に複数回の再試行を必要とすると徐々にドレインします。

デフォルトで最大試行回数が 3 回の場合、リクエストの約 22% を超えると一時的な障害が持続し、スロットリングエラーの場合は約 32% を超えると、クォータがドレインし始めます。これらのレートを下回ると、成功したリクエストは、失敗した再試行よりも速く予算を補充します。

予算の開始バランスである 500 トークンは、短い障害バーストを吸収するバッファを提供します。エラーが短時間急増しても、バッファをドレインするのに十分な時間持続しない限り、再試行はブロックされません。

実用的な影響

サービス固有の動作

DynamoDB

DynamoDB クライアントは、DynamoDB の低レイテンシープロファイル用に最適化されたチューニングされたデフォルトを使用します。

これらのデフォルトは、Amazon DynamoDB ストリームと DynamoDB ストリームの両方に適用されます。

ロングポーリングオペレーション

特定の AWS オペレーションでは、ロングポーリングが使用されます。接続を開いたままにして、作業が到着するのを待つことができます。これらのオペレーションは、特別な再試行処理を受け取ります。

特殊な動作: 再試行クォータが枯渇し、再試行がブロックされた場合 (「」のステップ 7リクエストが失敗するとどうなるか)、SDK はエラーをコードに返す前にバックオフ遅延を適用します。

これは、ロングポーリングオペレーションは通常、タイトループで呼び出されるため重要です。コードは を呼び出しReceiveMessage、メッセージを処理し、すぐにReceiveMessage再度 を呼び出します。強制バックオフがない場合、トークン予算が枯渇すると、SDK は遅延なくエラーを返すことになります。その後、ポーリングループはすぐに次のリクエストを送信し、クライアントの CPU 使用率をスパイクして、追加のトラフィックを生成します。強制バックオフ遅延はこのサイクルを中断し、障害発生時にクライアントリソースの使用状況とポーリングレートを管理できるようにします。

AWS SDKsとツールによるサポート

次の表に、各 SDK で更新された再試行動作の可用性を示します。最小バージョン、before-and-afterデフォルト、コード例など、SDK 固有の詳細については、GitHub 追跡の問題を参照してください。