# プロアクティブ検証 ハードウェア・ソフトウェアスタックを**インシデント発生前にベンチマーク群で能動的に stress テストし、潜在的な劣化や障害を顕在化させる運用方式**。リアクティブなトラブルシューティング(インシデント発生後に根本原因を追う)、ベンダーによる pre-qualification test(納品前の一回限り)、性能ベンチマーク(MLPerf 等、ランキング目的)とは区別される。 [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] が満たすべき三要件を整理した: 1. **Comprehensive**: ベンダ qualification を通過したクラスタでも実ワークロードでしか出ない劣化を捕える網羅性。 2. **Clear-cut**: 漸減する劣化と自然変動を区別する明確な境界。同じテストの繰り返しで判定がぶれない再現性。 3. **Cost-efficient**: 検証コスト < 期待インシデント損失。検証時間とインシデント被覆の trade-off を明示的に最適化する。 ## 設計問題と主要解決アプローチ([[SuperBench]] 由来) - **基準学習(criteria learning)**: ground truth が無い前提で、経験 CDF の片側距離による類似度クラスタリングで欠陥/正常の境界を引く。平均値や LOF/One-Class SVM のような外れ値検出では境界が不明瞭(Figure 6, 9)。 - **検証部分集合の選択(benchmark selection)**: Cox-Time 生存解析でノードのインシデント確率を予測し、$\Delta p / t_i$(単位時間あたりの確率減少)が最大の順に貪欲選択。NP 困難な 0/1 ナップサックの変種を $O(n^2)$ に近似(Algorithm 1)。 - **検証イベント設計**: (1) ノード追加・firmware アップグレード、(2) ジョブ allocation、(3) 顧客インシデント報告のいずれかをトリガとしてイベント駆動、加えて定期的な regular validation。 - **ネットワーク検証の高速化**: Clos トポロジ性質を利用した Full Scan $O(n)$ と、$k$-tier fat-tree の hop ベース Quick Scan $O(1)$ で、規模に依存しない検証時間を実現。 - **パラメータ自動探索**: ベンチマークの周期を季節分解で推定し、warmup/measurement 長を自己類似度しきい値で最小化(再現性 < 1% 低下で 67.5〜78.3% 時間削減)。 ## 横断的知見 - **トラブルシューティングの限界をデータで示せる**: Azure A100 では 38.1% のインシデントが復旧に 1 日超、10.3% が 2 週間超([[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] Figure 2)。事後対応のみでは平均故障間隔を回復できないという定量根拠が、プロアクティブ検証の経済合理性を支える。 - **「全検証」も最適ではない**: SuperBench の Selector はフルセット検証と比べ MTBI を 1.11×、ノード利用率を 1.09× 改善する(Table 4)。検証自体がノード時間を消費するため、**検証時間も TCO の一部として扱う**設計が鍵。 - **CDF ベースの基準は variation の大きい AI ベンチに強い**: MLPerf でも安定系で ±2.5%、高変動系で ±5.0% の variance がある中、平均比較ではしきい値の意味を保てない。CDF 形状で「全体としてシフトしているか」を見ることでハードウェア起因の漸減を捕える。 - **OSS 化により業界標準化が進む**: microsoft/superbenchmark は AMD Instinct や PyTorch/ROCm ドキュメントで参照され、vendor 共有のベースラインになる(§1)。 - **[[障害予測]] と組み合わせる**: Cox-Time 単独では予測しかしないが、SuperBench は予測を「次に何を検証するか」のアクションに変換した点で価値がある。生存解析の AIOps への落とし込み方として参照可能。 - **「検証コストをどう抑えつつ継続的に実施するか」というプロアクティブ検証の Cost-efficient 要件は、GPU インフラに限らず人的なインシデント対応テストにも独立に現れる**: SuperBench はハードウェア検証のノード時間コストを TCO の一部として扱い、フルセット検証でなく Cox-Time で優先順位付けした部分集合検証によって MTBI とノード利用率を両立させる(横断的知見既出)。Google 自身が著した Anatomy of an Incident 2章は、対象が GPU クラスタでなく人的なインシデント対応プロセスであるにもかかわらず、同じ経済的トレードオフを独立に提示する——「運用予算の10%を割く」ような大規模な一括検証より、「4週間ごとに1時間」といった継続的な小規模テストの方が正当化しやすいと述べ、チームを疲弊させないことと勢いを失わないことのバランスでペースを決めるべきだとする。検証対象(ハードウェア vs 人的プロセス)がまったく異なる2つのソースが、「全数検証よりコスト意識を持った部分的・継続的な検証の方が持続可能である」という同じ設計原則に到達している点は、プロアクティブ検証が特定ドメインに縛られない一般的な信頼性設計パターンであることを示唆する。(Source: [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]], [[@2022__OReilly__Anatomy of an Incident - Chapter 2 Practicing Incident Response Readiness (Preparedness)]]) - **カオスエンジニアリングの一次資料は、本ページが集約する「プロアクティブ検証」という語をSREの規律区分そのものの分類軸として用いる**: 『カオスエンジニアリング ― 回復力のあるシステムの実践』3章は、アラートツール・インシデント対応管理・モニタリングツール・ディザスタリカバリ計画をいずれも「インシデントへの検知・解決までの時間を減らすリアクティブな実践」と位置づけ、SREを「過去のインシデントを糧として未来のインシデントを防ぐことでリアクティブとプロアクティブの両方の規律にまたがる」規律、カオスエンジニアリングを「プロアクティブに複雑なシステムの安全性を改善することだけに注力した唯一の主要な規律」と分類する。これは SuperBench や Anatomy of an Incident が実務上のコスト最適化として論じる「事後対応 vs 事前検証」の対比(横断的知見既出)を、規律・実践の分類体系というより上位のレベルで裏付けるものであり、GPU インフラのプロアクティブ検証・人的インシデント対応テストの継続実施(既出)・カオスエンジニアリングの本番実験はいずれも「事後対応だけでは信頼性の天井を超えられない」という同一の経済的直観を異なる実践形式で具体化した事例として整理できる。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 3 原則の全体像]] §3.2.1, [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]]) ## 未解決の問い - Anatomy of an Incident の「4週間ごとに1時間」のような具体的なペース配分の目安は経験則にとどまり、SuperBench の Cox-Time 生存解析のような定量モデルを持たない。人的インシデント対応テストの検証頻度を、SuperBench 的な「単位時間あたりのインシデント確率減少」の枠組みで最適化することは可能か。(Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 2 Practicing Incident Response Readiness (Preparedness)]], [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]]) - 推論ワークロード(LLM serving、MoE)や混合ワークロードに対するベンチマーク集合はどう設計すべきか。SuperBench は学習ワークロード中心。 - 検証部分集合選択の被覆率 $\mathcal{C}$ は過去 trace 依存。**未知の故障モード**に対する保険になっていないことを補強する仕組み(active testing、chaos engineering、[[障害注入]])との結合は。 - 「正常」のドリフト(firmware アップデート・ワークロード進化)に追随する基準更新ループは現状オフライン+定期再学習。**オンライン学習化**は可能か。 - マルチクラウド/オンプレ混在環境で、ベンチマーク基準の互換性をどう保つか。SKU・BIOS・ドライバ・ハイパーバイザ依存が大きい。 ## 関連 - ソース: [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] / [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 3 原則の全体像]] - 概念: [[グレイ障害]] / [[プロアクティブ障害管理]] / [[GPUクラスタ運用]] / [[GPUレジリエンス]] / [[障害予測]] / [[障害注入]] / [[カオスエンジニアリング]] - 製品: [[SuperBench]]