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

© 2021 NTT DATA Corporation
継続的な性能担保、DevPerfOpsという考え方
2021/03/11 CloudNative Days Spring 2021 ONLINE
NTT DATA 技術革新統括本部デジタルテクノロジ推進室まかせいのう
堀内保大, Yasuhiro Horiuchi (@ka_shino_ki)

© 2021 NTT DATA Corporation 2
Agenda
1. Who am I?
2. 本セッションの目的、DevPerfOpsとは？
3. Progressive Delivery
4. リソースデプロイ時の自動負荷試験
5. まとめ

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)

What’s デジタルテクノロジ推進室
・デジタル化に必要な豊富な知識を持った技術者（デジタルテクノロジーディレクター、DTD）
・DTDをお客さま拠点に派遣しお客さまのデジタル化推進を強力に支援する
・全社のテクノロジーをDTDがお客様の案件に合わせてコーディネートし、提案
・コンサルからデリバリまでの体制を確保して一気通貫でお客へ価値を提供
https://www.nttdata.com/jp/ja/lineup/digital_technology_director/
https://ndigi.tech/

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

本セッションの目的、DevPerfOpsとは？
CI/CDパイプラインへの性能担保プロセス導入の課題感
• 継続的にリリースが走る場合、性能試験は一度きりだと以下のようなリスクが想定される
• 過去担保したアプリケーションとことなるバージョンがリリースされることによる、性能デグレ
• MWやFWのバージョン差分による性能デグレ
• 一方で、
• 毎回リリースごとに手作業で負荷試験を実施していくのは現実的ではない
• かといって都度本番リリースに張り付くのも大変

• そこで、Kubernetesのエコシステムを活用することで、
以下のような継続性能担保アプローチ（DevPerfOps）を検討
①性能試験アジリティ向上 Kubernetesリソースデプロイ時の自動負荷試験
②本番リリース時の
性能リスク低減
Progressive Delivery
性能担保観点アプローチ

特定ブランチへ
のプッシュ
①性能試験アジリティ向上：Kubernetesリソースデプロイ時の自動負荷試験
②本番リリース時の性能リスク低減：Progressive Delivery
• 目指す姿
• 特定ブランチへのリリース時には性能試験が自動で走る
• 本番リリース時に自動評価、自動切り戻し
• カナリーリリースで本番トラフィックを使った結果分析
Performance環境へ
のデプロイ開始
（GitOps）
Performance環境へ試験用ア
プリをデプロイし負荷試験を実施
問題あり
試験用アプリを
メインに昇格
試験用アプリを切り離し
パイプラインをFailed
問題なし
本番環境への
デプロイ
カナリーリリース
リリースアプリをメインに昇格
リリースアプリを切り離し
問題あり
問題なし
①
②

特定ブランチへ
のプッシュ
• 目指す姿
• 特定ブランチへのリリース時には性能試験が自動で走る
• 本番リリース時に自動評価、自動切り戻し
• カナリーリリースで本番トラフィックを使った結果分析
Performance環境へ
のデプロイ開始
（GitOps）
Performance環境へ試験用ア
プリをデプロイし負荷試験を実施
問題あり
試験用アプリを
メインに昇格
試験用アプリを切り離し
パイプラインをFailed
問題なし
本番環境への
デプロイ
カナリーリリース
リリースアプリをメインに昇格
リリースアプリを切り離し
問題あり
問題なし
①
②
本セッションではDevPerfOps実現案をサンプルアプリを使って紹介

Progressive Deliveryとは
• CDの次のステップとして位置づけられた比較的新しいリリース方式
• 従来のリリースに①リリース中の評価と②自動ロールバックを追加
• これによりリリース時のリスクを軽減することが可能

Progressive Deliveryのフロー例（カナリーリリースの場合）
• カナリーリリース実施中に、SLA等のメトリクスを定期的に評価をしながら、一定の割合までトラフィックを増加させることが
できれば完全にバージョンを切り上げる。
• 評価中にメトリクスがしきい値以下である回数が一定を超えると失敗と判定され、バージョンを切り戻す

