# カスケード障害 ## 定義 カスケード障害(cascading failure)とは、正のフィードバックによって時間とともに拡大する障害である。系の一部が過負荷などで壊れると、その分の負荷や責務が残りの部分に付け替えられ、残りの部分の障害確率が上がる。これがドミノ倒しのように連鎖し、局所的な障害が系全体を巻き込む障害へ拡大する。最も一般的な原因はサーバ過負荷であり、あるクラスタの喪失が残りのクラスタへの過負荷、クラッシュ、成功リクエスト率の低下を経て、系全体へ波及する。(Source: [[@2016__OReilly__SRE Book - Chapter 22 Addressing Cascading Failures]]) ## なぜ負荷を戻すだけでは回復しないのか カスケード障害の核心的な性質は、トリガーとなった負荷を障害発生前の水準まで下げるだけでは回復しないという点にある。ある系が 10,000 QPS で健全に稼働していたが 11,000 QPS でクラッシュを伴うカスケード障害を起こした場合、負荷を 9,000 QPS まで下げてもほぼ確実にクラッシュは止まらない。系は既にクラッシュによって容量そのものが縮小した状態にあり、縮小した容量で需要を処理することになるためである。健全に稼働できるサーバの割合が例えば 10% しかないなら、系を安定化させるにはおよそ 1,000 QPS まで、つまり元の需要よりはるかに低い水準まで負荷を落とす必要がある。この非対称性(壊れる QPS より、回復に必要な QPS の方がずっと低い)がカスケード障害を単純な過負荷と区別する。(Source: [[@2016__OReilly__SRE Book - Chapter 22 Addressing Cascading Failures]]) さらに、系を健全に保つはずの機構自体が、いったんこの状態に入ると悪化要因に転じうる。負荷分散はエラーを返したサーバを避けることで残りのサーバへの負荷をさらに増やし、Borg のようなクラスタスケジューラのヘルスチェック再起動は、起動直後でまだ仕事ができないタスクと、過負荷でヘルスチェックに落ち続けるタスクの両方を生み、系全体の健全なタスク数をかえって押し下げることがある。(Source: [[@2016__OReilly__SRE Book - Chapter 22 Addressing Cascading Failures]]) ## 横断的知見 - **SRE Book ch.22(2016)は、メタ安定障害(Bronson et al., HotOS 2021)が理論的に定式化する自己強化ループの現場側の先行記述にあたる**: メタ安定障害の3状態モデル(安定・脆弱・メタ安定)は「トリガーを除去してもフィードバックループが持続し、グッドプットが使用不能なほど低下する」状態を抽象的に定義するが、SRE Book ch.22 はこれと同じ現象を「11,000 QPS でクラッシュしたサービスは、9,000 QPS に戻してもほぼ確実に回復しない」という具体的な数値例で示す。5 年早い実務記述でありながら、HotOS 論文が持つ「トリガーを取り除いても系が自力で安定状態に戻れない」という核心的洞察を、独立の語彙(「カスケード障害」)で先取りしている。(Source: [[@2016__OReilly__SRE Book - Chapter 22 Addressing Cascading Failures]], [[@2021__HotOS__Metastable Failures in Distributed Systems]]) - **SRE Book ch.22 は、メタ安定障害の抽象的な「脆弱状態からメタ安定状態への遷移」に、回復に必要な負荷水準を見積もる具体的な定量関係(健全サーバ比率に応じた閾値)を与える**: HotOS 論文の3状態モデルは脆弱状態からメタ安定状態への遷移条件を定性的に述べるにとどまるが、SRE Book ch.22 は「健全に稼働できるサーバの割合が 10% なら、負荷を約 1,000 QPS まで落とす必要がある」という具体的な計算例を示す。両者を並べると、メタ安定障害の理論的な3状態モデルに、回復のための負荷水準を見積もる実務的な経験則を接続できる。(Source: [[@2016__OReilly__SRE Book - Chapter 22 Addressing Cascading Failures]], [[@2021__HotOS__Metastable Failures in Distributed Systems]]) ## 未解決の問い - カスケード障害(SRE Book, 2016)とメタ安定障害(HotOS, 2021)は同じ現象を指しているのか、それとも後者はより広いクラス(トリガー除去後も持続する自己強化ループ全般)を指し、前者はその中でも「サーバ過負荷とクラッシュの連鎖」という特定のサブクラスを指すのか。両概念の外延の異同は本章の記述だけからは判定できない。 - 過負荷制御(単一サービスの受付側設計、[[過負荷制御]])が有効に機能していれば、カスケード障害への遷移をどの程度未然に防げるのか。criticality に基づく選択的棄却は、本ページが扱う「回復に必要な負荷水準の非対称性」そのものを解消するのか、それとも遷移の閾値を引き上げるだけで非対称性自体は残るのか。 - ヘルスチェック停止・再起動・負荷遮断といった脱出手順(本ページ「なぜ負荷を戻すだけでは回復しないのか」参照)を、人間の判断を介さず自動実行する場合、どの順序・しきい値で行うのが安全か。誤って実行すると悪化させうる操作(不適切な再起動など)を自動化する設計はどう検証すべきか。 ## 関連 - ソース: [[@2016__OReilly__SRE Book - Chapter 22 Addressing Cascading Failures]] - 概念: [[メタ安定障害]] / [[過負荷制御]] / [[グレースフルデグレーデーション]] / [[障害緩和]] - 実体: [[Mike Ulrich]] / [[Borg]] / [[Chubby]] - 関連 MOC: [[structures/SRE - MOC]] ## 出典 - [[@2016__OReilly__SRE Book - Chapter 22 Addressing Cascading Failures]]