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