# MicroDiag: Fine-grained Performance Diagnosis for Microservice Systems ## 書誌情報 - 著者: [[Li Wu]]・[[Johan Tordsson]]・[[Jasmin Bogatinovski]]・Erik Elmroth・[[Odej Kao]] - 所属: [[Elastisys AB]](Umeå, Sweden)・[[TU Berlin]] DOS グループ・[[Umeå University]] コンピュータサイエンス学科 - 掲載誌: ICSE 2021 Workshop on Cloud Intelligence (CloudIntelligence), Madrid, Spain - 公開日: 2021-05-01(HAL 投稿: 2021-03-02) - URL: https://hal.inria.fr/hal-03155797 --- ## 概要と位置づけ MicroDiag はマイクロサービスシステムの性能問題を**細粒度**で自動診断するシステムである。「細粒度」とは、障害コンポーネントの特定にとどまらず、**どのメトリクスが異常か**（例: サービス s1 の CPU 使用率）まで特定することを意味する。 従来手法の限界を次の3点に整理している。 1. **機械学習系(深層学習)**: 正常から大きく逸脱する特徴量を前提とするため、逸脱が小さい障害を見逃す。加えてマイクロサービスの頻繁な更新のたびに再学習が必要。 2. **パターン認識系**: 過去の障害パターンとのグラフマッチングに依存し、未知の障害を診断できない。計算量もグラフサイズに対して指数的。 3. **既存の因果推論系**: Granger 因果性（Loud, Sieve）は蓄積効果前提で同時効果を扱えない。PC アルゴリズム系（CauseInfer）は時間遅れ前提が強く同時効果の計算精度が低い。さらにサービス単位でグラフを構築するため、どのサービスから探索を開始するかという問題が残る。 MicroDiag の解決策は、**コンポーネント依存グラフを媒介として因果推論の探索空間を絞り込む**という設計である。 --- ## 問題設定 典型的なマイクロサービスシステムにおいて、サービス・コンテナ・サーバノードをコンポーネント $C$ と定義する。各コンポーネントはメトリクス時系列 $M^c$（CPU 使用率・メモリ使用率・ディスク IO・応答時間等）を公開する。 問題: コンポーネント集合 $C$ とメトリクス $M$ が与えられたとき、マイクロサービスの応答時間 $m^{rt}$ に異常が検知された際に、性能問題を引き起こした**犯人メトリクス**（culprit metric）$m^{rc}_{rc}$ を特定せよ。 犯人メトリクス $m^{rc}_{rc}$ は **障害コンポーネント $c_{rc}$ + 異常メトリクス種別 $m_{rc}$** の両方を示す点が通常の根本原因箇所特定（コンポーネントのみ）との差異である。 --- ## システム設計 MicroDiag は 6 モジュールで構成される。 ### B. データ収集と前処理 クラウドネイティブな監視スタックを使用し、アプリケーション計装なしにメトリクスを収集する。 - **Node-exporter**: サーバ OS レベルのメトリクス監視 - **Cadvisor**: コンテナのリソースメトリクス監視 - **Istio**: サービスメッシュ経由のサービス間通信・応答時間監視 収集後、不変のメトリクス（常時一定値のもの）を除去し、残りをコンポーネント単位にグルーピングする。 ### C. 異常検知 マイクロサービスの応答時間 $m^{rt}$ に対して **BIRCH（距離ベースオンラインクラスタリング）** を適用する。応答時間の時系列に複数のクラスタが検出された場合を異常と判定する。 - **教師なし学習**: 歴史的障害データが不要 - **リアルタイム対応**: オンラインアルゴリズムによる逐次更新 - **根拠**: Gulenko et al. 2018 の手法を応用 ### D. コンポーネント依存グラフ構築 異常検知をトリガとして根本原因箇所特定が始まる。最初のステップとして、コンポーネント依存グラフ（Component Dependency Graph, DG）を構築する。 DG の構築規則: - 各サービスから、通信する他サービスへのエッジと、実行されるコンテナへのエッジを追加する - 各コンテナから、所属サービスへのエッジと、実行されるサーバへのエッジを追加する - 各サーバから、実行する全コンテナへのエッジを追加する 結果として有向グラフが得られるが、サービス間は双方向エッジが生じる場合もある。グラフのノードと依存関係は、Istio が収集するサービスレベルメトリクスと Cadvisor が収集するデプロイメント情報を解析して動的に発見する。これは著者らの先行研究（MicroRCA, NOMS 2020）の属性グラフの拡張版である。 DG の意義: サービス間の呼び出し依存に加え、**同一サーバ上でのリソース共有・競合によるコンポーネント間の依存**（コールグラフには現れない）も捕捉できる点が重要。 ### E. メトリクス因果グラフ推論 DG を基に、依存関係のあるコンポーネント間のメトリクスに限定して因果推論を行い、**メトリクス因果グラフ（Metrics Causality Graph, MG）** を構築する。 MG 内の各ノードはコンポーネント $c$ の個別メトリクス $m^c_i$ を表し、有向エッジが因果関係かつ異常伝播パスを示す。 MicroDiag は異常伝播の性質を3種に分類し、それぞれ異なる手法を適用する。 #### i) リソースメトリクス間の異常伝播 一つのリソース異常が他リソースへ**同時に**（時間遅れなく）伝播するケース。例: CPU の過負荷が同一コンテナ上のメモリ使用率にも即時影響する。 この同時効果を扱うために **構造因果モデル（Structural Causal Model, SCM）** を使用する。具体的には **DirectLiNGAM**（Shimizu et al., JMLR 2011）を採用する。 DirectLiNGAM の前提と動作: - 各変数はその直接原因の線形関数 + 独立誤差項として表現される（式1: $m^{c_x}_i = \sum_{k(j)<k(i)} b_{ij} m^{c_y}_j + e^{c_x}_i$） - サーバのリソースはコンテナのリソースの線形和（リニア関数）という仮定が成立 - 異常なリソースメトリクスは**非ガウス分布**に従うと仮定（Loboz 2012 に基づく） - ペアワイズ回帰の残差独立性に基づいて外生変数を特定し、影響を除去する反復処理で因果順序を推定 #### ii) リソース-サービスメトリクス間の異常伝播 コンテナリソースの異常がサービス応答時間に**累積的に**（時間遅れで）伝播するケース。 この時間遅れ効果を扱うために **Granger 因果性検定**を使用する。AIC（赤池情報量規準）で最適な時間ラグを特定し、$\chi^2$ 検定で因果関係を確認する。 DirectLiNGAM で推定したリソース間因果性を使って、Granger 検定のコンテナリソースメトリクス間での偽陽性を較正する。 #### iii) サービス間の異常伝播 サービスからサービスへの伝播は、コンポーネント依存グラフのサービス間エッジを逆向きにすることで表現する。（サービス A が B を呼び出す場合、異常は A が B へ伝播する方向ではなく、B の異常が A の応答時間悪化を引き起こすという逆方向） ### F. 犯人メトリクス箇所特定 MG が構築されたら、**PageRank** をグラフ上で実行して犯人メトリクスを特定する。 1. 各エッジにピアソン相関係数を重みとして付与（異常伝播の確率を表現） 2. 遷移確率行列 $P_{ij} = \frac{w_{ij}}{\sum_j w_{ij}}$（ノード $i$ が $j$ へリンクする場合）を計算 3. テレポーテーション確率 $c = 0.15$（推奨値に従う） 4. 箇所特定のために MG の**エッジを逆向き**にしてから PageRank を実行（逆伝播方向で探索） 5. スコア上位のメトリクスが根本原因候補 --- ## 実験評価 ### 実験環境 - **テストベッド**: Google Cloud Engine 上の Kubernetes クラスタ - マスタ 1 ノード + ワーカー 4 ノード（4 vCPU・15 GB、コンテナ最適化 OS） - マイクロサービス専用ワーカー 3 + データ収集専用 1 - **ベンチマーク**: Sock-shop（13 マイクロサービス） - **監視スタック**: Istio + Cadvisor + Node-exporter + Prometheus - **負荷生成**: Locust ベースの負荷生成器（別 VM: 6 vCPU・12 GB） ### 障害注入 stress-ng を使用して2種の障害を注入: 1. **CPU 枯渇（CPU Hog）**: コンテナの CPU リソースを意図的に消費 2. **メモリリーク（Memory Leak）**: コンテナのメモリを意図的に消費 対象マイクロサービス: catalogue・carts・orders・users の4つ。実験手順は「5分正常 → 1分障害注入 → 5分冷却」を各設定5回繰り返し、合計40ケース。 ### ベースライン手法 - **Loud（ICST 2018, Mariani et al.）**: Granger 因果性でメトリクス伝播グラフを構築し PageRank でランキング - **CauseInfer（INFOCOM 2014, Chen et al.）**: PC アルゴリズムでサービスごとのメトリクス因果グラフを構築しランキング ### 評価指標 - **PR@k**（Precision at top k）: 上位 k 件に真の根本原因が含まれる割合 - **AP@k**（Average Precision at k）: PR@j ($j \leq k$) の平均 ### 結果 | 指標 | Loud | CauseInfer | MicroDiag | 最小改善率 | |------|------|------------|-----------|-----------| | PR@1 | 34% | 9% | **60%** | +76.5% | | PR@3 | 74% | 49% | **97%** | +31.1% | | PR@5 | 94% | 69% | **100%** | +6.4% | | AP@5 | 70% | 42% | **89%** | +27.1% | 障害種別の内訳: - CPU Hog: PR@1=80%、PR@3=100%（高精度） - Memory Leak: PR@1=33%、PR@3=93%（PR@1 が低い理由: メモリリークは複数リソースメトリクスへ分散して現れるため因果関係の特定が困難。加えて 5 秒の監視間隔が変化を捕捉しきれない場合がある） --- ## 先行研究との対比 | 手法 | 因果推論手法 | 同時効果 | 時間遅れ効果 | 探索空間制限 | |------|------------|---------|------------|------------| | Loud/Sieve | Granger のみ | 非対応 | 対応 | なし（全メトリクス） | | CauseInfer | PC アルゴリズム | 低精度 | 対応 | サービス単位 | | MicroCause | 時系列 PC | 低精度・高コスト | 対応 | なし | | **MicroDiag** | **SCM + Granger** | **対応（DirectLiNGAM）** | **対応** | **コンポーネント依存グラフ** | MicroDiag の構造的優位性: コンポーネント依存グラフにより、依存関係のないコンポーネント間での偽陽性因果関係を大幅に削減できる。CauseInfer の「サービスごとのグラフ + 探索開始サービス選択問題」を、全コンポーネント統合グラフで解消した。 --- ## 制限と今後の課題 1. **評価の狭さ**: CPU Hog と Memory Leak の2種のみ。TrainTicket など大規模ベンチマークでの評価が今後の課題。 2. **メトリクス次元削減**: 特徴選択（feature selection）によりメトリクスの次元数を削減する拡張が必要。 3. **監視間隔**: 5 秒間隔が一部の急速な変化を捕捉できない可能性がある。 --- ## 関連ソース（先行研究リンク） - [[Li Wu]] らの先行研究: **MicroRCA**（NOMS 2020）— 根本原因のコンポーネント箇所特定（サービス粒度）。MicroDiag のコンポーネント依存グラフはこの属性グラフを拡張したもの。 - **Loud**（Mariani et al., ICST 2018）— Granger 因果性ベース。ベースライン手法として使用。 - **CauseInfer**（Chen et al., INFOCOM 2014）— PC アルゴリズムベース。ベースライン手法として使用。 - **DirectLiNGAM**（Shimizu et al., JMLR 2011）— MicroDiag が SCM として採用。[[@2011__JMLR__DirectLiNGAM - A Direct Method for Learning a Linear Non-Gaussian Structural Equation Model]] として wiki 内に取り込み済み。 - **BIRCH 異常検知**（Gulenko et al., IEEE CLOUD 2018）— 距離ベースオンラインクラスタリング。 --- ## 概念との接続 - [[因果推論ベースRCA]] — MicroDiag はメトリクス因果グラフ + PageRank という「因果探索 → スコアリング」2 段パイプラインの典型例。SCM（DirectLiNGAM）と Granger 因果性を**役割分担して組み合わせる**点が他の純 Granger 系・純 PC 系と異なる。 - [[マイクロサービスアーキテクチャ]] — Sock-shop テストベッドを使用。コンポーネント依存グラフは、サービス間呼び出しに加えてコンテナ-サーバのリソース共有依存を統合したトポロジ表現。 - [[異常検知]] — BIRCH による応答時間の異常検知が MicroDiag の全処理を起動するトリガ。教師なし・リアルタイム・歴史的障害データ不要の特性を持つ。 - [[因果発見]] — DirectLiNGAM は [[Shohei Shimizu]] らが提案した手法であり、DirectLiNGAM のソースページとの接続が成立する。 --- ## 関連 - 著者: [[Li Wu]] / [[Johan Tordsson]] / [[Jasmin Bogatinovski]] / [[Odej Kao]] - 組織: [[TU Berlin]] / [[Umeå University]] / [[Elastisys AB]] - 先行: MicroRCA（NOMS 2020）/ Loud（ICST 2018）/ CauseInfer（INFOCOM 2014） - 手法: [[DirectLiNGAM]] / [[因果推論ベースRCA]] / [[異常検知]] - ベンチマーク: [[マイクロサービスベンチマーク]]（Sock-shop）