@2025__SIGCOMM__Towards LLM-Based Failure Localization in Production-Scale Networks

# Towards LLM-Based Failure Localization in Production-Scale Networks > [!abstract] 概要(abstract 日本語訳) > 根本原因の特定と障害箇所特定は、クラウドネットワーク運用の信頼性維持において重要である。インシデントが報告されると、ネットワークオペレータは大量の監視データを確認し、できる限り迅速に根本原因(すなわち障害デバイス)を特定しなければならず、経験豊富なオペレータにとっても極めて困難な作業である。大規模言語モデル(LLM)はテキスト理解と推論において大きな可能性を示している。本論文では、オペレータの効率的なインシデント調査を支援するために設計された LLM ベースのフレームワーク BiAn を提案する。BiAn は監視データを処理し、詳細な説明とともに障害デバイスのランキングを生成する。現在までに BiAn は 10 か月間にわたってネットワークインフラにデプロイされており、オペレータが障害デバイスをより迅速に特定する支援に成功し、根本原因特定にかかる時間(TTR)を 20.5% 削減した(高リスクインシデントでは 55.2%)。過去 17 か月の実際のケースに基づく広範な性能評価により、BiAn が正確かつ高速な障害箇所特定を達成することが確認された。ベースラインと比較して精度が 9.2% 向上した。 ## 論文情報 - **タイトル**: Towards LLM-Based Failure Localization in Production-Scale Networks - **著者**: Chenxu Wang¹²、Xumiao Zhang²、Runwei Lu²³、Xianshang Lin²、Xuan Zeng²、Xinlei Zhang²、Zhe An²、Gongwei Wu²、Jiaqi Gao²、[[Chen Tian]]¹、Guihai Chen¹、[[Guyue Liu]]⁴、Yuhong Liao²、Tao Lin²、[[Dennis Cai]]²、[[Ennan Zhai]]² - ¹ [[Nanjing University]]、² [[Alibaba Cloud]]、³ New York University Shanghai、⁴ [[Peking University]] - 責任著者(Corresponding Authors): [[Ennan Zhai]]、[[Chen Tian]]、[[Guyue Liu]] - **媒体**: ACM SIGCOMM 2025 Conference (SIGCOMM '25) - **発表日**: 2025 年 9 月 8〜11 日、コインブラ、ポルトガル - **DOI**: 10.1145/3718958.3750505 - **PDF**: `.raw/papers/sigcomm25-bian.pdf`(16 ページ) ## 概要 BiAn(比安)は、Alibaba Cloud の本番規模ネットワーク(WAN + 87 データセンター)におけるインシデント調査を支援する LLM ベースの障害箇所特定システムである。インシデント 1 件あたり平均 26.4 MB に及ぶ監視アラートを 3 段階の階層推論・3 パイプライン統合・継続的プロンプト更新で処理し、疑わしいデバイスのランキングと説明をオペレータに提供する。10 か月の本番デプロイで TTR 平均 20.5% 短縮(高リスク 55.2%)、17 か月 357 件のオフライン評価で top-1 精度 95.5%(ベースライン 86.3%)を達成した。 ## 問題設定 **入力**: インシデント報告時に上流監視システムが選定した候補デバイス(既定 6 台)の監視アラート群(11 種モニタツール、平均 26.4 MB、最大 1 GB 超) **出力**: 各候補デバイスの障害スコアとランキング + 説明(オペレータが最終判断を行う) **前提条件**: - インシデントが「自己修復」をすり抜けた複雑なケースのみが対象 - ネットワーク運用センター(NOC)の既存監視インフラと独立して動作(既存モニタを置き換えない) - 推定根拠: Alibaba Cloud の 1 週間あたり約 2377 件の自己修復 vs 202 件の手動対応 **困難な理由**: 1. **過剰なアラート**: 1 インシデントで複数デバイスが数百件のアラートを生成する 2. **複雑な根本原因特定**: 単純なルールが適用できず、10 分超かかるケースが多い 3. **高いインシデント負荷**: 週 202 件を処理するオペレータの能力依存が大きい ## 提案手法 ### システム名: BiAn(比安) 中国神話の「比安」(正邪を見分ける神獣)から命名。ネットワーク環境で根本原因と障害デバイスを知的に分析する役割を反映する。 ### アーキテクチャ概要 **Figure 4: BiAn のシステムアーキテクチャ — 2 段推論プロセス** ![[_attachments/sigcomm25-bian/fig04-system-architecture.png]] (Figure 4. 第 1 段ではすべての候補デバイスに初期スコアを付与し、第 2 段ではより包括的なデータで絞り込んだデバイスを再分析して、障害デバイスのスコア差が顕著になる。) ### Step 1: 監視アラートの要約(Monitor Alert Summary) 11 種類の上流監視ツール(Dashboard Alarms・Link States・Link Traffic Usage・Traffic Drop Device・Packet Error・High-risk Syslog・Device Ping Log・Port Down Events・Command History・Device Change History・Syslog Volume)の各アラートを専用の LLM エージェントが処理し、デバイスごとに 11 種の凝縮サマリーを生成する。プロンプトは「役割定義・入力フィールド記述・要約ガイドライン・アラート例・期待サマリー・応答フォーマット」の 5 部構成。 **Figure 5: データソース種別と異常シナリオのマッピング** ![[_attachments/sigcomm25-bian/fig05-datasource-mapping.png]] (Figure 5. 11 種のデータソースが 7 種の異常シナリオ(Device Down / Congestion / Traffic Drop / Flapping / Network Changes / Syslog Surge / Alarm Count)にマッピングされる。10 年のオペレーション経験から導いた 7 シナリオがすべての観測可能な異常を網羅する。) ### Step 2: 単デバイス異常分析(Single-device Anomaly Analysis) 7 種の異常シナリオに対応する 7 つの LLM エージェントが、SOP(標準操作手順)に従い段階的に各デバイスの異常を分析する。1 デバイスが複数の異常を持つ場合もある。 ### Step 3: 統合スコアリング(Joint Scoring — Pipeline 1) 全デバイスの異常分析レポートをまとめた LLM エージェントが、各デバイスへの障害スコア(合計 1.0 になるよう正規化)を出力する。最高スコアのデバイスを障害デバイスとして特定する。 ### 4.2 3 パイプライン統合(Stage 2) Pipeline 1(SOP ベース)だけでは空間的・時間的複雑性を捉えられない場合に追加 2 パイプラインを統合する。 - **Pipeline 2: ネットワークトポロジー**: デバイス間の最短経路を使ってサブトポロジーを構築し、異常の伝播関係(親ノードが障害源になりやすいこと)を LLM に伝える。 - **Pipeline 3: イベントタイムライン**: 全デバイスのイベントを発生時刻順に列挙し、早い段階で異常が現れたデバイスの疑いを高める。 **統合推論**: Pipeline 1 の全デバイス初期スコアの後、Top-p フィルタで低疑惑デバイスを除外し、上位デバイスのみを Stage 2 で再分析する。3 パイプラインを統合した最終スコアリングを N=3 回実行し、**Rank of Ranks**(ランク平均)で LLM の出力ゆらぎを平滑化する。 ### 4.3 継続的プロンプト更新(Continuous Prompt Updating) ネットワーク構成の急速な進化に対応するため、LLM パラメータをファインチューニングする代わりに「プロンプトを学習させる」機構を導入する。 **Figure 7: 継続的プロンプト更新メカニズム** ![[_attachments/sigcomm25-bian/fig07-prompt-updating.png]] (Figure 7. Exploration→Reflection→Knowledge Consolidation→Prompt Augmentation の 4 段ループ。高温度 T で複数の推論トライアルを生成し、正解・不正解の差分から有用知識を抽出してプロンプトに統合する。) 4 段ループ: 1. **Exploration**: 現在のプロンプトで各インシデントに対して 5 回の推論を実行し、不完全なケースについて高温度 T で多様な推論を生成する 2. **Reflection**: Agent R が正解・不正解の推論を比較し、根本原因特定に影響する重要因子と実行可能知識を抽出する 3. **Knowledge Consolidation**: Agent C が全インシデントから抽出された知識を頻度別にランク付けし、上位 6 件を保持する 4. **Prompt Augmentation**: 統合された知識をタスクプロンプトに追記し、新旧知識をバッファで管理・マージするプロンプト更新は数か月ごと(主要ハードウェア・ソフトウェアアップグレードに合わせて)実施する。 ### 4.4 システム最適化 - **ファインチューニング**: Pipeline 1 の Step 1(アラート要約)と Step 2(異常分析)には小型 Qwen2.5-7B-Instruct をファインチューニングして使用し、Stage 2 等の複雑なタスクには大型 Qwen2.5-72B-Instruct を使用する。GPT-4 を教師ラベル生成に活用し、ルールベースアルゴリズムで正解性を検証する。 - **早期停止(Early Stop)**: Stage 1 のスコアエントロピーが閾値(0.75)を下回れば Stage 2 をスキップする。全ケースの 1/3 が早期停止対象となり、処理時間を 70.0% に短縮しつつ精度損失は 0.5% 以下。 - **並列実行**: 同ステップ内の複数エージェントを並行実行し、Rank of Ranks の N 回推論も並列化する。 ## 新規性既存の LLM ネットワーク運用研究の限界: - MonitorAssistant: ガイダンス指向のアノマリーレポートのみ生成、障害デバイスを特定しない - Oasis: 影響範囲評価とサマリー生成のみ - RCACopilot: 根本原因カテゴリ(粗粒度)のみ出力、具体的デバイスの特定なし - NetAssistant: 診断意図を認識してワークフロー実行、調査作業はオペレータに委任 - Ahmed ら: インシデントタイトルとダイジェストのみ使用(詳細ログを活用しない) BiAn の新規性: 1. **本番規模でのエンドツーエンド実装**: 17 か月 357 件のリアルインシデント評価 + 10 か月本番デプロイ 2. **3 パイプライン統合**: SOP ベース分析に加えてトポロジー伝播と時系列順序という 2 次元を追加 3. **ファインチューニングなしのプロンプト更新**: LLM パラメータを変えずにドメイン知識を継続的に学習させる機構 4. **Rank of Ranks**: 複数推論の平均スコアではなく平均ランクで LLM 出力のゆらぎを安定化 ## 実験設定 - **環境**: Intel Xeon Platinum 8269CY 2.50 GHz、32 GB RAM、1 TB SSD - **データセット**: 過去 17 か月にわたる実ネットワークインシデント 357 件(ポストインシデントレビューで根本原因が確定済み) - **モデル**: Qwen2.5-7B-Instruct(ファインチューニング済み、Step 1-2 用) + Qwen2.5-72B-Instruct(その他) - **ベースライン**: Hot Device(最多アラート関連デバイスを選ぶ手法、007 [NSDI 2018] から着想) - **評価指標**: Top-K 精度(Top-1/2/3)、TTR(根本原因特定時間) ## 実験結果 ### 精度 **Figure 9: インシデント分類別の箇所特定精度** ![[_attachments/sigcomm25-bian/fig09-accuracy-results.png]] (Figure 9. リスクレベル(左)・解決時間(中)・障害タイプ(右)で分類した BiAn と Hot Device の Top-1 精度比較。BiAn は全分類で Hot Device を上回る。) - **全体精度**: BiAn 95.5%、Hot Device 86.3%(+9.2pp) - **Top-2/Top-3**: BiAn 98.6% / 99.3%、Hot Device 88.9% / 93.0% - **同率首位ケース**: Hot Device は 70.5% に低下するが BiAn は 97.1% を維持 - **リスクレベル別**: 低・中リスクはほぼ同等; 高リスクは 87.2% に低下(同時多発インシデントによるノイズ増加) - **解決時間別**: 容易(≤1 分)95.7% → 中程度(1-5 分)92.9% → 困難(>5 分)87%程度 - **障害タイプ別**: ラインカード障害が最良(ホストデバイス単体に影響が限定されるため) ### アブレーション研究 **Figure 12: 設計段階ごとの精度推移** ![[_attachments/sigcomm25-bian/fig12-ablation-design-phases.png]] (Figure 12. Stage 1 のみ 87.2%→ Top-p フィルタ追加で 5.9% 向上 → Pipeline 2/3 追加でさらに向上 → 全構成で 95.5%。Top-p なしで 3 パイプライン統合すると全デバイスデータがトークン数を膨張させ精度が下がることに注意。) ### レイテンシとコスト - **エンドツーエンドレイテンシ**: 30 秒以内(並列実行で実際の合計が理論値の 115% 以内) - **ファインチューニングコスト**: 平均 $121.63 - **推論コスト**: Pipeline 1 単独 $0.17、BiAn 全体 $0.18 /インシデント ### A/B テスト(本番デプロイ) **Figure 8: TTR 比較と説明品質スコア** ![[_attachments/sigcomm25-bian/fig08-ttr-satisfaction.png]] (Figure 8. (a) リスクレベル別 TTR: BiAn がすべてのリスクレベルで Human RCA を下回る。高リスクで差が拡大する(LLM 推論時間がリスクレベルに依存しないため)。(b) 説明に対する満足度スコア: 大半が「やや役立つ(1)」または「非常に役立つ(2)」と評価し、「役に立たない(0)」は少数。) ### LLM 汎化性 Table 1 によると BiAn の設計は特定の LLM に依存しない: | モデル | サイズ | Top-1 | Top-2 | Top-3 | |---|---|---|---|---| | Qwen2.5 | 72B | 95.5% | 98.6% | 99.3% | | Llama-3.1 | 405B | 95.7% | 98.7% | 99.3% | | GPT-4o | — | 95.2% | 98.1% | 99.3% | | Claude-3.5-Sonnet | — | 93.9% | 97.4% | 98.5% | | Gemini-1.5-Pro | — | 93.2% | 97.9% | 98.7% | ## 考察 - **マルチデバイス障害**: BiAn は 1 インシデント = 1 障害デバイスを仮定しており、複数デバイスが同等に寄与するケース(例: 2 台の設定変更)に対応していない。ただし説明・スコアで上位 2 台が接近して現れることが多く、オペレータが気づける。 - **上流監視依存**: 無効または曖昧な監視データがある場合、BiAn も正確な特定が困難になる(人間オペレータも同様)。 - **リンクベースのインシデント未対応**: 現在はデバイスベースのインシデントのみ。リンクベースへの拡張は今後の作業。 ## 強み / 弱点・課題 **強み**: - 本番 10 か月・17 か月評価という実証規模の大きさ - LLM パラメータを変えずにプロンプト更新で継続学習する実用的アプローチ - Rank of Ranks による出力の安定化 - Top-3 精度 99.3% という高いフォールトトレランス **弱点・課題**: - API レイテンシ変動(平均 5 秒だが最大 16 秒の揺れ) - プロンプト長増加に伴う性能劣化(情報過多による注意散漫) - 静的ワークフロー設計(エージェントが失敗分析の再試行・ステップスキップ・動的エージェント呼び出しなどの適応的行動を持たない) ## 関連 - エンティティ: [[Ennan Zhai]] / [[Chen Tian]] / [[Nanjing University]] / [[Alibaba Cloud]] / [[Guyue Liu]] / [[Peking University]] / [[Dennis Cai]] - 概念: [[Fault Localization]] / [[LLMによる根本原因分析]] / [[ネットワーク監視]] / [[マルチエージェント協調]] / [[インシデント管理]] - 関連ソース: [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]] / [[@2025__SIGCOMM__SkeletonHunter - Diagnosing and Localizing Network Failures in Containerized Large Model Training]] / [[@2025__NSDI__Evolution of Aegis - Fault Diagnosis for AI Model Training Service in Production]]