Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
© 2020 NTT DATA Corporation
Kubernetesでの性能解析
~なんとなく遅いからの脱却~
2020/08/26 Kubernetes Meetup Tokyo #33
NTT DATA 技術革新統括本部 デジタルテ...
© 2020 NTT DATA Corporation 2
Agenda
1. Who am I?
2. 概要
– デモアプリと実施していること
– 性能試験のための基盤
3. Kubernetesでの性能解析の始め方
– Metrics by...
© 2020 NTT DATA Corporation 3
Who am I?
• 堀内 保大, Yasuhiro Horiuchi
• NTT DATA 技術革新統括本部 デジタルテクノロジ推進室
“まかせいのう”
• https://www...
© 2020 NTT DATA Corporation 4
What’s まかせいのう
・“性能はまかせろ“ → まかせいのう
・創業12年の実績から、試験方法論や監視観点、解析プロセスを整備
・性能に関して一気通貫で上流から下流まで対応
・海...
© 2020 NTT DATA Corporation 5
What’s まかせいのう
https://www.nttdata.com/jp/ja/lineup/macaseinou/
く
ら
う
ど
ね
い
て
ぃ
ぶ
始
め
ま
し
た
・...
© 2020 NTT DATA Corporation 6
本スライドの目的、モチベーション
• Kubernetesないしコンテナは性能解析かんたんじゃないですよ
ね?
• NodeやPodのリソース監視
• GCとか同時実行数などMWのリソ...
© 2020 NTT DATA Corporation
実施したことの概要
© 2020 NTT DATA Corporation 8
概要
デモアプリと実施していること
Sock Shop
• https://microservices-demo.github.io/
• Weaveworksのマイクロサービスデモア...
© 2020 NTT DATA Corporation 9
概要
性能試験のための基盤
Test Environment
Prometheus
Logging
sock-
shop
istio-system
monitoring
jmeter
...
© 2020 NTT DATA Corporation
Kubernetesでの
性能解析の始め方
© 2020 NTT DATA Corporation 11
性能解析の始め方→Observability
Observabilityを揃えることから始める
• Metrics → Prometheus
• 重要性:従来の監視と同概念。サービス...
© 2020 NTT DATA Corporation 12
Metricsって何を見ないといけないのか?
© 2020 NTT DATA Corporation 13
Metricsって何を見ないといけないのか?
• サービス監視(RED)
• Rate : =Throughput, 秒間リクエスト数, 秒間PV数
• Error Rate : エ...
© 2020 NTT DATA Corporation 14
Metricsって何を見ないといけないのか?
• サービス監視(RED)
• Rate : =Throughput, 秒間リクエスト数, 秒間PV数
• Error Rate : エ...
© 2020 NTT DATA Corporation 15
Metricsって何を見ないといけないのか?
• サービス監視(RED)
• Rate : =Throughput, 秒間リクエスト数, 秒間PV数
• Error Rate : エ...
© 2020 NTT DATA Corporation 16
Metrics
Prometheusで最低限監視しておきたい項目
詳しくはBlogまで
【暫定版】 Kubernetesの性能監視で必要なメトリクス一覧とPrometheusでのHo...
© 2020 NTT DATA Corporation 17
Metrics
Prometheusで最低限監視しておきたい項目
種別 監視対象 メトリクス How
サービス監視
RED
Jmeter
クライアント側
Throughput
Res...
© 2020 NTT DATA Corporation 18
Metrics
Prometheusで最低限監視しておきたい項目
▼Jmeter Dashboard
https://github.com/kashinoki38/prometheu...
© 2020 NTT DATA Corporation 19
Metrics
Prometheusで最低限監視しておきたい項目
各URLごとの
Response Time
▼Jmeter Dashboard
https://github.com...
© 2020 NTT DATA Corporation 20
Metrics
Prometheusで最低限監視しておきたい項目
各Workloadごと
のResponse
Time
各Workloadごと
のThroughput
各Worklo...
© 2020 NTT DATA Corporation 21
Metrics
Prometheusで最低限監視しておきたい項目
各NodeごとのLoad
Average
各NodeごとのCPU%
種別 監視対象 メトリクス How
リソース監視...
© 2020 NTT DATA Corporation 22
Metrics
Prometheusで最低限監視しておきたい項目
特定NodeのProcess数
特定NodeのProcessごとの時
間
種別 監視対象 メトリクス How
リソー...
© 2020 NTT DATA Corporation 23
Metrics
Prometheusで最低限監視しておきたい項目
各PodごとのCPU使用時間
各PodのCPU Throttle
種別 監視対象 メトリクス How
リソース監視
...
© 2020 NTT DATA Corporation 24
Metrics
Prometheusで最低限監視しておきたい項目
特定Podのコンテナごとの
CPU時間、Requests、
Limits
▼Pod / Containerダッシュボ...
© 2020 NTT DATA Corporation 25
Metrics
Prometheusで最低限監視しておきたい項目
特定Node上のPodのCPU時間
▼Pod / Containerダッシュボード
https://github.c...
© 2020 NTT DATA Corporation 26
Metrics
Prometheusで最低限監視しておきたい項目
特定Node上のPodのCPU時間
▼Pod / Containerダッシュボード
https://github.c...
© 2020 NTT DATA Corporation 27
Metrics
Prometheusで最低限監視しておきたい項目
種別 監視対象 メトリクス How
リソース監視
USE
AP
言語 : Java
スレッド数
GC
・Spring...
© 2020 NTT DATA Corporation 28
Metrics
Prometheusで最低限監視しておきたい項目
種別 監視対象 メトリクス How
リソース監視
USE
AP
言語 :
スレッド数
GC
golangクライアント...
© 2020 NTT DATA Corporation 29
Metrics
Prometheusで最低限監視しておきたい項目
種別 監視対象 メトリクス How
リソース監視
USE
AP
言語 :
スレッド数
GC
nodejsクライアント...
© 2020 NTT DATA Corporation 30
Loggingって何を見ないといけないの
か?
© 2020 NTT DATA Corporation 31
Logging Lokiの紹介
Loggingの課題
• 大量のログを軽量に扱いたい(grepのような使い心地)
• メトリクス、トレーシングとの関連性を持たせたい(コンテキストスイ...
© 2020 NTT DATA Corporation 32
Logging 解析観点
観点
• エラーメッセージ
• 時系列でのエラー量
grepライクな検索
エラーメッセージ
Label
(どのPod/Container/app
etc)
...
© 2020 NTT DATA Corporation 33
Tracingって何を見ないといけないの
か?
© 2020 NTT DATA Corporation 34
Tracing 依存関係可視化
Tracingでやりたいこと1
• サービス間の呼び出し依存関係
• 各呼び出しのResponse Time、スループット、エ
ラー率
→Kialiで...
© 2020 NTT DATA Corporation 35
Tracing 分散トレーシング
Tracingでやりたいこと2
• 分散トレーシング(各サービスのレイテンシの包含関係)
でできること
• Spanによる表示で後続のサービスが占め...
© 2020 NTT DATA Corporation 36
Observability
Test Environment
Prometheus
Logging
sock-
shop
istio-system
monitoring
jmeter...
© 2020 NTT DATA Corporation 37
余談ですが、
性能試験ってやってますか?
© 2020 NTT DATA Corporation 38
余談ですが、
性能試験ってやってますか?
A) 本番リリース直前に毎回やってる(自動化最強)
B) 重要なリリース前のみやってる+カナリアリリースして問題あったら
切り戻し
C) ほ...
© 2020 NTT DATA Corporation 39
余談ですが、
性能試験ってやってますか?
A) 本番リリース直前に毎回やってる(自動化最強)
B) 重要なリリース前のみやってる+カナリアリリースして問題あったら
切り戻し
C) ほ...
© 2020 NTT DATA Corporation
解析事例
© 2020 NTT DATA Corporation 41
解析事例
事例 何を見るか 確認観点
Nodeのリソース枯渇 Prometheu
• Nodeのリソース
• リソース枯渇要因はPodなのか、その他プロセスなのか
コンテナのリソース...
© 2020 NTT DATA Corporation 42
1. Nodeのリソース枯渇
1. Node Exporterのリソースグラフを確認
• この場合、とあるNodeのCPU使用率を確認すると1台の使用率がサチっている
何がCPUを食...
© 2020 NTT DATA Corporation 43
1. Nodeのリソース枯渇
2. 何がNodeのリソースを食っているのか
A) 複数のPodの積み重ねでNodeのCPUを食っているケース
→PodリソースグラフをNodeで絞って...
© 2020 NTT DATA Corporation 44
1. Nodeのリソース枯渇
2. 何がNodeのリソースを食っているのか
B) 複数のPodの積み重ねで見てもNodeのCPU使用量に乖離がある
=Node上のコンテナ以外から使用...
© 2020 NTT DATA Corporation 45
2. コンテナのリソースLimits抵触
1. Podのリソースグラフにて対象namespce上の全コンテナのリ
ソース使用量とLimits, Requetsを眺める
• 黄色→Li...
© 2020 NTT DATA Corporation 46
2. コンテナのリソースLimits抵触
2. Limitsにあたってしまってスケールできていないコンテナがいない
か
A) この場合はCPUのLimitsにあたってfront-en...
© 2020 NTT DATA Corporation 47
2. コンテナのリソースLimits抵触
2. Limitsにあたってしまってスケールできていないコンテナがいない
か
B) MemoryのLimitsに当たる場合はOOM Kill...
© 2020 NTT DATA Corporation 48
3. MWリソースの枯渇
すみません、go, nodejsはまた今度
• Javaで見るべきリソース
• ヒープ/GC
• Thread Pool
• Connection Pool...
© 2020 NTT DATA Corporation 49
3. MWリソースの枯渇
 ヒープ/GCでよくある問題
