サーキットブレーカーとは？ 10分でわかりやすく解説

UnsplashのNenad Grujicが撮影した写真      

マイクロサービスアーキテクチャでは、サービス間の呼び出しが連鎖するため、1つの障害が別のサービスへ波及しやすいという課題があります。そこで重要になるのが、障害の影響を局所化し、無駄なリトライや待ち時間を減らすための「サーキットブレーカー」パターンです。この記事では、サーキットブレーカーの基本概念から実装時の判断ポイント、運用で効くベストプラクティスまでを整理します。

サーキットブレーカーの基本概念

サーキットブレーカーの定義と役割

サーキットブレーカーは、分散システムにおける代表的なレジリエンス設計パターンの一つです。一定の条件で外部呼び出しを「速やかに失敗させる」ことで、障害の拡大やリソース枯渇を防ぎ、システム全体の安定性を保つことを目的とします。

とくに、下記のような状況で効果を発揮します。

• 下流サービスの遅延・タイムアウトが増え、上流が待ち続けてスレッドやコネクションが枯渇しそうなとき
• エラーが継続しているのに、同じ呼び出しを繰り返して失敗コストを増やしてしまうとき
• 障害復旧中にリクエストを一気に流し込み、回復を妨げてしまうとき

サーキットブレーカーの動作原理

サーキットブレーカーの動作は、一般的に次の3状態で説明されます。

1. Closed（閉）：通常状態です。リクエストを通常どおり送信し、成功・失敗を計測します。
2. Open（開）：障害を検知した状態です。リクエストを下流へ送らず、即座に失敗（またはフォールバック）させます。
3. Half-Open（半開）：Openの待機時間が経過した後の試行状態です。少数のリクエストだけを通し、回復したかどうかを確認します。

この仕組みにより、「障害中は無駄に叩かない」「回復したら段階的に戻す」という制御が可能になります。

サーキットブレーカーの状態遷移

状態遷移のイメージは次のとおりです。

Half-Openで「何回試すか」「何回失敗したらOpenに戻すか」は実装・ライブラリで調整できるため、システムの特性（ピーク時の負荷、復旧の揺らぎ）に合わせて設計します。

フェイルファストとの関係

サーキットブレーカーはフェイルファストの考え方を実装レベルで具体化したものと捉えられます。障害が疑われる呼び出しを「待つ」のではなく「早く諦める」ことで、上流のスレッド、キュー、コネクションなどの共有リソースを守るという意味で、分散システムの安定運用に直結します。

ただしフェイルファストは万能ではありません。たとえば一時的なネットワーク揺らぎを「障害」と誤判定すると、必要以上にOpenになりユーザー影響が拡大します。そこで次章以降の「しきい値設計」「観測」「テスト」が重要になります。

マイクロサービスアーキテクチャにおけるサーキットブレーカーの重要性

マイクロサービスアーキテクチャの概要

マイクロサービスアーキテクチャは、機能を小さなサービスに分割し、サービス同士がAPI等で連携しながらシステムを構成する設計手法です。サービス単位で開発・デプロイ・スケールできる一方、サービス間の呼び出しが増えることで「分散システム特有の失敗」が表面化しやすくなります。

マイクロサービス間の連携とカスケード障害

分散システムでは、下流の遅延やエラーが上流へ波及しやすく、カスケード障害（連鎖障害）につながることがあります。典型例は次の流れです。

• 下流サービスが遅延し、上流のタイムアウト待ちが増える
• 上流のワーカーやスレッドが待機で埋まり、別の正常リクエストも処理できなくなる
• リトライが重なると、下流の負荷をさらに押し上げて復旧を妨げる

このような状況では、「呼び出しを続けること」自体が障害を長引かせる要因になり得ます。

サーキットブレーカーによる障害の局所化

サーキットブレーカーは、サービス間呼び出しの失敗傾向を検知し、問題が疑われる経路を一時的に遮断します。これにより、障害を「局所」に閉じ込め、正常系の処理や別経路の処理を守ります。

重要なのは、遮断中に「ユーザー体験をどう落とすか」です。フォールバックや簡易表示、キャッシュ応答、後で再試行する非同期化など、ビジネス要件に合わせた設計が必要になります。

システムの回復性と可用性の向上

サーキットブレーカーは、障害時に無駄な待機と負荷を減らすだけでなく、復旧時の「押し寄せ」を抑える効果も期待できます。Half-Openの段階的試行により、回復途中の下流へ大量トラフィックを流し込むことを避け、自動的かつ段階的な復旧を実現しやすくなります。

サーキットブレーカーの実装方法

サーキットブレーカーの基本アルゴリズム

実装の核は「失敗傾向の測定」と「状態遷移」です。一般的には、次のような要素を組み合わせます。

1. 計測の窓：直近N回、直近T秒など、失敗率を算出する対象範囲を決めます。
2. 失敗の定義：HTTP 5xx、タイムアウト、例外、特定のアプリケーションエラーなど、何を失敗として数えるかを定めます。
3. しきい値：失敗率や失敗回数が一定以上になったらOpenに遷移させます。
4. 待機時間：Openのままにする時間を設け、一定時間後にHalf-Openへ遷移させます。
5. 試行の制御：Half-Openで通すリクエスト数（または割合）と、成功・失敗の判定条件を決めます。

ここでのポイントは、「失敗の定義」と「計測の窓」を曖昧にしないことです。たとえば「下流のバリデーションエラー」まで失敗に含めると、障害ではないのにOpenになり得ます。逆に、タイムアウトを失敗に含めないと、待機で上流リソースが枯渇します。

エラー率とタイムアウトの設定

設定パラメータは、サーキットブレーカーの性格を決めます。

