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.3k
Amazon Bedrock のビジネスへ適用を紹介します!Eコマースにおける課題を Amazon Bedrock で解決、事例とデモの紹介@2024/7/24 JAWS EXPERT online
kashinoki38
0
110
Amazon Personalize導入前に整理したい、ビジネス観点でのレコメンドの考え方
kashinoki38
0
130
Eコマースビジネスにおける生成AIの活用
kashinoki38
0
51
生成 AI が切り開く新たな小売消費財の体験
kashinoki38
0
120
AWS Developer Live Show「難しい事抜きでまずはコンテナを運用してみよう!」/ Let's try operate your container
kashinoki38
0
180
ECS Service Connect で ECS 上のマイクロサービスの耐障害性と可観測性を高めよう
kashinoki38
3
1k
KEDAを使ったイベント駆動オートスケーリング
kashinoki38
0
500
re:Invent 2022 reCap Container アップデート
kashinoki38
0
240
Other Decks in Technology
See All in Technology
Server Side Swift 実践レポート: 2024年に案件で採用して見えた課題と可能性
yusuga
1
420
例外処理を理解して、設計段階からエラーを「見つけやすく」「起こりにくく」する
kajitack
12
3.8k
Site Reliability Engineering on Kubernetes
nwiizo
6
4.4k
ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making
snoozer05
PRO
17
4k
データ基盤の成長を加速させる:アイスタイルにおける挑戦と教訓
tsuda7
0
110
AWSエンジニアに捧ぐLangChainの歩き方
tsukuboshi
0
220
企業テックブログにおける執筆ネタの考え方・見つけ方・広げ方 / How to Think of, Find, and Expand Writing Topics for Corporate Tech Blogs
honyanya
0
820
プロダクト開発、インフラ、コーポレート、そしてAIとの共通言語としての Terraform / Terraform as a Common Language for Product Development, Infrastructure, Corporate Engineering, and AI
yuyatakeyama
6
1.6k
第27回クラウド女子会 ~re:Invent 振り返りLT会~ 宣言型ポリシー、使ってみたらこうだった!
itkr2305
0
290
もし今からGraphQLを採用するなら
kazukihayase
9
4.2k
あなたはJVMの気持ちを理解できるか?
skrb
5
2k
Redshiftを中心としたAWSでのデータ基盤
mashiike
0
100
Featured
See All Featured
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.6k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
39
1.9k
Embracing the Ebb and Flow
colly
84
4.5k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
Documentation Writing (for coders)
carmenintech
67
4.6k
Thoughts on Productivity
jonyablonski
68
4.4k
Become a Pro
speakerdeck
PRO
26
5.1k
A Tale of Four Properties
chriscoyier
157
23k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
27
1.9k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.5k
GraphQLの誤解/rethinking-graphql
sonatard
68
10k
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の有効活用