はじめに
今お仕事させていただいてる場所でサーキットブレイカーの導入を任されたのですが、あまりにも知らなすぎていろいろ調べたので備忘録的にまとめます!
サーキットブレイカーって?
簡単にいうと、、、
マイクロサービス等でたくさんのクライアントからのリクエストを捌けずにエラーを返している時、そもそもサービスのリクエストそのものを遮断すること
この図のようにマイクロサービスを運用している時に特定のサーバが障害等の影響で動かなくなってしまった場合、動かないサーバに対してリクエストを送り続けてしまうとたくさんのリクエストがタイムアウトを待つということが起きてしまい、障害の影響範囲がさらに広がってしまいます。
そのような時に(特定のサーバに障害が起きていることがわかった時)そもそも障害を起こしているサーバに対するリクエストを送らずに自動的にエラーを返すようにすることで影響範囲を最小にするというデザインパターンの一つです。
つまり
「どうせエラーするんだったらリクエスト投げずにエラー返しちゃおうぜ!」
みたいなそんな感じのノリだと思ってもらえるといいと思います。
どうやって外部サーバが障害を起こしてることを検知するの?
ではどのようにして外部サーバが障害を起こしているのかを判別するのでしょうか???
実はそもそもサーキットブレイカーパターンには3つの状態が存在しています。
それはClosed
・Open
・Half Open
の3つの状態です
状態名 | 内容 |
---|---|
Close | 正常にリクエストが行われている状態 |
Open | リクエストに対して正常にリクエストは送られず、固定でエラーを返している状態 |
Half Open | Openの状態からCloseの状態に移行させるときの準備状態 |
(僕の感覚だとOpenが正常状態で、Closeが異常状態なのが普通な気がするんですが、、、まあ、おいておきますw)
そしてこの3つの状態があると知った上で考えると
外部サーバが障害を起こしてることを検知する
->Closeの状態からOpenの状態になる時の条件はなにか?
というように言い換えることができます。
例えば、、、
「リクエストをを投げた時n回連続で特定のエラーが起きた時にOpen状態に移行させる」(n回の部分は要件によって変更)
ように設定することで、サーバの状態を管理します。
どうやって設定するの?
設定する方法は大きく2つです
1, 外部リクエストを送っている箇所で各言語のライブラリなどを使って(goの場合はgobreaker)サーキットブレイカーを実装する
2, istioなどのサービスメッシュプラットフォームの機能を使用する
の2通りの実装があると思います。
終わりに
簡単にではありますが、サーキットブレイカーのまとめをさせてもらいました!
最近話題のマイクロサービスですが、サーキットブレイカーしかり、サービスメッシュしかり、分散トレーシングしかり、、、難しい単語が多すぎますよね汗
今後もマイクロサービスの流れは止まらないと思うので、個人としてもしっかりとキャッチアップをしていきたいですね