タダです.

「Amazon Builder's Library」のオンライン輪読会で今週のテーマが「ジッターを伴うタイムアウト、再試行、およびバックオフ」という記事なので内容を理解するために思考整理をします.

記事の整理

当然ですが,故障しないシステムはないから Amazon では障害可能性を許容してその可能性を削減する次の取組みが紹介されました.

タイムアウト
リトライ
バックオフ
ジッター

タイムアウト

タイムアウトの課題は設定するタイムアウト値の選択することと言い,タイムアウトの設定が高過ぎればクライアントの待ち時間が増えるしリソース消費も増える,低すぎるとリクエスト回数が増えレイテンシーの増加して最終的にサーバーダウンにつながります.Amazon のあるシステムではデプロイ直後にサービスが起動するときに少数のリクエストアイムアウトが発生したが,リトライすればリクエストの成功が見受けられていました.当初はタイムアウト値が20ミリ秒以下だったが,タイムアウトの長さを伸ばしてタイムアウトの問題を回避しました.

リトライ

リトライはサーバー側の負荷を増やしてリクエストの成功可能性を上げるため,それによって障害発生したとしてもトレードオフの関係になると触れられています.しかし,リトライとそのサーバーへの過負荷は劇薬と例えられ,適切な量であれば問題ないがやりすぎると重大な損傷(障害)の可能性がある上,分散システムではクライアント側で適切なリトライ回数を調整する方法がほとんどないです.そこで,Amazon の推奨はバックオフを使うことです.

ただし,Amazon の見解はリトライは適切なトレードオフの関係を作れば良い方法とされており,リトライのリクエストのタイミングが誤らなければこの方法は高可用性を提供するソリューションとなります.

バックオフ

バックオフはリトライを積極的に行う代わりにクライアント側である程度の待ち時間を作ります.バックオフの一般的な例がエクスポネンシャル・バックオフでリトライごとに待機時間が急激に増加する特徴があります.AWS SDK でもエクスポネンシャル・バックオフの実装が紹介されています.

単純な再試行に加えて、各 AWS SDK は効果的なフロー制御を行うために、エクスポネンシャルバックオフアルゴリズムを実装します。エクスポネンシャルバックオフは、再試行間の待機時間を累進的に長くして、連続的なエラー応答を受信するという考えに基づいています。最大遅延間隔で最大回数の再試行を実行する必要があります。再試行の最大遅延間隔と最大回数は必ずしも固定値ではなく、実行する操作や局所的な要因 (ネットワークのレイテンシーなど) に基づいて設定する必要があります

AWS でのエラーの再試行とエクスポネンシャルバックオフ https://docs.aws.amazon.com/ja_jp/general/latest/gr/api-retries.html

ただ,バックオフも万能ではなく過負荷やリクエストの競合による障害が原因の場合は役立ちません.リクエストの失敗が同じ時間であった場合次のリトライのタイミングで再度競合や過負荷が発生するため,ジッターつまり待ち時間をランダムにしてリトライのタイミングを分散させます.

ジッター

追加するジッターの量と追加方法は下記のブログが参考になります.記事を見ると,バックオフ(エクスポネンシャル・バックオフ)によりリトライの頻度は減っているが競合しているためジッターを入れることで競合が減ってクライアント側の仕事量も減っていってます.

原文 aws.amazon.com

翻訳記事 aws.typepad.com

原文を要約して補足説明した記事 codezine.jp

ジッターは全てのタイマー,バッチ処理,その他のバックオフ処理に追加することを検討することで,サーバーの負荷が分散されるてダウンストリームサービスのワークロードに合わせた拡張をしやすくする効果があります.著者はサーバーへのスパイクアクセスに対する制御ないが,顧客体験に影響を与えない場所へのジッターを追加することを推奨しています.Amazon ではリトライに注意を向けることが大切であると学び,システムの依存関係について確認して適切なタイミングでリトライすれば負荷の増加を回避することができます.そしてリトライが可用性の改善に役立たない場合はリトライを停止することも辞さないと記載がありました.