SERVERLESS LT初心者向け LT大会 #25 サーキットブレーカー 本当にそれ必要？ 発表日：2022/09/07 鈴木 源

目次 • はじめに • 自己紹介 • 本発表の目的とお願い事項 • フェールのこと（フェールソフト） • サーキットブレーカとは • 本当にそれ必要？ • まとめ 1

はじめに クラウドに携わり始めてから比較的耳にするようになった、 わかっているようでわかっていなかったサーキットブレーカーをご紹介します。 尚、本書はAzure 標準化ガイドラインを参考にしております。 興味がある方は以下のリンクより資料をご確認ください。誰でも閲覧可能です。 https://github.com/Azure/Azure-standardization-guideline 2

自己紹介 • 鈴木 源（Gen Suzuki） インフラエンジニア9年目 • 普段の業務 • Azure におけるサーバ構築、運用保守 • 最近の興味 • コミュニティ活動に参加したい！ • ハッカソンに参加すべく、アプリ開発勉強中 • Twitter：@HikaThf 3

本発表の目標とお願い事項 本発表ではサーキットブレーカーに関する説明を行います。 参加者全員が仕組みを理解できることを目標にしていますので、 最後まで聞けばわかるかもしれないと遠慮せず、ガンガン聞いてください！ また、サーキットブレーカーがどういうときに使われるべきか 皆さまの経験踏まえて、ディスカッションできると嬉しく思います。 ちなみに、私は実装反対派です。（苦笑） 4

サーキットブレーカーの前に フェールの種類 5

フェールソフトの例 ロード バランサー WEBサーバ#1 WEBサーバ#2 クライアント 縮退 6

フェールソフトの重要性 • フェールソフトに則った設計をすることで、下記の 2 つの業 務要件を同時に満たすことができる。 - システム障害の影響を最小限に抑える。 - システムによる継続的なサービス提供を図る。 • そのため、1 つの障害が重大なトラブルに発展しかねないが、 継続的なサービスの提供が必要となるミッション クリティカ ルなサービスでは、フェールソフトに則った設計をすること が特に重要である。 7

サーキットブレーカーとは （１／３） 下記の手法を用いることで、システム設計にフェールソフトを組 み込むことができる。 • サーキット ブレイカー: サーキット ブレーカーとは、障害部分を切り離し、障害復旧後に元 のフローに戻す設計パターンである。ユーザーに対して可能な範囲で のサービス提供を継続するため、サブシステム単位にサーキット ブ レーカーを実装し、障害による停止部分を切り離し、縮退稼働できる ようにする。 • エラー ページ: フロントの Web サーバーが障害やメンテナンスで停止している間、 ユーザーに穏やかな内容のエラーページを表示することで、復旧後の 再アクセスに誘導する。 ロードバランサでの 縮退もサーキットブレーカーと 呼ぶのか？聞いたことないぞ。 8

サーキットブレーカーとは （２／３） わからんすぎる ハーフオープンとか聞いたことないし。 9

サーキットブレーカーとは （３／３） また、カスケード障害への有効な対策となります。 図. カスケード障害のイメージ図 出典：すごいよ、サーキットブレーカー！ 〜 マイクロサービスアーキテクチャの設計パターン 〜 https://fujiyamaegg.com/tech-microservices-circuitbreaker/ 障害が波及してシステム全体が 停止したという話は聞いたことがあり ます！ 10

サーキットブレーカーの解説 • ３つの状態が定義されています ①クローズド、②オープン、③ハーフオープン • ざっくり説明するとこんな感じ ①問題ないね（正常） ②後ろで障害起きてるみたいよ、リクエスト送るのやめとくわ（異常） ③時間も経ったし、復旧してるかも？少しリクエスト投げてみるわ（様子見） 11

• クローズド（正常） クライアントがアプリケーションにアクセスすると、 アプリケーションはページに必要な外部APIをコールします。 サーキットブレーカーの解説（図解） （１／５） 外部API アプリケーション (サーキットブレーカー実装) クライアント (ブラウザ) 12

• クローズド（正常） 外部APIに障害が発生し、アプリケーションから外部API呼び出しが失敗したと仮定します。 その場合、アプリケーションではページに必要な一部コンテンツにエラーが生じます。 このエラーが一定数を超える（閾値を超過）と、オープンに遷移します。 サーキットブレーカーの解説（図解） （２／５） 外部API アプリケーション (サーキットブレーカー実装) クライアント (ブラウザ) 13

