【ITニュース解説】Understanding the Circuit Breaker Pattern in Distributed Systems day 52 of system design

分散システムでは、いつ、どのように問題が発生するかを完全に予測することは難しい。ネットワークの一時的な不調、システムを構成する個々のコンポーネントの故障、あるいは特定のルーターの誤動作など、予期せぬトラブルがシステム全体に大きな影響を及ぼすことがある。システムエンジニアにとって、このような状況下でもシステムを安定して稼働させ続けることは非常に重要な役割である。この課題を解決するための有力な設計パターンの一つが、「サーキットブレーカーパターン」だ。これは、システムの一部に障害が発生した際に、その障害が全体に広がるのを防ぎ、サービスのスムーズな継続を助けるための仕組みである。

サーキットブレーカーという言葉は、私たちの身近にある電気のブレーカーに似た役割を果たす。電気のブレーカーが過負荷やショートから電気回路と接続された機器を守るために電流を自動的に遮断するように、ソフトウェアにおけるサーキットブレーカーパターンは、システム内の特定のサービスが正常に機能しなくなった場合に、そのサービスへのリクエストを一時的に停止させる仕組みを指す。これにより、障害が発生したサービスが他の部分に悪影響を及ぼし、システム全体が停止してしまうような「連鎖的な故障」を防ぐことを目的としている。

具体的に、サーキットブレーカーパターンはどのように動作するのだろうか。あるサービスを利用するプログラム（これを「コンシューマー」と呼ぶ）が、複数のサービスに対して処理のリクエストを送る状況を想像してみよう。もしその中のどれか一つのサービスが技術的な問題で停止していた場合、サーキットブレーカーが導入されていないと、コンシューマーはその停止したサービスに対して無駄にリクエストを送り続けることになる。これは、システムの資源（メモリや処理能力など）を無駄に消費するだけでなく、システム全体の処理性能を著しく低下させる原因となる。

サーキットブレーカーパターンでは、コンシューマーと各サービスとの間に「プロキシ」と呼ばれる仲介役を導入する。このプロキシが、各サービスへのリクエストの状況を監視する役割を担う。もし、あるサービスに対するリクエストの失敗回数や応答時間が、事前に決められた基準（これを「閾値」と呼ぶ）を超えた場合、サーキットブレーカーはそのサービスへの回路を遮断した状態になる。この状態では、サーキットブレーカーは特定のサービスへの新たなリクエストを一切ブロックし、即座にエラー応答をコンシューマーに返す。これにより、コンシューマーは故障しているサービスからの応答を長時間待つ必要がなくなり、他の健全なサービスへの処理を継続できる。

この回路が遮断された状態は、一定期間継続する。この期間中、故障しているサービスが回復する時間を与える。設定されたタイムアウト期間が過ぎると、サーキットブレーカーは「ハーフオープン」という状態に移行する。このハーフオープン状態では、少数のテストリクエストだけを特定のサービスへ送ることが許される。もしこれらのテストリクエストが正常に成功すれば、そのサービスは回復したと判断され、サーキットブレーカーは「クローズド」、つまり通常の動作状態に戻り、全ての新しいリクエストを受け入れるようになる。しかし、もしテストリクエストが失敗した場合、サービスはまだ回復していないと判断され、サーキットブレーカーは再び「オープン」状態に戻り、再度リクエストのブロックとタイムアウト期間の待機を行う。この仕組みによって、システムは資源の無駄な消費を防ぎ、障害が発生した際に素早く対処することで、利用者にとってより良い体験を提供する（これを「フェイルファスト」という考え方で実現する）。

このパターンは、特に複数の独立したサービスが連携して動作する「マイクロサービスアーキテクチャ」において極めて重要である。例えば、従業員管理システムが、従業員の個人情報、休暇情報、業績データ、配属情報といった複数のサービスで構成されている場合を考えてみよう。これらのサービスが連携して一つの情報を提供する際、もし一つのサービスが停止してしまうと、サーキットブレーカーがなければシステム全体が正常に機能しなくなる可能性がある。

マイクロサービス環境では、システム全体の可用性を高いレベルで維持することが非常に難しい。例えば、システムが年間99.999%の稼働率を目標とする場合、これは年間でわずか約5分強のダウンタイムしか許されないことを意味する。もし、100個の独立したマイクロサービスが存在し、それぞれが独立して故障する可能性があるとすると、全体のダウンタイムは年間8時間を超える可能性があり、これはほとんどのビジネスで許容できない事態である。サーキットブレーカーのようなパターンは、このような状況で個々のサービスの障害が全体に波及するのを防ぐために不可欠となる。

サービスが故障する原因はいくつか考えられる。一つは「スレッド枯渇」である。これは、ウェブサーバーがサービスへのリクエストを処理するために「スレッド」と呼ばれる小さな実行単位を割り当てるが、もし一つのサービスが応答に時間がかかったり、停止したりすると、そのサービスを待つスレッドが大量に発生し、他のリクエストを処理するためのスレッドが不足してしまう状況を指す。結果として、新しいリクエストが処理されずに待機し、システム全体がフリーズしたかのような状態になる。もう一つは「カスケード障害」（連鎖的な故障）である。これは、サービスAがサービスBを呼び出し、サービスBがサービスCを呼び出し、さらにサービスCがサービスDを呼び出すといったように、サービス間に依存関係がある場合に発生する。もしサービスDが故障すると、それを待っていたサービスCが処理を完了できなくなり、次いでサービスB、サービスAへと、障害が連鎖的に伝播していく現象である。サーキットブレーカーは、これらの問題が発生した際に、障害を速やかに検知し、その影響を局所化する役割を果たす。

もしサーキットブレーカーがなければ、故障しているサービスへのリクエストは、設定されたタイムアウト時間（例えば30秒）が経過するまで待機することになる。この間に大量のリクエストがシステムに押し寄せると、それら全てが待機状態となり、システムのリソースを大量に消費してしまう。結果として、システムはさらに処理能力が低下し、最終的には全く応答しなくなる可能性がある。

しかし、サーキットブレーカーパターンを用いることで、このような状況は回避できる。サーキットブレーカーは、特定のサービスの故障が閾値を超えた時点で、そのサービスへのリクエストを即座に中断し、エラーを返却する。これにより、コンシューマーは不調なサービスからの応答を無駄に待つ必要がなくなり、リソースの消費も最小限に抑えられる。システムは、たとえ一部のサービスが故障していても、健全な部分については応答性を保ち続けることができる。

利用者の視点から見ても、「フェイルファスト」（速やかに失敗を通知する）は非常に重要である。ウェブサイトでボタンをクリックしたときに、長時間何も応答がなく待ち続けるのは利用者にとって非常にストレスがたまる体験だ。エラーメッセージがすぐに表示される方が、何が起きているのかが分かり、利用者も次の一手を考えやすい。サーキットブレーカーパターンは、このような即座のエラー通知を可能にし、利用者体験の悪化を防ぐ。さらに、障害が特定のサービスに限定されるため、他のサービスへの影響を防ぎ、システム全体の回復も早めることができる。

結論として、サーキットブレーカーパターンは、分散システム、特にマイクロサービスアーキテクチャにおいて、サービスの健全性を監視し、障害を早期に検知して影響を最小限に抑えるための極めて有効な手段である。これにより、システムのリソース枯渇を防ぎ、「フェイルファスト」という考え方で迅速にエラーを通知することで、システムの全体的な堅牢性を高め、利用者満足度の向上にも貢献する重要な設計パターンである。