サーキットブレイカーパターン：連続して起こる同様の障害への対応策
障害が起こりにくい・万が一、障害が起きた時にシステム側で早急な対応をするような仕組みを勉強しております。そこでサーキットブレイカー。
サーキットブレイカーパターンとはなにか
電子回路にも使われている遮断機が主な概念になっているパターン。何かしらのReq/Resに対して、良くない事象（つまり障害）が頻発すると「あ、これはやばいから一旦この導線をオフにしていこう」という仕組みのことを指します。リモートコールはインメモリコールと比べ、いくつか障害になりえる要素が多く、考慮が必要です。例えば、リモートコールはそもそも受信失敗しやすかったり、サプライヤー側からのレスポンスが頻繁にタイムアウトしてしまったりすることがあります。原因がリモートにある以上、対処がしにくく、かつ一度起きてしまったら、連続的に起こりうるような障害対応のために生まれたのがサーキットブレイカーパターンです。
仕組みと処理の流れ
- 中間層にサーキットブレイカーを設けます（処理の流れの中に組み込めばOK）
- クライアントがリクエストを投げると、そのリクエストはサーキットブレイカーを介してサプライヤー（リモートにあるサーバ側）に向かいます
- サプライヤー側になんの問題もなければサーキットブレイカーもそのまんまクライアントにレスポンスを渡します（正常系）
- もしサプライヤー側で処理が滞っていたり、そもそも何かしらの問題でサプライヤー側にリクエストが届いていなかったりしてレスポンスがなかったらサーキットブレイカーはその障害発生数を記録
- サーキットブレイカーで設定している閾値に達してしまうと、サーキットブレイカーは自身の処理を切り替え（これをトリップというらしい）、クライアント側へ早急にエラーメッセージを配信するようにします（この時点で、サプライヤーへの通信をしなくなる）。
- 妥当だと思われる障害復旧時間を設定しておけば、サーキットブレイカーは自己復旧を行ない、サプライヤー側へ疎通を図ります。問題がなさそうであれば、2の状態に戻ります。
なお、サーキットブレイカーはこのような状態を切り替えながら（トリップしながら）、障害検知・切り替え・復旧を行なっております。
Closedは電子回路でいうと電流が流れている状態なので正常系処理をしている状態。Openは導線を断ち切り、電流が止まっている状態なので「今サプライヤー側でなんか知らないけどよくない事態が起きてるのでそのリクエスト受け付けられないんです」とエラーメッセージを返している状態。HalfOpenがプログラム内で設定した時間間隔のもとサプライヤーへヘルスチェックしに行き、Closedに戻せるか確認している状態を意味します。
サーキットブレイカーの長所
自分らでは障害が起きても、根本的な対応が取れない外部サービスと連携している場合、導入する意味があるように思えます。一度Openになると、サプライヤーまでの通信は切られるので、ユーザーに時間的なストレスを感じさせないという点で、早急にエラーを返すことができるのがメリットだと思います。
ソース元： martinfowler.com
