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.3k
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
EKS Auto Mode
kashinoki38
1
2.8k
Amazon Bedrock のビジネスへ適用を紹介します!Eコマースにおける課題を Amazon Bedrock で解決、事例とデモの紹介@2024/7/24 JAWS EXPERT online
kashinoki38
0
110
Amazon Personalize導入前に整理したい、ビジネス観点でのレコメンドの考え方
kashinoki38
0
140
Eコマースビジネスにおける生成AIの活用
kashinoki38
0
55
生成 AI が切り開く新たな小売消費財の体験
kashinoki38
0
120
AWS Developer Live Show「難しい事抜きでまずはコンテナを運用してみよう!」/ Let's try operate your container
kashinoki38
0
190
ECS Service Connect で ECS 上のマイクロサービスの耐障害性と可観測性を高めよう
kashinoki38
3
1.1k
KEDAを使ったイベント駆動オートスケーリング
kashinoki38
0
530
re:Invent 2022 reCap Container アップデート
kashinoki38
0
250
Other Decks in Technology
See All in Technology
IoTシステム開発の複雑さを低減するための統合的アーキテクチャ
kentaro
1
110
AWSアカウントのセキュリティ自動化、どこまで進める? 最適な設計と実践ポイント
yuobayashi
7
580
システム・ML活用を広げるdbtのデータモデリング / Expanding System & ML Use with dbt Modeling
i125
1
320
ディスプレイ広告(Yahoo!広告・LINE広告)におけるバックエンド開発
lycorptech_jp
PRO
0
360
Potential EM 制度を始めた理由、そして2年後にやめた理由 - EMConf JP 2025
hoyo
2
2.6k
(機械学習システムでも) SLO から始める信頼性構築 - ゆる SRE#9 2025/02/21
daigo0927
0
270
分解して理解する Aspire
nenonaninu
2
1.1k
株式会社Awarefy(アウェアファイ)会社説明資料 / Awarefy-Company-Deck
awarefy
3
11k
Snowflakeの開発・運用コストをApache Icebergで効率化しよう!~機能と活用例のご紹介~
sagara
1
440
AI Agent時代なのでAWSのLLMs.txtが欲しい!
watany
2
220
2/18 Making Security Scale: メルカリが考えるセキュリティ戦略 - Coincheck x LayerX x Mercari
jsonf
0
210
ESXi で仮想化した ARM 環境で LLM を動作させてみるぞ
unnowataru
0
180
Featured
See All Featured
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.7k
Measuring & Analyzing Core Web Vitals
bluesmoon
6
250
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
1k
How to Ace a Technical Interview
jacobian
276
23k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Bash Introduction
62gerente
611
210k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
10
510
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
10
1.3k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.3k
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の有効活用