「あなたのリトライが私たちを殺しています。」
あるサービスチームが、依存先チームからこのメッセージを受け取りました。障害の真っ最中に、依存先のAPIがタイムアウトしている。当然、リトライする。3回、5回、10回。クライアント側は正しい動作をしているつもりです。
しかし依存先から見れば、障害で処理能力が半分に落ちているところに、通常の数倍のリクエストが殺到している状態でした。リトライが障害を悪化させ、回復を妨げていた。
これはどこかの寓話ではありません。2012年8月、Knight Capitalの話です。デプロイ時に旧コード(Power Peg)が誤って活性化され、45分間に数百万件の注文を自動生成。4.4億ドルの損失を出して実質破綻しました。注文が「完了」とマークされず、システムが注文を再生成し続けた。構造としては「フィードバックループが閉じていない無限再実行」で、リトライ暴走と同じ力学です。
リトライは障害を乗り越えるための仕組みです。しかし設計を誤ると、リトライそのものが障害の原因に変わります。
自分自身と戦うシステム -- 3つの暴走パターン
Michael Nygardは著書 Release It! で、本番システムが自分自身を攻撃するパターンを複数挙げています。リトライ関連の暴走パターンは3つです。
ドッグパイル
キャッシュの有効期限が切れた瞬間、全クライアントが同時にオリジンサーバーへリクエストを送る。通常時は1秒あたり100リクエストのサービスが、ドッグパイル時には数千リクエストを同時に受ける。正常に戻ったはずのサービスが、一斉リトライの波で再び倒れる。
障害から復旧した瞬間が最も危険です。キューに溜まったリクエストが一斉に流れ込むので、復旧直後に再度ダウンする。これを繰り返すと、オンコール担当の精神が先にダウンします。
カスケーディング障害
サービスAがBに依存し、BがCに依存する。Cが遅延すると、Bのスレッドがブロックされる。Bのスレッドが枯渇すると、Aのリクエストもブロックされる。1つのサービスの遅延が、依存チェーンを通じて全体に波及します。
ここでの厄介なポイントは、遅延がエラーより悪質だということです。エラーは速く返るのでリソースを長時間占有しません。しかし遅延はスレッドやコネクションを占有し続ける。Nygardの言葉を借りれば、「遅いレスポンスは、エラーよりも悪い」。
遅いレスポンスの罠
タイムアウト30秒のHTTPクライアントが、遅延するサービスを呼び出す。30秒間スレッドが占有される。その間にリクエストが積み上がり、スレッドプールが枯渇する。
タイムアウトが長すぎればリソースを長時間食い潰し、短すぎれば正常な処理まで中断する。「適切なタイムアウト値」は見た目以上に難しい問題です。私はこれまで「デフォルト値のままでした」という告白を何度も聞いてきました。自分もやっていた時期があるので、人のことは言えませんが。
リトライ設計の3原則
リトライそのものが悪なのではありません。問題は「考えなしのリトライ」です。
ただし大前提として、リトライ先のAPIが冪等(同じリクエストを複数回送っても結果が変わらない)でなければ、どんなリトライ戦略も安全にはなりません。POST /orders を3回リトライしたら注文が3件できた、という話は笑えません。
| 原則 | やること | やらないと何が起きるか |
|---|---|---|
| 指数バックオフ | リトライ間隔を1→2→4→8秒と倍増 | 全クライアントが同時にリトライし続ける |
| ジッター | バックオフにランダムな揺らぎを加える | バックオフの波が同期してスパイクが周期的に発生 |
| リトライバジェット | システム全体のリトライ割合に上限を設ける | 個々は合理的でも、集団として破壊的になる |
指数バックオフだけでは足りない
即座にリトライするのではなく、リトライ間隔を徐々に広げる。これは基本中の基本です。しかし指数バックオフだけでは不十分です。全クライアントが同じタイミングでリトライを開始すると、1秒後、2秒後、4秒後にそれぞれスパイクが発生する。バックオフの波が同期してしまうのです。
ジッターで波を崩す
バックオフにランダムな揺らぎを加えます。
import random
def retry_with_jitter(attempt, base=1, max_delay=60):
delay = min(base * (2 ** attempt), max_delay)
jitter = random.uniform(0, delay)
return jitter
AWSのブログ「Exponential Backoff And Jitter」(2015)で、Full Jitter戦略が推奨されています。リトライタイミングが分散され、ドッグパイル効果が軽減されます。
リトライバジェット -- 集団行動の制御
「直近1分間のリクエストのうち、リトライが占める割合が20%を超えたら、新規のリトライを停止する。」
Google SREハンドブックで紹介されているアプローチです。個々のクライアントは自分のリトライが「合理的」だと判断しています。しかし全員が同時にリトライすれば、集団として破壊的になる。リトライバジェットは、この「合成の誤謬」に対処します。
交通渋滞と同じです。1台が車線変更するのは合理的。全員が同時に車線変更すると、渋滞が悪化する。
本番デバッグ時の5つのチェックポイント
障害の原因がリトライや制御ロジックにある場合、以下の5点を確認してください。
| # | チェック項目 | 確認すること | 危険サイン |
|---|---|---|---|
| 1 | リトライ間隔 | 指数バックオフ+ジッターが実装されているか |
sleep(1) のベタ書き |
| 2 | リトライ上限 | 最大リトライ回数が設定されているか |
while True + retry |
| 3 | タイムアウト値 | デフォルト値のまま放置されていないか | タイムアウト未設定、または30秒超 |
| 4 | サーキットブレーカー | 依存先障害時にリクエストを止める仕組みがあるか | 障害中も全リクエストを投げ続ける |
| 5 | フィードバックループ | 処理完了が正しく記録されるか | 完了マークなしの処理が再実行される |
Knight Capitalの事故では、項目2と項目5の両方が欠落していました。注文に上限がなく、完了マークがつかないので再生成し続けた。2つの欠落が重なった結果が4.4億ドルです。
制御ロジックの本質的な怖さ
ここまで読んで「うちのリトライ設定は大丈夫だろう」と思った方。私も以前はそう思っていました。本番障害で初めて「あれ、リトライ何回まで?」と調べて、答えが見つからなかったときの焦りは忘れられません。
正常系のコードは毎日何百万回も実行され、バグがあればすぐに気づきます。しかし制御ロジック -- リトライ、タイムアウト、バックオフ、サーキットブレーカー -- は障害時にしか実行されません。障害は頻繁には起きないので、制御ロジックのバグは長期間潜伏します。そして本当に必要な瞬間に、期待通りに動かない。
「障害を乗り越えるための仕組み」が「障害を悪化させる仕組み」に変わる。このパラドックスが、制御ロジックの本質的な難しさです。
だからこそカオスエンジニアリングが必要になります。本番環境で意図的に障害を起こし、制御ロジックが想定通りに動くか検証する。平常時に制御ロジックをテストする唯一の方法は、平常時に障害を作ることです。矛盾しているようですが、それが現実の運用です。
まとめ
リトライは味方にも敵にもなります。
- ドッグパイル、カスケーディング障害、遅いレスポンス -- 暴走パターンを知らなければ、自分のリトライが何を引き起こしているか気づけません
- 指数バックオフ + ジッター + リトライバジェット -- この3つをセットで実装して初めて、リトライは安全になります
- 制御ロジックのバグは障害時まで眠っている -- 平常時のテストでは見つからない
あなたのサービスのリトライ設定、最後に確認したのはいつですか？ grep -r "retry" src/ を叩いてみると、思わぬ発見があるかもしれません。
付録: リトライデバッグスキル（コピペ用）
以下をそのまま CLAUDE.md やAIエージェントのスキル定義に貼ると、障害時のリトライ関連チェックをAIに実行させられます。
# リトライ・制御ロジックデバッグ
障害が発生し、リトライや制御ロジックが原因として疑われる場合に実行する。
## 初動: 5つのチェックポイント
以下を順番に確認し、各項目の結果を報告すること。
1. **リトライ間隔**: 指数バックオフ+ジッターが実装されているか。`sleep(1)` のベタ書きは危険サイン
2. **リトライ上限**: 最大リトライ回数が設定されているか。`while True` + retry は無限ループと同義
3. **タイムアウト値**: デフォルト値のまま放置されていないか。未設定または30秒超は要確認
4. **サーキットブレーカー**: 依存先障害時にリクエストを止める仕組みがあるか
5. **フィードバックループ**: 処理完了が正しく記録されるか。完了マークなしの処理が再実行される構造は致命的
## 検出コマンド
# リトライ関連コードの洗い出し
grep -rn "retry\|retries\|max_attempts\|backoff\|jitter" src/
# タイムアウト設定の確認
grep -rn "timeout\|TIMEOUT\|time_out" src/
# サーキットブレーカーの有無
grep -rn "circuit\|breaker\|CircuitBreaker" src/
## 判定基準
- 5項目すべてに明示的な設定がある → 🟢 問題なし
- 1-2項目が欠落 → 🟡 改善推奨（欠落箇所と修正案を提示）
- 3項目以上が欠落、またはリトライ上限なし → 🔴 即時対応（Knight Capital型の暴走リスクあり）
## 前提条件の確認
リトライ設計の前に、以下の前提が満たされているか確認すること。
- リトライ先APIは冪等か（同じリクエストを複数回送っても結果が変わらないか）
- 冪等でない場合、冪等キー（Idempotency-Key ヘッダ等）の仕組みはあるか
参考文献
- Michael Nygard, Release It! (2007, 2018 2nd Edition) -- 安定性アンチパターンの原典
- Google SRE Handbook, Chapter 22: "Addressing Cascading Failures" -- リトライバジェットの解説
- AWS Architecture Blog, "Exponential Backoff And Jitter" (2015) -- Full Jitter戦略の提案
- SEC Filing: Knight Capital Group, Form 10-Q (2012) -- 4.4億ドル損失の詳細