# MicroRCA: Root Cause Localization of Performance Issues in Microservices > [!abstract] 概要 > ソフトウェアアーキテクチャは、開発におけるレジリエンス、俊敏性、スケーラビリティを実現するため、モノリシックアーキテクチャからマイクロサービスへ移行しつつある。しかしマイクロサービスでは、技術の異質性、マイクロサービス数の多さ、ソフトウェア機能とインフラストラクチャの頻繁な更新のため、性能問題の診断が難しい。本論文は、マイクロサービスにおける性能問題の根本原因を特定するシステム MicroRCA を提示する。MicroRCAは、アプリケーションへの計装なしに、アプリケーション性能の症状と対応するシステム資源使用率を相関させ、リアルタイムで根本原因を推定する。根本原因の箇所特定は、サービスとマシンをまたぐ異常伝播をモデル化する属性付きグラフに基づく。Kubernetesクラスタ上で稼働するマイクロサービスベンチマークへ一般的な異常を注入した実験では、MicroRCAは89%の適合率と97%の平均適合率を達成し、複数の最先端手法を上回った。 ## 論文情報 - タイトル: MicroRCA: Root Cause Localization of Performance Issues in Microservices - 著者: Li Wu, Johan Tordsson, Erik Elmroth, Odej Kao - 媒体: IEEE/IFIP Network Operations and Management Symposium (NOMS) - 発表年: 2020 - 掲載情報: Budapest, Hungary、2020年4月 ## 概要 MicroRCAは、コンテナ化されたマイクロサービス環境で、性能問題の根本原因となるサービスをアプリケーション計装なしに順位付けするシステムである。入力には、サービスメッシュから得たサービス間の応答時間、コンテナとホストのCPU・メモリ・送信バイト数などのシステムメトリクス、サービスとホストの動的な関係を使う。サービス呼び出し経路だけでなく、同じ仮想マシンに同居するサービス間の資源競合も異常伝播の経路に含める点が重要である。 問題の出発点は、マイクロサービスの大規模化・異種技術の混在・頻繁な更新が、従来の静的な依存関係やアプリケーション固有の診断器を陳腐化させることである。Uberの例では4000のマイクロサービスが稼働し、Netflixは200万、Uberは5億の監視メトリクスを公開しているとされる。すべてのメトリクスを診断に使えば収集・分析コストが大きくなる一方、アプリケーションコードを計装するトレース手法は開発者の実装負担と更新への追随コストを伴う。また、アプリケーションレベルの因果グラフだけを用いる手法は、フロントエンドへほとんど影響しないバックエンドの異常を見逃しうる。 MicroRCAは、サービスの遅い応答時間を検知対象とし、検知されたサービス間辺を異常辺として異常部分グラフを作る。その後、異常サービスの応答時間と、隣接サービスの応答時間またはホスト・コンテナ資源使用率との相関から辺重みとサービス異常スコアを計算する。異常スコアを個人化ベクトルにしたPersonalized PageRankを異常部分グラフ上で実行し、ホストノードを除いたサービス順位を根本原因候補として出力する。 ## 問題設定 ### 研究上の問いと動機 本論文の研究上の問いは、アプリケーション内部を計装せず、技術スタックに依存しない観測だけから、マイクロサービスの性能症状を生じさせたサービスをリアルタイムに特定できるか、である。マイクロサービス化によって、サービスの配置・呼び出し・資源共有が複雑になり、単一障害が複数のアラートへ伝播する。サービス数が数百から数千に増えると、運用者が調べる候補も増える。 既存手法には三つの制約がある。ログ型手法は、原因に関する情報を得やすい反面、リアルタイム処理が難しく、異常の手掛かりがログへ出ることを仮定する。トレース型手法は実行経路上の遅延を詳細に追えるが、ソースコードへトレース計装を追加する必要がある。メトリクス型・因果グラフ型手法のうち、サービス呼び出し関係だけを使うものは、異常がフロントエンドへほぼ伝わらない葉サービスや、同居サービスとの資源競合を扱いにくい。さらに、アプリケーション固有の性能指標をすべて異常検知にかけると、メトリクス数に比例したオーバーヘッドが生じる。 ### 入力・出力 MicroRCAへの入力は、次の観測系列と動的な関係である。 - サービス間の応答時間。特に、通信するサービス対の応答時間をアプリケーションレベルのサービス指標として取得する。 - コンテナとホストの資源使用率。CPU使用率、メモリ使用量、送信バイト数を収集する。 - サービス間の呼び出し関係と、コンテナ化されたサービスがどのホストで稼働しているかという配置関係。 - 異常検知で得たサービス間応答時間の異常辺と、その検知信頼度 \(\alpha\)。 出力は、異常部分グラフ上のサービスノードを根本原因らしさの順に並べたリストである。設計上の最終対象はサービスであり、PageRank実行後にホストノードをランキングから除く。評価では、単一のサービスへ単一障害を注入したケースの真の原因サービスを正解とする。 ### 前提と制約 MicroRCAは、異常がマイクロサービスの応答時間の増加として現れることを前提とする。異常検知自体はMicroRCAの中心的な比較対象ではなく、根本原因箇所特定の評価では、MonitorRankとMicroscopeにもMicroRCAと同じ異常検知結果を与える。これは、両手法の異常検知が、特にpaymentのような非自明な異常を検知できず、根本原因箇所特定の比較を歪めるためである。 属性グラフを作る時間範囲では、すべてのマイクロサービスが信頼できる状態で動作し、収集メトリクスがサービスとホストの関係を正確に表すと仮定する。サービスメッシュから観測できない依存関係、共有メモリなどの非通信依存、応答時間へ現れない性能劣化は、観測構成の外にある。さらに、相関は異常伝播の類似度として使うが、相関係数そのものを厳密な因果効果とは解釈しない。 ## 提案手法 ### 全体パイプライン Figure 1のシステムは、データ収集、異常検知、原因分析エンジンからなる。原因分析エンジンはさらに、属性グラフ構築、異常部分グラフ抽出、障害サービス箇所特定の三段階へ分かれる。 1. **データ収集**: サービスメッシュと監視システムから、サービスレベルとシステムレベルの時系列メトリクスを収集し、時系列データベースへ保存する。 2. **異常検知**: サービス間の遅い応答時間を異常として検知する。MicroRCAは、距離ベースのオンラインクラスタリング手法BIRCHを使う非教師あり検知器を利用する。 3. **属性グラフ構築**: 検知前の一定時間窓におけるメトリクスを解析し、サービスノード、ホストノード、サービス呼び出し辺、サービスから配置先ホストへの辺を作る。 4. **異常部分グラフ抽出**: 異常なサービス間応答時間の辺の始点を異常サービスノードとし、その隣接サービス・ホストを追加して連結部分グラフを構成する。 5. **重み付けとスコアリング**: 異常辺、異常サービスと正常サービスの辺、異常サービスと正常ホストの辺に、応答時間と資源使用率の相関を割り当てる。異常サービスには応答時間とコンテナ資源の相関を反映した異常スコアを付与する。 6. **サービス箇所特定**: 異常スコアをPersonalized PageRankの個人化ベクトルとして使い、辺をサービス呼び出しの逆向きに反転して根本原因候補をランキングする。最後にホストノードを除く。 ### 属性グラフの構築 サービス集合を \(S=\{s_1,s_2,\ldots,s_k\}\)、ホスト集合を \(H=\{h_1,h_2,\ldots,h_m\}\) とする。サービス \(s_i\) がサービス \(s_j\) へリクエストを送れば、\(s_i\rightarrow s_j\) の有向辺を加える。コンテナ化されたサービス \(s_i\) がホスト \(h_j\) に配置されていれば、\(s_i\rightarrow h_j\) の有向辺を加える。したがって、グラフはサービス間呼び出しだけでなく、同居するサービスから共通ホストへの資源影響も表現する。 グラフノードと動的関係は、アプリケーションレベルとシステムレベルで監視されるメトリクスを列挙・解析して得る。構築に使う時間窓では、サービスとホストの関係が正しく観測されることを仮定する。元のサービス呼び出し辺は「呼び出し元から呼び出し先」へ向いているが、根本原因を探す際には、異常なサービスから原因候補側へ遡るため辺を反転する。 ### 異常部分グラフの抽出 サービス間の応答時間を異常検知対象とする。異常と判定された辺の始点を異常サービスノードとみなし、異常サービスノードの異常応答時間の平均を \(rt^a\) というノード属性にする。例えばFigure 2(a)で \(s_1\rightarrow s_2\)、\(s_2\rightarrow s_3\)、\(s_2\rightarrow s_4\) の応答時間が異常なら、\(s_2,s_3,s_4\)を異常サービスノードとする。続いて、これらのノードと接続するサービス・ホストを追加する。Figure 2(c)のように、異常サービス自身だけでなく、隣接する \(s_1,s_5\) や \(h_1,h_2\) も部分グラフに含めることで、症状を受けたノードと原因候補の両方を残す。 ### 異常部分グラフの重み付け 辺重みは、接続ノード間の挙動の類似度を表す。MicroRCAはPearson相関係数 \(\mathrm{corr}(i,j)\) を類似度として使い、異常辺、異常サービスと正常サービスの辺、異常サービスと正常ホストの辺を別々に重み付けする。 - **異常辺の重み \(w_a\)**: 異常部分グラフ抽出で異常と判定されたサービス間応答時間には、異常検知の信頼度 \(\alpha\in(0,1]\) を一律に割り当てる。異常検知が正確なら高い \(\alpha\)、不確実なら低い \(\alpha\)を選ぶ。 - **異常サービスと正常サービスの重み \(w_n\)**: 異常サービスノードの平均異常応答時間 \(rt^a\) と、正常サービスとの辺の応答時間の相関を使う。例えば、異常サービス \(s_3\)について、\(s_1\)と\(s_3\)の応答時間が、\(s_2\)と\(s_3\)の平均異常応答時間とどれだけ相関するかを重みにする。 - **異常サービスと正常ホストの重み \(w_h\)**: 異常サービスの \(rt^a\) と、配置先ホストのCPU・メモリ・I/O・ネットワーク使用率集合 \(U_h\) の各指標との最大相関を使う。正常サービスの応答時間もホスト資源と強く相関しうるため、異常サービスへ入る辺の重みの平均を補正係数として掛け、サービス症状とホスト資源の類似度を辺重みにする。 異常部分グラフの辺 \(i\rightarrow j\) の重みは、論文のEquation 2に対応して概念的に次のように整理できる。 \[ w_{ij}= \begin{cases} \alpha & \text{辺 }(i,j)\text{ の応答時間が異常}\\ \mathrm{corr}(rt(i,j),rt^a(j)) & i\text{ が正常サービス、}j\text{ が異常サービス}\\ \mathrm{corr}(rt(i,j),rt^a(i)) & i\text{ が異常サービス、}j\text{ が正常サービス}\\ \text{ホスト用の式} & j\text{ が正常ホスト} \end{cases} \] Algorithm 1は、まず異常ノードごとに入辺を走査する。異常辺なら \(\alpha\)、それ以外なら異常ノードの平均異常応答時間との相関を割り当てる。次に出辺を走査し、相手がサービスなら異常ノードの \(rt^a\) と出辺の応答時間との相関を割り当て、相手がホストなら、異常ノードへの入辺重みの平均とホスト資源との最大相関の積を割り当てる。この処理によって、異常サービスが呼び出し関係上は目立たなくても、ホスト資源の異常と結びつく場合に原因候補として残せる。 ### サービス異常スコア 異常サービスノード \(s_j\)には、異常部分グラフ内で周辺ノードへ及ぼす影響を示す平均辺重み \(w(s_j)\)を持たせる。さらに、サービスのコンテナ資源使用率集合 \(U_c(s_j)\)と平均異常応答時間 \(rt^a(s_j)\)の最大相関を組み合わせ、異常スコアを次で定義する。 \[ AS(s_j)=w(s_j)\cdot \max_{u_k\in U_c(s_j)} \mathrm{corr}(u_k,rt^a(s_j)) \] このスコアを高くするのは、異常な応答時間が周辺ノードへ強く結び付き、かつコンテナ資源使用率にも対応しているサービスである。サービスの異常症状だけでなく、資源使用率との対応を加えることで、応答時間の変化が明確でない非計算集約型サービスも、関連する資源や隣接症状と合わせて評価できる。 ### Personalized PageRankによる箇所特定 異常部分グラフで根本原因候補を順位付けするため、Personalized PageRankを使う。遷移行列 \(P\) は、ノードから出る辺の重みを正規化した遷移確率である。個人化ベクトル \(u\) には、異常サービスノードの異常スコアを設定する。PageRankベクトル \(v\)は次の固定点方程式で求める。 \[ v=(1-c)Pv+cu \] ここで \(c\in(0,1)\) はランダムなノードへ戻るテレポート確率であり、典型値として \(c=0.15\)を使う。異常スコアを個人化ベクトルにすることで、ランダムテレポートでも異常サービスノードへより頻繁に戻り、異常に関連する部分グラフへスコアを集中させる。 元のサービス間辺は呼び出し元から呼び出し先へ向いているため、根本原因箇所特定の前に辺を反転する。これにより、異常を示すサービスから、その異常を説明しうる呼び出し元サービスへスコアを伝播できる。PageRankの結果からホストノードを除き、サービスだけのランキングを出力する。Figure 2(e)はこの流れを、異常サービスの抽出、辺重み・異常スコアの付与、反転グラフ上のランキングとして示している。 既存手法と同様にグラフ中心性を利用するが、MicroRCAはサービス呼び出しの相関だけでなく、コンテナ・ホストの資源使用率を重みに取り込む。そのため、呼び出し次数の大きいdominant serviceだけでなく、呼び出し先を持たず、応答時間の異常がフロントエンドへ伝わりにくいleaf serviceも、資源相関を通じて候補にできる。 Figure 1〜Figure 7を本文で参照する。以下は原本から抽出した図表画像であり、図表専用の知識節ではなく、提案手法・実験の根拠として配置する。 **図表抽出1** ![[wiki/sources/_attachments/Wu-et-al.-2020---MicroRCA---Root-Cause-Localization-of-Performance-Issues-in-Microservices/fig-image-001-001.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出2** ![[wiki/sources/_attachments/Wu-et-al.-2020---MicroRCA---Root-Cause-Localization-of-Performance-Issues-in-Microservices/fig-image-001-002.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出3** ![[wiki/sources/_attachments/Wu-et-al.-2020---MicroRCA---Root-Cause-Localization-of-Performance-Issues-in-Microservices/fig-image-005-001.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出4** ![[wiki/sources/_attachments/Wu-et-al.-2020---MicroRCA---Root-Cause-Localization-of-Performance-Issues-in-Microservices/fig-image-005-002.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出5** ![[wiki/sources/_attachments/Wu-et-al.-2020---MicroRCA---Root-Cause-Localization-of-Performance-Issues-in-Microservices/fig-image-005-003.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出6** ![[wiki/sources/_attachments/Wu-et-al.-2020---MicroRCA---Root-Cause-Localization-of-Performance-Issues-in-Microservices/fig-image-005-004.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出7** ![[wiki/sources/_attachments/Wu-et-al.-2020---MicroRCA---Root-Cause-Localization-of-Performance-Issues-in-Microservices/fig-image-005-005.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出8** ![[wiki/sources/_attachments/Wu-et-al.-2020---MicroRCA---Root-Cause-Localization-of-Performance-Issues-in-Microservices/fig-image-005-006.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） **図表抽出9** ![[wiki/sources/_attachments/Wu-et-al.-2020---MicroRCA---Root-Cause-Localization-of-Performance-Issues-in-Microservices/fig-image-005-007.png]] （PDF原本の図表抽出画像。図表番号は本文の参照一覧と原本ページで確認できる。） ## 新規性 MicroRCAの新規性は、サービスレベルの性能症状と、コンテナ・ホストレベルの資源使用率を同じ属性グラフ上の異常伝播モデルに組み込み、アプリケーション計装なしでサービス根本原因を特定する点にある。 - **サービスとホストの異種グラフ**: サービス呼び出し辺だけでなく、サービスから配置先ホストへの辺を作り、同居サービス間のCPU・メモリ競合が症状へ伝わる経路を表す。 - **アプリケーション非依存の異常表現**: 技術スタックごとの内部指標を新たに計装せず、サービスメッシュの応答時間と一般的なコンテナ・ホスト資源を使う。 - **症状と資源の相関**: 異常サービスの応答時間と、隣接サービスの応答時間やホスト・コンテナ資源使用率を相関させ、非自明な異常サービスやleaf serviceを原因候補へ戻す。 - **検知信頼度と中心性の統合**: 異常辺の検知信頼度を重みとして保持し、サービス異常スコアを個人化したPageRankで異常部分グラフ全体へ伝播させる。 - **動的な関係への対応**: サービスメッシュと配置メトリクスから分析時点のグラフを構築するため、頻繁なデプロイで静的依存グラフが古くなる問題を緩和する。 ## 実験設定 ### テストベッドとSock-shop Google Cloud Engine上にKubernetesクラスタを構築し、サービスメッシュ、監視系、マイクロサービスベンチマークSock-shopを配置した。クラスタはマスター1台とワーカー4台からなり、ワーカー3台をマイクロサービス、1台をデータ収集へ割り当てた。クラスタ外のサーバ1台で負荷生成器を動かした。Table Iの構成は次のとおりである。 - マスター: Container-Optimized OS、1 vCPU、3.75 GBメモリ。 - ワーカー4台: 各Container-Optimized OS、4 vCPU、15 GBメモリ。 - 負荷生成器: Ubuntu 18.04.2 LTS、6 vCPU、12 GBメモリ。 - ソフトウェア: Kubernetes 1.14.1、Istio 1.1.5、Prometheus 2.3.1、node-exporter v0.15.2。 Sock-shopは靴を販売する電子商取引サイトを模した13マイクロサービスのベンチマークで、異なる技術で実装されたサービスがREST over HTTPで通信する。front-endはユーザ要求の入口、catalogueは商品カタログ、cartsは買い物かご、userは認証とアカウント情報、ordersはログイン後の注文、paymentとshippingは支払いと配送を処理する。各マイクロサービスは1 vCPUと1 GBメモリに制限し、複製数は1とした。paymentは非計算集約型で通常CPU使用率が50 mHz程度であり、CPU・メモリ障害を強く注入しても応答時間への影響が小さいサービスとして評価上重要である。cartsとordersはCPU・メモリ集約型で、メモリリークがCPUオーバーヘッドも生むため、資源制限との相互作用が現れる。 ### ワークロードとデータ収集 負荷生成器はLocustを使って500同時ユーザを、5つのLocust slaveへ分散してシミュレートし、Sock-shopへ合計約600クエリ毎秒を送った。実ユーザの挙動を反映するため入口のfront-endとcatalogueへ多く、carts、user、ordersへ少ない要求を送る。Table IIの各サービスに対する要求率は、front-end 200 req/s、catalogue 300 req/s、user 50 req/s、carts 50 req/s、orders 20 req/sであり、表上の同時ユーザ数はいずれも100である。 サービスメッシュにはIstioを使い、Istio経由でPrometheusからサービスレベルとコンテナレベルのメトリクスを収集した。ホストレベルのメトリクスはnode-exporterから取得した。Prometheusの収集間隔は5秒である。サービスレベルでは、通信するサービス対ごとの応答時間を収集する。コンテナとホストでは、CPU使用率、メモリ使用量、総送信バイト数を収集する。MicroRCAはこれらを時系列データベースへ送り、応答時間の異常検知と根本原因分析の両方に利用する。 ### 障害注入 評価では、既存研究でも使われる三種類の性能障害をSock-shopへ注入した。 - **Latency**: tcでネットワークパケットを遅延させ、対象サービスの応答時間を200 ms増加させる。 - **CPU hog**: stress-ngでCPUを消費させる。通常CPU使用率が約50 mHzのpaymentには99%の高負荷を与え、その他の対象サービスには95%相当の負荷を与える。 - **Memory leak**: stress-ngでメモリを継続的に確保する。Table IIIでは、対象サービスごとに1〜2個のメモリ割り当て単位を使う設定を示す。cartsとordersのような資源集約型サービスではメモリリークがCPUにも影響する。 障害を含む各実験ケースでは、障害を1分間継続させる。Latencyはfront-end、catalogue、user、carts、orders、payment、shippingの各サービスで、CPU hogとMemory leakはfront-endを除くサービスを中心に注入した。各注入を5回繰り返し、合計95ケースを得た。95ケースは、Latency 7サービス、CPU hog 6サービス、Memory leak 6サービスをそれぞれ5回実行した構成に対応する。各ケースは一つのマイクロサービスに一つの根本原因を持つ。 ### 比較手法と指標 比較対象は、ドメイン知識なしのランダム選択、MonitorRank、Microscopeである。 - **Random Selection (RS)**: 調査していないマイクロサービスから毎回ランダムに一つ選び、原因が見つかるまで続ける。 - **MonitorRank**: カスタムランダムウォークで原因を特定する。外部要因を分類する擬似異常クラスタリングは、今回がマイクロサービス内部障害だけを扱うため実装しない。 - **Microscope**: サービスレベルメトリクスのペアリングからサービス因果グラフを構成し、異常サービスノードを起点に原因を推論する。 MonitorRankとMicroscopeは、異常検知器がpaymentのような非自明な異常を見逃すため、根本原因箇所特定の比較ではMicroRCAの異常検知結果を共有する。これにより、比較は異常検知の差ではなく、異常部分グラフから原因サービスを順位付けする性能に焦点を置く。 評価指標は、正解根本原因が上位k件に含まれる確率 \(PR@k\) と平均適合率 \(MAP\) である。\(PR@k\)は、異常集合 \(A\)の各ケースについて、ランキング中の上位k件に正解集合 \(v_{rc}\)が含まれる割合を、正解原因数を上限にして平均する。高い \(PR@1\)は最初の候補が正解である頻度を、\(PR@3\)は運用者が上位3候補を確認すればよい頻度を表す。MAPはサービス数Nに対する \(PR@k\) をk=1からNまで平均した値であり、ランキング全体の品質を表す。 ## 実験結果 ### 障害種別・サービス別の性能 Figure 3とTable IVは、障害種別とサービス別のMicroRCAの結果を示す。Latencyでは、平均PR@1が0.89、PR@3が1.00、MAPが0.97である。CPU hogでは平均PR@1が0.90、PR@3が1.00、MAPが0.97である。Memory leakでは平均PR@1が0.90、PR@3が1.00、MAPが0.975である。三種類とも、正解サービスをほぼ90%のケースで1位に置き、すべてのケースで上位3件に含めた。 サービス別には、すべてのサービスでMAPが80〜100%の範囲にあり、shippingとpaymentを除けばPR@1も80%を超えた。Latencyでは、front-end、orders、catalogue、carts、paymentのPR@1が1.00、userとshippingが0.60である。CPU hogでは、orders、catalogue、user、shippingが1.00、cartsが0.80、paymentが0.60であり、Memory leakではorders、user、cartsが1.00、catalogue、shipping、paymentが0.80である。PR@3は表の全サービスで1.00だった。 shippingとpaymentの性能が相対的に低い理由を、論文は三つ挙げる。第一に、paymentは非計算集約型で、CPU・メモリを使い切っても応答時間がほとんど変化しない。第二に、shippingとpaymentは要求数が少なく、他サービスを呼び出さないため、応答時間の増加が目立ちにくい。第三に、実験ではこれらの異常を検知するため小さな異常検知閾値を使い、偽アラームが増えた。 ### Baselineとの総合比較 Table Vの全95ケースに対する総合結果は次のとおりである。 - PR@1: RS 0.21、MonitorRank 0.41、Microscope 0.79、MicroRCA 0.89。 - PR@3: RS 0.46、MonitorRank 0.65、Microscope 0.86、MicroRCA 1.00。 - MAP: RS 0.58、MonitorRank 0.73、Microscope 0.85、MicroRCA 0.97。 MicroRCAはMonitorRankに対してPR@1を118%、PR@3を53.2%、MAPを33.7%改善し、Microscopeに対してそれぞれ13.3%、15.9%、14.7%改善した。論文の要約では、これを89%の適合率と97%のMAP、baselineに対する平均13%の適合率改善として報告する。 障害種別ごとの比較では、LatencyでMicroRCAのPR@1が0.89となり、RS 0.17、MonitorRank 0.23、Microscope 0.66を上回った。LatencyのMAPはMicroRCA 0.97、MonitorRank 0.73、Microscope 0.70である。CPU hogではPR@1がMicroRCA 0.90、MonitorRank 0.60、Microscope 0.87、MAPが0.97、0.77、0.92である。Memory leakではPR@1がMicroRCA 0.90、MonitorRank 0.43、Microscope 0.87、MAPが0.98、0.68、0.95である。MicroRCAはLatency、CPU hog、Memory leakのすべてで高い性能を保った。 Figure 4. サービス別比較では、MonitorRankは次数の大きいordersのようなdominant nodeを特定しやすい一方、paymentのようなleaf nodeに弱い。Microscopeは異常サービスを原因候補へ追加していくためleaf nodeには比較的強いが、子サービスからアラームが上がったときのdominant nodeの特定に弱い。MicroRCAは、呼び出し次数の大きいサービスとleaf serviceの双方で、サービス異常と資源相関を組み合わせて順位付けする。 ### 異常検知品質への感度 Figure 5. 異常検知F1-scoreと正解原因の順位を比較すると、異常が正しく検知された場合、三手法とも良い性能を示す。一方、偽アラームが多い場合、Microscopeは根本原因を特定できないケースがあり、MonitorRankは特定できても順位が低くなる。MicroRCAは異常検知F1-scoreが0.4未満の18ケースのうち13ケースで正解原因を1位に置き、他の二手法を上回った。正解が見つからないケースは、比較を見やすくするため順位10として扱った。これは総サービス数を超える順位であり、根本原因を実質的に見失ったことを表す。 ### オーバーヘッド Table VIでは、MicroRCAの計算時間は、5秒のデータ収集間隔でリアルタイム実行できる程度に短いと評価されている。異常検知は8コアで0.01秒、属性グラフ構築は8コアで3.3秒、根本原因箇所特定は8コアで0.03秒であった。主なオーバーヘッドは継続的なデータ収集であり、0.6 vCPUと1511 MBのメモリを消費した。分析自体は短いが、サービスレベルとシステムレベルのメトリクスを常時収集するコストは無視できず、軽量な監視手法が今後の課題となる。 ### 異常検知信頼度 \(\alpha\) と閾値への感度 Figure 6では、異常辺へ与える信頼度 \(\alpha\)を0.15から1.0まで変え、PR@1、PR@2、PR@3、MAPを調べた。PR@1は \(\alpha=0.55\)で最大になり、\(\alpha\geq0.7\)で低下した。PR@3は \(\alpha<0.55\)で常に1.0だが、それより大きくすると低下した。一方、障害種別ごとのMAPは比較的安定して96%以上を保ったため、以後の実験ではPR@1とPR@3が最大となる \(\alpha=0.55\)を使った。実運用では、異常検知器ごとの性能に合わせてこの値を調整する必要がある。 Figure 7では、異常検知モジュールの閾値を0.01から0.1まで変えた。MicroRCAは閾値0.02〜0.065の比較的広い範囲で良好に動作し、三手法とも閾値0.045で良い性能を示したため、以後は0.045を用いた。 ## 考察 MicroRCAが既存のサービス因果グラフ型手法を上回る主な理由は、異常サービスの応答時間だけでなく、そのサービスに関係するコンテナ・ホスト資源を異常伝播の証拠として使う点にある。呼び出し次数の大きいサービスは、異常が多数の子サービスへ伝播するため既存手法でも見つけやすい。しかしpaymentのようなleaf serviceはフロントエンドへ影響しにくく、サービス間応答時間の相関だけでは原因としてスコアが上がらない。MicroRCAは、サービスの応答時間が目立たなくても、コンテナ・ホスト資源との相関や周辺ノードとの異常スコアによって候補へ戻せる。 属性グラフへ同居サービスとホストを含める設計は、サービス呼び出し経路に現れない資源競合を表す。例えば一つのサービスがCPUを使い切ると、同じホスト上の別サービスの応答時間が遅くなる。この場合、異常サービスの直接的な呼び出し次数だけを見ると被害サービスを原因と誤認しうるが、ホスト資源との相関と反転グラフ上のPageRankにより、原因側へスコアを戻せる。 一方、\(\alpha\)と異常検知閾値への感度は、MicroRCAが上流の異常検知品質に依存することを示す。MAPは広い範囲で安定していたが、PR@1・PR@3は異常辺の信頼度に影響され、閾値を小さくしすぎると偽アラームが増える。検知器の誤りを完全に除くのではなく、異常辺の確信度を重みとして保持することで、F1-scoreが低いケースでもMonitorRankやMicroscopeより順位を保ったと解釈できる。 相関による重み付けは、サービス技術の違いを吸収する単純な観測単位を提供するが、相関と因果を区別しない。異常サービスと資源使用率が同時に変化しても、それだけで資源が原因だとは限らない。したがって、MicroRCAの出力は自動修復の命令ではなく、運用者が調査すべきサービス候補の絞り込みとして利用するのが適切である。 ## 強み / 弱点・課題 ### 強み - アプリケーションソースコードへの計装なしで、サービスメッシュと一般的な資源メトリクスから診断できる。 - サービス呼び出し経路と、同じ仮想マシンへ配置されたサービス・ホストの関係を一つの属性グラフで扱える。 - サービス応答時間、コンテナ資源、ホスト資源を相関させ、dominant serviceとleaf serviceの両方を評価できる。 - Personalized PageRankに異常サービススコアを与え、異常部分グラフ上の影響を根本原因候補側へ伝播できる。 - 95ケースの評価でPR@1 0.89、PR@3 1.00、MAP 0.97を達成し、RS、MonitorRank、Microscopeを上回った。 - 属性グラフ構築3.3秒、原因箇所特定0.03秒という短い分析時間で、5秒間隔の監視へ組み込める。 ### 弱点・課題 - Kubernetes、Istioなどの構成ではサブ秒間隔の監視が難しい。5秒の収集間隔より速く異常が伝播する場合、そのサービスを異常として検知できない。 - データ収集は0.6 vCPUと1511 MBのメモリを消費し、分析計算より大きなコストになる。軽量監視への置き換えが必要である。 - サービスメッシュから見えない依存関係、共有メモリなどの非通信依存、応答時間へ現れない性能異常は属性グラフに入らない。 - 相関係数を類似度・影響度として使うため、交絡や共通負荷による同時変化を因果関係と区別できない。Personalized PageRankも因果グラフの同定ではなく、重み付き中心性による順位付けである。 - 異常辺の信頼度 \(\alpha\)と異常検知閾値へ感度があり、検知器の特性に応じた調整を要する。paymentやshippingのように要求数が少なく応答時間の異常が目立たないサービスでは、偽アラームや低いPR@1が生じた。 - 評価は一つのSock-shopベンチマーク、三種類の障害、単一サービスへの単一障害95ケースに基づく。複数同時障害、実運用での未知障害、複数原因の識別はこの評価からは確認できない。 - 出力対象はサービスであり、CPUやメモリを消費した具体的なプロセス・設定変更主体まで特定するものではない。将来課題として、性能劣化の自動修復も挙げられている。 ## 出典 - [[.raw/papers/Wu-et-al.-2020---MicroRCA---Root-Cause-Localization-of-Performance-Issues-in-Microservices.pdf]] - [[.raw/papers/Wu-et-al.-2020---MicroRCA---Root-Cause-Localization-of-Performance-Issues-in-Microservices.txt]]