## Memo - [[2021__SIGSOFT__Faster, deeper, easier - crowdsourcing diagnosis of microservice kernel failure from user space|Pan+, SIGSOFT2021]]を発展させたジャーナル版 - [[北京大学のAIOps研究グループ]] - [[Pymicro]]を使用 ## Structure ### 1. Standpoints - 本論文は、クラウドプラットフォームを使用するマイクロサービスの障害原因診断を目的とする。 - カーネルが特殊な意味で使われている。カーネル(空間)とは、クラウドプラットフォーム側を意味し 、ユーザー空間とは、クラウドユーザー側を意味する。カーネルサービスとは、クラウドプラットフォームが提供し、管理するサービスである。 - クラウドプラットフォームでは、低レベルなメトリクスをユーザーが取得できなかったり、メトリクスではなくログのみの基盤が提供されているケースにDyCauseは着目している。 - 同じクラウドプラットフォームにデプロイされている複数のアプリがカーネルサービスを介して呼び出す場合、ユーザー空間情報のみからクラ ウドカーネルの状態を推定する必要がある。 - ![[Pasted image 20230412120340.png|400]] - 図１では、App1の開発者はコールドチェーン上のカーネルサービスs2が原因であることをユーザー空間データから推定しなければならない。 - 前提条件 - 各アプリはプライバシーを保護するために、集約された時系列データのみを共有し、メトリクスデータ以外を使用しない。ユーザー空間からアクセス可能なプリミティブな情報（APIリクエストログ、パフォーマンスメトリクスなど）を使う。線形補間する。 - 異常伝搬時間は数分を仮定 ### 2. Contributions 1. クラウドソーシングのフレームワークを使用することを提案 - 各アプリ内に分散データ収集プロキシを展開することで、アプリ開発者はカーネル空間の性能指標にアクセスでき、ユーザー空間から診断できる 2. クラウドソーシングの指標からサービスの相関を正確に特徴付けるために、[[Granger因果性|グレンジャー因果]]を用いたサービス間の動的な因果関係の概念と、それを生成するスライディングウィンドウベースの統計アルゴリズムを提案する。 3. 動的な因果関係を調べることで、最適な根本原因特定アルゴリズムを設計する。 ### 3. Major Ideas 1. クラウドソーシングによるメトリックの収集：各アプリケーションが専用のAPIプロキシを使用してカーネルAPIの呼び出しを記録し、そのログを集中型のDyCauseデータストアに送信する。ログをカーネルサービスのメトリクスデータに集約する。生成されたメトリクスデータのみを共有するため、各アプリのプライバシーは保護される。 2. 異常区間の検出： [[SPOT]]を使う。 - ほとんどのメトリクスで、低いほど良い。したがって、我々は高い閾値のみを計算する。 - SLIメトリクスのみの異常を検知するのではなく、異常サービスの個数が指定の割合を超えると、障害として検出される。 - 異常タイムスタンプの前後のデータのウィンドウがそれぞれ含まれる。 3. 時間的な動的因果（DCC）の発見： まず、多くのスライディングウィンドウで因果関係を検証することにより、動的なサービス相関を分析し、動的因果曲線（DCC）を生成する。その後、各アプリは、これらの曲線を局所的に集約し、カーネル間の依存関係を特徴付ける局所相関グラフを推定する。 - Discovery of causal time intervals論文によると、Granger因果では、短期間でしか有意でないことがある。そこで、２つの線形回帰モデル（片方の完全なモデルはより独立な変数をもつ）を構築する。 - ![[Pasted image 20230412145144.png|600]] - 図４のテストがパスする区間をグレンジャー因果区間とする - 不要な計算を刈り取りながら、サイズや位置の異なる多くのスライディングウィンドウでグレンジャー因果性をテストする。 - 全体的に、異常区間を正確に特定し、時間的な伝播の順序を明らかにしている。 - 計算量 ![[Pasted image 20230412145613.png|200]] - メトリクスペアに対するDCCを求めた後に、サービスペア単位のDCCの合計から適応的に決定された閾値をもとに依存関係グラフを構築する。 - エッジの重みとして、絶対ピアソン相関係数を用いて類似度を測定する 4. クラウドソーシングによるグラフの融合： 複数のアプリの情報を組み合わせる。アプリの局所相関グラフを収集し、1つの共有相関グラフに融合させる。プライバシー保護のため、アプリのローカル相関グラフを保存し、診断のためにアプリに共有相関グラフのみを提供する。 5. バックトレースによる根本原因解析： 融合相関グラフのバックトレース検索を行い、異常伝播経路の可能性を列挙し、根本原因サービスリストを作成する。 - スコアはフロントエンドサービスへのパスの数に比例する。 - バックトレース検索には、[[BFS]]を用いる。 - ピアソン相関 ### 4. Experimental design & Results - [[Pymicro]]とIBM Cloudのデータセットを用いる。 - Pymicro - マイクロサービス数は16-32、根本原因の数は1から4であり、主なメトリクスはサービス遅延である。 - IBM Cloud - 各インシデントについて、1500近くのサービスAPIの2時間のリクエストログを記録する - 評価指標は、PR@KとRankScoreを使う。RankScoreは[[2018__IPCCC__FacGraph - Frequent Anomaly Correlation Graph Mining for Root Cause Diagnose in Micro-Service Architecture|FacGraph]]、[[2009__CSMR__Automatic Failure Diagnosis Support in Distributed Large-Scale Software Systems based on Timing Behavior Anomaly Correlation|TBAC]]の提案を拡張し、複数の根本原因をサポートする。 - ![[Pasted image 20230412183509.png|400]] - ベースラインは次の３種類のカテゴリから5個選択されている。 - コールログ依存は、[[2009__CSMR__Automatic Failure Diagnosis Support in Distributed Large-Scale Software Systems based on Timing Behavior Anomaly Correlation|TBAC]]と[[2013__PER__Root Cause Detection in a Service-Oriented Architecture|MonitorRank]] - テンプレートを用いたサービス依存グラフを構築する [[2009__SIGCOMM__Detailed Diagnosis in Enterprise Networks|NetMedic]] - 因果探索アルゴリズムを用いる [[2018__ICSOC__Microscope―Pinpoint Performance Issues with Causal Graphs in Micro-service Environments|Microscope]]と[[2018__CCGRID__CloudRanger―Root Cause Identification for Cloud Native Systems|CloudRanger]] - 依存グラフの可視化 - 図10と表３は、Dycauseの依存グラフをPCアルゴリズムとGranger因果に置き換えたときのものである。PCは精度が0であり、GCで0.6前後である。PCは有意水準に関わらず0である。GCはエッジの多いグラフを生成する。 - ![[Pasted image 20230412184613.png|400]] - ![[Pasted image 20230412183657.png]] - パラメータ - SPOT: 最初の3600秒のメトリクスで初期化し、q = 0.001, d = 300 - PCのαは{0.05, 0.1, 0.2} - PCMCIと依存 関係リンクの有意な値は、0.05と0.001 - 実験結果 - PymicroではPR@5で因果探索+ランダムウォークタイプの手法が100%に近いスコアとなっている。IBM CloudのデータでもCloudRangerやMonitorRankはPR@5が0.8を超えている。 - 実行時間は、図14にあるように、データ長が7200secでもDyCauseが高速である。MonitorRankとCloudRangerだけが遅い。 ![[Pasted image 20230412185716.png]] - データの解像度が高くともDyCauseは高い性能となっている。（理由は書かれていない） ### 5. Discussions & Limitations - ### 6. Thoughts - 今どきのパブリッククラウドは、インフラ層がサービス化されていて、データにアクセスできないという最近の事情を反映している。しかし、マイクロサービスを採用する大きなシステムだと、Kubernetesを採用していて、cAdvisorなどKubernetesが取得できるレベルの粒度のデータが取得でき、かつ、監視基盤も整っているはず。現実に存在する問題設定なのかが気になった。IBM Cloudではあるのかもしれない。 - 精度が全体的に高いのはサービス粒度で特定しているためで、より小さい粒度だと精度は落ちるのではないか？ - 図14左図からわかるように、DyCauseが他手法と比べて圧倒的に良い精度をだしているわけではないようにみえるが、リアルデータでPR@5 98.3と100%に近い性能をだしていることがすごい。 - 図４のGranger因果が短期間でないと有意にならないケースがあることをはじめて知った。 ## Abstract 今日、クラウド上の多くのWebアプリケーション（アプリ）は、マイクロサービスに基づいて構築されています。しかし、異常が非常に動的で複雑な方法で伝播するため、それらのトラブルシューティングは課題だらけになっています。既存の診断方法は、ほとんどがマイクロサービスのシステムカーネルから取得したモニタリングメトリクスに基づいて設計されています。そのため、アプリケーションの所有者やサイトの信頼性エンジニア（[[notes/sre/SRE]]）であっても、マイクロサービスシステムにそのような包括的な監視インフラがない場合、それらの手法に効果的に頼ることができません。本論文では、非対称な診断情報の問題に対するクラウドソーシングソリューションであるDyCauseを開発します。本ソリューションは、ユーザ空間から協調的にカーネルサービスの稼働状況を収集し、オンデマンドで診断が開始される。アーキテクチャや機能的なインフラを必要としないため、DyCauseはマイクロサービスシステムにおいて高速かつ軽量に展開することが可能である。また、異常発生時のサービス間のきめ細かな動的因果関係を発見するために、統計解析に基づく効率的なアルゴリズムを設計しています。このアルゴリズムに基づき、マイクロサービスシステム内の異常伝播経路を分析し、より解釈しやすい診断結果を生成することも可能である。評価では、制御されたシミュレーション環境と実環境のクラウドシステムでDyCauseをテストしました。その結果、DyCauseはいくつかの最新手法の中で最も精度と効率が高く、パラメータの面でもよりロバストであることが示された。 [[2023__TDSC__DyCause - Crowdsourcing to Diagnose Microservice Kernel Failure__translations]]