# AutoMAP: Diagnose Your Microservice-based Web Applications Automatically **WWW 2020 | 2020-04-20 | Taipei** マイクロサービスベースのウェブアプリケーションを対象に、事前のシステム知識を不要とした自動根本原因診断ツール AutoMAP(Automated Microservice-based Web Applications Patrol)を提案した論文。ダブルブラインド審査のため著者名は匿名化されているが、手法・用語の連続性から [[Tsinghua University]] の NetManAIOps グループ([[Dan Pei]] らの系譜)との関連が強く示唆される。MS-Rank[32]の先行研究として著者らが引用する論文も同グループの成果(M. Ma, W-L. Lin, D-S. Pan, P. Wang)であり、著者の重複が疑われる。 ![[wiki/sources/_attachments/2020WWW_AutoMap/fig2-automap-framework.png]] *図2: AutoMAP のフレームワーク概要。P1〜P6 のフェーズで構成される。* --- ## 研究の背景と課題 マイクロサービスアーキテクチャは開発の抽象化・モジュール化・独立スケーリングを促進する一方、サービスとその依存関係が継続的なリファクタリングを経て複雑に変化するため、障害箇所の特定が困難になる。論文が指摘する三つの課題は以下のとおりである。 1. **動的なアプリケーション構造**: 頻繁に変化する状況ではスレッショルディング等の静的な手法が機能しない。コールトポロジは変動し続けるため、静的な構造を事前に取得しておくことが困難または非現実的なシステムも存在する。 2. **間接的な異常伝播**: サービスが異なるホスト・コンテナに分散し、同期呼び出し(同期リクエスト)と非同期呼び出し(メッセージプロキシ/パブサブ)が混在する。同じホスト・コンテナ上の無関係なサービスにも異常が波及するため、コール依存関係だけでは伝播トポロジを捉えられない。 3. **複数種類のメトリクス**: 単一種類のメトリクスでは多様なサービスの異常を特徴付けるのに不十分。かつ非同期呼び出しでは伝播依存関係をメトリクスが直接反映しないことがある。 ![[wiki/sources/_attachments/2020WWW_AutoMap/fig1-anomaly-propagation-example.png]] *図1: マイクロサービスによるウェブアプリケーションにおける異常伝播の例。六角形がサービス、赤が根本原因、黄が影響サービス。* --- ## AutoMAP の設計 ### 問題設定 マイクロサービスベースのウェブアプリケーションを「グレーボックス」として扱う。すなわち複数種類の監視メトリクスのみを入力とし、コールトポロジ・サービス機能などの事前知識を一切仮定しない。フロントエンドサービス $v_{fe}$ に異常が観測された際に、その根本原因サービス集合 $\mathbf{v}_{rc} \subset V$ を特定することが目標である。 使用するメトリクスは 7 種類: レイテンシ(Mlat)、スループット(Mthr)、コンジェスチョン(Mcon = throughput/latency)、CPU 使用率(Mcpu)、I/O カウント(Mio)、メモリ消費率(Mmem)、可用率(Mavl)。 ### フレームワーク全体像 AutoMAP は以下の 6 フェーズを反復する: - **P1** サンプリング間隔の選定(周波数加重平均のサービス呼び出し間隔) - **P2** 複数種類のメトリクスを用いた異常行動グラフの構築 - **P3** 加算(+)・減算(−)演算による異常プロファイルの抽出 - **P4** 行動グラフに沿ったヒューリスティック根本原因特定アルゴリズムの実行 - **P5** 結果の検証と精度算出 - **P6** メトリクス重み行列の更新。新規インシデント発生時は P1 へ戻る --- ## 異常行動グラフの構築 ### 定義 **異常行動グラフ** $G(V, E, W)$ はサービス間の影響相関を記述する重み付きグラフである。頂点 $v_i$・$v_j$ 間の重み $W_{i,j,k} \in [0,1]$ はメトリクス $M_k$ に基づく相関の信頼度を表し、$\sum_k W_{i,j,k} = 1$ である。辺 $v_i \to v_j$($W_{i,j,k} > 0$)は「$M_k$ に基づき $v_i$ が $v_j$ に影響を受ける」ことを示す。 ### 構築手順 完全無向グラフから始め、条件付き独立性検定によって辺の重みを段階的に除去し、最終的にエッジに方向を付与して weighted-CPDAG(完全部分有向非巡回グラフ)を得る。 1. 完全無向重み付きグラフ $G$ を初期化($W_{i,j,k} = 1$ for all $i,j,k$) 2. 各メトリクス $M_k$ について全サービスペアの条件付き独立性を検定。独立と判定されたペアの $W_{i,j,k}$ を 0 に設定 3. 全 $k$ で $W_{i,j,k} = 0$ なら辺を除去。重みを正規化 4. v-構造の方向付けとメンコフの 3 ルールによる残余辺の方向付け 条件付き独立性検定には $\chi^2$ 検定を使用。有意水準 $\alpha$ が小さいほど辺が多く残り、大きいほど辺が多く除去される。アルゴリズム計算量はグラフの最大次数 $d$ に対して $m \cdot 2^{nd} \sum_{i=0}^{d} \binom{n-1}{i}$ でメトリクス数・次数に対して指数的に増加する。 ![[wiki/sources/_attachments/2020WWW_AutoMap/fig5-behavior-graph-subtraction.png]] *図5: 行動グラフの引き算操作の例。通常グラフ G1 と異常グラフ G2 の差分として異常相関(赤の実線辺)を抽出する。* --- ## サービスプロファイルと異常プロファイル ### 加算演算(+)とサービスプロファイル 行動グラフに対して**加算演算**を定義し、複数の正常期間のグラフを集約することでサービスプロファイルを生成する。サービス $v_i$ のプロファイルは、出力隣接ノード $O_i$ への辺の重みベクトル平均として定義される: $\text{Profile}(v_i) = \frac{1}{|O_i|} \sum_{l \in O_i} W_{i,l}$ このベクトルは「$v_i$ が他サービスに与える影響がどのメトリクスに支配されるか」を示す。論文ではクラウドプラットフォーム上のサービスを支配的メトリクスにより 5 カテゴリに分類した: | カテゴリ | 代表メトリクス | 代表サービス | |---|---|---| | 表現系(Representational) | Mlat, Mavl | Dashboard, Console | | 計算系(Computing) | Mthr, Mcpu | Spark, AI, NLP | | ネットワーク系(Networking) | Mcon | Message Hub, IoT center | | ストレージ系(Storage) | Mio | Cloudant, MongoDB, HBase | | 環境系(Environmental) | Mmem | Container, Docker, Kubernetes | ### 減算演算(−)と異常プロファイル **減算演算**は異常期間の行動グラフから正常期間の共有相関を除去することで、異常固有の相関パターン(異常プロファイル)を抽出する: $\text{Profile}(G_{ab}) = G_{ab} - \sum_{i=1}^{k} G_i$ ここで $G_i$ は正常期間 $w_i$ のグラフ。減算後の辺重みが負になる場合は 0 に設定し、余剰相関(正常時にも存在する相関)を取り除く。 --- ## 自動メトリクス重み学習とプロファイル類似度 ### 類似度関数 異常プロファイル間の類似度 $\text{sim}(G_i, G_j) \in [0,1]$ を以下の 4 ステップで算出する: 1. 共有異常プロファイル $G = (G_i - G_j) + (G_j - G_i)$ を計算 2. 頂点オーバーラップスコア $\text{sim}_{VO}$: 両グラフの頂点カテゴリの一致度 3. 辺オーバーラップスコア $\text{sim}_{EO}$: 共有辺の重みユークリッド距離 4. 調和平均 $\text{sim}(G_i, G_j) = 2 \cdot \frac{\text{sim}_{VO} \cdot \text{sim}_{EO}}{\text{sim}_{VO} + \text{sim}_{EO}}$ ### 自動メトリクス重み学習 対象異常 $G_A$ に類似した上位 $k$ 件の過去プロファイルを検索し、それらの根本原因とフロントエンドサービスの相関スコアを精度重み付き投票で集約することで、各メトリクスの重み $w_k$ を自動決定する。初回は $M_{lat}$ をデフォルト使用。 --- ## ヒューリスティックランダムウォークアルゴリズム ![[wiki/sources/_attachments/2020WWW_AutoMap/fig7-behavior-graph-sample-incident.png]] *図7: サンプルインシデントの行動グラフ(一部)。S18 がフロントエンド。S1, S12, S27 は接続なし、(S3,S19)と(S4,S11,S23,S25)は孤立。* フロントエンドサービスから始め、三種類の遷移確率を組み合わせたランダムウォークで訪問回数をカウントし、降順でランキングする: - **前向き遷移(Forward)**: 辺方向に従い、各メトリクスの相関スコアと重みに比例して遷移 $p_{i,j} = \sum_{k=1}^{m} w_k W_{i,j,k} \cdot \frac{c_{j,fe,k}}{\sum_{l \in O_i} c_{l,fe,k}}$ - **自己遷移(Self)**: いずれの近傍も相関が低い場合、現在ノードに留まる確率 $p_i^s = \max(0, p_{i,i} - \max_{l \in I_i \cup O_i} p_{i,l})$ - **後ろ向き遷移(Backward)**: 出力近傍の相関が低い場合に辺の逆方向へ遷移できる。強度パラメータ $\rho \in [0,1)$ が小さいほど元の方向に制約、大きいほど逆行しやすくなる ランダムウォークは異常プロファイル(正常相関除去後)ではなく元の行動グラフ $G_A$ に基づいて実施し、候補検出確率を高めている。 --- ## 実験と評価 ### データセット - **シミュレーション環境**: Docker コンテナ上の 16 マイクロサービス。Zookeeper 管理。コンテナシャットダウン・DoS 攻撃で障害を注入。 - **実世界環境**: 大規模クラウドプラットフォームの 20 インシデント(SRE チームが根本原因を検証済み)。各インシデントで 1732 マイクロサービス API から 7200 秒分・約 1500 万メトリクスを収録。 ### ベースライン手法 TBAC、MonitorRank、CloudRanger、NetMedic、MS-Rank の 5 手法と比較。単一メトリクス依存の手法は $M_{lat}$ と $M_{thr}$ でそれぞれ評価。 ### 結果 ![[wiki/sources/_attachments/2020WWW_AutoMap/fig8-precision-comparison-top1-3-5.png]] *図8: 実世界インシデントにおける各アルゴリズムの top-1/3/5 および avg-5 精度比較。* ![[wiki/sources/_attachments/2020WWW_AutoMap/fig9-self-optimization-rounds.png]] *図9: 診断ラウンド数の増加に伴う AutoMAP の精度向上(vs NetMedic)。* | 指標 | AutoMAP | 最良ベースライン(NetMedic, Mlat) | |---|---|---| | Top-1 精度 | **64.4%** | 59.4% | | Top-3 精度 | 91.2%相当 | 89.5% | | Top-5 精度 | **93.9%** | 93.3% | | Avg-5 精度(10ラウンド後) | **89.7%** | 85.2% | 主要な知見: - 相関スコアのみに依存する TBAC は精度が低い(top-1: 23.1-25.4%)。ランダムウォーク手法全般が静的手法より高精度 - MS-Rank との比較では、AutoMAP の異常プロファイル導入により top-1 精度が特に改善 - 診断ラウンドを重ねるにつれ精度は顕著に向上(10 ラウンドで top-5 が 59.7% → 93.9%) - NetMedic は自己最適化を持たないため、動的に変化するアーキテクチャでは不安定 **パラメータ感度**: - $\alpha$(条件付き独立性有意水準): 小さいほど辺が少なく、大きいほど多い。データが少ない場合($\ell = 200$)は大きめが有効。データが豊富な場合($\ell = 1440$)は影響が小さい。$\alpha = 0.5$ でも処理は 4 分以内 - $\rho$(後ろ向き遷移強度): 中程度($\rho = 0.2$)が推奨。大きすぎると精度改善が飽和 **ドメイン知識の導入効果**: ドメイン知識(同一ソースの API リンク、既知のコール相関、辺方向の指定等)をグラフに加えることで、特にデータが少ない場合($\ell = 200$)に精度向上(+4.9〜+8.2%)。データが豊富な場合でも改善効果はあるが軽微(+0〜+3.2%)。 --- ## 関連研究との位置づけ - **MonitorRank**(SIGMETRICS 2013): 事前のサービスコールトポロジが必要。AutoMAP はこれを不要とした - **CloudRanger**(CCGrid 2018): 統計的特性でトポロジを再構築。AutoMAP はより動的な相関を捉える - **Microscope**(ICSOC 2018): 因果グラフでパフォーマンス問題を特定。AutoMAP は複数メトリクスを自動選択 - **MS-Rank**(ICWS 2019): 自適応メトリクス選択の先行研究。AutoMAP は異常プロファイルによる履歴特徴の活用でこれを発展させた - **NetMedic**: 障害伝播テンプレートを使った多段依存グラフ生成。固定テンプレートへの依存が動的環境で弱点となる --- ## 結論と今後の方向性 AutoMAP は事前知識ゼロの「グレーボックス」設定でマイクロサービス診断の 90%超精度を達成し、既存のベースライン手法を有意に上回ることを実験で示した。また実運用 SRE への応用として、参照診断結果の提示により 1 インシデントあたり平均 3 時間の調査時間削減を目指す設計思想が示されている。今後の展望として、ソーシャルネットワーク・生物ネットワークなど他の複雑システムへの拡張が挙げられている。 --- ## 関連 - ソース: [[MS-Rank]] / [[CloudRanger]] / [[Microscope]] - エンティティ: [[Dan Pei]] / [[Minghua Ma]] / [[Tsinghua University]] - 概念: [[根本原因分析]] / [[異常検知]] / [[マイクロサービスアーキテクチャ]] / [[因果グラフ]] - 関連 MOC: `[[AIOps - Failure Detection - MOC]]`