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

© 2020 NTT DATA Corporation
Kubernetesでの性能解析
～なんとなく遅いからの脱却～
2020/08/26 Kubernetes Meetup Tokyo #33
NTT DATA 技術革新統括本部デジタルテクノロジ推進室まかせいのう
堀内保大, Yasuhiro Horiuchi (@ka_shino_ki)

© 2020 NTT DATA Corporation 2
Agenda
1. Who am I?
2. 概要
– デモアプリと実施していること
– 性能試験のための基盤
3. Kubernetesでの性能解析の始め方
– Metrics by Prometheus
– Logging by Loki
– Tracing by Kiali / Jaeger
4. 解析事例

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)

What’s まかせいのう
・“性能はまかせろ“ → まかせいのう
・創業12年の実績から、試験方法論や監視観点、解析プロセスを整備
・性能に関して一気通貫で上流から下流まで対応
・海外グループ会社にも展開中 macaseinou!
もし何か性能でお困りごとあれば何でも！まずはご連絡ください！
https://www.nttdata.com/jp/ja/lineup/macaseinou/

What’s まかせいのう
https://www.nttdata.com/jp/ja/lineup/macaseinou/
く
ら
う
ど
ね
い
て
ぃ
ぶ
始
め
ま
し
た
・“性能はまかせろ“ → まかせいのう
・創業12年の実績から、試験方法論や監視観点、解析プロセスを整備
・性能に関して一気通貫で上流から下流まで対応
・海外グループ会社にも展開中 macaseinou!
もし何か性能でお困りごとあれば何でも！まずはご連絡ください！

本スライドの目的、モチベーション
• Kubernetesないしコンテナは性能解析かんたんじゃないですよ
ね？
• NodeやPodのリソース監視
• GCとか同時実行数などMWのリソース監視
• ログ
• Tracing
• 問題が起きたときにどうしてますか？
• CPUが高騰した際の原因分析できてますか？
• usr? sys?
• GCなの？
• APのなにかの関数なの？
• 本スライドでは上記のような性能解析の基礎をKubernetesでも実
施できる方法論を網羅的に紹介したい

実施したことの概要

概要
デモアプリと実施していること
Sock Shop
• https://microservices-demo.github.io/
• Weaveworksのマイクロサービスデモアプリ
• 靴下のECサイト
• 公式GitHubは古いので、K8s v1.16への対応が必要
↓
https://github.com/kashinoki38/microservi
ces-demo
実施していること
• GKE上にSock Shopをデプロイし、
Observabilityを実装→負荷試験実施→解析

概要
性能試験のための基盤
Test Environment
Prometheus
Logging
sock-
shop
istio-system
monitoring
jmeter
Metrics
Tracing
負荷がけ
サンプルアプリ
Grafana

Kubernetesでの
性能解析の始め方

性能解析の始め方→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本柱

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ででき
る
後から情報取るのは困難、、
コマンドだけだと対象が多すぎて全部見れない、、

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にサブコンテナとして配置

Metrics
サービス監視
RED
Jmeter
Throughput
ResponseTime
Error%

Metrics
▼Jmeter Dashboard
https://github.com/kashinoki38/prometheus-sample-yaml/blob/master/grafana/jmeter-metrics-
dashboard.json
Throughput
Jmeterスレッド
数
Error数
各URLごとの
Throughput
各URLごとの
Error詳細
サービス監視
RED
Jmeter
Throughput
ResponseTime
Error%

Metrics
各URLごとの
Response Time
▼Jmeter Dashboard
https://github.com/kashinoki38/prometheus-sample-yaml/blob/master/grafana/jmeter-metrics-
dashboard.json
サービス監視
RED
Jmeter
Throughput
ResponseTime
Error%

Metrics
各Workloadごと
のResponse
Time
各Workloadごと
のThroughput
各Workloadご
とのSuccess%
各Workloadへの
Incoming
Throughput
各Workloadへの
Incoming
Success%
各Workloadからの
Outgoing
Throughput
Outgoing
Success%
Outgoing Response
Time
サービス監視
RED
システム側
Throughput
ResponseTime
Error%
Istioのテレメトリ機能で各serviceのメトリクスを収集
▼Istio-workloadダッシュボード
https://github.com/kashinoki38/prometheus-sample-yaml/blob/master/grafana/Istio-Workload-
Dashboard.json

Metrics
各NodeごとのLoad
Average
各NodeごとのCPU%
リソース監視
USE
Node
CPU/Memory/NW/D
k使用量
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

