グレイ障害 - yuuk1's Digital Garden

# グレイ障害クラウドや分散システムにおいて、コンポーネントが**完全には停止しないが徐々に性能が劣化する**故障様式の総称。[[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]](Huang+、HotOS 2017、[[Lidong Zhou]] 共著)が正式に定義し、Arpaci-Dusseau+(2001)の「fail-stutter」、Gunawi+(TOS 2018)の「fail-slow at scale」、Do+(SoCC 2013)の「limpware / limplock」、Lou+(NSDI 2020)の「partial failure」など、類似概念が多分野で並立する。**特徴は observability の非対称性**——システム内部の監視が「OK」を返す一方で、利用側のアプリは明確に劣化を観測する。 ## 公式定義(Huang+ 2017) Huang+ 2017 は Observer/App モデルを用いて以下のように定義する: - **System**: サービスを提供するエンティティ。Observer(ヘルス情報収集)と Reactor(復旧アクション)を内包する - **App**: System を利用するエンティティ。端点間メトリクス(クエリレイテンシ・リモート I/O 状態等)から独自のヘルス観測を行う - **グレイ障害**: 少なくとも 1 つの App が System を不健全と観測しているが、Observer は System を健全と観測している状態 | | $A_i^{\text{good}}$ | $A_i^{\text{bad}}$ | |---|---|---| | $S^{\text{good}}$ | ➊ 正常 | ➋ **グレイ障害** | | $S^{\text{bad}}$ | ➌ 良い方向の差分 | ➍ fail-stop 障害 | ケース ➋ が核心: ユーザーが苦しんでいるが Reactor が呼ばれず回復しない。(Source: [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]] §3) **時間的進展**: 潜在障害(➊)→グレイ障害(➋)→完全障害(➍)。断続的誤動作ではこの遷移を繰り返す。メモリリークが典型例。(Source: [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]] §3.3) **グレイ障害の具体例** (Azure 本番、Source: [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]] §2): - 深刻な性能劣化・ランダムパケットロス・不安定な I/O・メモリスラッシング・容量プレッシャー・非致命的な例外 - Clos ネットワークのコアスイッチがランダムパケットロス → ルーティングプロトコルが再ルーティングしない → 高冗長性が逆に可用性を下げる逆説 - VM が内部でネットワーク接続障害を経験しているが、ハートビートのみ監視する外部検知器には見えない - 容量制約を報告できないデータサーバへの書き込み継続 → クラッシュ→リブートのループ → 連鎖障害 ## AI 時代のグレイ障害 [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] は、AI クラウドで顕在化する 3 つの新しい増悪要因を整理した: 1. **ハードウェア冗長が劣化を覆い隠す**: GPU CUDA コアや HBM 行リマッピング(Row Remap)、InfiniBand の過剰プロビジョン uplink など、信頼性のための冗長機構が「半壊」を許容するため、平均値ベースのモニタリングでは検出されない。Azure A100 では HBM の correctable error が 10 件を超えるとエンドツーエンド回帰確率が 5.6%→83.3% に跳ね上がる(Table 1)。 2. **長時間・同期ワークロードが劣化を増幅する**: AI 学習は週〜月単位で同期的に動くため、単一ノードの劣化が gang-scheduled 全体を停止させる。Azure A100 クラスタの MTBI は 17.5 時間、38.1% のインシデントが復旧に 1 日超を要する(Figure 1-2)。 3. **部分修復(partial repair)が信頼性を漸減させる**: ToR の冗長 uplink が複数本切れたとき、運用は「動く最小本数だけ復旧」して問題を閉じることが多い。これにより同じノードの 1 回目→20 回目のインシデント間隔は 719.4→151.7 時間まで縮む(Figure 4)。 ## 横断的知見 - **グレイ障害の根本は「Observer が見ているものとアプリが経験しているものの乖離」**: Huang+ 2017 は差分可観測性(differential observability)としてこれを定式化した。ハートビートが「正常」を返しても VM が内部で接続不能なケース(§2.2)・平均パケットロス率が閾値未満でも特定フローが影響を受けるケース(§2.1)・容量制約を報告できないデータサーバへの書き込み継続(§2.3)はいずれも同一の構造的パターンを示す。GrayScope([[@2024__FSE__Illuminating the Gray Zone - Non-Intrusive Gray Failure Localization in Server Operating Systems]])の非侵入的メトリクス箇所特定・Harp の物理パス単位監視・SuperBench のプロアクティブ検証はすべて「Observer の観測ギャップを埋める」という同一の方向性を取る。(Source: [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]] §3.2, [[@2024__FSE__Illuminating the Gray Zone - Non-Intrusive Gray Failure Localization in Server Operating Systems]], [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]]) - **高冗長性はグレイ障害に対して両刃の剣**: Huang+ 2017 はコアスイッチ数が増えるほど少なくとも 1 台がグレイ障害を起こす確率も上がるという逆説を示した($1-(n-1)^m/n^m$ → 1)。SuperBench も ToR の冗長アップリンクが複数本劣化したとき「動く最小本数だけ復旧」することで同一ノードのインシデント間隔が短縮する「部分修復の罠」を報告している。冗長化設計が fail-stop 障害を想定している限り、グレイ障害では効果が薄いか逆効果になりうる。(Source: [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]] §2.1, [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] §2.2) - **集約パケットロス率ではグレイ障害を検知できない**: Pingmesh 系の監視はネットワーク全体の平均的なパケットロス率を見るため、特定フローへの選択的ドロップ(リーフスイッチのシステムソフトウェアバグによる特定フローへのドロップ)や低比率のリンク輻輳では閾値未達で通知されない。Harp([[@2026__NSDI__Harp - Improving VPC Network Availability via Efficient Failure Detection and Rerouting in Tencent Cloud]] §6.1・Figure 11(c)(d))は UDP ソースポートで特定した物理パス単位で健全性を追跡するため、集約率が低くても検知・迂回が可能。SuperBench([[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]])が「モニタリングだけでは漸減する冗長が見えない」と指摘する構造的問題の別事例。(Source: [[@2026__NSDI__Harp - Improving VPC Network Availability via Efficient Failure Detection and Rerouting in Tencent Cloud]] Figure 11, [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] §1) - **AI ワークロードはグレイ障害の倍率器**: gang-scheduled で同期通信が必須なため、単一ノードの劣化が全ノードのアイドル時間に直結する([[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] §1)。同じ観察は [[耐障害LLM訓練]] や [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]] でも繰り返されており、AI 専用の検証/回復メカニズムが必要だという結論を共有している。 - **モニタリングだけでは見えない**: 既存ワークロードのモニタは平均値ベースで冗長の漸減を捕えない。SuperBench は「standalone でハードウェアを stress する独立テスト」が必要だと主張する(§1-2.3)。**この点は [[障害注入]] と相補的**——障害注入は能動的に壊して観察するが、プロアクティブ検証は「正常そうに見えるノードを stress テストして潜在劣化を捕える」。 - **「沈黙ノード」はグレイ障害の AIOps 入力表現版である**: [[@2021__ASE__Graph-based Incident Aggregation for Large-Scale Online Service Systems|GRLIA]] は、障害伝播中の中間サービスがフォールトトレランスやモニタ閾値によりインシデントを出さない現象を、障害影響グラフが分断される主要因として扱う。Huang+ 2017 のグレイ障害が「内部監視では健康に見えるが外部利用では劣化する」非対称性なら、GRLIA の沈黙ノードは「障害の影響を受けているが incident stream には現れない」非対称性である。どちらも平均的・閾値的なモニタリングでは伝播範囲が欠けるため、GRLIA は KPI トレンド類似度で補完し、SuperBench/Harp は能動検証やパス単位監視で補完する。(Source: [[@2021__ASE__Graph-based Incident Aggregation for Large-Scale Online Service Systems]], [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]], [[@2026__NSDI__Harp - Improving VPC Network Availability via Efficient Failure Detection and Rerouting in Tencent Cloud]]) - **失敗モードがワークロード依存**: 同じ Azure A100 クラスタで影響を受けた 4.7% のノードのうち、21.5% は 6 つの代表ベンチを走らせても 1 つでしか劣化を再現できない([[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] §2.3)。「あるベンチで OK だから健全」とは言えず、ベンチマーク群の被覆性こそが鍵。 - **冗長は IB / メモリ / 電源温度の三層で同時に効く**: 熱帯地域のデータセンタでは IB リンクの BER > 10⁻¹² の不良が高緯度比 35×。GPU の thermal throttling もラック位置依存で起きる(§2.1)。同じラックの中でも環境が均一ではないため、「均一なハードウェアに均一な冷却」という前提が信頼性を蝕む。 - **トラブルシューティングと検証は別物**: トラブルシュートは事後的・ワークロード固有・部分修復で打ち切られる。検証はインシデント前に冗長を**全部**修復することを目的とする([[プロアクティブ検証]])。 - **Microsoft 2 年超の実証研究がグレイ障害を「アラームフラッド回避と微細障害検知のトレードオフ」として操作的に定義した**: [[@2020__ESEC-FSE__Towards Intelligent Incident Management - Why We Need It and How We Make It|Chen+ ESEC/FSE 2020]] は Microsoft 6 コアサービスの実証研究から、グレイ障害の産業規模での現れを「アラームフラッドを避けるために設定した鈍感なアラーム閾値が重大問題を見逃す」という構造として記述する(§4.2、Lesson 4)。フォールトトレランス設計が 1 つの障害を複数レイヤのリソース障害に連鎖させ、モニタが閾値ベースの大量アラームを発生させる(アラームフラッド)。これを抑制するため閾値を鈍感にした結果、微妙な性能劣化(グレイ障害)が通知されなくなる。Huang+ 2017 の「Observer/App 非対称性」という理論的定義に対し、本論文は「フォールトトレランス設計 → アラームフラッド → 閾値鈍感化 → グレイ障害の見逃し」という操作的な産業メカニズムを補完する。また本論文は重要度アップグレード(ユーザから重要度が上げられたインシデント)をグレイ障害の近似指標として扱う——直接定量化できない本番環境での代替評価アプローチ。(Source: [[@2020__ESEC-FSE__Towards Intelligent Incident Management - Why We Need It and How We Make It]] §4.2) ## 未解決の問い - **差分可観測性のギャップを自動的に測定する指標はどう設計するか**: Huang+ 2017 は「多次元ヘルス監視」を提唱するが、何をどれだけ監視すれば Observer とアプリの観測ギャップを定量化できるかは未解決。Observer の監視カバレッジと App の観測カバレッジの「差分」を測るメトリクスが必要ではないか。 - **グレイ障害の検知とその検知行為自体が引き起こすグレイ障害をどう両立するか**: Huang+ 2017 §4.2 では「過度なプロービングが劣化システムに追加負荷をかけ逆効果になる」と指摘する。SuperBench のプロアクティブ検証も本番ワークロードへの影響を最小化することが課題。検証密度と干渉のトレードオフの最適設計は？ - **パス単位の直接監視と集約監視の最適組み合わせ**: Harp のパス単位インバンド監視は特定フロー障害を捉えるが、ネットワーク全体のトレンド把握には集約監視が適している。両者を組み合わせてグレイ障害検知を高精度化する設計指針は？ - ground truth が無い状況で、**全ノードが系統的に劣化している場合**(新型 SKU の初期投入や firmware 一斉退化)に CDF 類似度ベースの基準学習は機能するのか。Day-0 デプロイでの基準ブートストラップ手法は何が良いか。 - 「漸減する冗長」を可視化する **operator 向けメトリクス**(redundancy budget のような指標)は設計可能か。現状はインシデント間隔の事後集計しかない。 - インシデントを出さないが KPI だけ異常な「沈黙ノード」を、グレイ障害候補として継続監視すべきか。GRLIA は障害中の集約補助として使うが、同じ信号を平時に蓄積すれば、閾値未満の劣化サービスやモニタ設定不備を先回りで見つけられるか。 - LLM 推論ワークロードや MoE のようなトラフィックパターンに対しても、SuperBench 系の検証は同じ被覆を持てるか。長文出力時の KV cache 帯域や、稀少エキスパートの活性化に依存する劣化は別ベンチを要求するか。 - グレイ障害と [[障害予測]](survival analysis)を組み合わせたとき、**Cox-Time の covariates にどのテレメトリを追加すべきか**(ECC カウンタ・thermal・SMART・NCCL retry など)。 ## 関連 - ソース(定義): [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]] - ソース(検知・緩和): [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] / [[@2026__NSDI__Harp - Improving VPC Network Availability via Efficient Failure Detection and Rerouting in Tencent Cloud]] / [[@2021__ASE__Graph-based Incident Aggregation for Large-Scale Online Service Systems]] / [[@2024__FSE__Illuminating the Gray Zone - Non-Intrusive Gray Failure Localization in Server Operating Systems]] - 概念: [[差分可観測性]] / [[プロアクティブ検証]] / [[フォールトトレランス]] / [[Fault Localization]] / [[GPUクラスタ運用]] / [[GPUレジリエンス]] / [[障害予測]] / [[障害注入]] - 著者: [[Peng Huang]] / [[Lidong Zhou]] / [[Chuanxiong Guo]] - 製品: [[SuperBench]] - MOC: `[[structures/AIOps.MOC]]`(該当があれば一方向参照)