# グレイ障害 クラウドや分散システムにおいて、コンポーネントが**完全には停止しないが徐々に性能が劣化する**故障様式の総称。Huang+(HotOS 2017、[[Lidong Zhou]] 共著)が "gray failure: the Achilles' heel of cloud-scale systems" として定式化し、Arpaci-Dusseau+(2001)の「fail-stutter」、Gunawi+(TOS 2018)の「fail-slow at scale」、Do+(SoCC 2013)の「limpware / limplock」、Lou+(NSDI 2020)の「partial failure」など、類似概念が多分野で並立する。**特徴は observability の非対称性**——システム内部の監視が「OK」を返す一方で、利用側のアプリは明確に劣化を観測する([[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] §6)。 ## 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)。 ## 横断的知見 - **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 テストして潜在劣化を捕える」。 - **失敗モードがワークロード依存**: 同じ 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)。同じラックの中でも環境が均一ではないため、「均一なハードウェアに均一な冷却」という前提が信頼性を蝕む。 - **トラブルシューティングと検証は別物**: トラブルシュートは事後的・ワークロード固有・部分修復で打ち切られる。検証はインシデント前に冗長を**全部**修復することを目的とする([[プロアクティブ検証]])。 ## 未解決の問い - ground truth が無い状況で、**全ノードが系統的に劣化している場合**(新型 SKU の初期投入や firmware 一斉退化)に CDF 類似度ベースの基準学習は機能するのか。Day-0 デプロイでの基準ブートストラップ手法は何が良いか。 - 「漸減する冗長」を可視化する **operator 向けメトリクス**(redundancy budget のような指標)は設計可能か。現状はインシデント間隔の事後集計しかない。 - LLM 推論ワークロードや MoE のようなトラフィックパターンに対しても、SuperBench 系の検証は同じ被覆を持てるか。長文出力時の KV cache 帯域や、稀少エキスパートの活性化に依存する劣化は別ベンチを要求するか。 - グレイ障害と [[障害予測]](survival analysis)を組み合わせたとき、**Cox-Time の covariates にどのテレメトリを追加すべきか**(ECC カウンタ・thermal・SMART・NCCL retry など)。 ## 関連 - ソース: [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] - 概念: [[プロアクティブ検証]] / [[GPUクラスタ運用]] / [[GPUレジリエンス]] / [[障害予測]] / [[フォールトトレランス]] / [[障害注入]] - 製品: [[SuperBench]] - MOC: `[[structures/AIOps.MOC]]`(該当があれば一方向参照)