Metrics
特定NodeのProcess数
特定NodeのProcessごとの時
間
リソース監視
USE
Node
CPU/Memory/NW/D
k使用量
▼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
ディスク
パーティション使用率
パーティションサイズ
inode総数/使用率
ネットワーク
ポート/Socket
Drops
Errs
プロセス
プロセス数
プロセス数(ゾンビ)

Metrics
各PodごとのCPU使用時間
各PodのCPU Throttle
リソース監視
USE
Pod/Containe
CPU/Memory/NW/D
k使用量
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
ディスク
ネットワーク
ポート/Socket
Drops
Errs
▼Pod / Containerダッシュボード
https://github.com/kashinoki38/prometheus-sample-yaml/blob/master/grafana/pod_detail-dashboard.json

Metrics
特定Podのコンテナごとの
CPU時間、Requests、
Limits
Pods Availability
Available Pods数
Pods Restarts
Pods status
Running / Pending /
Failed / Unknown
Container
Restarts
Errors
Terminated Reason
Waiting Reason
Restart Reason
Containers status
Waiting / Running
CPU
CPU使用率
Throttle
CPU Core Limits
CPU Core Requests
メモリ
メモリ使用量
Memory Limits
Memory Requests
ディスク
ネットワーク
ポート/Socket
Drops
Errs
リソース監視
USE
Pod/Containe
CPU/Memory/NW/D
k使用量
OK)

Metrics
特定Node上のPodのCPU時間
Pods Availability
Available Pods数
Pods Restarts
Pods status
Running / Pending /
Failed / Unknown
Container
Restarts
Errors
Terminated Reason
Waiting Reason
Restart Reason
Containers status
Waiting / Running
CPU
CPU使用率
Throttle
CPU Core Limits
CPU Core Requests
メモリ
メモリ使用量
Memory Limits
Memory Requests
ディスク
ネットワーク
ポート/Socket
Drops
Errs
リソース監視
USE
Pod/Containe
CPU/Memory/NW/D
k使用量
OK)

Metrics
リソース監視
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

Metrics
リソース監視
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）

Metrics
リソース監視
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）

Loggingって何を見ないといけないの
か？

Logging Lokiの紹介
Loggingの課題
• 大量のログを軽量に扱いたい（grepのような使い心地）
• メトリクス、トレーシングとの関連性を持たせたい（コンテキストスイッチを減らしたい）
→今回はLokiを採用
Lokiでできること
• Grafanaでのログ検索
• コンテキスト検索（前後の検索）
• grepライクな検索
• Grafanaでのログ時系列可視化
PromQLライクな可視化
• tracingとの連携（Grafanaへのアドオン）
詳しくは、https://de.slideshare.net/nttdata-tech/grafana-loki-
kubernetesloggingnttdata
Grafana
Promtail
Lokiのログ集約フロー

Logging 解析観点
観点
• エラーメッセージ
• 時系列でのエラー量
grepライクな検索
エラーメッセージ
Label
(どのPod/Container/app
etc)
前後のログ行
エラー検索（sock-shop namespaceのエラー）
時系列でのエラー量可視化
（Podごとのエラー量）
PromQLライクなクエリ
エラー量の可視化
任意のラベルで集計可

Tracingって何を見ないといけないの
か？

Tracing 依存関係可視化
Tracingでやりたいこと１
• サービス間の呼び出し依存関係
• 各呼び出しのResponse Time、スループット、エ
ラー率
→Kialiで可能
でできること
• サービス感の依存関係グラフ
• 依存関係に重ねて、Response Time、スルー
プット、エラー率
が見える
• 実態のデータはenvoyのPrometheusメトリクス
から取得

Tracing 分散トレーシング
Tracingでやりたいこと２
• 分散トレーシング（各サービスのレイテンシの包含関係）
でできること
• Spanによる表示で後続のサービスが占める時間を可視化できる

Observability
Test Environment
Prometheus
Logging
sock-
shop
istio-system
monitoring
jmeter
Metrics
Tracing
負荷がけ
サンプルアプリ
Grafana

余談ですが、
性能試験ってやってますか？

余談ですが、
A) 本番リリース直前に毎回やってる（自動化最強）
B) 重要なリリース前のみやってる＋カナリアリリースして問題あったら
切り戻し
C) ほぼやってない（祈る）

余談ですが、
A) 本番リリース直前に毎回やってる（自動化最強）
B) 重要なリリース前のみやってる＋カナリアリリースして問題あったら
切り戻し
C) ほぼやってない（祈る）
DevPerfOps (DevOps内での性能担保方法論)検討
中…
ケーススタディ教えてください！
ぜひ議論したいです。https://kashionki38.hatenablog.com/
(Hatena)
@ka_shino_ki (Twitter)
kashinoki38 (GitHub)