• オープン（異常） 外部APIに障害が発生し、アプリケーションから外部API呼び出しが失敗したと仮定します。 オープンに遷移すると同時にアプリケーション上ではオープンタイマーが動き始めます。 また、オープンでは外部APIの呼び出しは実行されません。規定したエラーを返却します。 サーキットブレーカーの解説（図解） （３／５） 外部API アプリケーション (サーキットブレーカー実装) クライアント (ブラウザ) オープンタイマー 14

• オープン（異常） 外部APIに障害が発生し、アプリケーションから外部API呼び出しが失敗したと仮定します。 オープンに遷移して一定時間が経過（オープンタイマーがタイムアウト）すると、 障害が解消したかもしれない？ということで、ハーフオープンに遷移します。 サーキットブレーカーの解説（図解） （４／５） 外部API アプリケーション (サーキットブレーカー実装) クライアント (ブラウザ) ？ オープンタイマー 15

• ハーフオープン（様子見） 外部APIに障害が発生し、アプリケーションから外部API呼び出しが失敗したと仮定します。 ハーフオープンに遷移すると、サーキットブレーカーの設定値に従い、 一定割合のリクエストのみ外部API呼び出しを再開します。 正常終了すればクローズへ、異常終了すれば再度オープンに遷移します。 サーキットブレーカーの解説（図解） （５／５） 外部API アプリケーション (サーキットブレーカー実装) クライアント (ブラウザ) ？ 16

ようやく本題。これ本当に必要か？ サーキットブレーカーの設計は理解した。 これ本当に必要か？というのがテーマ。 ひっかかりポイント 1. アプリケーションで実装しないといけない （ライブラリはある。Polly, Opossumなど） 2. 運用に向けた作りこみが必要 今の状態や緊急時の手動閉塞の仕組みなど 結論：ロードバランサーにやらせればいいだろ 業務処理に集中してもらうために可用性などの 仕組みをソフトウェアに移管しているのに本末 転倒感がある。 17

例えばこんな構成の場合 可用性向上のためにどうする？（１／２） アプリ （サーバレス） クライアント アプリ （サーバレス） アプリｻｰｷｯﾄﾌﾞﾚｰｶｰ （サーバレス） クライアント アプリ （サーバレス） アプリ （サーバレス） クライアント ロード バランサー アプリ （サーバレス） 案１ 案２ ベース 前述の理由より、案２としたい。１：１構成にロードバランサーってなんだという話はありますが・・・ 18

例えばこんな構成の場合 可用性向上のためにどうする？（２／２） アプリ （サーバレス） クライアント 外部API アプリｻｰｷｯﾄﾌﾞﾚｰｶｰ （サーバレス） クライアント 外部API アプリ （サーバレス） クライアント ロード バランサー 外部API 案１ 案２ ベース 外部APIの前に自前のロードバランサは置かない。（外部APIに不要なリクエストを送ることになる） 消去法的に案１が有力に…！ 19

まとめ サーキットブレーカーは２つの方式がある サーキットブレーカーという言葉には、大きく２つの方式がある。 広義：負荷分散装置とWEBサーバのような従来の考え方に基づく方式 • 目的：障害箇所を切り離して業務継続 • 方式：インフラ機能による縮退稼働 狭義：アプリケーション実装による3つの状態を持つ方式 • 目的：カスケード障害を想定した障害の波及を抑止する • 方式：アプリケーションによるサーキットブレーカー機能 20

まとめ サーキットブレーカーの使いどころ ✓制御可能なシステム構成の場合（社内システム） ロードバランサーや再試行ポリシーの組み合わせにより信頼性の高い構成が取れる。 ✓制御不可能なシステム構成の場合（外部API呼び出し） 外部APIの仕様により、ロードバランサーや再試行ポリシーの設計が難しい場合に は、サーキットブレーカーを選択するメリットが出てくる。 サーバー側で即座にエラーを返すので、待ち時間によるリソース利用も防げる点も 嬉しいポイント。 21

おまけ サーキットブレーカーの機能を持つライブラリでは、以下の機能が提供されている。 但し、扱いやすさではロードバランサーに劣る。 ✓ブレーカーの現在の状態含む統計情報の取得が可能 ✓ブレーカーの状態を強制的に変更可能 22