@2023__TSC__Robust Failure Diagnosis of Microservice System through Multimodal Data

# Robust Failure Diagnosis of Microservice System through Multimodal Data > [!abstract] 概要 > 大規模マイクロサービスシステムの自動障害診断は重要である。既存の障害診断手法の多くは、メトリクス、ログ、トレースのいずれか一つのモダリティに依存している。本研究では実世界の障害事例を調査し、複数モダリティを組み合わせることで診断性能を向上できることを示す。一方で、異種データを統一的に表現することと、不均衡な障害データへ対処することは難しい。そこで、サービスインスタンスから得られるマルチモーダルデータを埋め込みとデータ増強で表現し、デプロイメント情報とトレースから依存グラフを構築し、グラフニューラルネットワーク（GNN）によって根本原因インスタンスと障害タイプを特定するDiagFusionを提案する。二つのデータセットで評価した結果、既存手法に対して根本原因インスタンスの特定を20.9%〜368%、障害タイプの判定を11.0%〜169%改善した。 ## 論文情報 - タイトル: Robust Failure Diagnosis of Microservice System through Multimodal Data - 著者: Shenglin Zhang, Pengxiang Jin, Zihan Lin, Yongqian Sun, Bicheng Zhang, Sibo Xia, Zhengdan Li, Zhenyu Zhong, Minghua Ma, Wa Jin, Dai Zhang, Zhenyu Zhu, Dan Pei - 媒体: IEEE Transactions on Services Computing（原本の書誌表記ではIEEE TSC） - 発表年: 2023 - 提案システム: DiagFusion ## 概要 DiagFusionは、メトリクス・ログ・トレースを時刻とインスタンスIDを共有するイベント列へ変換し、fastTextでイベントを埋め込む。トレースの呼び出し関係とデプロイメントの共有資源関係からインスタンス依存グラフを作り、GNNでサービスグループと障害タイプを同時に分類する。サービスグループが決まった後、グループ内インスタンスをイベント数で順位付けして根本原因ランキングを得る。異種データの統一、不均衡クラスの増強、欠測モダリティへの頑健性を一つの枠組みで扱う点が特徴である。 ## 研究の動機と研究課題マイクロサービスでは、数十から数千のサービスが呼び出し連鎖を形成し、各サービスが複数インスタンス、ホスト、データベース、ネットワーク資源に依存する。一つの障害が呼び出し連鎖や共有資源を通じて多数のインスタンスへ波及するため、観測された異常インスタンスをそのまま根本原因とみなせない。論文は、2021年12月のAWS障害で診断と緩和に約7時間を要した例を、自動診断の必要性を示す事例として挙げる。既存手法はメトリクス、ログ、トレースの単一モダリティ、または少数の組み合わせに依存する。しかし、性能劣化はメトリクスに現れやすい一方、具体的なエラー理由はログにしか現れないことがある。呼び出し経路上の遅延やHTTP状態はトレースに現れる。単一モダリティでは、一部の障害に兆候が現れない、あるいは他モダリティにしかない補助情報を使えない。さらに実障害のタイプは不均衡で、稀な障害の学習例が不足する。論文の研究課題は次の通りである。 - **RQ1（有効性）**: マルチモーダルデータを融合するDiagFusionは、既存手法より根本原因インスタンス特定と障害タイプ判定に有効か。 - **RQ2（寄与）**: イベント埋め込み、データ増強、依存グラフ、GNNの各要素は性能にどの程度寄与するか。 - **RQ3（効率）**: オフライン学習とオンライン診断の時間は実運用に許容できるか。 - **RQ4（感度）**: 埋め込み次元、増強量、GNN層数、時間窓は性能へどう影響するか。 ## 問題設定入力は、サービスインスタンス単位のメトリクス時系列、ログ、分散トレース、デプロイメント情報である。出力は、(1)全インスタンスを根本原因らしさの順に並べたランキング、(2)障害事例のタイプ分類である。学習時には各過去障害について `<root cause instance-id, failure type>` のラベルが与えられる。外部の異常検知・アラート機構が診断対象の障害時刻を与えること、監視データが収集・保存されていることを仮定する。監視基盤、アラート生成、根本原因ラベル作成は対象外である。インスタンスの増減に対応するため、まずサービスグループを推定し、その内部のインスタンスを順位付けする。 ## 提案手法 DiagFusionは、イベント抽出、イベント表現と増強、依存グラフ構築、GNNによるマルチタスク学習、グループ内順位付けの順に処理する。 ### イベント抽出と共通表現三つのモダリティを、少なくとも時刻とインスタンスIDを持つイベントへ変換する。インスタンスiのイベント列を `E_i` とし、時刻順にソートする。 - **トレース**: caller-calleeの組ごとにスパンを集約する。応答時間などの数値属性は3σ則で異常を抽出し、HTTP状態コードなどのカテゴリ属性は出現数の急増を異常とする。イベントは概念的に `<timestamp, caller-instance-id, callee-instance-id>` で表す。 - **ログ**: Drainでログ行をテンプレート部分と変数部分に分解し、テンプレート文字列をハッシュしてイベントテンプレートIDとする。変数値への過適合を避け、`<timestamp, instance-id, event-template-id>` として扱う。 - **メトリクス**: 時系列の外れ値を3σ則で抽出し、基準からの上昇・下降を異常方向として記録する。イベントは `<timestamp, instance-id, metric-name, anomaly-direction>` である。この統一により、例えばファイル欠落・コードバグについて、ログのエラー、トレースのHTTP 500、ネットワーク送信バイト数の低下を同じ障害事例のイベント列で扱える。 ### ラベル再構成、fastText、データ増強過去障害がp件、インスタンスがq個なら、各障害と各インスタンスの組から `N=p×q` 系列を作る。真の根本原因インスタンスには実際の障害タイプ、それ以外には `non-root-cause` を付与する。イベントを単語、障害タイプを文書ラベルとみなしてfastTextを学習する。系列x_nとラベルy_nに対する初期損失は次である。 `min_f -1/N Σ_(n=1)^N y_n log f(x_n)` 正規化bag-of-featuresとして学習した初期モデルを `f_0`、イベントベクトル集合を `V_0` とする。少数クラスについて、系列中の一つのイベントを選び、`V_0` 上でユークリッド距離が最も近いイベントへ置換する。これを繰り返して各障害タイプと `non-root-cause` の系列を増やし、例として1クラスあたり1000系列まで拡張する。増強後に再学習して最終ベクトル集合 `V_1` を得る。word2vecやGloVeではなく、ラベル情報を使うfastTextを採用する点が重要である。インスタンスiの初期ノード特徴はイベントベクトルの平均である。 `h_i^(0) = 1/|E_i| Σ_(e∈E_i) V_1(e)` ### 依存グラフとGNN ノードはサービスインスタンスである。トレースの呼び出し関係を集約し、caller→calleeとcallee→callerの両方向の辺を加える。デプロイメント情報からは、同じホストや共有資源に配置されたインスタンス間の関係も加える。これにより、論理的なサービス呼び出しと物理的な資源共有を同一グラフで表現する。ノード特徴行列をX、隣接行列をA、次数行列をD（`D_ii=Σ_j A_ij`）とすると、トポロジー適応型グラフ畳み込みは次で表される。 `H^K = Σ_(k=0)^K [D^(-1/2) A D^(-1/2)]^k X Θ^k` `Θ^k` は各ホップの線形変換パラメータである。0次からK次の近傍情報を足し合わせ、MaxPoolingと全結合層でグラフ全体を読み出す。出力はS個のサービスグループクラスとT個の障害タイプクラスである。 F件の障害に対する結合損失は、サービスグループの正解・確率を `y^(s),p^(s)`、タイプの正解・確率を `y^(t),p^(t)` として次である。 `-1/F Σ_(i=1)^F (Σ_(j=1)^S y^(s)_(i,j) log p^(s)_(i,j) + Σ_(k=1)^T y^(t)_(i,k) log p^(t)_(i,k))` まず原因サービスグループを予測し、グループ内部のインスタンスをイベント列長で並べる。異常イベントが多いインスタンスほど原因らしいという仮定である。論文の例では、B1のAccess denied障害に対してグループBと障害タイプを予測し、B1をTop-1に置く。著者らはこの例の診断を10秒未満で実行できるとしている。図1〜図9、表1〜表7を本文で参照する。以下は原本から抽出した図表画像であり、図表専用の知識節ではなく、提案手法・実験の根拠として配置する。 **図表抽出1** （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出2** ![[wiki/sources/_attachments/Zhang-et-al.-2023---Robust-Failure-Diagnosis-of-Microservice-System-through-Multimodal-Data/fig-image-005-001.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出3** ![[wiki/sources/_attachments/Zhang-et-al.-2023---Robust-Failure-Diagnosis-of-Microservice-System-through-Multimodal-Data/fig-image-005-002.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出4** ![[wiki/sources/_attachments/Zhang-et-al.-2023---Robust-Failure-Diagnosis-of-Microservice-System-through-Multimodal-Data/fig-image-006-001.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出5** ![[wiki/sources/_attachments/Zhang-et-al.-2023---Robust-Failure-Diagnosis-of-Microservice-System-through-Multimodal-Data/fig-image-006-002.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出6** ![[wiki/sources/_attachments/Zhang-et-al.-2023---Robust-Failure-Diagnosis-of-Microservice-System-through-Multimodal-Data/fig-image-006-003.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出7** ![[wiki/sources/_attachments/Zhang-et-al.-2023---Robust-Failure-Diagnosis-of-Microservice-System-through-Multimodal-Data/fig-image-006-004.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出8** ![[wiki/sources/_attachments/Zhang-et-al.-2023---Robust-Failure-Diagnosis-of-Microservice-System-through-Multimodal-Data/fig-image-006-005.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出9** ![[wiki/sources/_attachments/Zhang-et-al.-2023---Robust-Failure-Diagnosis-of-Microservice-System-through-Multimodal-Data/fig-image-013-001.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出10** ![[wiki/sources/_attachments/Zhang-et-al.-2023---Robust-Failure-Diagnosis-of-Microservice-System-through-Multimodal-Data/fig-image-013-002.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出11** ![[wiki/sources/_attachments/Zhang-et-al.-2023---Robust-Failure-Diagnosis-of-Microservice-System-through-Multimodal-Data/fig-image-013-003.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出12** ![[wiki/sources/_attachments/Zhang-et-al.-2023---Robust-Failure-Diagnosis-of-Microservice-System-through-Multimodal-Data/fig-image-013-004.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出13** ![[wiki/sources/_attachments/Zhang-et-al.-2023---Robust-Failure-Diagnosis-of-Microservice-System-through-Multimodal-Data/fig-image-013-005.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出14** ![[wiki/sources/_attachments/Zhang-et-al.-2023---Robust-Failure-Diagnosis-of-Microservice-System-through-Multimodal-Data/fig-image-014-001.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出15** ![[wiki/sources/_attachments/Zhang-et-al.-2023---Robust-Failure-Diagnosis-of-Microservice-System-through-Multimodal-Data/fig-image-014-002.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出16** ![[wiki/sources/_attachments/Zhang-et-al.-2023---Robust-Failure-Diagnosis-of-Microservice-System-through-Multimodal-Data/fig-image-014-003.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出17** ![[wiki/sources/_attachments/Zhang-et-al.-2023---Robust-Failure-Diagnosis-of-Microservice-System-through-Multimodal-Data/fig-image-014-004.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出18** ![[wiki/sources/_attachments/Zhang-et-al.-2023---Robust-Failure-Diagnosis-of-Microservice-System-through-Multimodal-Data/fig-image-014-005.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出19** ![[wiki/sources/_attachments/Zhang-et-al.-2023---Robust-Failure-Diagnosis-of-Microservice-System-through-Multimodal-Data/fig-image-014-006.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出20** ![[wiki/sources/_attachments/Zhang-et-al.-2023---Robust-Failure-Diagnosis-of-Microservice-System-through-Multimodal-Data/fig-image-014-007.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出21** ![[wiki/sources/_attachments/Zhang-et-al.-2023---Robust-Failure-Diagnosis-of-Microservice-System-through-Multimodal-Data/fig-image-014-008.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） - 本文図表参照: Figure 1, Figure 2, Figure 3, Figure 4, Figure 5, Figure 6, Figure 7, Figure 8, Figure 9, Table 1, Table 2, Table 3, Table 4, Table 5, Table 6, Table 7 ## 新規性複数モダリティを別々に判定して投票するのではなく、異種データを共通イベント列へ変換し、ラベル情報を含む埋め込みとして学習する点に新規性がある。さらに、トレースの論理的呼び出しグラフだけでなく、デプロイメント情報から共有ホスト・共有資源の関係を加える。イベント増強、グラフ伝播、障害タイプ分類を一つの枠組みにまとめ、根本原因位置と障害タイプを同時に推定する。 ## 実験設定 ### データセット GAIA（D1）と商用銀行管理システムの実障害データ（D2）を用いる。D1は10サービス、MySQLとRedisの2データベース、5ホストからなる。表1の障害件数は、System stuck/high memory usage 505件、Process crash/incorrect deallocation 16件、Login failure/network interruption 527件、File missing/code bug 36件、Access denied/misconfiguration 15件であり、クラス不均衡が大きい。D2は2021年1月〜6月に二人の経験豊富な運用担当者が記録した商用銀行管理システムの障害で、CPU、memory、JVM-CPU、JVM-memory、I/Oの5タイプを含む。 | データセット | インスタンス数 | 学習障害 | テスト障害 | トレース | ログ | メトリクス | |---|---:|---:|---:|---:|---:|---:| | D1 (GAIA) | 17 | 160 | 939 | 2,321,280 | 87,974,577 | 56,684,196 | | D2 (商用銀行管理システム) | 18 | 80 | 79 | 1,123,200 | 21,356,923 | 8,228,010 | 学習・テストは障害開始時刻で分割し、同じ障害の情報が両方へ入るリークを避ける。D2のインスタンス数について本文と表2に差があるため、ここでは表2の18を記載する。 ### 比較手法、指標、実装根本原因インスタンス特定ではMicroHECL、MicroRank、AutoMAP、MS-Rank、PDiagnoseを比較し、障害タイプ判定ではCloud19、LogCluster、CloudRCAを比較する。各手法の原論文の設定を基礎に、データセット依存の入力形式・パラメータを調整する。根本原因ランキングには、真の原因が上位k件に入れば1、入らなければ0とする `A@k` を用いる。`Avg@5` は `A@1`〜`A@5` の平均である。障害タイプはweighted precision、weighted recall、weighted F1で評価し、precisionは `TP/(TP+FP)`、recallは `TP/(TP+FN)`、F1は `2PR/(P+R)` で計算する。実装はPython 3.7.13、PyTorch 1.10.0、scikit-learn 1.0.2、fastText 0.9.2、DGL 0.9.0である。実験機はIntel Xeon E5-2650 v4 2.20 GHzを12個、メモリ128 GBで、GPUを使わない。各実験を5回繰り返して平均する。 ## 実験結果 ### RQ1: 有効性障害タイプ判定の結果は次の通りである。 | 手法 | D1 Precision | D1 Recall | D1 F1 | D2 Precision | D2 Recall | D2 F1 | |---|---:|---:|---:|---:|---:|---:| | DiagFusion | 0.860 | 0.829 | 0.839 | 0.822 | 0.797 | 0.800 | | Cloud19 | 0.774 | 0.774 | 0.756 | 0.526 | 0.278 | 0.297 | | LogCluster | 0.615 | 0.477 | 0.336 | 0.521 | 0.722 | 0.605 | | CloudRCA | 0.436 | 0.453 | 0.357 | 0.589 | 0.506 | 0.538 | DiagFusionのF1はD1で0.839、D2で0.800である。根本原因特定の `Avg@5` はD1で0.750、D2で0.790。D1の内訳は `A@1=0.419`、`A@3=0.813`、`A@5=0.914` である。本文の図8は、両データセットで `Avg@5` が0.75以上、単一モダリティ構成より少なくとも0.13、PDiagnoseより少なくとも0.18高いと説明する。D2について本文の説明と表4の集計値に記述差があるため、ここでは表4の0.790を採用する。論文の総括では、既存法に対する根本原因箇所特定の改善率を20.9%〜368%、障害タイプ判定の改善率を11.0%〜169%としている。 ### RQ2: アブレーションと欠測モダリティ表4のC1〜C5は、C1がデータ増強なし、C2がword2vec、C3がGloVe、C4がdecision tree、C5がkNNへの置換である。D1の完全構成は `A@1=0.419`、`A@3=0.813`、`A@5=0.914`、`Avg@5=0.750`、分類F1=0.839である。データ増強なしでは `Avg@5=0.641`、F1=0.779へ低下する。word2vecとGloVeでは `Avg@5` がそれぞれ0.594、0.588となり、fastTextの0.750を下回る。decision treeでは0.616、kNNでは0.744で、分類F1はそれぞれ0.104、0.095である。 D2では完全構成の `Avg@5=0.790` に対し、データ増強なし0.471、word2vec 0.780、GloVe 0.785、decision tree 0.587、kNN 0.671である。データセットにより埋め込み置換の差は変わるが、増強とGNNを除くと性能が大きく落ちる。 D1のテスト939件のうち62件はメトリクスを欠く。全モダリティ時のDiagFusionは `A@1=0.419`、`A@3=0.813`、PDiagnoseは0.272、0.554である。トレースとログだけでもDiagFusionは `A@1=0.274`、`A@3=0.661` を得る一方、PDiagnoseは0、0.161である。少なくとも二つのモダリティで診断できるが、欠測時は完全構成より低下する。 ### RQ3: 実行時間表5の平均時間（秒）では、DiagFusionのD1はオフライン11.02、オンライン10.95、D2はオフライン3.59、オンライン3.26である。根本原因特定のオンライン時間は、MicroHECLがD1 65.98、D2 28.40、MicroRankが34.47、54.94、PDiagnoseが42.51、68.74である。AutoMAPは0.299、0.511、MS-Rankは1.14、12.94だが、精度とのトレードオフがある。DiagFusionはGPUなしでも概ね12秒以内にオンライン診断する。 ### RQ4: ハイパーパラメータ埋め込み次元は5、10、30、50、75、100、150、200、増強数は50、200、1000、2000、4000、GNN層数は1〜5で比較する。D1は安定するがD2は揺れが大きい。埋め込み次元は100を採用する。増強し過ぎると近傍置換によるノイズが増える。GNNは3層を超えると性能が悪化し、過平滑化または小規模データでの過学習が考えられる。時間窓の影響は比較的小さい。 ## 考察学習ベースの方法は、専門家が全ルールを手作業で列挙しなくても、複雑なモダリティ間のパターンを獲得できる。fastTextは障害ラベルを埋め込み学習へ組み込むため、word2vec・GloVeより診断タスクに適したイベント表現を作れる。GNNは呼び出しと資源共有という既知のグラフ構造を直接利用できる。実運用では、インスタンスの生成・破棄に対してサービスグループを安定した中間単位として使う。新しいサービスグループが追加された時に再学習する設計を想定する。ラベルはインシデント管理記録やカオスエンジニアリングの障害注入記録から得られる可能性がある。メトリクスが欠けてもログとトレースを使えるため、観測基盤の部分的な劣化時にもフォールバックになる。一方、インスタンスをイベント列長で順位付けする規則は、根本原因ほど異常イベントが多いという仮定に依存する。下流で大量の二次異常が発生する障害では誤順位付けの可能性がある。イベントベクトルの平均は順序と長期の時間依存性を圧縮するため、同じイベント集合でも発生順が異なるケースを区別しにくい。 ## 強み / 弱点・課題強みは、三モダリティの統一表現、fastTextによるラベル指向のイベント埋め込み、少数クラス増強、論理依存と資源共有のグラフ融合、インスタンスとタイプの同時診断である。少なくとも二モダリティで動作するため、観測欠測にも一定の頑健性がある。限界は、根本原因インスタンスと障害タイプのラベル、トレース・デプロイメントの依存グラフに依存することである。評価データは二つで規模が小さく、D2は非公開である。D1には単純な障害も含まれ、実環境の多段カスケード、未監視プロセス、短時間スパイクを十分に表さない可能性がある。観測されない外部異常やグラフ未登録の依存関係は診断できない。増強は現実に存在しない系列を作る可能性があり、増強し過ぎるとノイズが増える。埋め込みは専門家の重み付けやオントロジーを明示的には保持しない。 ## 今後の課題著者らは、イベントと依存グラフの時間的変化、サーバレス環境、分布と文脈を考慮したメトリクス表現、グラフインデックス、より大規模なシステムでの検証を挙げる。モダリティや損失の重みの自動調整、産業環境の多様な異常、複数ユーザーのラベル不一致への対応も課題である。静的なグラフと平均イベント特徴から、障害前後のイベント順序と依存関係の変化を扱う時間モデルへ拡張することが必要である。 ## 出典 - [[.raw/papers/Zhang-et-al.-2023---Robust-Failure-Diagnosis-of-Microservice-System-through-Multimodal-Data.pdf]] - [[.raw/papers/Zhang-et-al.-2023---Robust-Failure-Diagnosis-of-Microservice-System-through-Multimodal-Data.txt]]