Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Kubernetes環境に対する性能試験
Search
kashinoki38 - Yasuhiro Horiuchi
June 30, 2020
Technology
3
3.4k
Kubernetes環境に対する性能試験
2020/06/30 Kubernetes Novice Tokyo #2でのLT資料です。
kashinoki38 - Yasuhiro Horiuchi
June 30, 2020
Tweet
Share
More Decks by kashinoki38 - Yasuhiro Horiuchi
See All by kashinoki38 - Yasuhiro Horiuchi
NRF 2025 現地レポート
kashinoki38
0
42
EKS Auto Mode
kashinoki38
3
3.9k
Amazon Bedrock のビジネスへ適用を紹介します!Eコマースにおける課題を Amazon Bedrock で解決、事例とデモの紹介@2024/7/24 JAWS EXPERT online
kashinoki38
0
140
Amazon Personalize導入前に整理したい、ビジネス観点でのレコメンドの考え方
kashinoki38
0
200
Eコマースビジネスにおける生成AIの活用
kashinoki38
0
88
生成 AI が切り開く新たな小売消費財の体験
kashinoki38
0
160
AWS Developer Live Show「難しい事抜きでまずはコンテナを運用してみよう!」/ Let's try operate your container
kashinoki38
0
250
ECS Service Connect で ECS 上のマイクロサービスの耐障害性と可観測性を高めよう
kashinoki38
3
1.4k
KEDAを使ったイベント駆動オートスケーリング
kashinoki38
0
690
Other Decks in Technology
See All in Technology
Claude Code に プロジェクト管理やらせたみた
unson
6
4.1k
ビズリーチが挑む メトリクスを活用した技術的負債の解消 / dev-productivity-con2025
visional_engineering_and_design
3
7.7k
AWS認定を取る中で感じたこと
siromi
1
190
Zero Data Loss Autonomous Recovery Service サービス概要
oracle4engineer
PRO
2
7.8k
MUITにおける開発プロセスモダナイズの取り組みと開発生産性可視化の取り組みについて / Modernize the Development Process and Visualize Development Productivity at MUIT
muit
1
16k
OSSのSNSツール「Misskey」をさわってみよう(右下ワイプで私のOSCの20年を振り返ります) / 20250705-osc2025-do
akkiesoft
0
170
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
50
20k
freeeのアクセシビリティの現在地 / freee's Current Position on Accessibility
ymrl
2
200
使いたいMCPサーバーはWeb APIをラップして自分で作る #QiitaBash
bengo4com
0
1.9k
ビズリーチにおけるリアーキテクティング実践事例 / JJUG CCC 2025 Spring
visional_engineering_and_design
1
120
PO初心者が考えた ”POらしさ”
nb_rady
0
210
Enhancing SaaS Product Reliability and Release Velocity through Optimized Testing Approach
ropqa
1
230
Featured
See All Featured
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Become a Pro
speakerdeck
PRO
29
5.4k
Designing Experiences People Love
moore
142
24k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
Unsuck your backbone
ammeep
671
58k
Adopting Sorbet at Scale
ufuk
77
9.5k
4 Signs Your Business is Dying
shpigford
184
22k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.5k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.4k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Transcript
マスター タイトルの書式設定 1 Kubernetes環境に対する 性能試験 2020/06/30 Kubernetes Novice Tokyo #2
@kashinoki38 Yasuhiro Horiuchi
マスター タイトルの書式設定 2 Agenda • 自己紹介 • 概要 • デモアプリと実施していること
• 性能試験のための基盤 • 性能改善の営み@K8s の準備 • 性能評価の理解 • Prometheusで最低限監視しておきたい項目 • 監視以外に必要なモノ • 負荷がけ準備 • 試験実施 2
マスター タイトルの書式設定 3 自己紹介 3 • 某SIer勤務 • 業務:性能全般幅広く (プリセールス
/ インフラコンサル / サイジング / 性能試験 / 性能問題解決) • Kubernetes歴4ヶ月 • あんまり周りにK8sの監視ちゃんとやりながら試験してるところないなあ • ▷K8s上のアプリケーションに対する性能試験についてベストラプラクティスを 調査中 https://kashionki38.hatenablog.com/ (Hatena) @ka_shino_ki (Twitter)
マスター タイトルの書式設定 4 概要 デモアプリと実施していること 4 • Sock Shop •
https://microservices-demo.github.io/ • Weaveworksのマイクロサービスデモアプリ • 靴下のECサイト • 公式GitHubは古いので、K8s v1.16への対応が必要 ↓ https://github.com/kashinoki38/microservices-demo • 実施していること • GKE上にSock Shopをデプロイし、性能試験っぽいこと をして実施→評価→解析を回す =性能改善の営み @ K8s
マスター タイトルの書式設定 5 概要 性能試験のための基盤 5 Test Environment Prometheus Logging
sock-shop istio-system monitoring jmeter Metrics Tracing 負荷がけ サンプルアプリ Grafana
マスター タイトルの書式設定 6 性能改善の営み @K8s の準備 性能評価の理解 6 • サービス監視(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 : エラーイベントの数
マスター タイトルの書式設定 7 性能改善の営み @K8s の準備 性能評価の理解 7 • サービス監視(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 : エラーイベントの数 後から情報取るのは困難、、 コマンドだけだと対象が多すぎて全部見れない、、
マスター タイトルの書式設定 8 性能改善の営み @K8s の準備 性能評価の理解 8 • サービス監視(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でできる 後から情報取るのは困難、、 コマンドだけだと対象が多すぎて全部見れない、、
マスター タイトルの書式設定 9 性能改善の営み @K8s の準備 Prometheusで最低限監視しておきたい項目 9 種別 監視対象
メトリクス How 観点 サービス監視 RED Jmeter クライアント側 Throughput ResponseTime Error% Jmeterのメトリクスを収集 BackendListner->InfluxDB->Grafana 試験の性能目標に対して達成して いるかどうか システム側 Throughput ResponseTime Error% Istioのテレメトリ機能で各serviceのメ トリクスを収集 現状、評価よりは解析用途 (SLOを達成しているかどうか?) リソース監視 USE Node CPU/Memory/NW/Disk 使用量 NodeExporterをDaemonSetとして配置し収 集 各Nodeのリソース上限に抵触して いないか Pod/Container CPU/Memory使用量 cAdvisorにて収集 (Kubeletバイナリに統合されているので scrapeの設定のみでOK) Limitsに抵触していないか 急に死んでいないか • これに加え主要なMWのメトリクスも見ておきたい • Nginx / MySQL / MongoDB • さらに管理リソースの監視も必要のはず • K8s, Istioのコントロールプレーン • kubelet, kube-proxy, envoy トラブル事例含 めて調査中
マスター タイトルの書式設定 11 • Observabilityの3柱 • Metrics→Done by Prometheus •
Logging→Loki • 重要性:基本的に永続化されない。kubectl logsじゃきつい トラシューしたいときに残っているようにしたい • Tracing→ • 重要性:MSA数珠つなぎでややこしい E2Eで遅くても原因のサービスにたどり着けない 11 https://peter.bourgon.org/blog/2017/02/21/metrics- tracing-and-logging.html トラブル事例含め て調査中 トラブル事例含め て調査中 性能改善の営み @K8s の準備 監視以外に必要なモノ
マスター タイトルの書式設定 12 性能改善の営み @K8s の準備 12 Test Environment Prometheus
Logging sock-shop istio-system monitoring jmeter Metrics Tracing 負荷がけ サンプルアプリ Grafana
マスター タイトルの書式設定 13 性能改善の営み @K8s の準備 負荷がけ準備 13 • 負荷がけクライアントもK8sにデプロイしたい
• とりあえずJmeterで探してみる • Jmeter Operator発見 https://github.com/kubernauts/jmeter-operator • Operatorが割とCPUを食うので一旦Operatorはやめて、Deploymentだけに PodのCPU使用率
マスター タイトルの書式設定 14 性能改善の営み @K8s の準備 14 Test Environment Prometheus
Logging sock-shop istio-system monitoring jmeter Metrics Tracing 負荷がけ サンプルアプリ Grafana
マスター タイトルの書式設定 16 試験実施 16 • シナリオ • 登録済みのユーザによる、ソックス購入シナリオ •
jmeterシナリオ https://github.com/kashinoki38/microservices-demo/blob/master/deploy/kubernetes/manifests- loadtest/scenario.jmx • シナリオフロー https://github.com/kashinoki38/microservices- demo/blob/master/deploy/kubernetes/loadtests/scenario-definition.xlsx
マスター タイトルの書式設定 17 試験実施 – shot1 17 • 目標負荷:100tps(Transaction =
PV) • 未達 Jmeter実行結果
マスター タイトルの書式設定 18 試験実施 – shot1 Node1台のCPUがサチっている 18 • NodeのCPU使用率を確認すると1台の使用率がサチっている
NodeのCPU使用率
マスター タイトルの書式設定 19 試験実施 – shot1 Node1台のCPUがサチっている 19 • NodeのCPU使用率を確認すると1台の使用率がサチっている
ノードを追加 後から思えばpodの ノード偏りもあった NodeのCPU使用率
マスター タイトルの書式設定 20 試験実施 – shot2 20 • 目標負荷:100tps(Transaction =
PV) • 達成 Jmeter実行結果
マスター タイトルの書式設定 21 試験実施 – shot3 21 • 目標負荷:150tps(Transaction =
PV) • 未達 • Topページが大幅に遅延 Jmeter実行結果
マスター タイトルの書式設定 22 試験実施 – shot3 22 • 目標負荷:150tps(Transaction =
PV) • 未達 • Topページが大幅に遅延 • 解析 • front-end podのContainerのCPU使用量がLimits付近 front-end containerのCPU使用量 TopのJmeterレスポンスタイム
マスター タイトルの書式設定 23 試験実施 – shot3 23 • 目標負荷:150tps(Transaction =
PV) • 未達 • Topページが大幅に遅延 • 解析 • front-end podのContainerのCPU使用量がLimits付近 • front-end→catalogueのoutgoing request durationが遅い Istio Workload front-end
マスター タイトルの書式設定 24 試験実施 – shot3 24 • 目標負荷:150tps(Transaction =
PV) • 未達 • Topページが大幅に遅延 • 解析 • front-end podのContainerのCPU使用量がLimits付近 • front-end→catalogueのoutgoing request durationが遅い • catalogueのRequest Durationが遅い Istio Workload front-end Istio Workload catalogue
マスター タイトルの書式設定 25 試験実施 – shot3 25 • 目標負荷:150tps(Transaction =
PV) • 未達 • Topページが大幅に遅延 • 解析 • front-end podのContainerのCPU使用量がLimits付近 • front-end→catalogueのoutgoing request durationが遅い • catalogueのRequest Durationが遅い • catalogue containerがrestartしている時間でJmeterの レスポンスが遅延 not ready catalogue containerのCPU使用率 TopのJmeterレスポンスタイム catalogue container ready数 catalogue container restart
マスター タイトルの書式設定 26 試験実施 – shot3 26 • 目標負荷:150tps(Transaction =
PV) • 未達 • Topページが大幅に遅延 • 解析 • front-end podのContainerのCPU使用量がLimits付近 • front-end→catalogueのoutgoing request durationが遅い • catalogueのRequest Durationが遅い • catalogue containerがrestartしている時間でJmeterの レスポンスが遅延 • catalogue containerがrestartしている時間でnpm ERR! 頻発 catalogue podのログ
マスター タイトルの書式設定 27 試験実施 – shot3 27 • 目標負荷:150tps(Transaction =
PV) • 未達 • Topページが大幅に遅延 • 解析 • front-end podのContainerのCPU使用量がLimits付近 • front-end→catalogueのoutgoing request durationが遅い • catalogueのRequest Durationが遅い • catalogue containerがrestartしている時間でJmeterの レスポンスが遅延 • catalogue containerがrestartしている時間でnpm ERR! 頻発 • ボトルネック仮説 • front-endのCPU枯渇 → Podを増設、プロファイリング • catalogueの遅延+エラー頻発 → 詳細解析(How?)
マスター タイトルの書式設定 28 試験実施 – shot3 28 • 目標負荷:150tps(Transaction =
PV) • 未達 • Topページが大幅に遅延 • 解析 • front-end podのContainerのCPU使用量がLimits付近 • front-end→catalogueのoutgoing request durationが遅い • catalogueのRequest Durationが遅い • catalogue containerがrestartしている時間でJmeterの レスポンスが遅延 • catalogue containerがrestartしている時間でnpm ERR! 頻発 • ボトルネック仮説 • front-endのCPU枯渇 → Podを増設、プロファイリング • catalogueの遅延+エラー頻発 → 詳細解析(How?) 力尽きた
マスター タイトルの書式設定 29 今後の改善事項 29 • まとめ • Sock Shopに対して最低限のリソースとサービスメトリクスを評価する基盤作った
• 作業途中のものは随時ここに →https://github.com/kashinoki38/microservices-demo/tree/master/deploy/kubernetes • とりあえず性能改善の営みをなんとなく回せる • 改善事項 • ボトルネック情報の蓄積←ぜひ教えて下さい! • 試験実施改善 • 自動化 • シナリオのバージョン管理+試験結果との紐付け • 詳細な解析 • MWリソース、プロファイリングの差し込み方 • Jaeger, Kiali, Lokiの有効活用