解析事例

解析事例
事例何を見るか確認観点
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で検索
し、具体的エラーメッセージの確認
• エラーの頻度等の時系列可視化

1. Nodeのリソース枯渇
1. Node Exporterのリソースグラフを確認
• この場合、とあるNodeのCPU使用率を確認すると1台の使用率がサチっている
何がCPUを食っているのか
NodeのCPU使用率

2. 何がNodeのリソースを食っているのか
A) 複数のPodの積み重ねでNodeのCPUを食っているケース
→PodリソースグラフをNodeで絞ってPodのリソースを積み上げグラフで確認
特定Node内の全PodのCPU使用率積み上げ

2. 何がNodeのリソースを食っているのか
B) 複数のPodの積み重ねで見てもNodeのCPU使用量に乖離がある
＝Node上のコンテナ以外から使用されるプロセスが食っているケース
→Process exporterの各Node積み上げで確認する
特定Node内の全ProcessのCPU使用率積み上
げ

2. コンテナのリソースLimits抵触
1. Podのリソースグラフにて対象namespce上の全コンテナのリ
ソース使用量とLimits, Requetsを眺める
• 黄色→Limits、水色→Usage
• CPU, Memory
各コンテナのCPU使用量、Limits、
Requests

2. Limitsにあたってしまってスケールできていないコンテナがいない
か
A) この場合はCPUのLimitsにあたってfront-endコンテナのCPUが枯渇してい
るのがわかる
front-end pod内のコンテナのCPU使用量、Limits、
Requests

2. Limitsにあたってしまってスケールできていないコンテナがいない
か
B) MemoryのLimitsに当たる場合はOOM KilledやRestartsを繰り返している
ことが多い
ContainerのRestart回数

3. MWリソースの枯渇
すみません、go, nodejsはまた今度
• Javaで見るべきリソース
• ヒープ/GC
• Thread Pool
• Connection Pool
→※Defaultで取れないので考慮必要
JMX Dashboard

 ヒープ/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

GCログも標準出力しておくようにすると、どこまでヒープ拡張しようとしていたのか把握可能
• 下記の例だと232MBまでヒープが拡張しており、Metaspaceと合わせるとLimitsに対して
拡張しすぎていることが把握可能
標準出力されたGCログ GCログの1分ごとの出力回数

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の追加

つながると以下のような情報が容易に取れる
GCやThreadなどのJVMリソース情報
CPUサンプリング
サンプリング結果のSnapshot

例えばOrdersのJavaAPにつないでみると、
• 最も時間がかかっているのはnewOrder()メソッド（あくまで比較的という話）
• newOrder()から呼ばれるFutureTask.get()
• 他サービスへのREST呼び出しの非同期処理の結果取得

分散トレーシングでみても
確かにordersの他サービス呼び出しに時間がかかっているように見える

5. 後続サービスの遅延
1. まずはKialiを眺めて、依存関係上にResponseTimeをマッピングす
る
• エラーは色分けされて出るのでエラー有無も把握可能
• この場合、front-end→catalogue部分で遅延
• サービスが多くなればなるほど重要。いきなりリソース解析せずこれでREDベー
スであたりをつける

5. 後続サービスの遅延
2. Jaegerでより詳細にトレースサンプルを確認する
• この場合、catalogue/size?tagsの呼び出しが遅延しているのがわかる
• あくまでサンプリングなので、KialiやPrometheusの統計的なデータと合わせて確認する

6. アプリケーションのエラー
1. Istio workloadダッシュボードでHTTPコードベースでエラー有無
確認
• この場合、front-end→ordersでordersが406を返していることがわかる

2. Lokiにて、当該時間のエラーの確認
• front-endが受け取ったエラー
• 406としてPayment declined : amount exceeds 100.00 とあり、
APで設定しているOrder可能回数に抵触していることがわかった

3. Lokiにて、当該時間のエラーの可視化
• 例えば、1分間に平均どれくらいエラーが発生しているのかが可視化できる

まとめ

まとめ
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はまだまだ余地があるので調査していきたい

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Kubernetesでの性能解析～なんとなく遅いからの脱却～（Kubernetes Meetup Tokyo #33 発表資料）

Ähnlich wie Kubernetesでの性能解析～なんとなく遅いからの脱却～（Kubernetes Meetup Tokyo #33 発表資料） (20)

Mehr von NTT DATA Technology & Innovation

Mehr von NTT DATA Technology & Innovation (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (7)