設定例：
1分おきに5%ずつトラフィックを増加
1分おきにスループットとレスポンスタイムを評価
50%に到達するまでにしきい値を5回下回るとFail
v2評価用のPodを新規にデプロイ
分間5%ずつ増加させていく

設定例：
50%までしきい値を5回下回らな
ければCanary Analysis成功

設定例：
PrimaryのPodをv1→v2に
切り上げる

設定例：
v2確認用のPodを削除

Progressive Deliveryができるツールは以下あたり
• Flagger
• weaveworks社
• Service mesh（Istio, Linkerd, App mesh）前提
• Argo Rollouts
• Argoプロジェクト
• Argo CD等と組み合わせ可能
• 最近はService meshと組み合わせたトラフィック管理も可能
• Spinnaker (+ Kayenta）
• PipeCD

Progressive Deliveryができるツールは以下あたり
• Flagger → 今回使用
• weaveworks社
• Service mesh（Istio, Linkerd, App mesh）前提
• Argo Rollouts
• Argoプロジェクト
• Argo CD等と組み合わせ可能
• 最近はService meshと組み合わせたトラフィック管理も可能
• Spinnaker (+ Kayenta）
• PipeCD

Flaggerによる
実践

FlaggerによるProgressive Delivery実践
Flaggerアーキテクチャ
• IstioならVirtualServiceをOperatorが自動で書き換えていくことで、v2評価用(canary)へのトラフィック量を増加さ
せていく動きを実現
• 評価のメトリクスはPrometheus等から取得できる

• 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

• Flaggerの設定（canary.yaml）
Flaggerの詳細設定（リリース方式、Canary Analysisのパラメータ等）はCanaryリソースで定義する。
apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
name: sock-shop
namespace: sock-shop
spec:
...

▼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
stepWeight: 10

▼評価判定条件
.spec.analysis.metricsにて評価中の判定条件を設
定できる。
analysis:
...
metrics:
- name: request-success-rate
# minimum req success rate (non 5xx responses)
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上のメトリクス使って独自で条件を定義で
きる

▼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/“ # 任意のコマンドを指定可能
⇒webhooksを活用することで、リソースデプロイ時の自動負荷試験が実現可能（後述）

• Canaryリソースのデプロイ（deploy/podinfoをtargetに設定）
Service と Deployment と VirtualService が作成される。
$ 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

$ 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 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

imageのバージョンを変更し、Progressive Deliveryを開始させる。
新しいバージョンにcanary
serviceが向いている
徐々にトラフィックが増えていく
Webhooksで定義した負荷
テストによる負荷

imageのバージョンを変更し、Progressive Deliveryを開始させる。
新しいバージョンにcanary
serviceが向いている
徐々にトラフィックが増えていく
Webhooksで定義した負荷テストによる負荷
→本番のトラフィックと混じり過負荷の懸念があるた
め、本番リリース時はやらないほうが良い

Flagger webhooksによる
Kubernetesリソースデプロイ時の
自動負荷試験
準備編

Kubernetesリソースデプロイ時の自動負荷試験
サンプルアプリ紹介
sock-shop をサンプルアプリとして、Observability と負荷試験自動化スタックを追加
→https://github.com/kashinoki38/sockshop-kashinoki38
割と容易にデプロイできるようにまとめたのでぜひ試してみてください
※Sock Shopとは、、
• https://microservices-demo.github.io/
• weaveworksのマイクロサービスデモアプリ
• 靴下のECサイト

サンプルアプリアーキテクチャ
istio-system
Tracing
jmeter
sock-shop サンプルアプリ
kube-Prometheus-stack
monitoring
Metrics
Grafana
Loki
Logging
負荷がけ
デプロイ検知、
自動試験
メトリクス自動
評価

istio-system
Tracing
jmeter
monitoring
Metrics
Grafana
Loki
Logging
負荷がけ
自動試験
Observability※
評価
※参考
https://kashionki38.hatenablog.com/entry/2020/08/06/011420

istio-system
Tracing
jmeter
monitoring
Metrics
Grafana
Loki
Logging
負荷がけ
自動試験
負荷試験自動化
スタック
評価

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"'

Kubernetesリソースデプロイ時の
自動負荷試験
実施編

実施フロー
istio-system
jmeter
sock-shop
monitoring
Grafana
Loki
②デプロイ検知後
curlで疎通試験
③configmapに
定義されたシナリオ
で10分負荷試験
自動試験
評価
③’負荷試験中に2分おきに5
回メトリクスをしきい値評価
・SuccessRate:90%以上
・ResponseTimeP95:2sec以下
④
A. 成功すると試験用Deployment
をメインに昇格し、Ingress gwからの
トラフィックの向き先とする
B. 疎通試験、負荷試験での評価が
5回失敗するとデプロイ失敗
①デプロイ検知後、新
バージョンを試験用
Deploymentでリリース
（Ingress gwからのトラ
フィックは流さない設定）

A. デプロイ成功例

targetのDeployment変更検知
Slackへも変更検知を通知

疎通試験成功

負荷試験実施中（10分間）
2分ごとに5セット自動評価が実施される
※問題があれば”Halt ~~~”のmsg

※問題があれば”Halt ~~~”のmsg
Istioのメトリクスを実際に確認しても、メトリクスに問
題がない（しきい値内）ことが確認できる

試験用Deploymentをメインに昇格し、
Ingress gwからのトラフィックの向き先とする
Slackへも昇格を通知

B. デプロイ失敗例
処理に2000msのスリープを追加
app.get("/catalogue*", function (req, res, next) {
setTimeout(() => {
helpers.simpleHttpRequest(endpoints.catalogueUrl + req.url.toString(), res, next);
}, 2000);
});

targetのDeployment変更検知
Slackへも変更検知を通知

request-duration-customeメトリクス
がしきい値2000を超えている

自動評価が5回失敗したため、Rolling back
（試験用を切り離し）
試験用Deploymentを0スケールダウンさせる
Slackへも自動評価失敗を通知

まとめ

DevPerfOps再整理
• ステージングや試験環境へのリリース向け
• →リリースの度に必ず負荷試験が走ることで性能を担保する
• 事前に試験用のクラスタを作っておいてデプロイ時に負荷試験が走るイメージ
• 特定ブランチPushを検知したらデプロイ開始
• 更新したDeploymentの試験用リソースが立って負荷試験、自動評価、OK/NG
• あくまで本番リリース向け
• Webhooksによる負荷試験はここでは実施しないほうが良い（過負荷の懸念）
• カナリーリリースで本番トラフィックを使った自動評価とそれに応じた自動切り戻しを実施
• →本番トラフィックがあるタイミングでのリリースが望まれる

課題
• リソース効率が悪い（更新されたターゲットのPodが2倍必要）
• 試験環境が一時的にBlue/Greenで既存環境＋試験環境で2倍リソース必要（更新リソー
スのみ）
• 試験場結果連携、永続化の高度化が必要（結局グラフとか見て張り付いちゃう）
• Slackへの重要グラフ添付
• 結果のS3等へのアップロード
• データ準備、負荷モデル、シナリオ作成の自動化
• サービスごとのSLI/SLOの事前定義が必須
• リリースをするタイミングにトラフィック量が多くないと少量本番トラフィックだけの評価では意味ない
• 合わせて負荷ツールで負荷を追加することもできるが、本番トラフィック量に合わせてリアルタイム
に負荷量を調整するようなインテリジェントな仕組みが必要

まとめ
• Kubernetesのエコシステムを活用すれば継続性能担保アプローチを実施することができる
• DevPerfOpsとは？
• ①性能試験アジリティ向上：Kubernetesリソースデプロイ時の自動負荷試験
• ②本番リリース時の性能リスク低減：Progressive Delivery
• DevPerfOpsのアプローチについてFlaggerを用いた実装案を説明した
• サンプル
https://github.com/kashinoki38/sockshop-kashinoki38
• 課題はまだまだあるが、一部でも参考にしてDevPerfOpsしてもらえると嬉しいです
• 本番インシデントを未然に防ぐのだ！

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

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

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

ダッシュボードのデモ

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

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

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

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

Recommended

Recommended

More Related Content

More from NTT DATA Technology & Innovation

More from NTT DATA Technology & Innovation (20)

Recently uploaded

Recently uploaded (10)

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

Editor's Notes