Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
© 2021 NTT DATA Corporation
継続的な性能担保、DevPerfOpsという考え方
2021/03/11 CloudNative Days Spring 2021 ONLINE
NTT DATA 技術革新統括本部 デジタ...
© 2021 NTT DATA Corporation 2
Agenda
1. Who am I?
2. 本セッションの目的、DevPerfOpsとは?
3. Progressive Delivery
4. リソースデプロイ時の自動負荷試験
5...
© 2021 NTT DATA Corporation 3
Who am I?
• 堀内 保大, Yasuhiro Horiuchi
• NTT DATA 技術革新統括本部 デジタルテクノロジ推進室
“まかせいのう”
• https://www...
© 2021 NTT DATA Corporation 4
What’s デジタルテクノロジ推進室
・デジタル化に必要な豊富な知識を持った技術者(デジタルテクノロジーディレクター、DTD)
・DTDをお客さま拠点に派遣しお客さまのデジタル化推進...
© 2021 NTT DATA Corporation 5
What’s まかせいのう
・“性能はまかせろ“ → まかせいのう
・創業12年の実績から、試験方法論や監視観点、解析プロセスを整備
・性能に関して一気通貫で上流から下流まで対応
・海...
© 2021 NTT DATA Corporation 6
本セッションの目的、DevPerfOpsとは?
CI/CDパイプラインへの性能担保プロセス導入の課題感
• 継続的にリリースが走る場合、性能試験は一度きりだと以下のようなリスクが想定さ...
© 2021 NTT DATA Corporation 7
本セッションの目的、DevPerfOpsとは?
• そこで、Kubernetesのエコシステムを活用することで、
以下のような継続性能担保アプローチ(DevPerfOps)を検討
①性...
© 2021 NTT DATA Corporation 8
本セッションの目的、DevPerfOpsとは?
特定ブランチへ
のプッシュ
①性能試験アジリティ向上:Kubernetesリソースデプロイ時の自動負荷試験
②本番リリース時の性能リスク...
© 2021 NTT DATA Corporation 9
本セッションの目的、DevPerfOpsとは?
特定ブランチへ
のプッシュ
①性能試験アジリティ向上:Kubernetesリソースデプロイ時の自動負荷試験
②本番リリース時の性能リスク...
© 2021 NTT DATA Corporation 10
Progressive Delivery
© 2021 NTT DATA Corporation 11
Progressive Deliveryとは
Progressive Deliveryとは
• CDの次のステップとして位置づけられた比較的新しいリリース方式
• 従来のリリースに①...
© 2021 NTT DATA Corporation 12
Progressive Deliveryとは
Progressive Deliveryのフロー例(カナリーリリースの場合)
• カナリーリリース実施中に、SLA等のメトリクスを定期的...
© 2021 NTT DATA Corporation 13
Progressive Deliveryのフロー例(カナリーリリースの場合)
• カナリーリリース実施中に、SLA等のメトリクスを定期的に評価をしながら、一定の割合までトラフィックを...
© 2021 NTT DATA Corporation 14
Progressive Deliveryとは
設定例:
1分おきに5%ずつトラフィックを増加
1分おきにスループットとレスポンスタイムを評価
50%に到達するまでにしきい値を5回下回...
© 2021 NTT DATA Corporation 15
Progressive Deliveryとは
設定例:
1分おきに5%ずつトラフィックを増加
1分おきにスループットとレスポンスタイムを評価
50%に到達するまでにしきい値を5回下回...
© 2021 NTT DATA Corporation 16
Progressive Deliveryとは
設定例:
1分おきに5%ずつトラフィックを増加
1分おきにスループットとレスポンスタイムを評価
50%に到達するまでにしきい値を5回下回...
© 2021 NTT DATA Corporation 17
Progressive Deliveryとは
Progressive Deliveryができるツールは以下あたり
• Flagger
• weaveworks社
• Service ...
© 2021 NTT DATA Corporation 18
Progressive Deliveryとは
Progressive Deliveryができるツールは以下あたり
• Flagger → 今回使用
• weaveworks社
• S...
© 2021 NTT DATA Corporation 19
Flaggerによる
Progressive Delivery
実践
© 2021 NTT DATA Corporation 20
FlaggerによるProgressive Delivery実践
Flaggerアーキテクチャ
• IstioならVirtualServiceをOperatorが自動で書き換えていく...
© 2021 NTT DATA Corporation 21
FlaggerによるProgressive Delivery実践
• HelmでFlaggerをインストール
$ helm upgrade -i flagger flagger/fl...
© 2021 NTT DATA Corporation 22
FlaggerによるProgressive Delivery実践
• Flaggerの設定(canary.yaml)
Flaggerの詳細設定(リリース方式、Canary Analy...
© 2021 NTT DATA Corporation 23
FlaggerによるProgressive Delivery実践
• Flaggerの設定(canary.yaml)
▼Flagger の監視対象設定
対象となる deploymen...
© 2021 NTT DATA Corporation 24
FlaggerによるProgressive Delivery実践
▼評価判定条件
.spec.analysis.metricsにて評価中の判定条件を設
定できる。
analysis:...
© 2021 NTT DATA Corporation 25
FlaggerによるProgressive Delivery実践
▼webhooks設定
.spec.analysis.webhooksにて評価の前中後で実施するテストを定義できる。...
© 2021 NTT DATA Corporation 26
• Canaryリソースのデプロイ(deploy/podinfoをtargetに設定)
Service と Deployment と VirtualService が作成される。
F...
© 2021 NTT DATA Corporation 27
FlaggerによるProgressive Delivery実践
$ kubectl -n test set image deployment/podinfo podinfod=st...
© 2021 NTT DATA Corporation 28
FlaggerによるProgressive Delivery実践
imageのバージョンを変更し、Progressive Deliveryを開始させる。
新しいバージョンにcanar...
© 2021 NTT DATA Corporation 29
FlaggerによるProgressive Delivery実践
imageのバージョンを変更し、Progressive Deliveryを開始させる。
新しいバージョンにcanar...
© 2021 NTT DATA Corporation 30
Flagger webhooksによる
Kubernetesリソースデプロイ時の
自動負荷試験
準備編
© 2021 NTT DATA Corporation 31
Kubernetesリソースデプロイ時の自動負荷試験
サンプルアプリ紹介
sock-shop をサンプルアプリとして、Observability と負荷試験自動化スタックを追加
→h...
© 2021 NTT DATA Corporation 32
Kubernetesリソースデプロイ時の自動負荷試験
サンプルアプリ アーキテクチャ
istio-system
Tracing
jmeter
sock-shop サンプルアプリ
ku...
© 2021 NTT DATA Corporation 33
Kubernetesリソースデプロイ時の自動負荷試験
サンプルアプリ アーキテクチャ
istio-system
Tracing
jmeter
sock-shop サンプルアプリ
ku...
© 2021 NTT DATA Corporation 34
Kubernetesリソースデプロイ時の自動負荷試験
サンプルアプリ アーキテクチャ
istio-system
Tracing
jmeter
sock-shop サンプルアプリ
ku...
© 2021 NTT DATA Corporation 35
Kubernetesリソースデプロイ時の自動負荷試験
Flagger x Jmeter
Jmeterへの対応
・FlaggerのloadtesterにJmeterを注入したイメージ(...
© 2021 NTT DATA Corporation 36
Kubernetesリソースデプロイ時の
自動負荷試験
実施編
© 2021 NTT DATA Corporation 37
Kubernetesリソースデプロイ時の自動負荷試験
実施フロー
istio-system
jmeter
sock-shop
kube-Prometheus-stack
monito...
© 2021 NTT DATA Corporation 38
Kubernetesリソースデプロイ時の自動負荷試験
A. デプロイ成功例
© 2021 NTT DATA Corporation 39
Kubernetesリソースデプロイ時の自動負荷試験
A. デプロイ成功例
targetのDeployment変更検知
Slackへも変更検知を通知
© 2021 NTT DATA Corporation 40
Kubernetesリソースデプロイ時の自動負荷試験
A. デプロイ成功例
疎通試験成功
© 2021 NTT DATA Corporation 41
Kubernetesリソースデプロイ時の自動負荷試験
A. デプロイ成功例
負荷試験実施中(10分間)
2分ごとに5セット自動評価が実施される
・SuccessRate:90%以上
...
© 2021 NTT DATA Corporation 42
Kubernetesリソースデプロイ時の自動負荷試験
A. デプロイ成功例
負荷試験実施中(10分間)
2分ごとに5セット自動評価が実施される
・SuccessRate:90%以上
...
© 2021 NTT DATA Corporation 43
Kubernetesリソースデプロイ時の自動負荷試験
A. デプロイ成功例
試験用Deploymentをメインに昇格し、
Ingress gwからのトラフィックの向き先とする
Sla...
© 2021 NTT DATA Corporation 44
Kubernetesリソースデプロイ時の自動負荷試験
B. デプロイ失敗例
処理に2000msのスリープを追加
app.get("/catalogue*", function (re...
© 2021 NTT DATA Corporation 45
Kubernetesリソースデプロイ時の自動負荷試験
B. デプロイ失敗例
targetのDeployment変更検知
Slackへも変更検知を通知
© 2021 NTT DATA Corporation 46
Kubernetesリソースデプロイ時の自動負荷試験
B. デプロイ失敗例
負荷試験実施中(10分間)
2分ごとに5セット自動評価が実施される
request-duration-cu...
© 2021 NTT DATA Corporation 47
Kubernetesリソースデプロイ時の自動負荷試験
B. デプロイ失敗例
負荷試験実施中(10分間)
2分ごとに5セット自動評価が実施される
request-duration-cu...
© 2021 NTT DATA Corporation 48
Kubernetesリソースデプロイ時の自動負荷試験
B. デプロイ失敗例
自動評価が5回失敗したため、Rolling back
(試験用を切り離し)
試験用Deploymentを0...
© 2021 NTT DATA Corporation 49
まとめ
© 2021 NTT DATA Corporation 50
DevPerfOps再整理
①性能試験アジリティ向上:Kubernetesリソースデプロイ時の自動負荷試験
• ステージングや試験環境へのリリース向け
• →リリースの度に必ず負荷試...
© 2021 NTT DATA Corporation 51
課題
①性能試験アジリティ向上:Kubernetesリソースデプロイ時の自動負荷試験
• リソース効率が悪い(更新されたターゲットのPodが2倍必要)
• 試験環境が一時的にBlue...
© 2021 NTT DATA Corporation 52
まとめ
• Kubernetesのエコシステムを活用すれば継続性能担保アプローチを実施することができる
• DevPerfOpsとは?
• ①性能試験アジリティ向上:Kubernet...
© 2021 NTT DATA Corporation 53
Reference
https://github.com/fluxcd/flagger/
https://docs.flagger.app/
https://speakerdeck....
© 2021 NTT DATA Corporation
© 2021 NTT DATA Corporation
Observabilityスタック
© 2021 NTT DATA Corporation 56
性能解析の始め方→Observability
Kubernetesにおける性能解析はObservabilityを揃えることから始める
• Metrics → Prometheus
•...
© 2021 NTT DATA Corporation 57
Metrics
Prometheusで最低限監視しておきたい項目
詳しくはBlogまで
【暫定版】 Kubernetesの性能監視で必要なメトリクス一覧とPrometheusでのHo...
© 2021 NTT DATA Corporation 58
ダッシュボードのデモ
© 2021 NTT DATA Corporation 59
Logging
Loki
Loggingの課題
• 大量のログを軽量に扱いたい(grepのような使い心地)
• メトリクス、トレーシングとの関連性を持たせたい(コンテキストスイッチを...
© 2021 NTT DATA Corporation 60
Logging
Loki
観点
• エラーメッセージ
• 時系列でのエラー量
grepライクな検索
エラーメッセージ
Label
(どのPod/Container/app
etc)
...
© 2021 NTT DATA Corporation 61
Tracing
依存関係可視化
Tracingでやりたいこと1
• サービス間の呼び出し依存関係
• 各呼び出しのResponse Time、スループット、エラー率
→Kialiで可...
© 2021 NTT DATA Corporation 62
Tracing
分散トレーシング
Tracingでやりたいこと2
• 分散トレーシング(各サービスのレイテンシの包含関係)
でできること
• Spanによる表示で後続のサービスが占め...
Nächste SlideShare
Wird geladen in …5
×
Nächste SlideShare
What to Upload to SlideShare
Weiter

1

Teilen

継続的な性能担保、DevPerfOpsという考え方(CloudNative Days Spring 2021 ONLINE 発表資料)

継続的な性能担保、DevPerfOpsという考え方
(CloudNative Days Spring 2021 ONLINE 発表資料)

2021年3月11日

NTT DATA 技術革新統括本部
デジタルテクノロジ推進室 まかせいのう
堀内 保大, Yasuhiro Horiuchi

Ähnliche Bücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Ähnliche Hörbücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

継続的な性能担保、DevPerfOpsという考え方(CloudNative Days Spring 2021 ONLINE 発表資料)

  1. 1. © 2021 NTT DATA Corporation 継続的な性能担保、DevPerfOpsという考え方 2021/03/11 CloudNative Days Spring 2021 ONLINE NTT DATA 技術革新統括本部 デジタルテクノロジ推進室 まかせいのう 堀内 保大, Yasuhiro Horiuchi (@ka_shino_ki)
  2. 2. © 2021 NTT DATA Corporation 2 Agenda 1. Who am I? 2. 本セッションの目的、DevPerfOpsとは? 3. Progressive Delivery 4. リソースデプロイ時の自動負荷試験 5. まとめ
  3. 3. © 2021 NTT DATA Corporation 3 Who am I? • 堀内 保大, Yasuhiro Horiuchi • NTT DATA 技術革新統括本部 デジタルテクノロジ推進室 “まかせいのう” • https://www.nttdata.com/jp/ja/lineup/macaseinou/ • 業務:性能全般幅広く • 特に性能試験 / 性能問題解決 / Global向けプリセールス • Kubernetes歴1年 https://kashionki38.hatenablog.com/ (Hatena) @ka_shino_ki (Twitter) kashinoki38 (GitHub)
  4. 4. © 2021 NTT DATA Corporation 4 What’s デジタルテクノロジ推進室 ・デジタル化に必要な豊富な知識を持った技術者(デジタルテクノロジーディレクター、DTD) ・DTDをお客さま拠点に派遣しお客さまのデジタル化推進を強力に支援する ・全社のテクノロジーをDTDがお客様の案件に合わせてコーディネートし、提案 ・コンサルからデリバリまでの体制を確保して一気通貫でお客へ価値を提供 https://www.nttdata.com/jp/ja/lineup/digital_technology_director/ https://ndigi.tech/
  5. 5. © 2021 NTT DATA Corporation 5 What’s まかせいのう ・“性能はまかせろ“ → まかせいのう ・創業12年の実績から、試験方法論や監視観点、解析プロセスを整備 ・性能に関して一気通貫で上流から下流まで対応 ・海外グループ会社にも展開中 macaseinou! もし何か性能でお困りごとあれば何でも!まずはご連絡ください! https://www.nttdata.com/jp/ja/lineup/macaseinou/
  6. 6. © 2021 NTT DATA Corporation 6 本セッションの目的、DevPerfOpsとは? CI/CDパイプラインへの性能担保プロセス導入の課題感 • 継続的にリリースが走る場合、性能試験は一度きりだと以下のようなリスクが想定される • 過去担保したアプリケーションとことなるバージョンがリリースされることによる、性能デグレ • MWやFWのバージョン差分による性能デグレ • 一方で、 • 毎回リリースごとに手作業で負荷試験を実施していくのは現実的ではない • かといって都度本番リリースに張り付くのも大変
  7. 7. © 2021 NTT DATA Corporation 7 本セッションの目的、DevPerfOpsとは? • そこで、Kubernetesのエコシステムを活用することで、 以下のような継続性能担保アプローチ(DevPerfOps)を検討 ①性能試験アジリティ向上 Kubernetesリソースデプロイ時の自動負荷試験 ②本番リリース時の 性能リスク低減 Progressive Delivery 性能担保観点 アプローチ
  8. 8. © 2021 NTT DATA Corporation 8 本セッションの目的、DevPerfOpsとは? 特定ブランチへ のプッシュ ①性能試験アジリティ向上:Kubernetesリソースデプロイ時の自動負荷試験 ②本番リリース時の性能リスク低減:Progressive Delivery • 目指す姿 • 特定ブランチへのリリース時には性能試験が自動で走る • 本番リリース時に自動評価、自動切り戻し • カナリーリリースで本番トラフィックを使った結果分析 Performance環境へ のデプロイ開始 (GitOps) Performance環境へ試験用ア プリをデプロイし負荷試験を実施 問題あり 試験用アプリを メインに昇格 試験用アプリを切り離し パイプラインをFailed 問題なし 本番環境への デプロイ カナリーリリース リリースアプリをメインに昇格 リリースアプリを切り離し 問題あり 問題なし ① ②
  9. 9. © 2021 NTT DATA Corporation 9 本セッションの目的、DevPerfOpsとは? 特定ブランチへ のプッシュ ①性能試験アジリティ向上:Kubernetesリソースデプロイ時の自動負荷試験 ②本番リリース時の性能リスク低減:Progressive Delivery • 目指す姿 • 特定ブランチへのリリース時には性能試験が自動で走る • 本番リリース時に自動評価、自動切り戻し • カナリーリリースで本番トラフィックを使った結果分析 Performance環境へ のデプロイ開始 (GitOps) Performance環境へ試験用ア プリをデプロイし負荷試験を実施 問題あり 試験用アプリを メインに昇格 試験用アプリを切り離し パイプラインをFailed 問題なし 本番環境への デプロイ カナリーリリース リリースアプリをメインに昇格 リリースアプリを切り離し 問題あり 問題なし ① ② 本セッションではDevPerfOps実現案をサンプルアプリを使って紹介
  10. 10. © 2021 NTT DATA Corporation 10 Progressive Delivery
  11. 11. © 2021 NTT DATA Corporation 11 Progressive Deliveryとは Progressive Deliveryとは • CDの次のステップとして位置づけられた比較的新しいリリース方式 • 従来のリリースに①リリース中の評価と②自動ロールバックを追加 • これによりリリース時のリスクを軽減することが可能
  12. 12. © 2021 NTT DATA Corporation 12 Progressive Deliveryとは Progressive Deliveryのフロー例(カナリーリリースの場合) • カナリーリリース実施中に、SLA等のメトリクスを定期的に評価をしながら、一定の割合までトラフィックを増加させることが できれば完全にバージョンを切り上げる。 • 評価中にメトリクスがしきい値以下である回数が一定を超えると失敗と判定され、バージョンを切り戻す
  13. 13. © 2021 NTT DATA Corporation 13 Progressive Deliveryのフロー例(カナリーリリースの場合) • カナリーリリース実施中に、SLA等のメトリクスを定期的に評価をしながら、一定の割合までトラフィックを増加させることが できれば完全にバージョンを切り上げる。 • 評価中にメトリクスがしきい値以下である回数が一定を超えると失敗と判定され、バージョンを切り戻す Progressive Deliveryとは 設定例: 1分おきに5%ずつトラフィックを増加 1分おきにスループットとレスポンスタイムを評価 50%に到達するまでにしきい値を5回下回るとFail v2評価用のPodを新規にデプロイ 分間5%ずつ増加させていく
  14. 14. © 2021 NTT DATA Corporation 14 Progressive Deliveryとは 設定例: 1分おきに5%ずつトラフィックを増加 1分おきにスループットとレスポンスタイムを評価 50%に到達するまでにしきい値を5回下回るとFail 50%までしきい値を5回下回らな ければCanary Analysis成功 Progressive Deliveryのフロー例(カナリーリリースの場合) • カナリーリリース実施中に、SLA等のメトリクスを定期的に評価をしながら、一定の割合までトラフィックを増加させることが できれば完全にバージョンを切り上げる。 • 評価中にメトリクスがしきい値以下である回数が一定を超えると失敗と判定され、バージョンを切り戻す
  15. 15. © 2021 NTT DATA Corporation 15 Progressive Deliveryとは 設定例: 1分おきに5%ずつトラフィックを増加 1分おきにスループットとレスポンスタイムを評価 50%に到達するまでにしきい値を5回下回るとFail PrimaryのPodをv1→v2に 切り上げる Progressive Deliveryのフロー例(カナリーリリースの場合) • カナリーリリース実施中に、SLA等のメトリクスを定期的に評価をしながら、一定の割合までトラフィックを増加させることが できれば完全にバージョンを切り上げる。 • 評価中にメトリクスがしきい値以下である回数が一定を超えると失敗と判定され、バージョンを切り戻す
  16. 16. © 2021 NTT DATA Corporation 16 Progressive Deliveryとは 設定例: 1分おきに5%ずつトラフィックを増加 1分おきにスループットとレスポンスタイムを評価 50%に到達するまでにしきい値を5回下回るとFail v2確認用のPodを削除 Progressive Deliveryのフロー例(カナリーリリースの場合) • カナリーリリース実施中に、SLA等のメトリクスを定期的に評価をしながら、一定の割合までトラフィックを増加させることが できれば完全にバージョンを切り上げる。 • 評価中にメトリクスがしきい値以下である回数が一定を超えると失敗と判定され、バージョンを切り戻す
  17. 17. © 2021 NTT DATA Corporation 17 Progressive Deliveryとは Progressive Deliveryができるツールは以下あたり • Flagger • weaveworks社 • Service mesh(Istio, Linkerd, App mesh)前提 • Argo Rollouts • Argoプロジェクト • Argo CD等と組み合わせ可能 • 最近はService meshと組み合わせたトラフィック管理も可能 • Spinnaker (+ Kayenta) • PipeCD
  18. 18. © 2021 NTT DATA Corporation 18 Progressive Deliveryとは Progressive Deliveryができるツールは以下あたり • Flagger → 今回使用 • weaveworks社 • Service mesh(Istio, Linkerd, App mesh)前提 • Argo Rollouts • Argoプロジェクト • Argo CD等と組み合わせ可能 • 最近はService meshと組み合わせたトラフィック管理も可能 • Spinnaker (+ Kayenta) • PipeCD
  19. 19. © 2021 NTT DATA Corporation 19 Flaggerによる Progressive Delivery 実践
  20. 20. © 2021 NTT DATA Corporation 20 FlaggerによるProgressive Delivery実践 Flaggerアーキテクチャ • IstioならVirtualServiceをOperatorが自動で書き換えていくことで、v2評価用(canary)へのトラフィック量を増加さ せていく動きを実現 • 評価のメトリクスはPrometheus等から取得できる
  21. 21. © 2021 NTT DATA Corporation 21 FlaggerによるProgressive Delivery実践 • HelmでFlaggerをインストール $ helm upgrade -i flagger flagger/flagger —namespace=istio-system —set metricsServer=http://prometheus.istio-system:9090 —set slack.url=https://hooks.slack.com/services/YOUR-WEBHOOK-ID —set slack.channel=general —set slack.user=flagger $ kubectl get deploy -n istio-system NAME READY UP-TO-DATE AVAILABLE AGE flagger 1/1 1 1 9h
  22. 22. © 2021 NTT DATA Corporation 22 FlaggerによるProgressive Delivery実践 • Flaggerの設定(canary.yaml) Flaggerの詳細設定(リリース方式、Canary Analysisのパラメータ等)はCanaryリソースで定義する。 apiVersion: flagger.app/v1beta1 kind: Canary metadata: name: sock-shop namespace: sock-shop spec: ...
  23. 23. © 2021 NTT DATA Corporation 23 FlaggerによるProgressive Delivery実践 • Flaggerの設定(canary.yaml) ▼Flagger の監視対象設定 対象となる deployment を.spec.targetRefに記載。 当該 Deployment に変更が加わった際に Canary Analysis が開始される。 spec: # deployment reference targetRef: apiVersion: apps/v1 kind: Deployment name: podinfo ▼リリース方式と Canary Analysis 設定 .spec.analysisにて設定 Canary Release の場合 ・maxWeight%までstepWeight%ずつ新規 Deployment へトランザクションを増加さ せて割り振る ・リトライ間隔(interval), rollback するまでののリトライ回数(threshold) Blue/Green デプロイメントの場合 • maxWeight, stepWeightを設定せず、iterationsを設定することで Blue/Green デプロイメントを実現可能。 • 1分 × iterationsの間、Analysis が実施される。 analysis: # schedule interval (default 60s) interval: 1m # max number of failed metric checks before rollback threshold: 5 # max traffic percentage routed to canary # percentage (0-100) maxWeight: 50 # canary increment step # percentage (0-100) stepWeight: 10
  24. 24. © 2021 NTT DATA Corporation 24 FlaggerによるProgressive Delivery実践 ▼評価判定条件 .spec.analysis.metricsにて評価中の判定条件を設 定できる。 analysis: ... metrics: - name: request-success-rate # minimum req success rate (non 5xx responses) # percentage (0-100) thresholdRange: min: 99 interval: 1m - name: request-duration # maximum req duration P99 # milliseconds thresholdRange: max: 1000 interval: 30s apiVersion: flagger.app/v1beta1 kind: MetricTemplate metadata: name: request-duration-custome namespace: istio-system spec: provider: type: prometheus address: http://kube-prometheus-stack- prometheus.monitoring.svc.cluster.local:9090 query: | histogram_quantile(0.95, sum( irate( istio_request_duration_milliseconds_bucket{ reporter="destination", destination_workload=~"front-end", destination_workload_namespace=~"sock-shop" }[2m] ) ) by (le) ) • Flaggerの設定(canary.yaml) ※MetricTemplateで任意のPromQLでメトリクスを定義可能 リソースなどPrometheus上のメトリクス使って独自で条件を定義で きる
  25. 25. © 2021 NTT DATA Corporation 25 FlaggerによるProgressive Delivery実践 ▼webhooks設定 .spec.analysis.webhooksにて評価の前中後で実施するテストを定義できる。 例: ・評価前に単疎通テスト ・評価中に負荷テスト webhooks: - name: acceptance-test type: pre-rollout # Canary Analysis前 url: http://flagger-loadtester.test/ timeout: 30s metadata: type: bash cmd: “curl -sd ‘test’ http://podinfo-canary:9898/token | grep token” # 任意のコマンドを指定可能 - name: load-test url: http://flagger-loadtester.test/ timeout: 5s metadata: cmd: “hey -z 1m -q 10 -c 2 http://podinfo-canary.test:9898/“ # 任意のコマンドを指定可能 • Flaggerの設定(canary.yaml) ⇒webhooksを活用することで、リソースデプロイ時の自動負荷試験が実現可能(後述)
  26. 26. © 2021 NTT DATA Corporation 26 • Canaryリソースのデプロイ(deploy/podinfoをtargetに設定) Service と Deployment と VirtualService が作成される。 FlaggerによるProgressive Delivery実践 $ kubectl apply -f canary.yaml VirtualService/ podinfo service/podinfo deploy/podinfo service/podinfo deploy/podinfo-primary deploy/podinfo service/podinfo-primary service/podinfo-canary deploy/podinfo-canary ingress gateway New New New New New 100% 0% Replica 0 ingress gateway
  27. 27. © 2021 NTT DATA Corporation 27 FlaggerによるProgressive Delivery実践 $ kubectl -n test set image deployment/podinfo podinfod=stefanprodan/podinfo:3.1.1 $ watch "kubectl describe canary podinfo -n test|tail" Every 2.0s: kubectl describe canary podinfo -n test|tail DESKTOP-NTAMOVN: Mon Jan 25 00:42:58 2021 Normal Synced 8m22s (x5 over 6h45m) flagger New revision detected! Scaling up podinfo.test ★ターゲットの変更を検知 Normal Synced 7m22s (x5 over 6h44m) flagger Advance podinfo.test canary weight 10 ★virtualserviceで10%をpodinfoに流す(1分ごとに10%増加) Normal Synced 7m22s (x5 over 6h44m) flagger Pre-rollout check acceptance-test passed ★受け入れテストクリア Normal Synced 7m22s (x5 over 6h44m) flagger Starting canary analysis for podinfo.test Normal Synced 6m22s flagger Advance podinfo.test canary weight 20 Normal Synced 5m22s flagger Advance podinfo.test canary weight 30 Normal Synced 4m22s flagger Advance podinfo.test canary weight 40 Normal Synced 3m22s flagger Advance podinfo.test canary weight 50 Normal Synced 2m22s flagger Copying podinfo.test template spec to podinfo-pr imary.test Normal Synced 22s (x2 over 82s) flagger (combined from similar events): Promotion comple ted! Scaling down podinfo.test deploy/podinfoのimageバージョンを変更し、Progressive Deliveryを開始させる。 Every 2.0s: kubectl get po DESKTOP-NTAMOVN: Mon Jan 25 15:39:58 2021 NAME READY STATUS RESTARTS AGE flagger-loadtester-597d7756b5-xhcdq 2/2 Running 0 21h podinfo-7b96774c87-d5n4s 2/2 Running 0 19s ★新しく起動 podinfo-7b96774c87-prnlv 1/2 Running 0 14s ★新しく起動 podinfo-primary-b49dbb9dc-8jgq4 2/2 Running 0 14h podinfo-primary-b49dbb9dc-jslz4 2/2 Running 0 14h
  28. 28. © 2021 NTT DATA Corporation 28 FlaggerによるProgressive Delivery実践 imageのバージョンを変更し、Progressive Deliveryを開始させる。 新しいバージョンにcanary serviceが向いている 徐々にトラフィックが増えていく Webhooksで定義した負荷 テストによる負荷
  29. 29. © 2021 NTT DATA Corporation 29 FlaggerによるProgressive Delivery実践 imageのバージョンを変更し、Progressive Deliveryを開始させる。 新しいバージョンにcanary serviceが向いている 徐々にトラフィックが増えていく Webhooksで定義した負荷テストによる負荷 →本番のトラフィックと混じり過負荷の懸念があるた め、本番リリース時はやらないほうが良い
  30. 30. © 2021 NTT DATA Corporation 30 Flagger webhooksによる Kubernetesリソースデプロイ時の 自動負荷試験 準備編
  31. 31. © 2021 NTT DATA Corporation 31 Kubernetesリソースデプロイ時の自動負荷試験 サンプルアプリ紹介 sock-shop をサンプルアプリとして、Observability と負荷試験自動化スタックを追加 →https://github.com/kashinoki38/sockshop-kashinoki38 割と容易にデプロイできるようにまとめたのでぜひ試してみてください ※Sock Shopとは、、 • https://microservices-demo.github.io/ • weaveworksのマイクロサービスデモアプリ • 靴下のECサイト
  32. 32. © 2021 NTT DATA Corporation 32 Kubernetesリソースデプロイ時の自動負荷試験 サンプルアプリ アーキテクチャ istio-system Tracing jmeter sock-shop サンプルアプリ kube-Prometheus-stack monitoring Metrics Grafana Loki Logging 負荷がけ デプロイ検知、 自動試験 メトリクス自動 評価
  33. 33. © 2021 NTT DATA Corporation 33 Kubernetesリソースデプロイ時の自動負荷試験 サンプルアプリ アーキテクチャ istio-system Tracing jmeter sock-shop サンプルアプリ kube-Prometheus-stack monitoring Metrics Grafana Loki Logging 負荷がけ デプロイ検知、 自動試験 Observability※ メトリクス自動 評価 ※参考 https://kashionki38.hatenablog.com/entry/2020/08/06/011420
  34. 34. © 2021 NTT DATA Corporation 34 Kubernetesリソースデプロイ時の自動負荷試験 サンプルアプリ アーキテクチャ istio-system Tracing jmeter sock-shop サンプルアプリ kube-Prometheus-stack monitoring Metrics Grafana Loki Logging 負荷がけ デプロイ検知、 自動試験 負荷試験自動化 スタック メトリクス自動 評価
  35. 35. © 2021 NTT DATA Corporation 35 Kubernetesリソースデプロイ時の自動負荷試験 Flagger x Jmeter Jmeterへの対応 ・FlaggerのloadtesterにJmeterを注入したイメージ(flagger/loadtesterはheyとghzのみ対応) https://hub.docker.com/repository/docker/kashinoki38/jmeter-flagger/general ・JmeterシナリオはConfigMapによりJmeterのDeploymentにアタッチ ・Flaggerのwebhooksの負荷テストとしてJmeterを定義 configMapGenerator: - name: jmeter-scenario-load-test files: - scenario.jmx webhooks: ... - name: load-test url: http://jmeter-flagger-loadtester.jmeter/ timeout: 5s metadata: # /jmeter/apache-jmeter-*/bin/jmeter -n -t $1 -Dserver.rmi.ssl.disable=true -JServerName=$2 - JNumOfThreads=$3 -JRampUp=$4 -JDuration=$5 -JTPM=$6 cmd: '/bin/bash /load_test /scenario.jmx "front-end-canary.sock-shop" "50" "180" "600" "3000"'
  36. 36. © 2021 NTT DATA Corporation 36 Kubernetesリソースデプロイ時の 自動負荷試験 実施編
  37. 37. © 2021 NTT DATA Corporation 37 Kubernetesリソースデプロイ時の自動負荷試験 実施フロー istio-system jmeter sock-shop kube-Prometheus-stack monitoring Grafana Loki ②デプロイ検知後 curlで疎通試験 ③configmapに 定義されたシナリオ で10分負荷試験 デプロイ検知、 自動試験 メトリクス自動 評価 ③’負荷試験中に2分おきに5 回メトリクスをしきい値評価 ・SuccessRate:90%以上 ・ResponseTimeP95:2sec以下 ④ A. 成功すると試験用Deployment をメインに昇格し、Ingress gwからの トラフィックの向き先とする B. 疎通試験、負荷試験での評価が 5回失敗するとデプロイ失敗 ①デプロイ検知後、新 バージョンを試験用 Deploymentでリリース (Ingress gwからのトラ フィックは流さない設定)
  38. 38. © 2021 NTT DATA Corporation 38 Kubernetesリソースデプロイ時の自動負荷試験 A. デプロイ成功例
  39. 39. © 2021 NTT DATA Corporation 39 Kubernetesリソースデプロイ時の自動負荷試験 A. デプロイ成功例 targetのDeployment変更検知 Slackへも変更検知を通知
  40. 40. © 2021 NTT DATA Corporation 40 Kubernetesリソースデプロイ時の自動負荷試験 A. デプロイ成功例 疎通試験成功
  41. 41. © 2021 NTT DATA Corporation 41 Kubernetesリソースデプロイ時の自動負荷試験 A. デプロイ成功例 負荷試験実施中(10分間) 2分ごとに5セット自動評価が実施される ・SuccessRate:90%以上 ・ResponseTimeP95:2sec以下 ※問題があれば”Halt ~~~”のmsg
  42. 42. © 2021 NTT DATA Corporation 42 Kubernetesリソースデプロイ時の自動負荷試験 A. デプロイ成功例 負荷試験実施中(10分間) 2分ごとに5セット自動評価が実施される ・SuccessRate:90%以上 ・ResponseTimeP95:2sec以下 ※問題があれば”Halt ~~~”のmsg Istioのメトリクスを実際に確認しても、メトリクスに問 題がない(しきい値内)ことが確認できる
  43. 43. © 2021 NTT DATA Corporation 43 Kubernetesリソースデプロイ時の自動負荷試験 A. デプロイ成功例 試験用Deploymentをメインに昇格し、 Ingress gwからのトラフィックの向き先とする Slackへも昇格を通知
  44. 44. © 2021 NTT DATA Corporation 44 Kubernetesリソースデプロイ時の自動負荷試験 B. デプロイ失敗例 処理に2000msのスリープを追加 app.get("/catalogue*", function (req, res, next) { setTimeout(() => { helpers.simpleHttpRequest(endpoints.catalogueUrl + req.url.toString(), res, next); }, 2000); });
  45. 45. © 2021 NTT DATA Corporation 45 Kubernetesリソースデプロイ時の自動負荷試験 B. デプロイ失敗例 targetのDeployment変更検知 Slackへも変更検知を通知
  46. 46. © 2021 NTT DATA Corporation 46 Kubernetesリソースデプロイ時の自動負荷試験 B. デプロイ失敗例 負荷試験実施中(10分間) 2分ごとに5セット自動評価が実施される request-duration-customeメトリクス がしきい値2000を超えている
  47. 47. © 2021 NTT DATA Corporation 47 Kubernetesリソースデプロイ時の自動負荷試験 B. デプロイ失敗例 負荷試験実施中(10分間) 2分ごとに5セット自動評価が実施される request-duration-customeメトリクス がしきい値2000を超えている
  48. 48. © 2021 NTT DATA Corporation 48 Kubernetesリソースデプロイ時の自動負荷試験 B. デプロイ失敗例 自動評価が5回失敗したため、Rolling back (試験用を切り離し) 試験用Deploymentを0スケールダウンさせる Slackへも自動評価失敗を通知
  49. 49. © 2021 NTT DATA Corporation 49 まとめ
  50. 50. © 2021 NTT DATA Corporation 50 DevPerfOps再整理 ①性能試験アジリティ向上:Kubernetesリソースデプロイ時の自動負荷試験 • ステージングや試験環境へのリリース向け • →リリースの度に必ず負荷試験が走ることで性能を担保する • 事前に試験用のクラスタを作っておいてデプロイ時に負荷試験が走るイメージ • 特定ブランチPushを検知したらデプロイ開始 • 更新したDeploymentの試験用リソースが立って負荷試験、自動評価、OK/NG ②本番リリース時の性能リスク低減:Progressive Delivery • あくまで本番リリース向け • Webhooksによる負荷試験はここでは実施しないほうが良い(過負荷の懸念) • カナリーリリースで本番トラフィックを使った自動評価とそれに応じた自動切り戻しを実施 • →本番トラフィックがあるタイミングでのリリースが望まれる
  51. 51. © 2021 NTT DATA Corporation 51 課題 ①性能試験アジリティ向上:Kubernetesリソースデプロイ時の自動負荷試験 • リソース効率が悪い(更新されたターゲットのPodが2倍必要) • 試験環境が一時的にBlue/Greenで既存環境+試験環境で2倍リソース必要(更新リソー スのみ) • 試験場結果連携、永続化の高度化が必要(結局グラフとか見て張り付いちゃう) • Slackへの重要グラフ添付 • 結果のS3等へのアップロード • データ準備、負荷モデル、シナリオ作成の自動化 ②本番リリース時の性能リスク低減:Progressive Delivery • サービスごとのSLI/SLOの事前定義が必須 • リリースをするタイミングにトラフィック量が多くないと少量本番トラフィックだけの評価では意味ない • 合わせて負荷ツールで負荷を追加することもできるが、本番トラフィック量に合わせてリアルタイム に負荷量を調整するようなインテリジェントな仕組みが必要
  52. 52. © 2021 NTT DATA Corporation 52 まとめ • Kubernetesのエコシステムを活用すれば継続性能担保アプローチを実施することができる • DevPerfOpsとは? • ①性能試験アジリティ向上:Kubernetesリソースデプロイ時の自動負荷試験 • ②本番リリース時の性能リスク低減:Progressive Delivery • DevPerfOpsのアプローチについてFlaggerを用いた実装案を説明した • サンプル https://github.com/kashinoki38/sockshop-kashinoki38 • 課題はまだまだあるが、一部でも参考にしてDevPerfOpsしてもらえると嬉しいです • 本番インシデントを未然に防ぐのだ!
  53. 53. © 2021 NTT DATA Corporation 53 Reference https://github.com/fluxcd/flagger/ https://docs.flagger.app/ https://speakerdeck.com/mathetake/introduction-to-flagger?slide=49 https://medium.com/google-cloud-jp/gke-istio- flagger%E3%81%AB%E3%82%88%E3%82%8Bprogressive-delivery-5f1ea9b627c1 https://qiita.com/mumoshu/items/63b29bca6a052d8c7087 https://techstep.hatenablog.com/entry/2020/10/11/112027
  54. 54. © 2021 NTT DATA Corporation
  55. 55. © 2021 NTT DATA Corporation Observabilityスタック
  56. 56. © 2021 NTT DATA Corporation 56 性能解析の始め方→Observability Kubernetesにおける性能解析は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本柱
  57. 57. © 2021 NTT DATA Corporation 57 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/ Disk使用量 NodeExporterをDaemonSetとして配置し収集 Pod/Container CPU/Memory/NW/ Disk使用量 cAdvisorにて収集 (Kubeletバイナリに統合されているのでscrapeの設定のみでOK) MW AP スレッド数 GC 言語のPrometheusクライアントライブラリ Prometheus、Grafana、NodeExporter、kube-state-metricsがkube-prometheus-stack
  58. 58. © 2021 NTT DATA Corporation 58 ダッシュボードのデモ
  59. 59. © 2021 NTT DATA Corporation 59 Logging Loki Loggingの課題 • 大量のログを軽量に扱いたい(grepのような使い心地) • メトリクス、トレーシングとの関連性を持たせたい(コンテキストスイッチを減らしたい) →今回はLokiを採用 Lokiでできること • Grafanaでのログ検索 • コンテキスト検索(前後の検索) • grepライクな検索 • Grafanaでのログ時系列可視化 PromQLライクな可視化 • tracingとの連携(Grafanaへのアドオン) 詳しくは、https://de.slideshare.net/nttdata-tech/grafana-loki-kubernetesloggingnttdata Grafana Promtail Lokiのログ集約フロー
  60. 60. © 2021 NTT DATA Corporation 60 Logging Loki 観点 • エラーメッセージ • 時系列でのエラー量 grepライクな検索 エラーメッセージ Label (どのPod/Container/app etc) 前後のログ行 エラー検索(sock-shop namespaceのエラー) 時系列でのエラー量可視化 (Podごとのエラー量) PromQLライクなクエリ エラー量の可視化 任意のラベルで集計可
  61. 61. © 2021 NTT DATA Corporation 61 Tracing 依存関係可視化 Tracingでやりたいこと1 • サービス間の呼び出し依存関係 • 各呼び出しのResponse Time、スループット、エラー率 →Kialiで可能 でできること • サービス感の依存関係グラフ • 依存関係に重ねて、Response Time、スループット、エ ラー率 が見える • 実態のデータはenvoyのPrometheusメトリクスから取 得
  62. 62. © 2021 NTT DATA Corporation 62 Tracing 分散トレーシング Tracingでやりたいこと2 • 分散トレーシング(各サービスのレイテンシの包含関係) でできること • Spanによる表示で後続のサービスが占める時間を可視化できる
  • oohiratakeharu

    May. 24, 2021

継続的な性能担保、DevPerfOpsという考え方 (CloudNative Days Spring 2021 ONLINE 発表資料) 2021年3月11日 NTT DATA 技術革新統括本部 デジタルテクノロジ推進室 まかせいのう 堀内 保大, Yasuhiro Horiuchi

Aufrufe

Aufrufe insgesamt

960

Auf Slideshare

0

Aus Einbettungen

0

Anzahl der Einbettungen

152

Befehle

Downloads

0

Geteilt

0

Kommentare

0

Likes

1

×