## Memo ### 0. Metadata - [[NetManAIOps]]、Microsoft Research Asia、Nankai University、[[FudanSELab]]からの共同研究？論文。 ### 1. Standpoints - マルチモーダルデータ（メトリクス、ログ、トレース + デプロイメントデータ（システム構成に関する事前知識））を用いたマイクロサービスの障害原因コンテナを特定する手法DiagFusionを提案している。 - 用語：インスタンス=コンテナ、サービスインスタンス=マイクロサービスのサービス、モダニティ=データ型 - シングルモーダルのみでは限界がある理由として、(1) 複数のモダリティに異常なパターンを示す可能性と(2)ある種の障害は特定のモダリティに反映されないの２つがある。 - (1)については、図１では、F1が根本原因であり、トレース、ログ、メトリクスのそれぞれが異常なパターンを示している。 ![[Pasted image 20230226205932.png|400]] - (2) について、 [[Generic AIOps Atlas|GAIA]]データセットを用いた実証実験表１では、この5種 類の障害のパターンを区別できるモダリティはない ![[Pasted image 20230226204915.png|600]] - 障害パターンを学習し、根本原因のインスタンスを特定し、障害の種類を決定するために、[[Graph Neural Network|GNN]]を適用するが次の２つの課題がある。 - 課題１： マルチモーダルデータを統一的に表現することは困難である。各モダニティは時系列、半構造化テキスト、ツリー構造であり、共通性がない。それに対して、**軽量な前処理と表現学習を組み合わせ、異なるモダリティのデータを同じベクトル空間にマッピング**することで解決する。 - 課題2： 不均衡な障害の種類：ある種の障害は他のものよりはるかに稀である。そこで、[[Data Augmentation]]により不足する障害のデータを増強することで解決する。 - 図２はMicrosoftのインシデント管理システムに記録されている障害の種類ごとのインシデント数であり、不均衡であることがわかる。 - ![[Pasted image 20230417114206.png|300]] - 問題設定 - タスク１：根本原因のインスタンスローカライズ（ランキング問題） - タスク２：障害の種類判定（分類問題） ### 2. Contributions - 故障診断のためのマルチモーダルデータベースのアプローチであるDiagFusionを提案 - トレースデータとデプロイメントデータから依存関係グラフを構築し、故障伝播経路を捕捉する。 - インスタンスローカライゼーションと故障タ イプの決定という2つの故障診断を実現 - マイクロサービスシステムの故障診断のために3つのモダリティの統一的な表現を学習した初の研究である。 - データ増強により、限られたラベル付き故障や不均衡な故障タイプでも動作するようにする。さらに、過去の故障パターンを用いてGNNを学習し、空間的特徴と起こ りうる故障伝播経路の両方を捕捉する。 - 160例と80例に基づいてDiagFusion を学習させた場合、2つのデータセットでそれぞれ0.75と0.7 6のAvg@5を達成し、根本原因のインスタンスローカライゼー ションの精度を20.9%から368%向上 ### 3. Major Ideas - 全体の流れ（図３） - ![[Pasted image 20230417115808.png|300]] - 過去の障害から (1) 生のトレース、ログ、メトリクスデータからイベントを抽出し、タイムスタンプによってシリアライズする。(Event Sequence) - (2) 学習時のデータ増強を行う。(Data Augumentation) - (3) イベントのembeddingベクトルを生成するために、fastTextモデルを学習させる。 (Event Embedding Model) - (4) デプロイメントデータとトレースデータからマイクロサービスの依存関係グラフを構築する。(DG) - (5) 最後にイベントと依存関係グラフをGNNにより結合学習する。 - 各モダニティのイベント抽出 - トレースイベントの抽出：異常検出のために、数値フィールド（応答時間など）のための異常検出アルゴリズム([[3σ則]])を適用する。カテゴリカルなフィールド（Status Codeなど）では、各値の出現回数をカウントし、劇的な増加に対して異常検出する。呼び出し元と呼び出し先のグループが、そのフィールドのいずれかが異常になった場合、異常とする。<timestamp, caller-instance-id, callee-instance- id>が得られる。 - ログイベントの抽出：固定深度解析ツリーにより、ログメッセージのテンプレート部分と可変 部分を区別するDrain[25]を用いる。テンプレート部分の文字列をハッシュ化し、イベントテンプレートIDを取得し、<timestamp, instance-id, event-template-id>が得られる。 - メトリクスイベント抽出：異常メトリクスを検出するために、[[3σ則]]を実行する。異常の方向が↑か↓かも抽出し、<timestamp, instance-id, metric-name, anomaly-direction>が得られる。 - 各イベントのグループ化：タイムスタンプとインスタンスIDという2つのフィールドを共有していることに着目し、イベントをインスタンスIDでグループ化し、同じグループ内のイベントをタイムスタンプでシリアライズする。 - ![[Pasted image 20230417121522.png|400]] - イベント埋め込みモデル：単語列をイベント列、文書ラベルを故障の種類に置換して、fastTextで埋め込みベクトルにマッピングする。 - 依存関係グラフの構築 - サービス間の伝搬失敗には 、ネットワーク呼び出しとリソース競合の2つある。 - ネットワーク呼出は、トレースを集約してコールグラフを得て、有効辺を追加する。 - リソース競合は、デプロイメントデータからエッジを追加する。 - システム全体像を把握するための障害伝搬を学習するGNN - インスタンスiはそのすべてのイベントを平均化することで表現する。 - GNN のK層目では、トポロジー適応グラフ畳み込みを適用し、GNNに読み出し層、すなわちMaxPooling層を追加し、マイクロ サービスシステム全体の情報を統合し、読み出し層の後、出 力ニューロンを持つ完全連結層が存在する。 - 各ニューロンは、 タスク1では根本原因インスタンスの可能性のあるサービスグループ、タスク2では障害タイプのいずれかに対応する。 - データ増強：イベント埋め込みモデルを学習させた後に、対象の障害の種類のイベント列をランダムに取り、イベントの1つをベクトル空間のユークリッド距離が最も近い隣人に置き換えることで新しいイベント列を追加する。[[Chaos Engineering]]により、多数の障害ケースを生成できる。 - マイクロサービスのインスタンスが作成・破壊された場合、読み出し層が各インスタンスの根本原因インスタンスである確率を直接出力するのであれば、モデルを頻繁に再トレーニングする必要がある。そのため、根本原因インスタンスを直接決定せず、タスク1のサービスグループに対して学習し、サービスグループ内のインスタンスを、そのイベント列の長さによってランク付けする。これで、再トレーニングタイミングは、インスタンスではなく、サービスグループ単位の作成・破壊になる。 ### 4. Experimental design & Results - データセット：D1はGAIAデータセットであり、D2はトップク ラスの商業銀行のマネジメントシステムから収集されている。D2は14のインスタンスからなり、障害を5つのタイプ（CPU関連、メモリ関連、JVM-CPU関連、JVM-メモリ関連、IO関連）に分類する。データ収取間隔は30秒以上。 - ![[Pasted image 20230417145753.png|400]] - ベースライン - タスク１：[[2022__ICSE-SEIP__MicroHECL - High-Efficient Root Cause Localization in Large-Scale Microservice Systems|MicroHECL]]、[[2021__WWW__MicroRank―End-to-End Latency Issue Localization with Extended Spectrum Analysis in Microservice Environments|MicroRank]]、[[2020__WWW__AutoMAP - Diagnose Your Microservice-based Web Application|AutoMAP]]、[[2018__MS-Rank Multi-Metric and Self-Adaptive Root Cause|MS-Rank]]、[[2021__ISPA__Diagnosing Performance Issues in Microserviceswith Heterogeneous Data Source|PDiagnose]] - タスク2：Cloud19、[[2016__ICSE-C__Log Clustering based Problem Identification for Online Service Systems|LogCluster]]、[[2021__CIKM__CloudRCA - A Root Cause Analysis Framework for Cloud Computing Platforms|CloudRCA]] - 各種法のパラメータは、その論文にあわせて設定される。 - 評価指標：タスク１はAC@KとAVG@K、タスク２は多クラス分類問題であるため、重み付き平均precision, recall, F1-scoreを使う。 - 実装：Python 3.7.13、PyTorch 1.10.0, scikit-learn 1.0.2, fastText 0.9.2, and DGL 0.9.0 - 12 × Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHzと128GB (GPU なし) のサーバ - すべての実験を 5回繰り返し、平均結果をとる - タスク１：マルチモーダルデータを用いたPDagnoseと比較すると、 DiagFusionのAvg@5は0.18以上高い。過去の失敗から学習することで、診断の精度が向上することを示す。 - ![[Pasted image 20230417145654.png|500]] - タスク２：より多くの障害種別とパターンを持つD2はD1ほど性能がよくないが、DiagFusionはF1-Scoreを0.80に維持できている。 - ![[Pasted image 20230417145732.png|500]] - Ablation Study：1) データ増強、2) fastText embedding、3) DGとGNNをそれぞれ評価する。 - C1: データ増強を削除 する - C2: fastTextの代わりに[[word2vec]]の埋め込みを使用 する。 - C3: fastTextの代わりにGloVeの埋め込みを使用する。 - C4: GNNの出力層を[[決定木]]に置き換える。 - C5: GNNの出力層を[[k-最近傍法|k-NN]]モデルに置き換える。 - ![[Pasted image 20230417150220.png|500]] - C2&C3では、fastTextが教師あり情報を利用するのに対し、word2vecとGloVeは自己教師あり情報を利用するため性能が低下する。 - C4&C5では、決定木やk-NNの分類器はグラフ構造情報を理解することができないため、性能が低下する。 - 実行時間：DiagFusionは平均12秒以内に1つの障害をオンライン診断する。他手法と比べて遅いほうである。 - パラメータ敏感性 - データ拡張では、サンプル数がある程度増加した 場合、学習セットの情報はすでに十分に活用されている。 その代わり、ノイズが過剰に混入しているため、性能が低 下する可能性がある。 - GNNの層数は3より少ないときに最良となる。深いGNNの学習には余分な学習サンプルが必要 であり、実際のシステムで満たすことが難しいため、層数を大きく設定することを推奨されない。 - タイムウィンドウの長さ（2-20点？分？）は性能にほ とんど影響を与えません ### 5. Discussions & Limitations - 学習ベースのアプローチを採用した理由は、１）精度、２）汎化能力、３）複雑なデータへの適合性の３点である。 - 学習ベースではラベル付けされたサンプルが必要となるが、（１）インシデント管理システムではラベル付けが自然となされている、（２）DiagFusionは多くの学習サンプルを必要としない、（3）Chaos Engineeringの普及によりサンプルを増やしやすくなる、といった理由で対象できる。 - fastTextに対して、ELMo、[[BERT]]、[[GPT]]のような深い動的埋め込みはNLPでよく使われるが、障害例 の数が大規模モデルの学習に不足するため、マイクロサービスの設定には適さない。 - マイクロサービスのようなグラフ構造に対して、ランダムウォークベースのアプローチ（AutoMAP、MS-Rank）があるが、ドメイン知識はシステムによって大きく異なるため、一般化できる能力に限界がある。 - モダニティの欠落は、（１）データ収集の問題、（２）データの利用可能性の問題、（３）データ検索の問題 - 表６では、PDiagnoseに対して、メトリクスが欠落してもDiagFusionが性能が高いことを示す。Diagnoseは各モダリティを独立して扱うため、欠落したモダリティがあると効果を失う。 - ![[Pasted image 20230417151754.png|400]] - 実環境への展開の懸念： 1. サービスインスタンス（コンテナ）単位での増減には再学習を必要とせず、サービスグループ（マイクロサービス）が作成されたときに再学習が必要となるが、それは稀なことである。 2. 3つのモダリティを同時に監視しないシステムでは、DiagFusionは、3つのうち任意の2つが利用可能であれば、動作可能である。fastTextはイベント列、GNNは特徴ベクトルで学習するため、オリジナルのデータではないためである。 - 本研究の脅威 - D1とD2のデータセットサイズが限られる。 - 本研究で使用した障害事例D1の中には、産業用システムの障害例よりも単純で、異なるタイプの限られた部分しか表していないものがある。 - Microscope、MS-Rank、AutoMAPなどの依存関係グラフを構築する研究の正しさは、パラメータ設定に大きく依存するため、適用性が低下する。 - [[2021__CIKM__CloudRCA - A Root Cause Analysis Framework for Cloud Computing Platforms|CloudRCA]]は、[[PCアルゴリズム]]を用いて、メトリックの異常パターン、ログの異常パターン、および故障の種類の間の因果関係を学習し、階層的なベイジアンネットワークを構築する、P Diagnosは3つのモダリティの軽量な異常検出を利用し て、異常パターンを検出し、投票ベースの戦略をとる。しかし、これらは、マイクロサービスのトポロ ジーの特徴を無視する。 - Grootは、メトリクス、ステータスログ、および開発者の活動を統合している。あらかじめ定義された多数のルールが必要であり、ほとんどのシナリオへの適用性が低下する。 ### 6. Thoughts - マルチモーダルデータをオリジナルのまま学習するのではなく、モーダルに依存しないイベント列にシリアライズあるいはその後のfastTextによる特徴ベクトル化して、学習することで、特定のモダニティの不足に対処しているのはよくできている。 - 事前学習が必要となる方法は、コンテナの増減のたびに再学習が必要なのではと以前議論していたが、マイクロサービス単位で学習することにより、コンテナ単位では推論時イベント列の流れで根本原因を決定していることも興味深い。 - 実際に実験でChaos Engineeringでデータ増強したわけではなさそうだが、Chaos Engineeringでデータ増強ができることを示唆しているのは、以前考えていた[[chaos 自己学習]]の考え方と同じものである。 - （メトリクスの増加と減少判定は、TSifterのフェーズ１でも回帰線の傾きが0より大きいか小さいかで判定できそう。） - 表６について、トレースが欠落した場合は、依存関係グラフを構築できなくなり、最後のGNNの学習に影響し、精度が低下するのではないか？ - より新しい研究である[[2023__ICSE__Eadro - An End-to-End Troubleshooting Framework for Microservices on Multi-source Data|Eadro]]もマルチモーダルデータを使うが、Eadroとの差異は何になるのか？ ## Abstract 大規模なマイクロサービスシステムでは、自動障害診断が極めて重要である。現在、ほとんどの障害診断手法は、シングルモーダルデータ（すなわち、メトリクス、ログ、トレースのいずれかを使用する）のみに依存しています。本研究では、実世界の障害事例を用いた実証研究を行い、これらのデータソース（マルチモーダルデータ）を組み合わせることで、より正確な診断につながることを明らかにします。しかし、これらのデータを効果的に表現し、不均衡な障害に対応することは依然として課題である。これらの課題に取り組むため、マルチモーダルデータを用いたロバストな障害診断アプローチであるDiagFusionを紹介します。DiagFusionは、サービスインスタンスのマルチモーダルデータを表現するために埋め込み技術とデータ拡張を活用し、デプロイメントデータとトレースを組み合わせて依存関係グラフを構築し、グラフニューラルネットワークを用いて根本原因インスタンスを特定し、障害の種類を決定します。実世界のデータセットを用いた評価により、DiagFusionは根本原因インスタンスの特定と障害タイプの決定の点で既存の手法を凌駕していることが示されています。