リトライとタイムアウト — 助けるつもりの再試行が、障害を大きくする

What — 1回の失敗が、何回の呼び出しになるか

リトライは、失敗した呼び出しをもう一度送ることです。一時的な失敗（一瞬の混雑、接続の切断）なら、もう一度送れば通ります。

問題は、呼び出しが何層にもつながっているときです。各層のリトライは、足し算ではなく掛け算になります。

アプリ          最大3回 ─┐
BFF             最大3回 ─┼─ 3 × 3 × 3 = 決済サービスに最大 27回
注文サービス    最大3回 ─┘

最下層が遅いとき、上の層はそれぞれ「失敗した」と判断して試し直します。失敗の原因である最下層に、いちばん多くの呼び出しが集まります。 弱っているところを、全員で叩いている形です。

タイムアウトが揃っていないと、誰も待っていない仕事が残る

リトライと並んで事故を大きくするのが、層ごとにばらばらのタイムアウトです。

注文サービスが諦めるまでの合計は、2秒 × 3回 + 待ち1秒 × 2回 = 8秒です。BFF は 5秒で諦めます。下の層の「試し切るまでの時間」が、上の層のタイムアウトより長いと、上が諦めたあとも下は働き続けます。

タイムアウト

応答を待つ上限時間。超えたら諦めて、握っていた接続やスレッドを手放す。

バックオフ

リトライの間に待つ時間。失敗するたびに伸ばしていくのが指数バックオフ。

ジッター

待ち時間にランダムな揺らぎを足すこと。同時に失敗した呼び出しが、同時に試し直さないようにする。

サーキットブレーカー

失敗が続いた呼び出し先を一定時間呼ばず、すぐ失敗として返す仕組み。

Why — なぜ再試行が障害を増幅するのか

リトライは「一時的な失敗なら、もう一度で通る」という前提で入れます。この前提は、失敗が偶然で、呼び出し先に余力があるときにしか成り立ちません。

呼び出し先が過負荷で遅くなっているときは逆です。遅さの原因は仕事が多すぎることで、リトライはそこに仕事を足します。

過負荷で遅い → タイムアウト → リトライ → さらに仕事が増える → さらに遅い → …

原因が取り除かれても、この循環は自分では止まりません。 冒頭で、重いクエリが2分で終わったのに40分止まり続けたのはこのためです。積み上がったリトライそのものが、過負荷の原因に入れ替わっていました。

即座に試し直すと、全員が同じ瞬間に叩く

失敗した直後に試し直すと、もう1つ問題が起きます。

障害は多くの呼び出しに同時に起きます。同じ瞬間に失敗した呼び出しが、同じ間隔で試し直すと、また同じ瞬間に届きます。負荷の山が、リトライの間隔ごとに繰り返し押し寄せます。

retry after 0ms

何を試し直してよいか

リトライしてよいのは、もう一度送れば結果が変わりうる失敗で、かつ2回届いても困らない操作だけです。

タイムアウトは「失敗した」ではなく「分からない」です。相手に届いて処理されたかもしれません。冪等でない操作をタイムアウトで試し直すと、二重に実行されます（api/idempotency）。

呼ばない、という選択

リトライは「もう一度呼ぶ」判断ですが、逆に**「しばらく呼ばない」**判断もあります。呼び出し先が明らかに弱っているなら、試し直すより、呼ばずにすぐ失敗として扱うほうが、自分も相手も守れます。

開いている間、呼び出し元は待たずに代わりの結果を返せます。相手には呼び出しが届かないので、回復するための時間ができます。半開で少しずつ試すのは、回復しかけの相手に一度に全部を戻すと、また潰してしまうからです。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。