AKS上のIstioデモアプリにJmeterで負荷かけてみた

以前、AKS上にIstioのBookinfoサンプルアプリをデプロイして、PrometheusとJaegerによる監視について検証をした。
kashionki38.hatenablog.com

負荷がけと準備
- Jmeterシナリオ
- ボトルネック仕込み
監視：サービスメトリクス（RED）
監視：リソースメトリクス（USE）
- Prometheus Pod Stats & Info
- Prometheus 1 Node Exporter for Prometheus Dashboard
まとめ

今回は、このアプリに対してJmeterで実際に負荷をかけてみて、どのようにそれぞれのダッシュボード上で負荷を観測できるのかを検証してみた。ただ負荷をかけるとだけだと面白くないので、ボトルネックを意図的に仕込んでみて、用意した監視ツールでどういうふうに観測できるのか、どうやって真因にたどり着くのか、を検証することにした。

負荷がけと準備

Jmeterシナリオ

今回はJmeterでproductpageにgetリクエストをひたすら投げるシナリオを作成した。
※言わずもがな超々シンプルです。 f:id:kashionki38:20200323021635p:plain

ボトルネック仕込み

ボトルネックを用意しておかないと面白くないので、reviews-v3のCPU limitsを0.05に引き下げて実施した。

- apiVersion: extensions/v1beta1
  kind: Deployment
      app: reviews
      version: v3
    name: reviews-v3
(中略)
  spec:
    template:
      spec:
        containers:
        - image: docker.io/istio/examples-bookinfo-reviews-v3:1.15.0
          resources:
            limits:
              cpu: 50m
            requests:
              cpu: 50m
(中略)

監視：サービスメトリクス（RED）

まずは、サービスとしてのSLA系のメトリクスのダッシュボード。Istio導入時のBuilt-inが結構良かったのでそのまま使っている。

Prometheus Istio Mesh Dashboard

サービス全体を見れるIstio Mesh DashboardがそれぞれのサービスについてのSLA値（リクエスト数、レイテンシ、Success Rate）が見れるため、瞬間瞬間のREDを確認しているには適している。
f:id:kashionki38:20200323013708p:plain

Success Rateが100％未満になったときには緑から色が変わるのでわかりやすくなる。
まずはこのSuccess Rateとレイテンシを見ておくのが重要だと思う。

f:id:kashionki38:20200323015054p:plain この例だと、P90 Latencyを見ると、reviews-v3とproductpage-v1のレイテンシが遅延していることがわかる。
この値をベースに各性能試験の自動評価は簡易に実装できるなーと思った。

Prometheus Istio Workload Dashboard

Istio Mesh Dashboardで悪い値が出たり、それぞれのサービスに関する時系列値の推移を見たくなったりしたが、Istio Workload Dashboardが便利。

いつから遅延し始めたのか、その際にトラフィックも高かったのか、どういったHTTPエラーがどれくらい返っているのかなど、基本的な情報を把握することができる。
f:id:kashionki38:20200323014258p:plain
f:id:kashionki38:20200323014439p:plain

Jaeger

遅延時の追い方は色々あると思うが、今回は折角トレーシングツールとしてJaegerが入っているので、Jaegerでどう表示されるのかを見てみた。
（このために、バックエンドのreview-v3をボトルネックにした笑）

producpageのServiceに絞ると、だいたい2secほどで推移していることがわかる。
f:id:kashionki38:20200323015433p:plain

実際にトレースのサンプルを開いてみると、productpageの2secのうち、1.93secはreviewsで費やされていることがわかる。 f:id:kashionki38:20200323015549p:plain

ちなみに、こんな感じの表示もできる。
f:id:kashionki38:20200323015751p:plain
f:id:kashionki38:20200323015803p:plain

ここまでで、productpageとreviews-v3が遅延しているが、真犯人はreviews-v3であり、productpageはそれを呼んでいるから煽りを食らっているだけという仮説を立てることができるはずだ。

監視：リソースメトリクス（USE）

Prometheus Pod Stats & Info

これは以前の記事で書いたが、別で導入したpod用のダッシュボード。
grafana.com kashionki38.hatenablog.com

それぞれのpodのリソース使用量、Requests、Limitsが可視化される。

今回だと、reviews-v3がボトルネックっぽいという仮説が立っているのでまずはreviews-v3のpodリソース使用状況を確認するだろう。
すると、こんな感じで見事reviewsコンテナのCPU使用量がLimitsまで張り付いていることがわかる。 f:id:kashionki38:20200323020319p:plain