サーキットブレーカーとは？解説

サーキットブレーカーは、失敗している依存先の呼び出しをしばらく止めるレジリエンスパターンです。これにより依存先は回復でき、呼び出し側は負荷を上乗せする代わりに素早く失敗できます。

依存先がダウンしているとき、何度もretryを繰り返すのはリソースの無駄であり、障害を悪化させかねません。電気機器にちなんで名付けられたサーキットブレーカーは、持続的な失敗を検知して「トリップ」し、依存先が再び健全に見えるまで以降の呼び出しをショートさせます。これはretryの重要な対となる仕組みです。

3つの状態

Closed: 呼び出しは正常に流れ、失敗がカウントされます。
Open: 失敗が多すぎてbreakerがトリップし、呼び出しは試行せずに素早く失敗します。
Half-open: cooldownの後、いくつかの試行呼び出しで依存先が回復したかをテストします。

なぜretryを補完するのか

retryは失敗が短期的であることを前提とします。サーキットブレーカーは、そうでない場合に対処します。依存先が本当にダウンしているなら、すべての呼び出しをretryするのは負荷を増やすだけです。breakerはトリップして無駄な呼び出しを止め、依存先を回復させ、その後で慎重に様子を見てから再開します。

素早く失敗する

breakerがopenのとき、呼び出しはtimeoutでハングする代わりに、明確な失敗を即座に返します。この素早く予測可能な失敗は、遅い失敗よりも望ましいことが多いです。リソースを解放し、連鎖的な遅延を避け、呼び出し側にグレースフルに縮退するための明確なシグナルを与えます。

CIにおける位置づけ

サーキットブレーカーが最も重要なのは、pipelineが呼び出すサービスやインテグレーション、そして概念的には、持続的に失敗するupstreamの扱い方においてです。どこかの時点でretryをやめ、本物のインシデントとして報告するのです。このパターンは、一時的なもの（retry）と持続的なもの（トリップしてエスカレーション）の境界を体現しています。

Latchkeyの視点

サーキットブレーカーの背後にある原則、すなわち一時的なものはretryするが壊れたものは叩き続けない、というのは、優れた自己修復のふるまいと重なります。Latchkeyの自己修復型マネージドrunnerは、一時的で機械的な失敗を適切な上限とともにretryし、一度きりの不具合がbuildを失敗させないようにしつつ、持続的な失敗を延々とretryすることはありません。

重要なポイント

サーキットブレーカーは、失敗している依存先の呼び出しを止めて回復を促します。
その状態はclosed・open・half-openです。
短期ではなく持続的な失敗に対処することで、retryを補完します。
open時に素早く失敗させることで、リソースを解放しカスケードを防ぎます。