[[2021__ACSOS__Causal Inference Techniques for Microservice Performance Diagnosis - Evaluation and Guiding Recommendations]] ![[Pasted image 20220602104425.png|600]] 図4に示すように、[[Kubernetes]]を使用してテストベッドを作成し、マイクロサービスベンチマークと監視ツール一式をデプロイしています。Kubernetesクラスタには、1つのマスターノードと複数のワーカーノード（sock-shopは4つ、train-ticketは6つ）があり、そのうち1つはデータ収集専用、残りはマイクロサービス用となっています。クラスタ内の各ワーカノードは、4vCPUと15GBのメモリで構成されています。また、クラスタ外の仮想マシン1台（6vCPU、12GBメモリ）がロードジェネレータを稼働させます。今回の展開では、フォルトを注入するマイクロサービスに対して、CPUリソースを1vCPU、メモリを1GBに制限し、レプリケーション係数を1に設定しています。 ロード・ジェネレータ 分散型オープンソースの負荷テストツールである[[Locust]]を使用して閉ループ負荷ジェネレータを開発し、ベンチマークごとにアプリケーションでの同時ユーザーをシミュレートします。実際のユーザーの挙動を反映させるため、ワークロードをカスタマイズしています。例えば、sock-shopでは、エントリーポイントのフロントエンドとカタログにはより多くのリクエストを送り、ショッピング、カート、ユーザー、注文のサービスにはより少ないリクエストを送ります。合計で1秒間に450〜600のクエリを両ベンチマークに供給しています。 データ収集 マイクロサービス向けのサービスメッシュ[[Istio]]、コンテナ向けのCadvisor、サーバーノード向けのnode-exporterなどの監視ツール群を用いて、テストベッドの複数の層からメトリクスを収集しています。一方、[[Prometheus]]は、上記のツールからメトリクスを収集するために配置され、使用するツールの既存のバージョンで私たちのテストベッドで実現可能な最高の監視頻度である5秒ごとにメトリクスをスクレイピングするように構成されています。 ### D. Benchmarks, Injected Faults, and Evaluation Metrics 評価は，マイクロサービスベンチマークに対するフォールトインジェクション実験で収集したメトリクスデータに基づいている． ベンチマーク 代表的なマイクロサービスベンチマークとして，靴下を販売するeコマースサイトと乗車券予約システムを模擬した[[Sock Shop]]と[[TrainTicket]]（マイクロサービスベンチマークの中では最大級）を選択した．Sock-shopは13のマイクロサービスからなり、train-ticketは41のマイクロサービスからなる。どちらもポリグロット（Java, golang, Node.jsなど）で、HTTP上のRESTで通信を行う。sock-shopと比較すると、train-ticketは伝搬経路が長く、より多くのメトリクスが公開されています。 注入されたフォルト (1)遅延：tcというトラフィック制御ツールを使ってネットワークパケットを遅延させる．(2) CPU占有率：計算機システムに負荷をかけるツールstress-ngを使って、CPUリソースを枯渇させています。sock-shopの決済のような非コンピュートインテンシブなマイクロサービスでは、99%、その他のマイクロサービスでは95%という高い使用率でCPUを使い果たすことができました。(3) メモリリーク: stress-ngを使用して、継続的にメモリを割り当てました。sock-shopのcartとorderのようなメモリ集中型のマイクロサービスでは、メモリ使用量が多いとCPU使用量も多くなるため、メモリリソースを使い切るために1VMのみを用意し、他のマイクロサービスには2VMを用意しました。 マイクロサービスにパフォーマンス問題を注入するために、上記のフォールト注入ツールを導入して既存のDockerイメージを更新し、コンテナ内で対応するコマンドを実行して異常をトリガーします。各異常は1分間続き、システムは次の注入の前に5分間のコールドダウンが必要です。一般性を高めるため、各障害とサービスに対して3-5回注入プロセスを繰り返します。