サーキットブレーカーとは？ マイクロサービスデザインパターン

サーキットブレーカーとは

サーキットブレーカーの仕様：手動または自動で、通常時と異常時の双方において回路を組み立てたり、電流を通したり、遮断したりする装置です。通常時は回路を閉じて電流を流し、異常時は限られた時間だけ回路を開いて電流を止めることができます。

以下はサーキットブレーカーの特徴の一部です:

• 通常時、手動または遠隔操作で回路を閉じたり遮断したりできる
• 故障時には瞬時に電流を遮断する機能がある
• 問題発生時、手動または遠隔操作で回路を再び閉じることができる

これらの特性により、さまざまな種類のサーキットブレーカーが、電気システムを守り制御する優れた手段となっています. 

‍

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

サーキットブレーカーには多くの種類があり、通常は外部呼び出しの失敗を監視するアプリのプロキシとして実装され、以下の操作が可能となります。下記のように、プロキシは状態機として動作するよう設定されています:

• 閉状態: 電子回路では閉じた回路が通常の状態であるのと同様に、閉状態がデフォルトの状態です。ユーザが指定経路で通信を行い、システムに障害がなければアプリは動作中です。この状態では、クライアントからのリクエストがバックエンドへ送られ、バックエンドからの応答が返されます。
• 開状態: この状態では、クライアントからのリクエストはミドルウェアに送られますが、バックエンドサーバにはアクセスできません。状態移行後、一定時間バックエンドへリクエストが送られず、代わりにエラーメッセージが返されます。
• 半開状態: 開状態時にタイムアウトが設定され、その後アプリは半開状態に移行します。この状態ではバックエンドへの再送信を試み、アクセス可能か確認します。アクセスできれば閉状態に戻り、できなければ再び開状態となります。

サーキットブレーカーパターンの使用例

サーキットブレーカーマイクロサービスアーキテクチャにおいて、このパターンがどのように利用されるか、具体例を見て理解を深めよう。

• シナリオ:

例えば、マイクロサービスを利用するアプリ内に5種類のサービスが存在するとする。サーバは各リクエストに対し、指定サービスを呼び出すために1つのスレッドを割り当てる。しかし、エラーによりサービスの処理が遅れ、スレッドが待機状態となる。1サービスにつき1スレッドの待機であれば問題ないが、高需要のサービスでは、後で他のスレッドが待たされる恐れがある。

その結果、まだ処理されていないリクエストはキューに並ぶか停止します。サービスが回復しても、ウェブサーバはキュー内のリクエスト処理に追われ、常に過負荷状態になって回復が困難となります。将来的に連鎖的な障害が発生し、サービスやシステム全体がクラッシュする可能性があるのです。

• 解決策:

上記の例は、サーキットブレーカーパターンの利用方法を示しています。仮に、あるサービスが200ミリ秒以内に反応する必要があると判断された場合、大量の問い合わせはそのサービスの高需要を意味します。問い合わせの75％が150〜200ミリ秒の遅延を超えると障害の前兆と考えられ、複数の問い合わせが200ミリ秒を超えるとサービスは応答しなくなり、一時的な停止を通知することになります。先に説明した通り、これは「閉状態」から「開状態」への移行です。

そのため、該当サービスへの問い合わせはキューに並ばなくなりますが、一定時間後にサーキットブレーカーが静かに当該サービスへpingを送るようになります。つまり、サーキットブレーカーパターンは現在「半開状態」にあり、初回の問い合わせが成功すれば同サービスへのリクエストが再び許可されます。

このように、サーキットブレーカーパターンはマイクロサービスアーキテクチャの障害耐性および回復力を高め、1つのマイクロサービスの障害が他へ波及するのを防ぐために利用できます。

Netflix Hystrix vs Resilience4J

Netflixのエンジニアが開発したHystrixは、HTTPリクエストを介して多数のノードを連携させる分散システムの安定性向上を目的としたオープンソースライブラリです。

これはサーキットブレーカーデザインパターンを利用して実現されます。

Resilience4Jは関数型プログラミングの原則に基づいて構築された独立したライブラリです。Hystrixのオブジェクト指向アプローチとは異なり、必要なデコレータだけを積み重ねることができ、依存関係も少なく、例えばサーキットブレーカーパターンを閉じるために必要な最小成功回数など、より細かな設定が可能です.