サーキットブレーカーの仕組み — 不調な配送サービスへの呼び出しを止める

ひよこ

配送サービスの応答が遅いと、注文画面も待ち続けちゃうの？

ペンギン先生

待ちが増えると、ほかの処理にも影響することがあるよ。サーキットブレーカーは、失敗が設定条件に達した相手への新しい呼び出しを一時的に遮断する仕組み。配送見積もりの例で、3つの状態を見てみよう。

ひよこ

障害が広がるってどういうこと？

ペンギン先生

たとえばAがBを、BがCを呼ぶ構成でCが応答しなくなると、Bで応答待ちがたまってスレッドや接続を使い尽くすことがある。するとAにも影響が広がるんだ。こうしたカスケード障害（障害の連鎖）を抑えるのが目的で、すべての障害を防ぐ保証ではないよ。

ひよこ

全部止まっちゃうのは怖いね…。サーキットブレーカーはどうやって防ぐの？

ペンギン先生

基本は3状態だよ。Closed（閉）では呼び出しを通し、失敗回数や失敗率などの設定条件を満たすとOpen（開）にして、対象への新しい呼び出しを遮断する。待機後はHalf-Open（半開）で少数だけ試し、復帰条件を満たせばClosed、失敗条件を満たせばOpenに戻すんだ。

ひよこ

Openのときはリクエストが全部ブロックされるの？ユーザーにはどう見えるの？

ペンギン先生

対象の呼び出しは拒否するけれど、その後の応答はアプリ側で設計するよ。古い情報でも支障がない画面ならキャッシュを返せるし、処理できない場合は利用できない旨を伝える。これがフォールバック戦略だね。注文や決済を実行できていないのに成功したように見せてはいけないよ。

ひよこ

なるほど！でも、いつOpenに切り替えるかはどうやって決めるの？

ペンギン先生

たとえばJavaのResilience4jなら、直近10回を集計し、最低10回の記録がそろって失敗率50%以上なら遮断、という設定ができる。5回失敗なら50%だね。Openで30秒待つのも設定例で、通信1回のタイムアウトとは別だよ。待機後の自動遷移か次の呼び出し時の遷移かも設定によるんだ。

ひよこ

サーキットブレーカーの状態って、運用中にどうやって確認するの？

ペンギン先生

Openへの遷移、失敗率や遅い呼び出し、フォールバックの発生を監視すると判断しやすいよ。頻繁に遮断されるなら、呼び出し先の障害や容量不足だけでなく、通信経路やしきい値が厳しすぎないかも調べよう。遮断する仕組み自体が故障を直してくれるわけではないんだ。

ひよこ

リトライと組み合わせたりもするの？

ペンギン先生

組み合わせられるけれど、リトライ終了が必ず遮断の合図になるわけではないよ。重ねる順番で失敗の数え方も変わる。再試行は一時的な障害に絞り、回数・待ち時間を制限して、Openによる拒否を繰り返さないようにする。注文などでは二重実行を防ぐ設計も必要だよ。

ひよこ

他にも似たパターンってあるの？

ペンギン先生

バルクヘッドパターンという補完的な仕組みがあるよ。船の隔壁（バルクヘッド）と同じ発想で、スレッドプールや接続プールをサービスごとに分離するんだ。サーキットブレーカーが「壊れたサービスへの呼び出しを止める」のに対して、バルクヘッドは「壊れたサービスがリソースを食い尽くすのを防ぐ」。組み合わせる場合も、どこまで資源を分けるか、設定と負担を確認しよう。

まずは、配送見積もりのサービスが応答しない場面を見る

通販アプリが配送サービスへ送料を問い合わせるとします。相手が不調なのに何度も待ち続けると、接続や処理の枠が埋まり、ほかの操作まで影響を受けることがあります。

サーキットブレーカーは、失敗が設定した条件に達したら、その相手への新しい呼び出しを一時的に止める仕組みです。相手の故障を修理する機能ではありません。

Closedは回路が閉じて通れる状態、Openは回路が開いて通らない状態です。「Openなら利用者へ開放」と読むと逆になるので、まず呼び出しが通るかで覚えましょう。

待機時間とタイムアウトを分ける

次は設定を理解するための例です。推奨値や既定値ではありません。

• 直近10回を集計し、最低10回がそろうまで失敗率で遮断しない。
• その10回のうち5回失敗なら50%。しきい値を50%に設定すると、失敗率が50%以上でOpenにする。
• Openで30秒待ったあと、少数の試行で復帰を判断する。

Resilience4jでは、このような最小件数やしきい値を設定できます。30秒は遮断後の待機の例で、通信1回のタイムアウトとは別です。待機後に自動遷移するか、次の呼び出しで遷移するかなども設定によります。

失敗として数える例外、遅い呼び出し、集計窓、Half-Openで通す件数も確認してください。すべてのエラーを同じ扱いにする必要はありません。

利用者へ何を返すかは、別に設計する

送料を調べられない場合には、「現在、配送の見積もりを確認できません」と伝えるなどの応答を決めます。古い情報を使ってよい画面なら、その条件を明示したうえでキャッシュを使う方法もあります。

注文や決済を終えていないのに、成功したように返してはいけません。 遮断時の代替応答、再試行の案内、担当者への通知は、業務に合うよう設計します。

もう少し詳しく：リトライと資源の分離

リトライはもう一度試すこと、サーキットブレーカーは呼び出しを通すか遮断するかの判断です。重ねる順番で、集計する失敗数も変わります。Openによる拒否を何度もリトライせず、一時的な障害に回数・時間を限定してください。書き込みには重複処理への対策も必要です。

バルクヘッドは、呼び出し先ごとに接続プールなどの資源を分ける補完的な方法です。両方を使っても、無条件に障害連鎖を防ぐ保証にはなりません。Openへの遷移、実際に失敗した呼び出し、代替応答の発生を監視し、呼び出し先や通信経路も調査します。

覚え方と次の一歩

「サーキットブレーカー」って出てきたら「不調な相手へ呼び出しを送り続けないための遮断係」と思えばだいたいOK！

レートリミットとの違い、ログ収集で残す状態遷移を確認できます。

参考資料

• Microsoft Learn: Circuit Breaker pattern — 基本3状態、遮断・復帰・フォールバック・監視。故障そのものの修理を保証しない。
• Resilience4j: CircuitBreaker — 最低呼び出し数、失敗率のしきい値以上、Half-Open条件、待機後の自動/次の呼び出しでの遷移。
• Microsoft Learn: Retry pattern — 一時的障害の再試行、回数・間隔・冪等性、重複処理とリトライ多重化の注意。
• Microsoft Learn: Bulkhead pattern — 依存先ごとの接続/スレッド等の資源分離と耐障害パターンの併用。