## Memo ![[Pasted image 20251126093518.png]] ## Memo with LLM ### 論文情報 **論文のタイトル**: AlertGuardian: Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems **著者と所属**: - Guangba Yu (Sun Yat-sen University, Guangzhou, China) - Genting Mai (Sun Yat-sen University, Guangzhou, China) - Rui Wang (Tencent, Shenzhen, China) - Ruipeng Li (Tencent, Shenzhen, China) - Pengfei Chen (Sun Yat-sen University, Guangzhou, China) - 責任著者 - Long Pan (Tencent, Shenzhen, China) - Ruijie Xu (Tencent, Shenzhen, China) **カンファレンス/ジャーナル名**: ASE 2025 (40th IEEE/ACM International Conference on Automated Software Engineering) **発表年**: 2025 ### 論文概要 AlertGuardianは大規模クラウドシステムにおけるアラート疲労を解決するフレームワークであり、大規模言語モデル(LLM)と軽量グラフモデルを協働させて、アラートのライフサイクル全体を管理する。アラートの除外ノイズ処理、自動要約生成、アラートルールの自動最適化という3つの段階を通じて、アラートストームを削減し、故障診断の効率化を実現する。Company-Xの4つの実データセット(ゲーム、オフィス、メディア、教育)での評価により、93.82%～95.50%のアラート削減率を達成し、1年以上の本番運用において実績を示している。 ### 詳細解説 #### 問題設定 大規模クラウドシステムでは、信頼性と可用性の監視のために膨大な数のアラートルールが設定される。しかし現実には以下の問題が発生している: **1) アラートストーム**: Company-Xの分析によると、200以上のシステムで1分間に平均200件以上のアラートが発火し、1日当たり数十万件のアラートが生成される。これらのアラートの大部分は実際の故障と無関係な「ノイズ」である。ノイズは以下の2つに分類される: - **常時アラート**: システムが正常に動作していても継続的に発火するアラート。通常、アラートルールの閾値が過敏に設定されている(例: CPU使用率40%という低すぎる閾値)。 - **周期的アラート**: 定期的に発火するアラート。例えば夜間の定期的なホスト再起動により毎日アラートが発生する。 **2) 低品質なアラートルール**: 手動で作成されたアラートルールには以下の欠陥がある: - **機能的冗長性**: 異なるエンジニアが同じ監視対象に対して複数のルールを作成し、属性の組み合わせも異なるため、実質的に同じアラートが重複している(例: Pod非実行状態を検出するRule-1とRule-2は別々に実装されている)。 - **不適切な静的閾値**: ルールの閾値が固定されており、トラフィックパターンや運用環境の変化に対応できず、常に誤検知が発生する。 **3) アラート管理プロセスの欠如**: 従来のアラート管理システム(例: [[Prometheus]] Alertmanager)はアラートルール設定と発火に注力し、以下の段階が不足していた: - **アラート要約**: ノイズ除外後も複数のクリティカルアラートが存在し、SREは各アラートの意味や根本原因を理解するために、システムドキュメント、インシデントチケット、アラートルール説明を手動で関連付ける必要がある。 - **アラートルール最適化**: 一度設定されたルールは実質的に永続的と見なされ、運用で得られた知見がルール設計にフィードバックされない。 #### 提案手法 AlertGuardianは以下の3つの段階を持つエンドツーエンドのフレームワークである: **① Alert Denoise (アラート除外ノイズ処理)** リアルタイムアラート処理のため、従来のクラスタリング手法ではなく、グラフ学習モデル「GraphGuardian」を採用した。このモデルはLINE (Large-Scale Information Network Embedding)と[[Transformer]]アーキテクチャを組み合わせている: - **前処理**: アラートを1分単位の時間窓に分割し、定義上の継続期間を考慮して複製する。高カーディナリティ属性(例: Pod ID、IPアドレス)は「ANON_POD_ID」のように匿名化し、計算量を削減する。仮想的なノイズアラートを毎分発火させ、これと共起頻度の高いアラートをノイズとして識別する。 - **共起行列の構築**: 各時間窓iに対して共起行列Miを構築(共起するアラートのペアを1でマーク)。複数の時間窓をまたいで統計的共起行列Mを集約する。 - **グラフ学習**: LINEは直接接続の共起頻度に基づいて局所的な"第一次"および"第二次"の近接性を学習する。Transformerは自己注意メカニズムを通じてすべての属性値ペアコードを同時に分析し、より複雑な高次依存関係を学習する。 - **類似度計算と閾値**: アラートu,vの埋め込みベクトルhuとhvに対して、二乗コサイン距離で類似度を計算する: d(hu,hv) = 1 − (hu·hv^T)/(||hu|| ||hv||)^2 コスト関数としてMLE(最尤推定)を使用し、共起頻度を二項分布として扱う: Binomial(k,c,p) = C(c,k) p^k (1-p)^(c-k) ここで p = d(hu,hv)、kは共起回数、cは総出現回数 - **オンライン推論**: 仮想ノイズアラートとの類似度が閾値θ(デフォルト0.7)以上のアラートをノイズとして分類し、それ以外を重要なアラートとして保持する。 **② Alert Summary (アラート要約)** ノイズ除外後も複数のクリティカルアラートが存在する場合、RAG(検索増強生成)とLLMを使用して、アラートを根本原因分析や推奨解決策を含む実行可能な要約に変換する: - **パイプライン**: 各アラートについてRAGシステムが属性(ルール名、コンポーネント名等)を使用して知識ベースから関連チャンク(アラートルール説明、インシデントチケット、システムドキュメント)を検索。関連チャンクをフィルタリングし、キャッシュされたシステムコンテキスト概要で強化。LLMに提供される。 - **LLMの判断**: LLM(Deepseek V3)がアラートの実行可能性を判定し、実行不可能なアラート(例: 一時的な異常)に対しては沈黙を保ち、実行可能なアラートに対しては構造化された以下の報告書を出力する: - Alerts: 現在の診断プロセスに最も関連する最大5つのアラート - Root Cause: 異常につながったルートコーズコンポーネント - Explanation: 故障診断の根拠 - Solution: ルートコーズに対する具体的な改善措置 - Reference: 関連するドキュメントへのリンク - **RAGを選択した理由**: LLMには静的な汎用知識しかなく、Company-X固有の運用知識にアクセスできない。fine-tuningは計算コストが高く、データセットの陳腐化やオーバーフィッティングのリスクがあるため、RAGで内部ドキュメントをベクトル化して保持し、プロンプト時に動的に関連チャンクを検索する方式が採用された。 **③ Alert Rule Refinement (アラートルール最適化)** ノイズアラートを特定する除外ノイズ処理の結果を基に、オフラインでアラートルールを自動最適化する。マルチエージェント・ワークフローを採用し、30分ごとに実行される: - **Detect Agent**: HDBSCANアルゴリズムでアラートをクラスタリングし、パターン検出ツールで周期的パターンを特定。アラートを改善が必要なクラスタまたはパターンに分類。 - **RAG Agent**: 各カテゴリグループについてRAGベクトルDBをクエリし、関連知識チャンク(ルール説明等)を集約して検索。 - **Rule Agent**: LLMを用いて4つのポリシーでルールを改善: - **ルール重複排除**: セマンティック意図と運用オーバーラップを比較し、冗長なルールを特定してマージ。 - **ルール集約**: 似たアラートをターゲットとするルール(例: Rule-1とRule-2の「Pod未実行」検出)を統合属性と共役条件(AND論理)でジェネラライズ。 - **閾値調整**: 知識ベースから対応する性統計分布(例: CPU使用率、レイテンシ)を分析し、過去30日の95パーセンタイル値などに基づいて適応的閾値を推奨(例: CPU閾値を40%から60%に引き上げ)。 - **時間分析**: 定期保全時間枠や日々のスパイク除外など、時間ベースの条件を提案(例: 5分以上継続する場合のみトリガー)。 - **Review Agent**: 構文チェックツールでシンタックスエラーを検証し、シミュレーションツールで過去のアラートに対してルールをテスト。ノイズ削減とクリティカルアラート保持のバランスが取れているか確認。 - **反復フィードバックループ**: 以下の停止条件を満たすまで反復: - **シンタックス整合性**: エラーがない。 - **クリティカルアラート保持**: すべてのクリティカルアラートが保持される。 - **ノイズ削減**: ノイズアラート比率が閾値(デフォルト5%)以下に落ちる。 30回の反復後も条件を満たさなければ最適化を終了。最終的に改善されたルールはSREの承認を得る。 #### 新規性 AlertGuardianの主な新規性は以下の通り: **1) 包括的なアラートライフサイクル管理**: 従来研究はアラート除外ノイズ処理やランキング単体に焦点を当ててきたのに対し、AlertGuardianはアラートルール生成から発火、処理、最適化までの全段階を統合的に扱う。 **2) 高カーディナリティ属性への対応**: 従来の共起頻度ベースの手法(OAS、UHAS)は属性の値域が小さいことを前提としていたが、AlertGuardianは属性の匿名化によって数百～数千の値域を持つ属性にも対応。Graph-based approachにより、OAS/UHASでは処理困難な属性の多様な組み合わせを効率的に扱う。 **3) LLMとグラフモデルのハイブリッドアプローチ**: - Alert Denoiseではリアルタイム処理に必要な低遅延のため軽量なグラフモデル(LINE+Transformer)を採用。 - Alert Summaryではセマンティックなアラート理解とコンテキスト生成のためLLMを活用。 - Rule RefinementではLLMのテキスト理解能力を用いた複雑なルール改善提案。 **4) RAG統合による知識活用**: 企業固有の運用知識(システムドキュメント、インシデントチケット、ルール説明)をベクトル化して保存し、動的に検索・活用。fine-tuningなしに実装可能で、知識ベースの更新に自動的に対応。 **5) 透明性とSREによる検証**: LLMが生成するルール改善提案の理由説明を提供し、またマルチエージェント・ワークフローの反復的フィードバックにより、最終的にSREの承認を得る人間中心設計。 #### 実験設定 **データセット**: Company-Xの4つの実運用システムから9日間のアラートデータを収集: - Dataset A (Game): 12,960ルール、2,853,345アラート、138インシデント - Dataset B (Office): 3,544ルール、1,243,259アラート、114インシデント - Dataset C (Media): 59,607ルール、3,883,293アラート、187インシデント - Dataset D (Education): 6,962ルール、2,692,964アラート、179インシデント **実装**: Python 3.7.2、PyTorch 1.13.1を使用。グラフ学習モデルは最初の6日のアラートで訓練し、最後の3日で評価。LLMはDeepseek V3(Alert Summary)とDeepseek R1(Rule Refinement)を使用。 **評価指標**: - **アラート削減比率**: (初期アラート数 − 除外後アラート数) / 初期アラート数 - **除外ノイズ精度**: - Precision: 保持されたアラートのうち実際のクリティカルアラートの割合 - Recall: 実クリティカルアラート全体に対して正しく保持されたアラートの割合 - F1スコア: PrecisionとRecallの調和平均 - **要約精度**: - Action Accuracy: 実行可能/不可能の判定精度 - Root Cause Analysis (RCA) Accuracy: 根本原因を正しく特定したアラートの割合 - Actionability/Relevance: SRE評価(1-5スケール) **比較ベースライン**: - Severity-based: 高重大度のアラートのみを優先(一般的なSRE慣行) - UHAS: EVT(極値理論)とIsolation Forestを使用したクラスタリング - OAS: 類似アラートの抑制(時間窓1分) - AlertGuardian w/o Anonymization: 属性匿名化なしの変種 #### 実験結果 **RQ1: Alert Denoise性能** - **アラート削減比率**: AlertGuardianは4つのデータセット全体で93.82%～95.50%を達成し、Severity法(84%～85%)、OAS(87%～88%)、UHAS(89%～91%)を大幅に上回る。属性匿名化なしの場合は90.20%～90%に低下し(5-6%低下)、匿名化の重要性を示す。 - **除外ノイズ精度**: 全データセットでPrecision 90%以上、Recall 85%以上、F1 0.92を達成。ベースライン手法は高Precisionだが低Recall(クリティカルアラートも削除)または逆。AlertGuardian w/o Anon は精度が低下。 - **処理効率**: オンライン推論は1分当たり200ミリ秒以下で処理可能(1システムあたり1分間に最大1000アラート)。オフライン訓練も100万アラートで約20分、7日分(500万アラート以下)で約100分で完了。 **RQ2: Alert Summary性能** Dataset Aで評価(ラベル付きデータが十分なため): - **Action Accuracy**: 98.5%(AlertGuardian), 91.5%(Qwen), 86.5%(RAGなし), 70.0%(OAS), 72.5%(UHAS) - **RCA Accuracy**: 90.5%(AlertGuardian), 88.0%(Qwen), 82.5%(RAGなし), 64.5%(OAS), 67.0%(UHAS) - **Actionability**: 4.8/5(AlertGuardian), 4.0(Qwen), 3.0(RAGなし) - **Relevance**: 4.9/5(AlertGuardian), 4.5(Qwen), 3.1(RAGなし) RAGなしの場合は著しく性能低下し、RAGによるコンテキスト拡張の重要性を示す。非LLMベースのOAS/UHASは解釈可能な要約を生成できない。 **RQ3: Alert Rule Refinement性能** 221～375のルール改善を推奨(各データセット): - **ルール重複排除**: 最高の受け入れ率80.0%～83.3%(意図が明確で低リスク) - **ルール集約**: 中程度の受け入れ率28.0%～29.3%(過度な汎化のリスク) - **閾値調整**: 23.3%～25.0%の受け入れ率(実装の複雑性と検証負荷) - **時間分析**: 7.5%～14.0%の受け入れ率(可変負荷での時間条件は誤りやすい) 全体的に31.2%～33.0%の受け入れ率で、375の提案のうち117が採用された。 **本番運用成績**(System A、ゲームプラットフォーム): - **Alert Denoise**: 1日30万件のアラートを約1万5000件に削減(95%削減)。F1スコア0.92でクリティカルアラートも保持。 - **Alert Summary**: 実行可能性判定の精度98%。MTTR(平均復旧時間)が156分から21分に低下(7.4倍改善)。 - **Rule Refinement**: 300以上のルール改善提案で約100が採用、日次の誤検知を5万件以上削減。 #### 限定事項と妥当性への脅威 **内部的脅威**: データラベリングのバイアスの可能性があるが、複数のSREによって検証された厳密なインシデント報告書とアノテーションを使用して軽減。LLM幻覚の問題についても、RAGによる出力のアンカリング及び反復的フィードバックループによる検証により対処。 **外部的脅威**: データセットはCompany-Xのみに限定されるが、4つの異なるドメイン(ゲーム、オフィス、メディア、教育)を含める多様性を確保。Company-Xが業界標準のPrometheus形式のアラートルールを使用しており、他のシステムとの互換性が高く、一般化可能性が高い。 ## Abstract 大規模クラウドシステムではアラートが信頼性確保に不可欠だが、現実には膨大な量のアラートが生成され、アラート疲労により運用効率が低下している。本論文はCompany-Xのアラートライフサイクル管理最適化の取り組みを詳述し、AlertGuardianを提案する。AlertGuardianは大規模言語モデル(LLM)と軽量グラフモデルを協働させてアラートライフサイクルを3段階で最適化する。Alert Denoiseはグラフ学習モデルと仮想ノイズを用いてノイズを除外し、Alert SummaryはRAGとLLMを活用して実行可能な要約を生成し、Alert Rule RefinementはマルチエージェントのIterative Feedbackでアラートルール品質を改善する。Company-Xの4つの実データセットでの評価結果、AlertGuardianは93.82%～95.50%のアラート削減率を達成し、全システムで既存手法を大幅に上回る。さらに98.5%の実行可能性判定精度を持つ高品質なアラート要約を提供し、故障診断の効率化を実現する。また1,174個のアラートルール改善を提案し、375個がSREに受け入れられた(受け入れ率32%)。Alert Denoiseモジュールは1年以上Company-Xで本番運用され、Alert SummaryおよびRule Refinementモジュールは3ヶ月以上パイロット運用中である。AlertGuardianの展開は大規模クラウドシステムにおけるアラート疲労解決への実用的な洞察を提供する。