Circuit Breakerの効用をEnvoy + Gatlingで検証してみた #microservices

マイクロサービス時代に可用性を高めるにはサービス間に Circuit Breaker をはさむと良いらしいと聞きます。これにより障害の連鎖を防ぐことが重要らしいのですが、具体的にどのように効果があるのかイメージがわかなかったのでEnvoyをつかって検証してみました。

構成

MacBook Proのローカル環境でDocker for Macを動かし、その上で下記のコンテナを動作させました。本来はちゃんとしたアプリを作ったほうがいい＆複数のバックエンドも用意したほうが本物っぽいですが、今回は極力簡略化しています。

負荷テストはGatlingアプリで実施しました。負荷のかけ方は下記のような流れです：

例えばECやインターネット広告などのレイテンシーが重要なシステムにおいては、この「一度負荷があがったらその後のすべてのレスポンスでレイテンシーが落ちる」といった状態は致命的ではないでしょうか。

サーキットブレーカーがないと...
- 見積り以上の負荷がいったんかかると、負荷が下がっても正常にレスポンスを返せるようにならない
- → システムのキャパシティに余裕を持たせなければならず、余計なシステムコストかかる
サーキットブレーカーがあれば...
- 突発的に負荷がかかっても、さばける範囲内で処理できる
- キャパシティの余裕を減らせてシステムコストを減らせる
Envoyはバックエンドへの接続数/リクエスト数・ペンディング数/リトライ回数にもとづきサーキットオープンするので
- バックエンドの負荷増減に対して反応がいい
  - → 障害の連鎖も起きにくい、ちゃんと縮退運行になりやすい
  - → 復旧もクイック
- よくある Circuit Breaker の「タイムアウトが頻発したらサーキットオープン」ではない

パラメータ調整が手間
- EnvoyのCircuit Breakerではバックエンドへの 最大接続数, 最大リクエストペンディング数, 最大リクエスト数 (HTTP/2), リトライ回数 の設定が可能ですが、バックエンドの処理可能なワークロードに応じて調整する必要があり、手間
  - 例：値を低く設定すると、バックエンドの遊び・無駄があるのにレスポンスを返せない
  - 例：値を高く設定すると、処理できない量のリクエストがバックエンドに流れて徐々にレスポンス悪化 or ノックアウトにつながる

Total	OK	KO	% KO
23249	14634	8615	37%

Error	Count	Percentage
status.find.is(200), but actually found 502	5595	64.945 %
j.u.c.TimeoutException: Request timeout to localhost/127.0.0.1:8080 after 1000 ms	2909	33.767 %
j.i.IOException: Connection reset by peer	100	1.161 %
o.a.e.RemotelyClosedException: Remotely closed	11	0.128 %

Total	OK	KO	% KO
23249	22750	499	2%

Error	Count	Percentage
status.find.is(200), but actually found 503	499	100 %

検証Exampleコード
測定環境
- MacBook Pro (15-inch, 2017), 2.8 GHz Intel Core i7, 16 GB 2133 MHz LPDDR3
Throttlingとの違い: https://ackintosh.github.io/blog/2017/02/18/2017-02-18/

(※ サーキットブレーカーは “リクエストする側” の対策。スロットリングは “リクエストされる側” の対策。という理解 ※)