分散システムにおけるサーキットブレーカーとバックオフを伴う再試行はどのように機能しますか?

Question

IT Interview Practice · Accepted Answer

分散システムでは、呼び出しが失敗します。**バックオフを伴う再試行**は*一時的な*エラーから回復します。**サーキットブレーカー**は本当に*ダウン*している依存関係を叩き続けるのを防ぎます。これらは相補的です: ちょっとした不具合は再試行し、障害時は遮断します。

## 指数バックオフ + ジッターを伴う再試行

一時的な障害（タイムアウト、短いネットワーク障害、503）の場合、再試行してください — ただし**指数関数的にバックオフしてジッターを追加**して、再試行が同期して雷群になるのではなく分散するようにします。

```text
attempt 1 → wait ~1s   (+ random jitter)
attempt 2 → wait ~2s   (+ random jitter)
attempt 3 → wait ~4s   (+ random jitter)
→ cap at maxRetries (e.g. 3) and a max delay → don't retry forever
```

主な注意点:

- **再試行を制限する** — 無制限の再試行は**再試行ストーム**を作成し、復帰中のサービスに過負荷をかけます。
- **べき等性** — 繰り返しても安全な操作のみを再試行してください（再試行された支払いは2回請求されてはいけません）。
- **ジッター** — これなしでは、すべてのクライアントが同じ瞬間に再試行して負荷を再上昇させます。

## サーキットブレーカー

サーキットブレーカーは依存関係への障害を追跡し、閾値の後に**開きます** — 停止したサービスを呼び出す代わりに高速失敗（またはフォールバックを返します）します。クールダウン後に**半開**になって復帰をプローブします。

```text
CLOSED   → calls pass through; count failures
  too many failures → trip → OPEN
OPEN     → fail fast immediately (no call); start cooldown timer
  cooldown elapsed → HALF-OPEN
HALF-OPEN → allow a few probe calls
  success → CLOSED (recovered) ; failure → back to OPEN
```

## それぞれが適用される場合

```text
Retry           → transient, likely-to-succeed-soon errors (1 slow call)
Circuit breaker → repeated/sustained failures (the dependency is down)
→ use together: breaker prevents retries from piling onto a dead service
```

## なぜ重要なのか

これなしでは、1つの失敗した依存関係が呼び出し元を巻き込みます: リクエストはタイムアウトで蓄積され、再試行は負荷を増幅し、障害はサービス全体に連鎖します。ジッター付き指数バックオフは不具合から再試行ストーム無しで回復します。キャップとべき等性は再試行を安全に保ちます。サーキットブレーカーは停止した依存関係のリソース浪費を停止し、復帰の余地を与えます。これらを組み合わせることで、依存関係の障害を包含された自己回復イベントに変えます。

指数バックオフ + ジッターを伴う再試行

サーキットブレーカー

それぞれが適用される場合

なぜ重要なのか

関連する質問