• タイムアウト：下流のSLO、通常レイテンシ、ピーク時の揺らぎを踏まえて決めます。短すぎると誤検知が増え、長すぎると上流が待機で詰まります。
• 失敗率しきい値：厳しすぎるとOpenが頻発し、緩すぎると障害検知が遅れます。実測データ（エラー率・レイテンシ分布）を元に決め、定期的に見直します。
• 待機時間：短すぎると復旧前に繰り返し突撃し、長すぎると回復しても遮断が続きます。復旧見込み時間や、下流チームの運用実態も考慮します。

また、サーキットブレーカーは単体で完結しません。タイムアウトとリトライを併用する場合は、リトライ回数・間隔（指数バックオフ等）と整合するように設計することが重要です。無計画なリトライは、障害を悪化させやすい代表例です。

フォールバック設計の実装方針

Open時に重要になるのがフォールバックです。代表例は次のとおりです。

• キャッシュ応答：多少古いデータでも許容できる場合に有効です。
• 簡易応答：詳細情報を省き、最低限の情報だけ返します。
• 非同期化：即時応答が不要な処理はキューに積み、後続処理に回します。
• 機能縮退：該当機能だけ一時停止し、他機能を守る設計にします。

フォールバックは「動けばよい」ではなく、データ整合性とユーザー説明がセットです。たとえばキャッシュ応答なら「いつ時点の情報か」、簡易応答なら「一時的に一部情報が表示できない」など、UI・API仕様としての明確化が求められます。

サーキットブレーカーのモニタリングと可視化

運用では、少なくとも次の指標を観測できるようにします。

• 状態（Closed / Open / Half-Open）の推移
• 失敗率、タイムアウト率、例外種別の内訳
• レイテンシ（平均ではなくp95/p99等も含む）
• フォールバック発生回数と、フォールバック時の応答内容

可視化の目的は「障害検知」だけではありません。設定が厳しすぎてOpenが頻発していないか、フォールバックが常態化していないかを把握し、継続的にチューニングするための基盤になります。

サーキットブレーカーのテスト方法

サーキットブレーカーは、正常系だけでは品質が確認できません。次の観点でテストを組み合わせます。

1. ユニットテスト：状態遷移や失敗カウント、待機時間などのロジックを検証します。
2. 統合テスト：実際の通信（HTTP/gRPC等）で、タイムアウト・エラー応答時の挙動を検証します。
3. フォールトインジェクション：遅延、エラー率上昇、接続切断などを意図的に発生させ、OpenとHalf-Openの挙動を確認します。
4. ロードテスト：ピーク相当の負荷で、スレッドやコネクション枯渇を防げているか、フォールバックが過負荷になっていないかを確認します。

ここまでの設計・観測・テストが揃ってはじめて、サーキットブレーカーは「障害時に役立つ仕組み」として機能します。

サーキットブレーカーのベストプラクティス

サーキットブレーカーの適用基準

すべての呼び出しに付けると複雑性と運用負荷が増えます。一般には次のような観点で適用箇所を選びます。

1. 障害時の影響度：止まると主要導線が崩れる、売上や業務に直結するなど、影響が大きい経路。
2. 外部依存性：他チーム運用のサービス、外部API、ネットワーク跨ぎなど、失敗要因が増える経路。
3. 遅延が致命傷になりやすい：待機が積み上がるとスレッド枯渇やキュー滞留を起こしやすい経路。
4. 代替手段が用意できる：キャッシュ応答や簡易応答など、ユーザー体験を制御できる経路。

フォールバック処理の設計

フォールバックは「障害時の代替」だけでなく「負荷時の保険」にもなります。ただし、フォールバック自体が重い処理（別サービスへの多段呼び出し等）になっていると、障害時に別のボトルネックを作ります。フォールバックは軽量で、依存関係を増やさないことが基本です。

サーキットブレーカーのチューニング

チューニングの中心は「誤検知」と「検知遅延」のバランスです。代表的な調整ポイントは次のとおりです。

• 計測の窓（直近N回か、直近T秒か）
• 失敗の定義（タイムアウト、特定例外、特定ステータス等）
• 失敗率しきい値、最小リクエスト数（母数が少ない状態でOpenにしないため）
• Openの待機時間
• Half-Openの試行回数・同時試行数

また、チューニングは一度で終わりません。監視データ（エラー率、レイテンシ、Open頻度）と、実際のユーザー影響（エラー画面、待ち時間）を突き合わせて継続的に調整します。

併用パターンと避けたい運用

サーキットブレーカーは、他のレジリエンス手法と組み合わせることで効果が上がります。

• タイムアウト：無制限に待たない。
• リトライ：指数バックオフ等で慎重に。リトライ嵐を避ける。
• バルクヘッド：重要経路とその他経路でリソースを分離し、巻き添えを防ぐ。
• レート制限：復旧直後の押し寄せや、異常トラフィックを抑える。

一方で、避けたい運用もあります。

• 過剰に厳しい設定：一時的な揺らぎでOpenが頻発し、かえって可用性を落とします。
• 状態が見えない：Openが発生しているのに気づけず、原因調査や改善が進みません。
• テスト不足：障害時に想定どおり動かず、最も困る場面で裏切ります。

まとめ

サーキットブレーカーは、分散システムにおいて障害の波及を抑え、無駄な待機やリトライでリソースが枯渇する事態を防ぐための重要な設計パターンです。状態遷移（Closed / Open / Half-Open）としきい値設計により、障害時は速やかに遮断し、復旧時は段階的に戻すことができます。

一方で、効果を最大化するには、失敗の定義、タイムアウト、フォールバック、監視、そして障害を想定したテストまでを含めた設計が欠かせません。自社のSLOや運用体制に合わせてパラメータを調整し、継続的に改善することで、回復性と可用性の高いマイクロサービス基盤を実現できます。