> [!abstract] 概要(arXiv abstract の日本語訳) > オンラインサービスシステムが複雑さと規模の面で成長し続けるにつれ、サービスインシデントの管理方法は企業収益とユーザーの信頼に大きな影響を及ぼす。 > カスケード効果により、クラウド障害はしばしば依存サービスやデバイスからの圧倒的な数のインシデントを伴う。 > 効率的なインシデント管理を追求するには、関連するインシデントを素早く集約し、問題範囲を絞り込む必要がある。 > この目的のため、本論文では、クラウド障害のカスケードグラフ上のグラフ表現学習に基づくインシデント集約フレームワーク GRLIA を提案する。 > 各一意なインシデント種別について表現ベクトルを教師なしで統一的に学習し、インシデント間のトポロジ的相関と時間的相関を同時に符号化できる。 > したがって、オンラインインシデント集約に容易に利用できる。 > 特に、相関をより正確に学習するため、細粒度のシステム監視データ、すなわち Key Performance Indicators(KPI)を活用して、障害のカスケード影響の完全な範囲を復元しようとする。 > 提案フレームワークは、Huawei Cloud の大規模オンラインサービスシステムから収集した実世界のインシデントデータで評価される。 > 実験結果は、GRLIA が有効であり既存手法を上回ることを示す。 > さらに、本フレームワークは産業実務への展開にも成功している。 ## 論文情報 - タイトル: Graph-based Incident Aggregation for Large-Scale Online Service Systems - 著者: [[Zhuangbin Chen]]、[[Jinyang Liu]]、[[Yuxin Su]]、[[Hongyu Zhang]]、[[Xuemin Wen]]、[[Xiao Ling]]、[[Yongqiang Yang]]、[[Michael R. Lyu]] - 所属: [[The Chinese University of Hong Kong]]、[[University of Newcastle]]、[[Huawei Cloud]] - 媒体: ASE 2021。arXiv:2108.12179、2021-08-27 投稿。 - コード: [[OpsPAI]]/[[GRLIA]]、`https://github.com/OpsPAI/grlia` - 既存単一ソースノート: [[papers/2021__ASE__Graph-based Incident Aggregation for Large-Scale Online Service Systems|papers 側ノート]] ## 概要 GRLIA は、クラウド障害で短時間に発生する多数のインシデントを、同一障害に由来するクラスタへオンラインに集約するフレームワークである。中心は、インシデント本文の類似度ではなく、障害影響グラフの補完とインシデント種別のグラフ表現学習を組み合わせる点にある。Huawei Cloud の Networking サービスの 6 か月分データで評価され、検知・集約の両方で既存手法を上回り、実運用にも展開された。 ## 問題設定 入力は、オンラインサービスシステムからストリームとして報告されるインシデント、KPI 時系列、サービスやネットワークのトポロジである。出力は、同一障害に起因すると推定されるインシデントクラスタであり、エンジニアが障害の影響範囲と根本原因候補を絞るために使う。 論文が強調する難しさは 3 つある。第一に、常時発生する軽微なインシデントが背景ノイズになる。第二に、関連インシデントでもタイトルや説明文が似ないことがある。第三に、フォールトトレランスやモニタ設定の閾値により、障害伝播経路上の中間サービスがインシデントを出さないため、障害影響グラフが欠落する。 ## 提案手法 **アーキテクチャ**: GRLIA は 4 段で構成される。第一段はサービス障害検知で、1 分あたりインシデント数の時系列に EVT(Extreme Value Theory)を適用してバーストを検知する。第二段は障害影響グラフ補完で、インシデント類似度と KPI トレンド類似度からノード間重みを計算し、Louvain コミュニティ検出で同一障害の影響範囲を推定する。第三段はグラフ表現学習で、障害影響グラフから生成したランダムウォーク列を Word2Vec に入力し、インシデント種別ごとの 128 次元表現を学習する。第四段はオンライン集約で、連続して到着するインシデントのコサイン類似度とトポロジ距離ペナルティを掛け合わせ、閾値以上なら同一グループへ束ねる。 **障害影響グラフ補完**: ノード間重みは、インシデント集合の Jaccard 類似度と KPI トレンドの DTW 類似度の重み付き和である。両ノードがインシデントを報告している場合は重み係数 α=0.5、どちらかが沈黙している場合は α=0 とし、KPI のみで類似度を測る。KPI は CPU 利用率、ラウンドトリップ遅延、ポート入出力トラフィック率、入力パケットエラー率、出力パケットロス率などで、異常 KPI だけを比較対象にする。 **インシデント表現学習**: 既存の FP-Growth は、頻出する軽微なインシデントに引きずられやすく、低頻度だが重要なインシデントを support 閾値で落とす。GRLIA は、サービスやデバイスが自然にグラフ構造を持つことを利用し、DeepWalk 型のランダムウォークでトポロジ近傍と時間的共起を一体的に学習する。通常のグラフ表現学習がノード表現を学ぶのに対し、GRLIA は複数ノードに現れうる「インシデント種別」の表現を学ぶ。 **オンライン集約**: インシデント $i, j$ の類似度は、埋め込みベクトルのコサイン類似度である historical closeness と、最短パス距離に基づく topological rescaling の積で定義される。距離ペナルティは閾値 $T=4$ を超えた場合だけ効き、集約閾値は $\lambda=0.7$ とされる。 ## 新規性 既存研究の UHAS はテキストとトポロジを重み付き和で扱い、LiDAR は教師ありでインシデント記述とコンポーネント表現を学習する。GRLIA は、インシデント本文の類似度に依存せず、KPI により欠落した障害影響グラフを補完したうえで、インシデント種別自体の表現を教師なしで学ぶ点が異なる。 特に重要なのは、障害伝播経路上の中間サービスが沈黙する現象を、単なる欠損ではなく集約精度を壊す構造的問題として扱った点である。この問題はグレイ障害や不完全なモニタ設計と接続し、後続のアラート集約・RCA 研究で繰り返し現れる入力表現の不完全性問題の早期事例である。 ## 実験設定 評価対象は Huawei Cloud の Networking サービスである。2020 年 5 月から 11 月までの本番インシデントを用い、最大 10 の availability zone を対象とする。個別インシデント種別は 3,000 超で、学習期間と評価月をずらした 3 データセットが構成される。Dataset1 は 2020 年 5〜7 月で学習し 8 月で評価、Dataset2 は 5〜8 月で学習し 9 月で評価、Dataset3 は 5〜9 月で学習し 10 月で評価する。 Dataset1/2/3 の学習期間インシデント数は約 18k/26k/36k、評価月インシデント数は約 8k/10k/8k である。学習期間の障害数は 105/151/203、評価月の障害数は 46/52/38 である。評価ラベルは経験豊富なドメインエンジニアが手動で付与し、集約品質には NMI(Normalized Mutual Information)を用いる。 ## 実験結果 障害検知では、固定閾値法(#incidents/min > 50)と比べ、GRLIA は 3 データセットすべてで高い精度・再現率・F1 を示す。F1 は Dataset1/2/3 で 0.937/0.962/0.949 であり、固定閾値の 0.799/0.883/0.761 を上回る。 インシデント集約では、GRLIA の NMI は Dataset1/2/3 で 0.831/0.866/0.912 である。最良ベースラインの LiDAR は 0.742/0.758/0.826、UHAS は 0.697/0.710/0.707、FP-Growth は 0.481/0.523/0.546 であり、GRLIA が一貫して上回る。 障害影響グラフ補完のアブレーションでは、補完なしの GRLIA' が 0.782/0.808/0.846 に低下する。論文は、モニタがアドホックに設定され、システム進化やフォールトトレランスに追従しきれないため、一部サービスが障害中にインシデントを出さないことを主要因として説明する。 ## 考察 GRLIA は「インシデントのタイトルが似ていない」ケースで強い。論文中の例では、`Traffic drops sharply in vRouter` と `OS network ping abnormal` は明確に相関するが、テキスト類似度だけでは捉えにくい。これは、アラート/インシデント集約の初期研究が文字列類似度に依存していたところから、トポロジ・時間・KPI の統合表現へ移る転換点として読める。 実運用では、GRLIA は Huawei Cloud のインシデント管理システムに組み込まれた。2020 年 11 月の 26 障害について平均障害対応時間を比較したところ、8 月比 24.8%、9 月比 21.9%、10 月比 18.6% の短縮が報告される。論文は、集約結果が調査範囲を狭めるだけでなく、モニタの誤名・情報欠落などの設定問題を発見する副次効果もあったと述べる。 ## 強み / 弱点・課題 強みは、教師なしで本番インシデント集約を行い、テキスト非類似・低頻度・背景ノイズ・不完全な障害影響グラフを同時に扱う設計である。さらに、実運用への組み込みと対応時間短縮の報告があり、単なるオフライン評価に閉じていない。 弱点は、評価が Huawei Cloud の Networking サービス単一ドメインに限定される点である。KPI セットもネットワークサービス向けに選ばれており、データベースやアプリケーションサービスでは別の KPI 選定が必要になる。また、手動ラベルにはノイズがありうる。論文は、実装とパラメータ設定の内的妥当性リスクに対してピアコードレビューと比較実験で緩和したと述べるが、他クラウド・他サービスでの再現性は未検証である。