AWS SDK によるリトライモードには legacy と standard そして試験的ステータスである adaptive があり、デフォルトで何も指定しない場合は legacy になる。リトライをあまり意識せずに使うことも多いと思うが、レガシーと名のついたモードを使い続けるのも抵抗があるので、基本的には指定すべきと思われる。これらの違いについて整理してみた。
概要
参考) Retry behavior - AWS SDKs and Tools
各モードの概要は以下のとおり。
- legacy : デフォルのリトライ。言語ごとに挙動は異なる。
- standard : 標準的なリトライルール。標準的なエラーセットとリトライクオータをサポートする。デフォルト(未指定時)の最大試行回数は 3 回。
- adaptive (試験的) : standard モードの機能に加え、クライアントサイドのスロットリングをおこなう。このモードは試験的ステータスであるため、将来的に動作が変更される可能性がある。
legacy モード
動作は言語により異なる。
standard/adaptive モード
SDK に依存しない標準的なリトライロジックとして、以下のように定義されている。異なる言語でも統一された動作となる(はず)。
リトライ判定
以下の要素から失敗理由によりリトライ可能かどうかを判断する。一時的なエラーやスロットリングエラーといったものはリトライするが、不正なリクエストといったリトライしても意味がないものはリトライしない。
- レスポンスの HTTP ステータスコード
- サービスから返されたエラーコード
- 接続に関するエラー (応答が受信できなかった場合)
再送間隔(バックオフ時間)
エクスポネンシャルバックオフ(指数的に増やした時間(例: 1,2,4,8,16,20,20,...))を最大値としてランダム化した時間を再送間隔とする。最大バックオフ時間は主に 20 秒だが、SDK によって異なる可能性がある。計算式で書くと以下のとおり。
再送間隔(秒) = min($b･2^{i}$, MAX_BACKOFF)
※$b$ = 0〜1 のランダム値, $i$ = 試行回数
Retry Quota (adaptive モードのみ)
リクエストが失敗しがちな状況では連続でリトライしないようにすることでトラフィックを制御、輻輳を防止する機能。連続してリクエストできる量をトークンバケット方式で管理する。リクエストが失敗したら消費、成功したら補充し、空になった場合はリトライを諦める。