## メモ 問題意識: マイクロサービス化による複雑性向上。外部（例えば、コンフィグレーションの変更）と内部（例えば、ソフトウェアのバグ）の障害のために、パフォーマンスの問題は珍しくない。[14]によるとAmazonでは1リクエストあたりの応答時間が100ミリ秒遅れると売上が1%減少するのに対し、Googleでは応答時間が500ミリ秒遅れると売上が20%減少すると報告されている。 [14] Ibidunmoye, O., Hern´andez-Rodriguez, F., Elmroth, E.: Performance anomaly detection and bottleneck identification. ACM Comput. Surv. (CSUR) 48(1), 4 (2015) マイクロサービスにおけるパフォーマンス上の問題を検知し、根本的な原因を特定する必要がある。 ### 問題意識 - **Complex network dependencies.** - **Continuous integration and delivery.** Puppetのレポート[1]によると、企業は年間1600回のアップデートを行っている可能性がある。([1] [https://puppet.com/blog/2017-state-devops-report-here](https://puppet.com/blog/2017-state-devops-report-here)) 異常検知と根本原因診断の手順がこれらの変化に適応しなければならない。 - **Dynamic run-time environment.** - **A large volume of monitoring metrics.** 論文[23]によると、Netflixでは200万件、Uberでは500万件、OpenStackでは17608件のメトリクスを監視している ([23] (Thalheim, J., et al.: Sieve: actionable insights from monitored metrics in distributed systems. In: Proceedings of the 18th ACM/IFIP/USENIX Middleware Conference, pp. 14–27. ACM (2017)) ### 先行研究の課題 X-Trace[12]やRoot[15]などは、アプリケーションやプラットフォームのソースコードを変更する必要があったり、CauseInfer[7]はダイナミックな環境に適応できなかったりする。 ### 提案手法 マイクロサービスシステムに対するパフォーマンス問題を特定し、原因グラフを用いて根本原因を推論する新しいシステムを提案する。データ収集、因果関係グラフ構築、原因推論の3つの手順で構成されている。フロントエンドサービスで異常が検出されると、異常の伝播経路を示す因果関係グラフが自動的に構築される。その後、原因推論手順が起動され、原因グラフを用いて根本原因を特定します。因果関係グラフはドメイン知識を必要とせず、アプリケーションをインストルメンテーションすることで構築される。Microscopeは、ブルートフォース検索ではなく、根本原因を特定するために条件付きグラフトラバースアルゴリズムを活用しており、処理するパフォーマンスメトリクスの量を大幅に削減する。 - 利用している [[条件付き独立性検定]]は、[[G2検定]]。 - Gaussian 独立性検定？ のような手法の代わりににG2検定。 - 確率変数の分布に仮定を置く必要がないため。 - [[2007__Estimating High-Dimensional Directed Acyclic Graphs with the PC-Algorithm]] - significance level 0.02 ### 貢献 - ネットワーク関連のシステムコールをキャプチャして解析することで，実サービスインスタンスの依存性をリアルタイムに自動的に捉えることができる新しいサービス依存性発見手法を提案する． - サービス依存性グラフとサービス影響グラフを1台のマシンに同居させて並列化したサービス因果関係グラフ構築手法を提供する．この因果関係グラフを用いて、サービスインスタンスレベルでの根本原因を正確に特定できる。 - ドメイン知識やアプリケーションの計測器を使わずに性能問題の根本原因を推論するMicroscopeのプロトタイプを設計・実装し、低コストで高精度・高想起を実現する。 ## 実験 ### 環境 - 12-core 2.40GHz CPU, 64GB of memory and runs with Ubuntu 16.04 OS - Kubernetes - ネットワーク接続情報をローカルのログファイル → Filebeat → elasticsearch - Prometheusでリクエストレイテンシを計測 インターバルは1秒 - マイクロサービスデモ環境としてSock-shopを利用。13 services - CPU resource limited to 1 GHz, memory resources limited to 1GB. - The replicas of service instances are set to 1–3. total 36 - sock-shopの負荷生成でQPS about 5000 ### Fault Injection コンテナに故障を注入する。 (1) CPU exhausting: we use stress [3], a deliberately simple workload generator for POSIX systems, to exhaust CPU resources in injected containers; (2) NetworkJam: we use “tc”, a traffic control tool in Linux, to delay the network packets; (3) ContainerPause: for simulating the status of hangup of a service instance, we pause the container with“PAUSE” command of Docker. 各サービスインスタンスに5回以上、1分以上注入。フォールト注入の総数は240回。 評価指標 - Precision at top K(PR@K): 推論が発動した場合に、根本原因がランキングリストの上位 K に現れる確率を示す。Kの値を小さくして根本原因を捉えることが重要であり、その結果、調査するサービスインスタンスの数を少なくすることができます。ここでは、K=1,2,3を使用します。 - Recall at top K (Recall@K): ランキングリストのトップKで検索された真の原因のうち、障害注入の総量に占める割合である。ここでは，K=1,2,3 とする． ### 有効性の評価 ![[Microscope Pinpoint Performance Issues with Causal/ScreenShot_2020-07-20_at_2.32.58_PM.png]] ![[Microscope Pinpoint Performance Issues with Causal/ScreenShot_2020-07-20_at_2.32.39_PM.png]] - PR@1のほとんどが70%から100%の範囲内に収まった - 例外1: ネットワークとコンテナの一時停止に関しては，shippingサービスとorderサービスの結果が得られていない - (i)サービスの遅延はDockerコンテナ内のプロセスによって収集される - (ii)これらのサービスは他のサービスを要求しないので、サービスの遅延はコンテナのネットワークを通過せずにプロセスからすぐに返される - (iii)プロセスではなくコンテナ内のネットワークをブロックするためにネットワーク遅延を注入している - 例外2: CPU exhausting: - (i)上述した原因推論がトリガーされない可能性があること - (ii)出荷と支払いの両方が計算集約的ではないこと、これらのサービスインスタンスでのCPU使用量がわずか5MHzであることに起因 (SLO違反しないような故障の注入であれば、そもそも対応をする必要もないので無視すればよいのではないか) 計算集約的でネットワークに敏感なサービスに対して平均 80～95%の精度とリコールを達成。 ### 他のアルゴリズムとの比較 TAN [9], NetMedic [18], [[2018__Middleware__Sieve Actionable Insights from Monitored Metrics|Sieve]] [23], Roots[15], [[2014__INFOCOM__CauseInfer―Automatic and distributed performance diagnosis with hierarchical causality graph in large distributed systems|CauseInfer]] [7], [[2013__PER__Root Cause Detection in a Service-Oriented Architecture|MonitorRank]] [19], and [[2018__CCGRID__CloudRanger―Root Cause Identification for Cloud Native Systems|CloudRanger]] [24]. - TANとの比較では、サービス依存性構築をTree Augmented Bayesian Networkに置換 - NetMedic との比較では、サービス依存性を推定するために NetMedic の状態相関アプローチを活用 - Sieve との比較では、静的なサービスコールグラフ（双方向グラフ）を取得するために sysdig を採用し、応答時間メトリクスを持つ動的なサービス依存性を取得するために Granger Causality を活用 - CauseInfer との比較では、ネットワークパケットをキャプチャし、ラグ相関を利用してサービスの依存性を発見 - MonitorRank との比較では、前作[24]で実装したランダムウォークアプローチを利用して根本原因を発見 - CloudRanger との比較では、PC アルゴリズムを利用してマイクロサービスの応答時間メトリクスを用いてサービスの依存性を構築 - PR@1 では Microscope の方が CauseInfer よりも 3%高く、CloudRanger よりも 13%高く、Roots よりも 35%高い結果が得られている。 - CauseInfer、CloudRanger、Sieveと比較すると、Microscopeは統計的な相関関係を計算するのではなく、ネットワーク接続のイベントを分析することで、サービスの定義を構築しているので、よりGround truthに近い。 - Microscopeはランク 1 で 88%の注入された故障を発見 ### Discussion **Overhead** ![[Microscope Pinpoint Performance Issues with Causal/ScreenShot_2020-07-20_at_4.02.46_PM.png]] **Sensibility** - データ長が 200 以下の場合には、精度やリコールが低いレベルに留まっている - PC アルゴリズムで計算したサービス因果グラフの精度が低いため **Scalability** - 36 個のサービスインスタンスから 120 個のサービスインスタンスへの精度低下は 7%にとどまる （実行時間は変化するのか？） --- 以下はDeepLによる翻訳 ## Abstract > Abstract. Driven by the emerging business models (e.g., digital sales) and IT technologies (e.g., DevOps and Cloud computing), the archi- tecture of software is shifting from monolithic to microservice rapidly. Benefit from microservice, software development, and delivery processes are accelerated significantly. However, along with many micro services running in the dynamic cloud environment with complex interactions, identifying and locating the abnormal services are extraordinarily diffi- cult. This paper presents a novel system named “Microscope” to identify and locate the abnormal services with a ranked list of possible root causes in Micro-service environments. Without instrumenting the source code of micro services, Microscope can efficiently construct a service causal graph and infer the causes of performance problems in real time. Experimental evaluations in a micro-service benchmark environment show that Micro- scope achieves a good diagnosis result, i.e., 88% in precision and 80% in recall, which is higher than several state-of-the-art methods. Meanwhile, it has a good scalability to adapt to large-scale micro-service systems. 新たなビジネスモデル（デジタルセールスなど）とIT技術（DevOpsやクラウドコンピューティングなど）に牽引され、ソフトウェアのアーキテクチャはモノリシックからマイクロサービスへと急速に移行しています。マイクロサービスの恩恵を受け、ソフトウェア開発、配信プロセスが大幅に加速されています。しかし、複雑な相互作用を持つダイナミックなクラウド環境では、多くのマイクロサービスが稼働しているため、異常なサービスを特定して特定することは非常に困難である。本論文では、マイクロサービス環境における異常なサービスを特定し、根本原因の可能性のあるサービスをランク付けして特定する「マイクロスコープ」という新しいシステムを紹介する。マイクロサービスのソースコードをインストルメントすることなく，サービスの原因グラフを効率的に構築し，リアルタイムにパフォーマンス問題の原因を推論することができる．マイクロサービスのベンチマーク環境での実験評価では、Microscopeは、精度88％、リコール80％と、いくつかの最先端の手法よりも高い診断結果を達成しています。また、大規模なマイクロサービスシステムにも適応できるスケーラビリティを持っている。 --- [[2018__ICSOC__Microscope―Pinpoint Performance Issues with Causal Graphs in Micro-service Environments__translations]]