> [!abstract] 概要(arXiv abstract の日本語訳) > 近年、AIOps(IT 運用のための人工知能)は、自動的かつ効果的なソフトウェアサービス管理を可能にするため、学界と産業界で盛んに研究されてきた。異常検知、根本原因箇所特定、インシデント管理など、AIOps には多くの取り組みが注がれてきた。しかし、既存研究の大半は非公開のデータセットで評価されており、その汎用性と実際の性能は保証されない。公開された大規模で実世界のデータセットの欠如は、研究者やエンジニアが AIOps の発展を強化することを妨げてきた。この問題に取り組むため、本研究では、AIOps に関する公開・実世界・大規模な 3 つのデータセットを導入する。これらは主に、KPI 異常検知、多次元データにおける根本原因箇所特定、障害発見と診断を対象とする。さらに重要な点として、これらのデータセットに基づき 2018 年・2019 年・2020 年に 3 回のコンペティションを開催し、数千のチームが参加した。今後もデータセットの公開とコンペティションの開催を継続し、AIOps の発展をさらに促進していく。 ## 論文情報 - タイトル: Constructing Large-Scale Real-World Benchmark Datasets for AIOps - 著者・所属: [[Zeyan Li]]¹・[[Nengwen Zhao]]¹・[[Shenglin Zhang]]²・[[Yongqian Sun]]²・[[Pengfei Chen]]³・[[Xidao Wen]]¹・[[Minghua Ma]]⁴・[[Dan Pei]]¹(¹[[Tsinghua University]]、²[[Nankai University]]、³[[Sun Yat-sen University]]、⁴[[Microsoft Research]]) - 媒体: ESEC/FSE 2022(Industry Track)、2022-11-14〜18、Singapore - arXiv ID: 2208.03938(投稿日 2022-08-08)、6 ページ - 関連リポジトリ: `netmanaiops/kpi-anomaly-detection`(dataset A)、`NetManAIOps/MultiDimension-Localization`(dataset B)、`NetManAIOps/AIOps-Challenge-2020-Data`(dataset C)。ソリューション集は `workshop.aiops.org` で公開。 ## 概要 本論文は AIOps 研究における公開・大規模・実世界データセットの不足という課題に対し、著者らの産学連携ネットワーク(NetManAIOps)が構築・公開してきた 3 つのデータセット(KPI 異常検知・多次元データ根本原因箇所特定・障害発見と診断)と、それらを用いて 2018〜2020 年に開催した AIOps アルゴリズムコンペティションを紹介する短い Industry Track 論文である。ImageNet がコンピュータビジョン分野の発展を後押ししたのと同様の役割を AIOps 分野で果たすことを狙いとする。 ## 問題設定 著者らは AIOps の研究領域を [[Fault Localization|failure management]](障害管理)と resource management(資源管理)の 2 つのマクロ領域に分類し(Notaro ら [36] に依拠)、本論文は failure management に焦点を絞る。failure management の目標は、Figure 1 が示すとおり検知(discovery)・診断(diagnosis)・緩和(mitigation)の 3 段階を経て、平均検知時間(MTTD)を短縮し、平均復旧時間(MTTR)を短縮し、平均故障間隔(MTBF)を延伸することである。既存研究の大半が非公開データセットで評価されているため手法間の公平な比較が困難であり、著者らはこの課題への回答として 3 データセットを公開してきた。 **Figure 1: 障害管理のパイプラインと主要指標** ![[_attachments/arxiv-2208.03938/fig01-failure-management-pipeline.png]] (Figure 1. Failure A から Failure B までの時間軸上に、Discovery(検知)と Mitigation(緩和)の 2 つの工程を配置し、MTTD(平均検知時間)・MTTR(平均復旧時間)・MTBF(平均故障間隔)の 3 指標を定義する概念図。Source: Adapted from 論文 Figure 1。) ## 提案手法(データセット構築) ### Dataset A: KPI 異常検知 - [[Sogou]]・[[eBay]]・[[Baidu]]・[[Tencent]]・[[Alibaba Group|Ali]] の 5 社から収集した実世界データで、27 種類の KPI を含む。各 KPI は経験を積んだエンジニアが手作業で異常をラベル付けした。 - KPI ごとの時間範囲は 2 か月から 7 か月に及び、Yahoo Benchmark 等の既存データセットと比べて大規模である(Table 1)。 - KPI パターンは季節性(取引量等)・安定(成功率等)・不安定(CPU 使用率等)の 3 種に分類され、Figure 2 は 1 週間分の 5 種類の KPI 波形(周期的パターン・鋸歯状パターン・ノイズパターン等)を示す。 **Figure 2: dataset A の代表的な KPI 波形** ![[_attachments/arxiv-2208.03938/fig02-kpi-examples.png]] (Figure 2. 月〜日の 1 週間を横軸に取った 5 種類の KPI の実測波形。上から順に、鋭いスパイクを伴う周期波形、鋸歯状に増減する波形、ノイズの多い波形など、KPI パターンの多様性を示す。Source: Adapted from 論文 Figure 2。) ### Dataset B: 多次元データの根本原因箇所特定 - [[Suning]] の実世界オンラインショッピングプラットフォームに基づく。プライバシー保護のため 5 つの属性は i, e, c, p, l として匿名化されている。測定量(measure)は 1 分あたりの平均注文数。 - 実障害の収集が困難なため、合成障害(synthetic failure)400 件を 8 週間分生成した。合成手順は以下の 6 ステップ: 1. 測定量が滑らかな時点を異常注入の対象時点として選ぶ。 2. 5 属性のうち m ∈ {1, 2, 3, 4} 個をランダムに選択する。 3. 選んだ属性に対応する属性組み合わせを n ∈ {1, 2, 3, 4} 個ランダムに選び、これを根本原因の正解ラベルとする。 4. 選んだ各属性組み合わせについて、[[Generalized Ripple Effect|generalized ripple effect(GRE)]] [24] とランダムな大きさで測定量を改変する。 5. 改変行と非改変行の両方にガウス分布ノイズを追加し、GRE の不完全性や予測残差を模擬する。 6. 「非選択の属性組み合わせがほぼ同じ行集合を共有している」「注入ノイズが大きく非改変行の全体測定量も異常化している」のいずれかの条件に該当する場合は手順 2 に戻ってやり直す。 - 結果として、400 件中 144/131/89/36 件がそれぞれ 1/2/3/4 個の根本原因属性組み合わせを含み、96/136/108/60 件がそれぞれ 1/2/3/4 個の属性を伴う。 - [[Squeeze]] [24] が用いる B0〜B4 は本データセットと同一の原データ・ほぼ同一の合成プロセスに基づく。 ### Dataset C: 障害発見と診断 - China Mobile Zhejiang の本番分散システム sysA(名称 S)に基づく。Figure 3 は OSB(Oracle Service Bus)・Service・DB・Docker・OS の 5 クラスからなるコンポーネントとその呼び出し依存関係(実線)・デプロイ依存関係(破線)を示す。 **Figure 3: 分散システム S のコンポーネント構成** ![[_attachments/arxiv-2208.03938/fig03-distributed-system-architecture.png]] (Figure 3. OSB1・OSB2 を起点に Docker/OS/DB コンポーネントへ広がる呼び出し依存(実線)とデプロイ依存(破線)。エージェント ID(cmdbId)ごとに KPI が収集され、障害伝播の追跡対象となる。Source: Adapted from 論文 Figure 3。) - 3 種類の監視データ(トレース・KPI・メトリクス)を収録。トレースは OpenTracing 仕様に従うスパン([[traceId]]・[[id]]・[[pid]] を持つ、Table 4 参照)として記録され、KPI はスパンの属性(成功可否・応答時間等)を cmdbId でグループ化・集約して得る。メトリクスは Docker・Linux・Oracle・Redis の 4 カテゴリ(Table 5)。 - 169 件の注入障害(ground-truth 時刻・根本原因つき)を 1 か月分収録。7 種類の障害注入タイプ(Table 6): データベースのポート閉鎖・セッション上限引き下げ、コンテナの CPU ストレス(`stress-ng`)、コンテナ/物理ノードのネットワーク遅延・パケットロス(`tc`)。ネットワークメトリクスをコンテナ上で収集していないため、コンテナ上のネットワーク障害については根本原因コンテナのみを診断対象とする。 ## 新規性 既存の公開データセット(Yahoo Benchmark・Numenta Anomaly Benchmark 等)は限られたデータ点数と合成異常しか含まず、単一の AIOps シナリオしかカバーしないのに対し、本論文の 3 データセットは (1) 実世界の本番システムに基づく、(2) KPI 異常検知だけでなく多次元根本原因箇所特定・end-to-end の障害発見/診断まで複数シナリオを横断する、(3) 経験豊富なエンジニアによる手動ラベル(dataset A)や体系的な合成手順(dataset B・C)により大規模なラベル付きデータを提供する、という 3 点で既存データセットの限界を克服する。 ## 実験設定(コンペティション設計) - **AIOps Challenge 2018**(dataset A ベース): 125 チーム・300 人超が参加。[43] の評価戦略(alarm delay restriction)を導入した新規評価法を設計。 - **AIOps Challenge 2019**(dataset B ベース): 141 チーム・547 人(学界 39%・産業界 61%)が参加。 - **AIOps Challenge 2020**(dataset C ベース): 141 チーム・517 人が参加。各チームは障害ごとに根本原因メトリクス候補を最大 2 件提出。適合率(precision)≥ 0.5 の結果を有効とみなし、有効な結果は診断所要時間または F-0.5 スコアで順位付けし、順位 i のチームに max(10 − i + 1, 0) 点を付与する。 ## 実験結果 - 2018 年コンペティション(dataset A): 最良 F1 スコアは 0.8216。 - 2019 年コンペティション(dataset B): 最良 F1 スコアは 0.9593。 - 2020 年コンペティション(dataset C): 129 件の障害に対する最良合計スコアは 755 点。 - 3 データセットはいずれも既存研究([13, 19, 24, 38, 50] 等の複数の後続論文)で広く利用されてきたと報告されている。 ## 考察 本論文はデータセット構築を主題とする Industry Track の短編であり、独自の検知・診断アルゴリズムの提案や比較評価は行っていない。中心的な主張は、実世界規模のラベル付きデータと年次コンペティションの組み合わせが AIOps コミュニティの手法比較可能性を底上げしてきたという実績の提示である。dataset B・C が合成障害・注入障害を採用した理由として、ground-truth 付き実障害を大量収集することの困難さが明示的に述べられており、実世界性と収集可能性のトレードオフが AIOps ベンチマーク設計に共通する制約であることを示す。 ## 強み / 弱点・課題 **強み** - Sogou・eBay・Baidu・Tencent・Ali・Suning・China Mobile Zhejiang という複数の実企業の本番システムに基づくデータであり、既存の Yahoo Benchmark 等より実世界に近い。 - 年次コンペティションにより数百〜数千人規模の参加者を集め、手法間の公平な比較基盤を提供してきた実績がある。 - dataset B は [[Squeeze]] をはじめとする後続の根本原因箇所特定研究で広く再利用されている(本 wiki が既に収集している複数の RCA 論文の一次データ源)。 **弱点・課題** - dataset B・C はいずれも実障害でなく合成・注入障害であり、著者ら自身が「実障害の大量収集が困難」という理由でこれを選んだと明言している。実障害分布との乖離がどの程度あるかは論文内で定量評価されていない。 - dataset B の 5 属性は匿名化(i, e, c, p, l)されており、根本原因の意味的解釈がしづらい。 - 6 ページの Industry Track 論文であり、合成障害生成手順の妥当性検証(既存障害分布との統計的類似性など)や、データセットの経年劣化・再現性に関する議論は薄い。 - 著者らは resource management(資源管理)領域を将来課題として明示的に除外しており、failure management に限定されたベンチマークである。