第10回のオンライン輪読会に備えて読んだ内容を自分なりにまとめておく。
今回の記事はこちら。
[期待/予想する内容]
この記事の目次は次のとおりである。
- はじめに：障害の発生
- タイムアウト
- 再試行とバックオフ
- ジッター
- まとめ
タイトルと目次の情報量が大して変わらないってどういうことなの……。
「はじめに：障害の発生」……障害が発生した、けと数秒とかで収まる場合もあるよね、だからクライアント側にリトライ（再試行）させるのが大事。そういう話の流れかな。多分。
「タイムアウト」……タイムアウトだから、ネットワークの一時的な不調の場合などだろうか。リトライは大事ですよね。
「再試行とバックオフ」……ただリトライしただけでは、状況が改善していない可能性があるので、2回目以降のリトライの際には徐々に実行間隔を広げていく、というのがバックオフの基本的な考え方のはず。その説明か。
指数関数的に、リトライの実行間隔を広げていくエクスポネンシャル・バックオフの話もここで出るかんあ。
「ジッター」……ジッターってバックオフ時にランダムにスリープするあれのことだろうか。AWS SDKで実装されているのを読んだ気がする。
[記事の要約]
次に、実際に記事を読んだ内容を箇条書きでまとめる。
はじめに：障害の発生
- サービスの障害の様々な要因：サーバー、ネットワーク、ロードバランサー、ソフトウェア、OS、人的ミス
- 障害の可能性を許容することでシステムの回復性を高める
- タイムアウト：サーバーのリソースを使い果たさないように
- 再試行：部分的、一時的な障害の回避。バックオフを利用して負荷集中を避ける。
- ジッター：リクエストのバーストを避けるためのランダムな待ち時間
タイムアウト
- 同一サーバ上でもプロセスをまたぐリクエストにはタイムアウトを設定する
- タイムアウト値の設定は難しい問題：低すぎても高すぎてもだめ
- メトリクスを利用して適切な値を選択すべし
- 事例：デプロイ時にタイムアウトするので、プロセス起動時にコネクションを確立するよう修正
再試行とバックオフ
- 再試行は強力な薬：使いすぎるとサーバーに負荷、回復に遅れ
- （上限付き）エクスポネンシャル・バックオフが推奨：待機時間を試行ごとに増加
- 再試行する箇所を１箇所にしないと複数レイヤーで指数関数的に負荷高まる
- エラー時の不要なリトライを避けるべくトークンシステムを利用する（AWS SDKに実装済み）
- APIの冪等性を保証し安全に再試行できるようにする
- クライアントエラーの場合は再試行しない：結果整合性を採用している場合そうとも言えない
ジッター
- すべて同じタイミングでバックオフされると負荷集中して意味がない
- ジッター：バックオフにランダム性を追加する
- リクエストだけでなく、タイマーやクロンジョブにもジッターを利用すべし
- 1分のうちの最初の数秒や、深夜0時の最初の数秒に負荷が集中するので
- ただしスケジュールされた作業の場合はホストごとにおなじ値を利用しないと予想できない問題が起きる
- （ランダム故に結局負荷が集中する、など）
まとめ
[予想のふりかえりなど]
大体予想通り、だった気がする。
ただ、スケジュールされたジョブの実行にもジッターによるランダム性を追加して、負荷集中を避けるという視点は自分にはなかったので、勉強になった。
ジッターも、ただ単にランダムなだけではなく、いくつか種類があることを学んだ（あまり区別できていないが……）。
- フル・ジッター（完全ランダム？）
- イコール・ジッター（ある程度スリープ値を小さく保つ？）
- デコリレイティッド・ジッター（完全ランダムより最大値を大きくする？）
[まとめ]
- 「The Amazon Builder's Library」の『ジッターを伴うタイムアウト、再試行、およびバックオフ』を読んだ
- 一時的な障害やレイテンシーは避けられないという考え方はAWSなどのクラウドを利用していく上でも重要な考え方だと思う
- ジッターの利用箇所としてクライアントサイドだけでなく、スケジュールされたジョブでも利用できるというのは新しい発見だった
これで10/13記事を読んだことになる。あと3つ！
引き続きAmazon Builder's Library読んでいくぞ。
