# クラウドインフラ障害診断 ## 定義 クラウドインフラ障害診断(Cloud Infrastructure Failure Diagnosis)は、IaaS・PaaS を支える物理デバイス群(IDC・クラウドネットワーク・クラウドサーバー等)で発生する障害の根本原因を自動的に特定し、トラブルシューティングを支援する取り組みの総称。 特に**バッチサーバー障害(Batch Servers Outage)**——関連する複数サーバーが同時にダウンし、上流サービスをすべて利用不能にする最も深刻な障害類型——の診断は、(1) 粗粒度監視データしか利用できない、(2) ドメイン横断の複雑な障害相関がある、(3) 複数障害の累積効果が原因になる、という 3 つの困難を抱える。 マイクロサービス RCA([[根本原因分析]])がメトリクス・ログ・トレースの細粒度データを前提とするのに対し、クラウドインフラ障害診断は**粗粒度監視データ(アラート・インシデント・変更)**のみを入力とする点で問題設定が根本的に異なる。([[@2025__arXiv__BSODiag - A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems]]) ## 横断的知見 - **粗粒度 3 モーダルの補完性**: Alibaba Cloud インフラの実証分析(BSODiag §II-C)で、インシデントは深刻な障害(スイッチ再起動・電源遮断)は捉えるが軽微な障害(高 CPU 使用率)を見逃し、アラートは軽微な障害に敏感だが偽陽性が多く、変更はどちらも捉えない障害(エアコン冷媒交換などの設定変更)を捉えることが確認された。3 モーダルを統合することで初めて包括的な障害プロファイリングが可能になる。単一ソースだけでは 6 種の障害類型のうち全種を捉えることができなかった。(Source: [[@2025__arXiv__BSODiag - A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems]] §II-C, 表I) - **根本原因の 78.4% はクロスドメインネットワーク障害**: Alibaba Cloud の 95 アウタージケースの分析で、根本原因の分布はネットワーク障害 78.4%・IDC 障害 14.8%・サーバー障害 6.8%。IDC 障害はリソース共有による伝播(ラック内一括影響)、ネットワーク障害は階層構造伝播(ロードバランサー→スイッチ→サーバー)という異なる相関メカニズムを持つ。単一の相関モデルではカバーできない。(Source: [[@2025__arXiv__BSODiag - A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems]] §II-C, 図3a) - **根本原因箇所特定だけでなく障害伝播パスが現場運用に不可欠**: BSODiag の実証分析(§II-C, RQ3)で、現場エンジニアは根本原因(電源障害)の修復だけでなく、伝播経路上の老朽化した PSW(Polymerize Switch)も発見・修復しなければならないことが示された。上位 k 件の根本原因ランキングを返すだけの手法はこの要件を満たさない。障害伝播パスの推論は「現場での再発防止」のための本質的な出力要素である。(Source: [[@2025__arXiv__BSODiag - A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems]] §II-C, 図4) - **教師なしアプローチがクラウドインフラ障害診断に適する**: アウタージケースの希少性から、ML ベースの教師あり分類器(SVM・Random Forest)は訓練データ不足で最適化が困難。BSODiag の実験では、教師なしの BSODiag(PR@3 87.5%)が Random Forest(74.3%)・SVM(66.1%)を大きく上回った。コスト ≪ 精度のトレードオフを教師なし設計で改善できる。(Source: [[@2025__arXiv__BSODiag - A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems]] §V-B, 表III) - **歴史的知識と現在の物理依存性の両方を組み合わせることが精度の鍵**: アブレーション実験で、障害知識グラフ(歴史的障害相関)・CMDB(現在の物理接続性)・MAPR(ランダムウォーク)のいずれを除いても全指標が低下した。特に CMDB 除去は「同一ドメイン内の物理的に隣接した障害」の相関を失う最大の要因となった。歴史的パターンと現在の状態の時空間統合がグローバル診断の核心である。(Source: [[@2025__arXiv__BSODiag - A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems]] §V-D, 図7) ## 未解決の問い - BSODiag の障害ルールツリーは専門家が手動構築するが、クラウド環境の変化に合わせて自動的に更新する機構はどう設計できるか。 - 新設クラウドシステムや初期フェーズ(歴史的障害データ不足)での障害知識グラフの冷スタート問題をどう解決するか。少数ショット学習や転移学習の適用可能性は？ - Alibaba Cloud 以外の CSP(AWS・Azure・GCP)でのクラウドインフラ障害診断の根本原因分布は同様か。異なるアーキテクチャへのモデルの汎化可能性は評価されていない。 - LLM を障害知識グラフの自動構築や障害種別分類に活用できるか。テキスト形式のインシデントチケットから構造化された障害相関を抽出する LLM ベースのアプローチは有望か。 - マイクロサービス RCA と物理インフラ RCA を統合した「レイヤーをまたぐ根本原因分析」のフレームワークは実現可能か。PolarDB などのクラウドサービスが物理インフラ障害に起因する場合、両レイヤーを接続した診断が必要になる。 ## 関連 - 親概念: [[根本原因分析]] - 兄弟概念: [[グラフベースRCA]] / [[マルチモーダル障害診断]] / [[データセンター信頼性]] - 論文: [[@2025__arXiv__BSODiag - A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems]] - システム: [[BSODiag]] - 研究機関: [[Xi'an Jiaotong University]] / [[Alibaba Cloud]] ## 出典 - [[@2025__arXiv__BSODiag - A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems]](§I〜VII 全体。特に §II-C 実証分析、§IV 手法、§V 実験)