More Related Content Similar to Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Similar to Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料) (20) More from NTT DATA Technology & Innovation
More from NTT DATA Technology & Innovation (20) Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)1. © 2020 NTT DATA Corporation
Kubernetesでの性能解析
~なんとなく遅いからの脱却~
2020/08/26 Kubernetes Meetup Tokyo #33
NTT DATA 技術革新統括本部 デジタルテクノロジ推進室 まかせいのう
堀内 保大, Yasuhiro Horiuchi (@ka_shino_ki)
2. © 2020 NTT DATA Corporation 2
Agenda
1. Who am I?
2. 概要
– デモアプリと実施していること
– 性能試験のための基盤
3. Kubernetesでの性能解析の始め方
– Metrics by Prometheus
– Logging by Loki
– Tracing by Kiali / Jaeger
4. 解析事例
3. © 2020 NTT DATA Corporation 3
Who am I?
• 堀内 保大, Yasuhiro Horiuchi
• NTT DATA 技術革新統括本部 デジタルテクノロジ推進室
“まかせいのう”
• https://www.nttdata.com/jp/ja/lineup/macaseinou/
• 業務:性能全般幅広く
• 特に性能試験 / 性能問題解決 / Global向けプリセールス
• Kubernetes歴半年
https://kashionki38.hatenablog.com/
(Hatena)
@ka_shino_ki (Twitter)
kashinoki38 (GitHub)
4. © 2020 NTT DATA Corporation 4
What’s まかせいのう
・“性能はまかせろ“ → まかせいのう
・創業12年の実績から、試験方法論や監視観点、解析プロセスを整備
・性能に関して一気通貫で上流から下流まで対応
・海外グループ会社にも展開中 macaseinou!
もし何か性能でお困りごとあれば何でも!まずはご連絡ください!
https://www.nttdata.com/jp/ja/lineup/macaseinou/
5. © 2020 NTT DATA Corporation 5
What’s まかせいのう
https://www.nttdata.com/jp/ja/lineup/macaseinou/
く
ら
う
ど
ね
い
て
ぃ
ぶ
始
め
ま
し
た
・“性能はまかせろ“ → まかせいのう
・創業12年の実績から、試験方法論や監視観点、解析プロセスを整備
・性能に関して一気通貫で上流から下流まで対応
・海外グループ会社にも展開中 macaseinou!
もし何か性能でお困りごとあれば何でも!まずはご連絡ください!
6. © 2020 NTT DATA Corporation 6
本スライドの目的、モチベーション
• Kubernetesないしコンテナは性能解析かんたんじゃないですよ
ね?
• NodeやPodのリソース監視
• GCとか同時実行数などMWのリソース監視
• ログ
• Tracing
• 問題が起きたときにどうしてますか?
• CPUが高騰した際の原因分析できてますか?
• usr? sys?
• GCなの?
• APのなにかの関数なの?
• 本スライドでは上記のような性能解析の基礎をKubernetesでも実
施できる方法論を網羅的に紹介したい
8. © 2020 NTT DATA Corporation 8
概要
デモアプリと実施していること
Sock Shop
• https://microservices-demo.github.io/
• Weaveworksのマイクロサービスデモアプリ
• 靴下のECサイト
• 公式GitHubは古いので、K8s v1.16への対応が必要
↓
https://github.com/kashinoki38/microservi
ces-demo
実施していること
• GKE上にSock Shopをデプロイし、
Observabilityを実装→負荷試験実施→解析
9. © 2020 NTT DATA Corporation 9
概要
性能試験のための基盤
Test Environment
Prometheus
Logging
sock-
shop
istio-system
monitoring
jmeter
Metrics
Tracing
負荷がけ
サンプルアプリ
Grafana
10. © 2020 NTT DATA Corporation
Kubernetesでの
性能解析の始め方
11. © 2020 NTT DATA Corporation 11
性能解析の始め方→Observability
Observabilityを揃えることから始める
• Metrics → Prometheus
• 重要性:従来の監視と同概念。サービスのSLA状況、サーバがリソース状況の把握しFactベースで
真因に迫る
• 観点
• サービスに関する指標(RED)
• ソースに関する指標(USE)
• Logging→Loki
• 重要性:基本的に永続化されない。kubectl logsじゃきつい
トラシューしたいときに残っているようにしたい
• 観点
• エラーメッセージ、レスポンスコードとの関連
• 時系列でのエラー量
• Tracing→
• 重要性:MSA数珠つなぎでややこしい
E2Eで遅くても原因のサービスにたどり着けない
• 観点
• サービス間の連携グラフとレイテンシ、スループット、エラー率のマップ
• 分散トレーシング(各サービスのレイテンシの包含関係)
https://peter.bourgon.org/blog/2017
/02/21/metrics-tracing-and-
logging.html
Observabilityの3本柱
12. © 2020 NTT DATA Corporation 12
Metricsって何を見ないといけないのか?
13. © 2020 NTT DATA Corporation 13
Metricsって何を見ないといけないのか?
• サービス監視(RED)
• Rate : =Throughput, 秒間リクエスト数, 秒間PV数
• Error Rate : エラー率, 5xxとか
• Duration : =ResponseTime, %ile評価が一般的
• リソース監視(USE)http://www.brendangregg.com/usemethod.html
• Utilization: 使用率 E.g. CPU使用率
• Saturation : 飽和度, どれくらいキューに詰まっているか
E.g. ロードアベレージ
• Errors : エラーイベントの数
14. © 2020 NTT DATA Corporation 14
Metricsって何を見ないといけないのか?
• サービス監視(RED)
• Rate : =Throughput, 秒間リクエスト数, 秒間PV数
• Error Rate : エラー率, 5xxとか
• Duration : =ResponseTime, %ile評価が一般的
• リソース監視(USE)http://www.brendangregg.com/usemethod.html
• Utilization: 使用率 E.g. CPU使用率
• Saturation : 飽和度, どれくらいキューに詰まっているか
E.g. ロードアベレージ
• Errors : エラーイベントの数
後から情報取るのは困難、、
コマンドだけだと対象が多すぎて全部見れない、、
15. © 2020 NTT DATA Corporation 15
Metricsって何を見ないといけないのか?
• サービス監視(RED)
• Rate : =Throughput, 秒間リクエスト数, 秒間PV数
• Error Rate : エラー率, 5xxとか
• Duration : =ResponseTime, %ile評価が一般的
• リソース監視(USE)http://www.brendangregg.com/usemethod.html
• Utilization: 使用率 E.g. CPU使用率
• Saturation : 飽和度, どれくらいキューに詰まっているか
E.g. ロードアベレージ
• Errors : エラーイベントの数
メトリクス監視はPrometheusででき
る
後から情報取るのは困難、、
コマンドだけだと対象が多すぎて全部見れない、、
16. © 2020 NTT DATA Corporation 16
Metrics
Prometheusで最低限監視しておきたい項目
詳しくはBlogまで
【暫定版】 Kubernetesの性能監視で必要なメトリクス一覧とPrometheusでのHowTo
https://kashionki38.hatenablog.com/entry/2020/08/06/011420
種別 監視対象 メトリクス How
サービス監視
RED
Jmeter
クライアント側
Throughput
ResponseTime
Error%
Jmeterのメトリクスを収集
BackendListner->InfluxDB->Grafana
システム側
Throughput
ResponseTime
Error%
Istioのテレメトリ機能で各serviceのメトリクスを収集
リソース監視
USE
Node
CPU/Memory/NW/D
k使用量
NodeExporterをDaemonSetとして配置し収集
ProcessExporterをDaemonSetとして配置
Pod/Containe
CPU/Memory/NW/D
k使用量
cAdvisorにて収集
(Kubeletバイナリに統合されているのでscrapeの設定のみで
MW AP
スレッド数
GC
言語のPrometheusクライアントライブラリ
DB
QPS
クエリレイテンシ
セッション数
待機イベント
各DBのExporterをDB Podにサブコンテナとして配置
17. © 2020 NTT DATA Corporation 17
Metrics
Prometheusで最低限監視しておきたい項目
種別 監視対象 メトリクス How
サービス監視
RED
Jmeter
クライアント側
Throughput
ResponseTime
Error%
Jmeterのメトリクスを収集
BackendListner->InfluxDB->Grafana
18. © 2020 NTT DATA Corporation 18
Metrics
Prometheusで最低限監視しておきたい項目
▼Jmeter Dashboard
https://github.com/kashinoki38/prometheus-sample-yaml/blob/master/grafana/jmeter-metrics-
dashboard.json
Throughput
Jmeterスレッド
数
Error数
各URLごとの
Throughput
各URLごとの
Error詳細
種別 監視対象 メトリクス How
サービス監視
RED
Jmeter
クライアント側
Throughput
ResponseTime
Error%
Jmeterのメトリクスを収集
BackendListner->InfluxDB->Grafana
19. © 2020 NTT DATA Corporation 19
Metrics
Prometheusで最低限監視しておきたい項目
各URLごとの
Response Time
▼Jmeter Dashboard
https://github.com/kashinoki38/prometheus-sample-yaml/blob/master/grafana/jmeter-metrics-
dashboard.json
種別 監視対象 メトリクス How
サービス監視
RED
Jmeter
クライアント側
Throughput
ResponseTime
Error%
Jmeterのメトリクスを収集
BackendListner->InfluxDB->Grafana
20. © 2020 NTT DATA Corporation 20
Metrics
Prometheusで最低限監視しておきたい項目
各Workloadごと
のResponse
Time
各Workloadごと
のThroughput
各Workloadご
とのSuccess%
各Workloadへの
Incoming
Throughput
各Workloadへの
Incoming
Success%
各Workloadからの
Outgoing
Throughput
各Workloadからの
Outgoing
Success%
各Workloadからの
Outgoing Response
Time
種別 監視対象 メトリクス How
サービス監視
RED
システム側
Throughput
ResponseTime
Error%
Istioのテレメトリ機能で各serviceのメトリクスを収集
▼Istio-workloadダッシュボード
https://github.com/kashinoki38/prometheus-sample-yaml/blob/master/grafana/Istio-Workload-
Dashboard.json
21. © 2020 NTT DATA Corporation 21
Metrics
Prometheusで最低限監視しておきたい項目
各NodeごとのLoad
Average
各NodeごとのCPU%
種別 監視対象 メトリクス How
リソース監視
USE
Node
CPU/Memory/NW/D
k使用量
NodeExporterをDaemonSetとして配置し収集
ProcessExporterをDaemonSetとして配置
Node Availability
Node稼働状況
unschedulable Node数
pods
Pods Allocatable
Pods Capacity
Pods Allocation
CPU
CPU使用率
CPU使用率コアごと
ロードアベレージ
CPU Core Capacity
CPU Core Limits
CPU Core Requests
CPU Core Allocatable
メモリ
メモリ使用量
スワップイン量
スワップアウト量
スワップ使用率
スワップサイズ
Memory Capacity
Memory Limits
Memory Requests
Memory Allocatable
ディスク
ディスクビジー率
ディスクI/O待ち数
ディスクI/O待ち時間
ディスク読込み量
ディスク書込み量
ディスク読込み回数
ディスク書込み回数
パーティション使用率
パーティションサイズ
inode総数/使用率
ネットワーク
送信トラフィック量
受信トラフィック量
ポート/Socket
Drops
Errs
ファイルディスクリプタ
プロセス
プロセス数
プロセス数(ゾンビ)
▼Node Exporterダッシュボード
https://github.com/kashinoki38/prometheus-sample-yaml/blob/master/grafana/node-exporter-dashboard.json
22. © 2020 NTT DATA Corporation 22
Metrics
Prometheusで最低限監視しておきたい項目
特定NodeのProcess数
特定NodeのProcessごとの時
間
種別 監視対象 メトリクス How
リソース監視
USE
Node
CPU/Memory/NW/D
k使用量
NodeExporterをDaemonSetとして配置し収集
ProcessExporterをDaemonSetとして配置
▼Process Exporterダッシュボード
https://github.com/kashinoki38/prometheus-sample-yaml/blob/master/grafana/process-
exporter-dashboard.json
Node Availability
Node稼働状況
unschedulable Node数
pods
Pods Allocatable
Pods Capacity
Pods Allocation
CPU
CPU使用率
CPU使用率コアごと
ロードアベレージ
CPU Core Capacity
CPU Core Limits
CPU Core Requests
CPU Core Allocatable
メモリ
メモリ使用量
スワップイン量
スワップアウト量
スワップ使用率
スワップサイズ
Memory Capacity
Memory Limits
Memory Requests
Memory Allocatable
ディスク
ディスクビジー率
ディスクI/O待ち数
ディスクI/O待ち時間
ディスク読込み量
ディスク書込み量
ディスク読込み回数
ディスク書込み回数
パーティション使用率
パーティションサイズ
inode総数/使用率
ネットワーク
送信トラフィック量
受信トラフィック量
ポート/Socket
Drops
Errs
ファイルディスクリプタ
プロセス
プロセス数
プロセス数(ゾンビ)
23. © 2020 NTT DATA Corporation 23
Metrics
Prometheusで最低限監視しておきたい項目
各PodごとのCPU使用時間
各PodのCPU Throttle
種別 監視対象 メトリクス How
リソース監視
USE
Pod/Containe
CPU/Memory/NW/D
k使用量
cAdvisorにて収集
(Kubeletバイナリに統合されているのでscrapeの設定のみで
OK)
Pods Availability
Available Pods数
Pods Restarts
Pods status
Running / Pending /
Failed / Unknown
Container
Restarts
Errors
Terminated Reason
Waiting Reason
Restart Reason
Containers status
Ready / Terminated /
Waiting / Running
CPU
CPU使用率
ロードアベレージ
Throttle
CPU Core Limits
CPU Core Requests
メモリ
メモリ使用量
スワップイン量
スワップアウト量
スワップ使用量
スワップサイズ
Memory Limits
Memory Requests
ディスク
ディスクビジー率
ディスクI/O待ち数
ディスクI/O待ち時間
ディスク読込み量
ディスク書込み量
ディスク読込み回数
ディスク書込み回数
ネットワーク
送信トラフィック量
受信トラフィック量
ポート/Socket
Drops
Errs
ファイルディスクリプタ
▼Pod / Containerダッシュボード
https://github.com/kashinoki38/prometheus-sample-yaml/blob/master/grafana/pod_detail-dashboard.json
24. © 2020 NTT DATA Corporation 24
Metrics
Prometheusで最低限監視しておきたい項目
特定Podのコンテナごとの
CPU時間、Requests、
Limits
▼Pod / Containerダッシュボード
https://github.com/kashinoki38/prometheus-sample-yaml/blob/master/grafana/pod_detail-dashboard.json
Pods Availability
Available Pods数
Pods Restarts
Pods status
Running / Pending /
Failed / Unknown
Container
Restarts
Errors
Terminated Reason
Waiting Reason
Restart Reason
Containers status
Ready / Terminated /
Waiting / Running
CPU
CPU使用率
ロードアベレージ
Throttle
CPU Core Limits
CPU Core Requests
メモリ
メモリ使用量
スワップイン量
スワップアウト量
スワップ使用量
スワップサイズ
Memory Limits
Memory Requests
ディスク
ディスクビジー率
ディスクI/O待ち数
ディスクI/O待ち時間
ディスク読込み量
ディスク書込み量
ディスク読込み回数
ディスク書込み回数
ネットワーク
送信トラフィック量
受信トラフィック量
ポート/Socket
Drops
Errs
ファイルディスクリプタ
種別 監視対象 メトリクス How
リソース監視
USE
Pod/Containe
CPU/Memory/NW/D
k使用量
cAdvisorにて収集
(Kubeletバイナリに統合されているのでscrapeの設定のみで
OK)
25. © 2020 NTT DATA Corporation 25
Metrics
Prometheusで最低限監視しておきたい項目
特定Node上のPodのCPU時間
▼Pod / Containerダッシュボード
https://github.com/kashinoki38/prometheus-sample-yaml/blob/master/grafana/pod_detail-dashboard.json
Pods Availability
Available Pods数
Pods Restarts
Pods status
Running / Pending /
Failed / Unknown
Container
Restarts
Errors
Terminated Reason
Waiting Reason
Restart Reason
Containers status
Ready / Terminated /
Waiting / Running
CPU
CPU使用率
ロードアベレージ
Throttle
CPU Core Limits
CPU Core Requests
メモリ
メモリ使用量
スワップイン量
スワップアウト量
スワップ使用量
スワップサイズ
Memory Limits
Memory Requests
ディスク
ディスクビジー率
ディスクI/O待ち数
ディスクI/O待ち時間
ディスク読込み量
ディスク書込み量
ディスク読込み回数
ディスク書込み回数
ネットワーク
送信トラフィック量
受信トラフィック量
ポート/Socket
Drops
Errs
ファイルディスクリプタ
種別 監視対象 メトリクス How
リソース監視
USE
Pod/Containe
CPU/Memory/NW/D
k使用量
cAdvisorにて収集
(Kubeletバイナリに統合されているのでscrapeの設定のみで
OK)
26. © 2020 NTT DATA Corporation 26
Metrics
Prometheusで最低限監視しておきたい項目
特定Node上のPodのCPU時間
▼Pod / Containerダッシュボード
https://github.com/kashinoki38/prometheus-sample-yaml/blob/master/grafana/pod_detail-dashboard.json
Pods Availability
Available Pods数
Pods Restarts
Pods status
Running / Pending /
Failed / Unknown
Container
Restarts
Errors
Terminated Reason
Waiting Reason
Restart Reason
Containers status
Ready / Terminated /
Waiting / Running
CPU
CPU使用率
ロードアベレージ
Throttle
CPU Core Limits
CPU Core Requests
メモリ
メモリ使用量
スワップイン量
スワップアウト量
スワップ使用量
スワップサイズ
Memory Limits
Memory Requests
ディスク
ディスクビジー率
ディスクI/O待ち数
ディスクI/O待ち時間
ディスク読込み量
ディスク書込み量
ディスク読込み回数
ディスク書込み回数
ネットワーク
送信トラフィック量
受信トラフィック量
ポート/Socket
Drops
Errs
ファイルディスクリプタ
種別 監視対象 メトリクス How
リソース監視
USE
Pod/Containe
CPU/Memory/NW/D
k使用量
cAdvisorにて収集
(Kubeletバイナリに統合されているのでscrapeの設定のみで
OK)
27. © 2020 NTT DATA Corporation 27
Metrics
Prometheusで最低限監視しておきたい項目
種別 監視対象 メトリクス How
リソース監視
USE
AP
言語 : Java
スレッド数
GC
・SpringBoot2系以降から実装の、Micrometer Actuator
使用
(pom.xml変更のみで良いはず)
・jmx exporter
・Prometheus java client library
ヒープメモリ
全体ヒープメモリ使用量
Young
Old
Metaspace
Code Cache
GC
頻度(Full/Young)
時間(Full/Young)
スレッド数 スレッド数
空きスレッド数 空きスレッド数
スレッドプール使用率 スレッドプール使用率
コネクションプール使用
数
コネクションプール使用数
▼jmxダッシュボード
https://github.com/kashinoki38/prometheus-sample-yaml/blob/master/grafana/jmx-exporter-dashboard.json
28. © 2020 NTT DATA Corporation 28
Metrics
Prometheusで最低限監視しておきたい項目
種別 監視対象 メトリクス How
リソース監視
USE
AP
言語 :
スレッド数
GC
golangクライアントライブラリのpromhttpを使用
https://github.com/prometheus/client_golang/tr
master/prometheus/promhttp
▼goダッシュボード
https://github.com/kashinoki38/prometheus-sample-yaml/blob/master/grafana/go-process-dashboard.json
Process Memory
仮想メモリサイズ / 常駐メモリサ
イズ
Memory Stats heap / stack / 実使用量
open fds ファイルディスクリプタ数
Goroutines goroutine呼び出し数
GC
頻度(Full/Young)
時間(Full/Young)
29. © 2020 NTT DATA Corporation 29
Metrics
Prometheusで最低限監視しておきたい項目
種別 監視対象 メトリクス How
リソース監視
USE
AP
言語 :
スレッド数
GC
nodejsクライアントライブラリのprom-clientを使用
https://github.com/siimon/prom-client
▼Nodejsダッシュボード
https://github.com/kashinoki38/prometheus-sample-yaml/blob/master/grafana/nodejs-dashboard.json
Process Memory プロセス使用メモリ
Heap Heapサイズ / Heap使用量
Active Active Handlers数
Event Loop Lag Event Loopのラグ
GC
頻度(minor / incremental / major)
時間(minor / incremental / major)
30. © 2020 NTT DATA Corporation 30
Loggingって何を見ないといけないの
か?
31. © 2020 NTT DATA Corporation 31
Logging Lokiの紹介
Loggingの課題
• 大量のログを軽量に扱いたい(grepのような使い心地)
• メトリクス、トレーシングとの関連性を持たせたい(コンテキストスイッチを減らしたい)
→今回はLokiを採用
Lokiでできること
• Grafanaでのログ検索
• コンテキスト検索(前後の検索)
• grepライクな検索
• Grafanaでのログ時系列可視化
PromQLライクな可視化
• tracingとの連携(Grafanaへのアドオン)
詳しくは、https://de.slideshare.net/nttdata-tech/grafana-loki-
kubernetesloggingnttdata
Grafana
Promtail
Lokiのログ集約フロー
32. © 2020 NTT DATA Corporation 32
Logging 解析観点
観点
• エラーメッセージ
• 時系列でのエラー量
grepライクな検索
エラーメッセージ
Label
(どのPod/Container/app
etc)
前後のログ行
エラー検索(sock-shop namespaceのエラー)
時系列でのエラー量可視化
(Podごとのエラー量)
PromQLライクなクエリ
エラー量の可視化
任意のラベルで集計可
33. © 2020 NTT DATA Corporation 33
Tracingって何を見ないといけないの
か?
34. © 2020 NTT DATA Corporation 34
Tracing 依存関係可視化
Tracingでやりたいこと1
• サービス間の呼び出し依存関係
• 各呼び出しのResponse Time、スループット、エ
ラー率
→Kialiで可能
でできること
• サービス感の依存関係グラフ
• 依存関係に重ねて、Response Time、スルー
プット、エラー率
が見える
• 実態のデータはenvoyのPrometheusメトリクス
から取得
35. © 2020 NTT DATA Corporation 35
Tracing 分散トレーシング
Tracingでやりたいこと2
• 分散トレーシング(各サービスのレイテンシの包含関係)
でできること
• Spanによる表示で後続のサービスが占める時間を可視化できる
36. © 2020 NTT DATA Corporation 36
Observability
Test Environment
Prometheus
Logging
sock-
shop
istio-system
monitoring
jmeter
Metrics
Tracing
負荷がけ
サンプルアプリ
Grafana
37. © 2020 NTT DATA Corporation 37
余談ですが、
性能試験ってやってますか?
38. © 2020 NTT DATA Corporation 38
余談ですが、
性能試験ってやってますか?
A) 本番リリース直前に毎回やってる(自動化最強)
B) 重要なリリース前のみやってる+カナリアリリースして問題あったら
切り戻し
C) ほぼやってない(祈る)
39. © 2020 NTT DATA Corporation 39
余談ですが、
性能試験ってやってますか?
A) 本番リリース直前に毎回やってる(自動化最強)
B) 重要なリリース前のみやってる+カナリアリリースして問題あったら
切り戻し
C) ほぼやってない(祈る)
DevPerfOps (DevOps内での性能担保方法論)検討
中…
ケーススタディ教えてください!
ぜひ議論したいです。https://kashionki38.hatenablog.com/
(Hatena)
@ka_shino_ki (Twitter)
kashinoki38 (GitHub)
41. © 2020 NTT DATA Corporation 41
解析事例
事例 何を見るか 確認観点
Nodeのリソース枯渇 Prometheu
• Nodeのリソース
• リソース枯渇要因はPodなのか、その他プロセスなのか
コンテナのリソース
Limits抵触
Prometheu • コンテナのリソース(CPU/Memory)とそのLimits
Javaのヒープ/GCまわり Prometheu
• ヒープの設定サイズとContainerのメモリLimits
• GCの頻度、時間
APメソッドプロファイリ
ング
VisualVM
• CPUを使っているメソッド
• 処理時間を要しているメソッド
後続サービスの遅延
Kiali,
Jaeger
• Microserviceのどの部分で遅延/エラーが起きているかを俯瞰的
見る
• 分散トレーシングで各サービスの包括関係、トレースの具体情報を
確認する
アプリケーションエラー
Prometheu
Loki
• HTTPエラーが発生しているサービスやエラーコードをLokiで検索
し、具体的エラーメッセージの確認
• エラーの頻度等の時系列可視化
42. © 2020 NTT DATA Corporation 42
1. Nodeのリソース枯渇
1. Node Exporterのリソースグラフを確認
• この場合、とあるNodeのCPU使用率を確認すると1台の使用率がサチっている
何がCPUを食っているのか
NodeのCPU使用率
43. © 2020 NTT DATA Corporation 43
1. Nodeのリソース枯渇
2. 何がNodeのリソースを食っているのか
A) 複数のPodの積み重ねでNodeのCPUを食っているケース
→PodリソースグラフをNodeで絞ってPodのリソースを積み上げグラフで確認
特定Node内の全PodのCPU使用率積み上げ
44. © 2020 NTT DATA Corporation 44
1. Nodeのリソース枯渇
2. 何がNodeのリソースを食っているのか
B) 複数のPodの積み重ねで見てもNodeのCPU使用量に乖離がある
=Node上のコンテナ以外から使用されるプロセスが食っているケース
→Process exporterの各Node積み上げで確認する
特定Node内の全ProcessのCPU使用率積み上
げ
45. © 2020 NTT DATA Corporation 45
2. コンテナのリソースLimits抵触
1. Podのリソースグラフにて対象namespce上の全コンテナのリ
ソース使用量とLimits, Requetsを眺める
• 黄色→Limits、水色→Usage
• CPU, Memory
各コンテナのCPU使用量、Limits、
Requests
46. © 2020 NTT DATA Corporation 46
2. コンテナのリソースLimits抵触
2. Limitsにあたってしまってスケールできていないコンテナがいない
か
A) この場合はCPUのLimitsにあたってfront-endコンテナのCPUが枯渇してい
るのがわかる
front-end pod内のコンテナのCPU使用量、Limits、
Requests
47. © 2020 NTT DATA Corporation 47
2. コンテナのリソースLimits抵触
2. Limitsにあたってしまってスケールできていないコンテナがいない
か
B) MemoryのLimitsに当たる場合はOOM KilledやRestartsを繰り返している
ことが多い
ContainerのRestart回数
48. © 2020 NTT DATA Corporation 48
3. MWリソースの枯渇
すみません、go, nodejsはまた今度
• Javaで見るべきリソース
• ヒープ/GC
• Thread Pool
• Connection Pool
→※Defaultで取れないので考慮必要
JMX Dashboard
49. © 2020 NTT DATA Corporation 49
3. MWリソースの枯渇
ヒープ/GCでよくある問題
1. GC頻発による遅延やCPU枯渇
• jmx dashboardでGC種別ごとの頻度、時間を確認可能
2. ContainerのメモリLimitsとの不整合によるOOME → コンテナ特有
• jdk8u191未満だと明示的にヒープサイズを設定しない場合、Nodeのメモリサイズの1/4でヒープが設定されてし
まう
→PodのLimitsを超えて設定されることがあり、ヒープが無邪気に拡大するとOOM Killedされる
• jdk8u131以降なら以下オプションでPodのMemoryLimitsを認識した設定になる
• -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap
• 明示的に指定する場合は、ヒープだけじゃなくMetaspaceなどの非ヒープにも注意
• Metaspaceが拡大してもOOM Killed発生する
→これでRestartsを繰り返してる場合、spring bootから情報を取ってるjmx dashboard
では事象が追えないかった。GCログも出しておくほうがよい
-verbose:gc
50. © 2020 NTT DATA Corporation 50
3. MWリソースの枯渇
GCログも標準出力しておくようにすると、どこまでヒープ拡張しようとしていたのか把握可能
• 下記の例だと232MBまでヒープが拡張しており、Metaspaceと合わせるとLimitsに対して
拡張しすぎていることが把握可能
標準出力されたGCログ GCログの1分ごとの出力回数
51. © 2020 NTT DATA Corporation 51
4. APメソッドプロファイリング
すみません、javaのみで(go, nodejsはまた今度!)
• 従来法:VisualVM
• jmxremoteのOption設定
• kubectl portforward
• VisualVMで接続
- env:
- name: JAVA_OPTS
value: -Xms64m -Xmx128m -XX:PermSize=32m -
XX:MaxPermSize=64m -XX:+UseG1GC
-Djava.security.egd=file:/dev/urandom
-Dcom.sun.management.jmxremote.port=3333
-Dcom.sun.management.jmxremote.ssl=false
-
Dcom.sun.management.jmxremote.authenticate=f
alse
-
Dcom.sun.management.jmxremote.rmi.port=3333
-Djava.rmi.server.hostname=127.0.0.1
これ重要です。
Portforwardでつなぎに行
くのでlocalhost
jmx remote接続用のJVM Optionの追加
52. © 2020 NTT DATA Corporation 52
4. APメソッドプロファイリング
つながると以下のような情報が容易に取れる
GCやThreadなどのJVMリソース情報
CPUサンプリング
サンプリング結果のSnapshot
53. © 2020 NTT DATA Corporation 53
4. APメソッドプロファイリング
例えばOrdersのJavaAPにつないでみると、
• 最も時間がかかっているのはnewOrder()メソッド (あくまで比較的という話)
• newOrder()から呼ばれるFutureTask.get()
• 他サービスへのREST呼び出しの非同期処理の結果取得
54. © 2020 NTT DATA Corporation 54
4. APメソッドプロファイリング
分散トレーシングでみても
確かにordersの他サービス呼び出しに時間がかかっているように見える
55. © 2020 NTT DATA Corporation 55
5. 後続サービスの遅延
1. まずはKialiを眺めて、依存関係上にResponseTimeをマッピングす
る
• エラーは色分けされて出るのでエラー有無も把握可能
• この場合、front-end→catalogue部分で遅延
• サービスが多くなればなるほど重要。いきなりリソース解析せずこれでREDベー
スであたりをつける
56. © 2020 NTT DATA Corporation 56
5. 後続サービスの遅延
2. Jaegerでより詳細にトレースサンプルを確認する
• この場合、catalogue/size?tagsの呼び出しが遅延しているのがわかる
• あくまでサンプリングなので、KialiやPrometheusの統計的なデータと合わせて確認する
57. © 2020 NTT DATA Corporation 57
6. アプリケーションのエラー
1. Istio workloadダッシュボードでHTTPコードベースでエラー有無
確認
• この場合、front-end→ordersでordersが406を返していることがわかる
58. © 2020 NTT DATA Corporation 58
6. アプリケーションのエラー
2. Lokiにて、当該時間のエラーの確認
• front-endが受け取ったエラー
• 406としてPayment declined : amount exceeds 100.00 とあり、
APで設定しているOrder可能回数に抵触していることがわかった
59. © 2020 NTT DATA Corporation 59
6. アプリケーションのエラー
3. Lokiにて、当該時間のエラーの可視化
• 例えば、1分間に平均どれくらいエラーが発生しているのかが可視化できる
61. © 2020 NTT DATA Corporation 61
まとめ
Sock Shopをベースに性能解析を一通り試してみた
• 環境:作業途中のものは随時ここに
→https://github.com/kashinoki38/microservices-demo/tree/master/deploy/kubernetes
• Metrics by Prometheus:各種取り揃えるのは大変。揃うと便利で強力。
• Prometheusのメトリクスやダッシュボードなどは以下ブログ
• 【暫定版】 Kubernetesの性能監視で必要なメトリクス一覧とPrometheusでのHowTo
• https://kashionki38.hatenablog.com/entry/2020/08/06/011420
• Logging by Loki:Garafanaで見れるの便利。検索や可視化がPromQL+Grep
ライク
• Tracing by
• Kiali:依存関係と遅延/エラー発生箇所の特定に便利
• Jaeger:サービス同士の処理時間の包含関係の解析に便利
• Profilingはまだまだ余地があるので調査していきたい
62. © 2020 NTT DATA Corporation 62
まとめ
Sock Shopをベースに性能解析を一通り試してみた
• 環境:作業途中のものは随時ここに
→https://github.com/kashinoki38/microservices-demo/tree/master/deploy/kubernetes
• Metrics by Prometheus:各種取り揃えるのは大変。揃うと便利で強力。
• Prometheusのメトリクスやダッシュボードなどは以下ブログ
• 【暫定版】 Kubernetesの性能監視で必要なメトリクス一覧とPrometheusでのHowTo
• https://kashionki38.hatenablog.com/entry/2020/08/06/011420
• Logging by Loki:Garafanaで見れるの便利。検索や可視化がPromQL+Grep
ライク
• Tracing by
• Kiali:依存関係と遅延/エラー発生箇所の特定に便利
• Jaeger:サービス同士の処理時間の包含関係の解析に便利
• Profilingはまだまだ余地があるので調査していきたい
Editor's Notes ・シナリオのバージョン管理は実行時にgitにpushすればいい話
#シナリオに変更があった場合に
・githubのリンクを試験結果ダッシュボードに出せば良い
・シナリオのバージョン管理は実行時にgitにpushすればいい話
#シナリオに変更があった場合に
・githubのリンクを試験結果ダッシュボードに出せば良い