1. GC頻発による遅延やCPU枯渇
• jmx dashboardでGC種別ごとの頻度、時間を確認可能
2. Contai...
© 2020 NTT DATA Corporation 50
3. MWリソースの枯渇
GCログも標準出力しておくようにすると、どこまでヒープ拡張しようとしていたのか把握可能
• 下記の例だと232MBまでヒープが拡張しており、Metaspac...
© 2020 NTT DATA Corporation 51
4. APメソッドプロファイリング
すみません、javaのみで(go, nodejsはまた今度!)
• 従来法:VisualVM
• jmxremoteのOption設定
• kub...
© 2020 NTT DATA Corporation 52
4. APメソッドプロファイリング
つながると以下のような情報が容易に取れる
GCやThreadなどのJVMリソース情報
CPUサンプリング
サンプリング結果のSnapshot
© 2020 NTT DATA Corporation 53
4. APメソッドプロファイリング
例えばOrdersのJavaAPにつないでみると、
• 最も時間がかかっているのはnewOrder()メソッド (あくまで比較的という話)
• n...
© 2020 NTT DATA Corporation 54
4. APメソッドプロファイリング
分散トレーシングでみても
確かにordersの他サービス呼び出しに時間がかかっているように見える
© 2020 NTT DATA Corporation 55
5. 後続サービスの遅延
1. まずはKialiを眺めて、依存関係上にResponseTimeをマッピングす
る
• エラーは色分けされて出るのでエラー有無も把握可能
• この場合、...
© 2020 NTT DATA Corporation 56
5. 後続サービスの遅延
2. Jaegerでより詳細にトレースサンプルを確認する
• この場合、catalogue/size?tagsの呼び出しが遅延しているのがわかる
• あくま...
© 2020 NTT DATA Corporation 57
6. アプリケーションのエラー
1. Istio workloadダッシュボードでHTTPコードベースでエラー有無
確認
• この場合、front-end→ordersでorders...
© 2020 NTT DATA Corporation 58
6. アプリケーションのエラー
2. Lokiにて、当該時間のエラーの確認
• front-endが受け取ったエラー
• 406としてPayment declined : amoun...
© 2020 NTT DATA Corporation 59
6. アプリケーションのエラー
3. Lokiにて、当該時間のエラーの可視化
• 例えば、1分間に平均どれくらいエラーが発生しているのかが可視化できる
© 2020 NTT DATA Corporation 60
まとめ
© 2020 NTT DATA Corporation 61
まとめ
Sock Shopをベースに性能解析を一通り試してみた
• 環境:作業途中のものは随時ここに
→https://github.com/kashinoki38/microser...
© 2020 NTT DATA Corporation 62
まとめ
Sock Shopをベースに性能解析を一通り試してみた
• 環境:作業途中のものは随時ここに
→https://github.com/kashinoki38/microser...
© 2020 NTT DATA Corporation
Prochain SlideShare
Chargement dans…5
×

Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)

