2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

サーキットブレイカー???ってなんですの?

Last updated at Posted at 2020-09-23

はじめに

今お仕事させていただいてる場所でサーキットブレイカーの導入を任されたのですが、あまりにも知らなすぎていろいろ調べたので備忘録的にまとめます!

サーキットブレイカーって?

簡単にいうと、、、

マイクロサービス等でたくさんのクライアントからのリクエストを捌けずにエラーを返している時、そもそもサービスのリクエストそのものを遮断すること

です。
もう少し具体的に表すと、、、
スクリーンショット 2020-09-22 20.19.17.png

この図のようにマイクロサービスを運用している時に特定のサーバが障害等の影響で動かなくなってしまった場合、動かないサーバに対してリクエストを送り続けてしまうとたくさんのリクエストがタイムアウトを待つということが起きてしまい、障害の影響範囲がさらに広がってしまいます。
そのような時に(特定のサーバに障害が起きていることがわかった時)そもそも障害を起こしているサーバに対するリクエストを送らずに自動的にエラーを返すようにすることで影響範囲を最小にするというデザインパターンの一つです。
スクリーンショット 2020-09-22 20.26.22.png

つまり

「どうせエラーするんだったらリクエスト投げずにエラー返しちゃおうぜ!」

みたいなそんな感じのノリだと思ってもらえるといいと思います。

どうやって外部サーバが障害を起こしてることを検知するの?

ではどのようにして外部サーバが障害を起こしているのかを判別するのでしょうか???
実はそもそもサーキットブレイカーパターンには3つの状態が存在しています。
それはClosedOpenHalf Openの3つの状態です

状態名 内容
Close 正常にリクエストが行われている状態
Open リクエストに対して正常にリクエストは送られず、固定でエラーを返している状態
Half Open Openの状態からCloseの状態に移行させるときの準備状態

(僕の感覚だとOpenが正常状態で、Closeが異常状態なのが普通な気がするんですが、、、まあ、おいておきますw)

そしてこの3つの状態があると知った上で考えると
外部サーバが障害を起こしてることを検知する->Closeの状態からOpenの状態になる時の条件はなにか?
というように言い換えることができます。
例えば、、、
「リクエストをを投げた時n回連続で特定のエラーが起きた時にOpen状態に移行させる」(n回の部分は要件によって変更)
ように設定することで、サーバの状態を管理します。

どうやって設定するの?

設定する方法は大きく2つです
1, 外部リクエストを送っている箇所で各言語のライブラリなどを使って(goの場合はgobreaker)サーキットブレイカーを実装する
2, istioなどのサービスメッシュプラットフォームの機能を使用する

の2通りの実装があると思います。

終わりに

簡単にではありますが、サーキットブレイカーのまとめをさせてもらいました!
最近話題のマイクロサービスですが、サーキットブレイカーしかり、サービスメッシュしかり、分散トレーシングしかり、、、難しい単語が多すぎますよね汗

今後もマイクロサービスの流れは止まらないと思うので、個人としてもしっかりとキャッチアップをしていきたいですね

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?