Kubernetesでの性能解析 ~なんとなく遅いからの脱却~
(Kubernetes Meetup Tokyo #33 発表資料)

2020/08/26

NTT DATA
Yasuhiro Horiuchi

  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)

  1. 1. © 2020 NTT DATA Corporation Kubernetesでの性能解析 ~なんとなく遅いからの脱却~ 2020/08/26 Kubernetes Meetup Tokyo #33 NTT DATA 技術革新統括本部 デジタルテクノロジ推進室 まかせいのう 堀内 保大, Yasuhiro Horiuchi (@ka_shino_ki)
  2. 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. 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. 4. © 2020 NTT DATA Corporation 4 What’s まかせいのう ・“性能はまかせろ“ → まかせいのう ・創業12年の実績から、試験方法論や監視観点、解析プロセスを整備 ・性能に関して一気通貫で上流から下流まで対応 ・海外グループ会社にも展開中 macaseinou! もし何か性能でお困りごとあれば何でも!まずはご連絡ください! https://www.nttdata.com/jp/ja/lineup/macaseinou/
  5. 5. © 2020 NTT DATA Corporation 5 What’s まかせいのう https://www.nttdata.com/jp/ja/lineup/macaseinou/ く ら う ど ね い て ぃ ぶ 始 め ま し た ・“性能はまかせろ“ → まかせいのう ・創業12年の実績から、試験方法論や監視観点、解析プロセスを整備 ・性能に関して一気通貫で上流から下流まで対応 ・海外グループ会社にも展開中 macaseinou! もし何か性能でお困りごとあれば何でも!まずはご連絡ください!
  6. 6. © 2020 NTT DATA Corporation 6 本スライドの目的、モチベーション • Kubernetesないしコンテナは性能解析かんたんじゃないですよ ね? • NodeやPodのリソース監視 • GCとか同時実行数などMWのリソース監視 • ログ • Tracing • 問題が起きたときにどうしてますか? • CPUが高騰した際の原因分析できてますか? • usr? sys? • GCなの? • APのなにかの関数なの? • 本スライドでは上記のような性能解析の基礎をKubernetesでも実 施できる方法論を網羅的に紹介したい
  7. 7. © 2020 NTT DATA Corporation 実施したことの概要
  8. 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. 9. © 2020 NTT DATA Corporation 9 概要 性能試験のための基盤 Test Environment Prometheus Logging sock- shop istio-system monitoring jmeter Metrics Tracing 負荷がけ サンプルアプリ Grafana
  10. 10. © 2020 NTT DATA Corporation Kubernetesでの 性能解析の始め方
  11. 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. 12. © 2020 NTT DATA Corporation 12 Metricsって何を見ないといけないのか?
  13. 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. 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. 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. 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. 17. © 2020 NTT DATA Corporation 17 Metrics Prometheusで最低限監視しておきたい項目 種別 監視対象 メトリクス How サービス監視 RED Jmeter クライアント側 Throughput ResponseTime Error% Jmeterのメトリクスを収集 BackendListner->InfluxDB->Grafana
  18. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 30. © 2020 NTT DATA Corporation 30 Loggingって何を見ないといけないの か?
  31. 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. 32. © 2020 NTT DATA Corporation 32 Logging 解析観点 観点 • エラーメッセージ • 時系列でのエラー量 grepライクな検索 エラーメッセージ Label (どのPod/Container/app etc) 前後のログ行 エラー検索(sock-shop namespaceのエラー) 時系列でのエラー量可視化 (Podごとのエラー量) PromQLライクなクエリ エラー量の可視化 任意のラベルで集計可
  33. 33. © 2020 NTT DATA Corporation 33 Tracingって何を見ないといけないの か?
  34. 34. © 2020 NTT DATA Corporation 34 Tracing 依存関係可視化 Tracingでやりたいこと1 • サービス間の呼び出し依存関係 • 各呼び出しのResponse Time、スループット、エ ラー率 →Kialiで可能 でできること • サービス感の依存関係グラフ • 依存関係に重ねて、Response Time、スルー プット、エラー率 が見える • 実態のデータはenvoyのPrometheusメトリクス から取得
  35. 35. © 2020 NTT DATA Corporation 35 Tracing 分散トレーシング Tracingでやりたいこと2 • 分散トレーシング(各サービスのレイテンシの包含関係) でできること • Spanによる表示で後続のサービスが占める時間を可視化できる
  36. 36. © 2020 NTT DATA Corporation 36 Observability Test Environment Prometheus Logging sock- shop istio-system monitoring jmeter Metrics Tracing 負荷がけ サンプルアプリ Grafana
  37. 37. © 2020 NTT DATA Corporation 37 余談ですが、 性能試験ってやってますか?
  38. 38. © 2020 NTT DATA Corporation 38 余談ですが、 性能試験ってやってますか? A) 本番リリース直前に毎回やってる(自動化最強) B) 重要なリリース前のみやってる+カナリアリリースして問題あったら 切り戻し C) ほぼやってない(祈る)
  39. 39. © 2020 NTT DATA Corporation 39 余談ですが、 性能試験ってやってますか? A) 本番リリース直前に毎回やってる(自動化最強) B) 重要なリリース前のみやってる+カナリアリリースして問題あったら 切り戻し C) ほぼやってない(祈る) DevPerfOps (DevOps内での性能担保方法論)検討 中… ケーススタディ教えてください! ぜひ議論したいです。https://kashionki38.hatenablog.com/ (Hatena) @ka_shino_ki (Twitter) kashinoki38 (GitHub)
  40. 40. © 2020 NTT DATA Corporation 解析事例
  41. 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. 42. © 2020 NTT DATA Corporation 42 1. Nodeのリソース枯渇 1. Node Exporterのリソースグラフを確認 • この場合、とあるNodeのCPU使用率を確認すると1台の使用率がサチっている 何がCPUを食っているのか NodeのCPU使用率
  43. 43. © 2020 NTT DATA Corporation 43 1. Nodeのリソース枯渇 2. 何がNodeのリソースを食っているのか A) 複数のPodの積み重ねでNodeのCPUを食っているケース →PodリソースグラフをNodeで絞ってPodのリソースを積み上げグラフで確認 特定Node内の全PodのCPU使用率積み上げ
  44. 44. © 2020 NTT DATA Corporation 44 1. Nodeのリソース枯渇 2. 何がNodeのリソースを食っているのか B) 複数のPodの積み重ねで見てもNodeのCPU使用量に乖離がある =Node上のコンテナ以外から使用されるプロセスが食っているケース →Process exporterの各Node積み上げで確認する 特定Node内の全ProcessのCPU使用率積み上 げ
  45. 45. © 2020 NTT DATA Corporation 45 2. コンテナのリソースLimits抵触 1. Podのリソースグラフにて対象namespce上の全コンテナのリ ソース使用量とLimits, Requetsを眺める • 黄色→Limits、水色→Usage • CPU, Memory 各コンテナのCPU使用量、Limits、 Requests
  46. 46. © 2020 NTT DATA Corporation 46 2. コンテナのリソースLimits抵触 2. Limitsにあたってしまってスケールできていないコンテナがいない か A) この場合はCPUのLimitsにあたってfront-endコンテナのCPUが枯渇してい るのがわかる front-end pod内のコンテナのCPU使用量、Limits、 Requests
  47. 47. © 2020 NTT DATA Corporation 47 2. コンテナのリソースLimits抵触 2. Limitsにあたってしまってスケールできていないコンテナがいない か B) MemoryのLimitsに当たる場合はOOM KilledやRestartsを繰り返している ことが多い ContainerのRestart回数
  48. 48. © 2020 NTT DATA Corporation 48 3. MWリソースの枯渇 すみません、go, nodejsはまた今度 • Javaで見るべきリソース • ヒープ/GC • Thread Pool • Connection Pool →※Defaultで取れないので考慮必要 JMX Dashboard
  49. 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. 50. © 2020 NTT DATA Corporation 50 3. MWリソースの枯渇 GCログも標準出力しておくようにすると、どこまでヒープ拡張しようとしていたのか把握可能 • 下記の例だと232MBまでヒープが拡張しており、Metaspaceと合わせるとLimitsに対して 拡張しすぎていることが把握可能 標準出力されたGCログ GCログの1分ごとの出力回数
  51. 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. 52. © 2020 NTT DATA Corporation 52 4. APメソッドプロファイリング つながると以下のような情報が容易に取れる GCやThreadなどのJVMリソース情報 CPUサンプリング サンプリング結果のSnapshot
  53. 53. © 2020 NTT DATA Corporation 53 4. APメソッドプロファイリング 例えばOrdersのJavaAPにつないでみると、 • 最も時間がかかっているのはnewOrder()メソッド (あくまで比較的という話) • newOrder()から呼ばれるFutureTask.get() • 他サービスへのREST呼び出しの非同期処理の結果取得
  54. 54. © 2020 NTT DATA Corporation 54 4. APメソッドプロファイリング 分散トレーシングでみても 確かにordersの他サービス呼び出しに時間がかかっているように見える
  55. 55. © 2020 NTT DATA Corporation 55 5. 後続サービスの遅延 1. まずはKialiを眺めて、依存関係上にResponseTimeをマッピングす る • エラーは色分けされて出るのでエラー有無も把握可能 • この場合、front-end→catalogue部分で遅延 • サービスが多くなればなるほど重要。いきなりリソース解析せずこれでREDベー スであたりをつける
  56. 56. © 2020 NTT DATA Corporation 56 5. 後続サービスの遅延 2. Jaegerでより詳細にトレースサンプルを確認する • この場合、catalogue/size?tagsの呼び出しが遅延しているのがわかる • あくまでサンプリングなので、KialiやPrometheusの統計的なデータと合わせて確認する
  57. 57. © 2020 NTT DATA Corporation 57 6. アプリケーションのエラー 1. Istio workloadダッシュボードでHTTPコードベースでエラー有無 確認 • この場合、front-end→ordersでordersが406を返していることがわかる
  58. 58. © 2020 NTT DATA Corporation 58 6. アプリケーションのエラー 2. Lokiにて、当該時間のエラーの確認 • front-endが受け取ったエラー • 406としてPayment declined : amount exceeds 100.00 とあり、 APで設定しているOrder可能回数に抵触していることがわかった
  59. 59. © 2020 NTT DATA Corporation 59 6. アプリケーションのエラー 3. Lokiにて、当該時間のエラーの可視化 • 例えば、1分間に平均どれくらいエラーが発生しているのかが可視化できる
  60. 60. © 2020 NTT DATA Corporation 60 まとめ
  61. 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. 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はまだまだ余地があるので調査していきたい
  63. 63. © 2020 NTT DATA Corporation

×