限界性能試験を自動化するOperatorを作ってみた（Kubernetes Novice Tokyo #14 発表資料）

© 2021 NTT DATA Corporation
限界性能試験を自動化するOperatorを作ってみた
2021年10月19日
NTTデータ伊藤秀朗

© 2021 NTT DATA Corporation 2
目次
1. はじめに
2. 性能試験とは
3. 限界性能試験の課題
4. 限界性能試験自動化システム
5. Operatorの作成
6. まとめ

はじめに－自己紹介－
伊藤秀朗（Twitter: @itohdak）
所属：NTTデータ（新卒2年目）
仕事：性能試験・性能問題解決
趣味：謎解き・競技プログラミング
ここに貼るバッジを集めたい、
とは思っている。。
Kubernetes歴
半年

はじめに－ざっくり概要－
Observability ＋ Kubernetes Operator
Kubernetes APIの機能を拡張したアプリケーション
固有のコントローラー
Operatorとは…
分散システムを開発/運用するにあたり必要な、
横断的な監視のための「可観測性」
Observabilityとは…
Metrics
Tracing
Logging
What is an operator?
https://cloud.redhat.com/learn/topics/operators
関連する様々なリソースを
一括で作成・設定・管理！
Observability
3本の柱

性能試験とは
ウォーターフォール開発における下流フェーズ
製造したシステムが、要件定義で定めた通りの性能が発揮できるか確認する
ここで性能が担保されない場合、リリースに黄色信号
必要があれば、チューニングも実施する
ここ！

性能試験とは－種別－
ピーク負荷試験
計画されたピーク負荷量をかけることで、システムが性能要件通りに動作するかを確認する。
限界負荷試験
加えるピーク負荷量を増加させていくことで、システムの限界性能を確認する。
長時間負荷試験
恒常的な負荷量を長時間かけ続けることにより、メモリリーク等の問題が発生しないことを確認する。
縮退時負荷試験
システムのスケールを縮退させた状態でピーク負荷試験を実施する。

限界性能試験の課題
「試験準備→試験実施→結果集計・評価」の繰り返し ※チューニングなしの場合
「試験準備」および「結果集計・評価」
は試験実施者が行う
試験実施中は見守っている必要がある
試験環境が実際に動いているのは、
試験実施の期間のみ
ランニングコストも大きくなる

限界性能試験の課題
「試験準備→試験実施→結果集計・評価」の繰り返し ※チューニングなしの場合
負荷量調整・試
験準備
性能試験実施結果まとめ・評価
「試験準備」および「結果集計・評価」
は試験実施者が行う
試験実施中は見守っている必要がある
試験環境が実際に動いているのは、
試験実施の期間のみ
ランニングコストも大きくなる
験準備

限界性能試験自動化システム
9

限界性能試験自動化のためのシステム概要
負荷掛けメトリクス取得
メトリクス確認・
評価
負荷量変化
2. Prometheus
1. Locust
APP
メトリクス監視
負荷量変化
2. Prometheus
1. Locust
APP
3. Manager
験準備

1. 負荷掛けツール－Locust－
Locustとは…Pythonで動作する負荷掛けツール
Master
Slave
ユーザ数
時間
ユーザ数
増やして！
計画値
シームレスにユーザ数を変更することが可能
Master-Slave構成を取ることが可能
→スケールイン/アウトが容易
負荷量変化
2. Prom etheus
1. Locust
APP
3. Manag er

2. メトリクス取得－Istio・Prometheus－
各サービスごとに専用のProxyを用意し、リクエスト時はそ
れを経由させることで、リクエストに対するレスポンスタイムや
リクエストルートを記録し、管理する
Istio
Proxy Proxy
Istio
KubernetesノードやIstio（Exporter）が出力するメト
リクスを一元的に集約し、ユーザからの問い合わせに対し、
情報を提供する。
Prometheus
自作の
Exporter
ユーザ
負荷量変化
2. Prom etheus
1. Locust
APP
3. Manag er

限界性能試験自動化のためのシステム概要
負荷量変化
2. Prometheus
1. Locust
APP
3. Manager
験準備
再掲

3. 限界性能試験を司るManager
以下のロジックを組み込んだコンテナイメージをGo言語で作成
1. Prometheusにスクレイピングをかけ、
Istio（あるいは、その他）から収集されたメトリクス情報を取得
2. 監視対象メトリクスの各値に対し、
あらかじめ設定しておいた閾値を抵触しないかをチェック
3. もし判定結果がOKなら、
（適宜負荷量を増加させながら）試験を続行
4. もし判定結果がNGなら、試験終了
Jobとして実行し、必要なときにPodを立ち上げ動作する
メトリクスを取得
判定OKか？
試験開始
試験終了
一定時間待つ
負荷量を増加
3
4
2
1
YES
NO
負荷量変化
2. Prom etheus
1. Locust
APP
3. Manag er

3. 限界性能試験を司るManager
メトリクスを取得
判定OKか？
試験開始
試験終了
一定時間待つ
負荷量を増加
YES
NO
負荷量変化
2. Prom etheus
1. Locust
APP
3. Manag er

Operatorの作成
16

独自Operatorの作成
負荷量変化
2. Prometheus
1. Locust
APP
3. Manager
「性能試験で使うリソース群」として、
一括で作成・操作できるようにOperator化！

Deployment
Operatorとは（1/2）
ReplicaSet
Reconciliationを独自に定義できる
リソースの状態をユーザの期待通りの状態に保ち続ける機能
Pod
例えば…
Deployment Controller
ReplicaSet Controller
Update
Watch
Update
Watch
Controller Manager
Podが異常停止しても、再度自動的に立ち上がる（Self-Healing）

https://hi1280.hatenablog.com/entry/2020/06/07/114712
全てのリソースの状態は
etcdに格納される
全ての処理はAPI Serverを
介して行われる
Kubeletは各々のNodeに
割り当てられてリソース状況を
Masterに通知する

https://hi1280.hatenablog.com/entry/2020/06/07/114712
kubectl create deployment
① ユーザのリソース作成に応じて、
etcdに期待するリソース状態が記録される
② リソース状態の変化を契機に
ControllerがReconcile処理をする
③ Reconciliationに応じて、
Scheduler等を通して、状態が更新される

Operator作成のためのフレームワーク（1/2）
気にかけないといけないコンポーネントがたくさん
• Informer
• リソース情報の変化を監視し、イベントトリガ時に適切な処理命令を発火する
• WorkQueue
• Informerにより発火された処理命令を溜めておく
• Processor
• WorkQueueから処理命令を取り出す
• 適切なReconciliationを実行する
• 成功した場合は、処理命令を破棄する
• 失敗した場合は、WorkQueueに適切にRequeueする
※より詳しい内容については、ぜひ「実践入門 Kubernetesカスタムコントローラーへの道」をご参照ください。
Reconciliationの処理と、
その処理対象だけに集中したい！

Operator作成のためのフレームワーク（2/2）
Reconciliationのロジックのみに集中できるように、Operator開発用のフレームワークが提供されている
• Kubebuilder
• Special Interest Groups（SIGs）によって開発されているフレームワーク
• Operator SDK
• CoreOS社によって提供されたOperator Frameworkの一つ

Operatorとして管理する対象リソース
LoadTestController
負荷スクリプト
負荷対象
Master
Slave
負荷試験Manager 負荷試験Status
Locustアクセス
Job起動
試験開始
Status更新
試験終了

作成したOperatorのReconciliation部分
Specの定義
• リソースを作成する際に
マニフェスト内でユーザが
指定できる部分
Statusの定義
• 作成されたリソースの
状態を表す
RBACの定義
• 他のリソースに対して
どのような操作権限を持たせるか
Reconciliationの定義
• Reconcileのメイン部分
（関数で分けているので
全体としてはもう少し長い）

どんな感じで動くの？
－デモ動画・画像－
25

負荷掛け対象として使ったサンプルアプリ
Online Boutique
• https://github.com/GoogleCloudPlatform/microservices-demo.git
ホーム画面決済画面

コマンド入力〜Jobのキック
Job
コマンド入力 ConfigMap (CM)
コマンド入力（裏でCMのstatusをrequiredに書き換えている）を検知し、
CMのstatusは、standby(→required)→runningへ切り替わり、
それをきっかけに新しいJobが作成されている

Job実行中のPodのログ
Jobにより作成されたPodのログ
各負荷量において、
Response time, Success rate, CPU utilizationを確認し、
予め設定した値に抵触していなければOKと判断し、負荷量を増加させている
チェックOK
チェックNG
試験終了

Grafanaで見たメトリクス負荷量が次第に増えていくにつれて、
レスポンスタイム、CPU使用率が上昇し
ていく様子がわかる。
途中レスポンスタイムが急激に増加し、
予め設定した閾値2秒を超過したところ
で、試験が終了している。

負荷掛けツールLocust側の設定値・メトリクス
ユーザ数
レスポンスタイム
スループット
レスポンスタイムが
閾値（2sec）を上回り、
負荷試験終了
ユーザ数が徐々に
増加している

負荷掛けツールLocust側の設定値・メトリクス
ユーザ数
レスポンスタイム
スループット
験準備
区間ごとに上記の手順が実施されている形
人間の作業を排除することで、省力化が図れている

まとめ
32

まとめ
限界性能試験における繰り返しの手順を自動化し、省人力化が期待できるツールを作成した
 Observerbility (Metrics) の使い方を知り、それを応用することができた
負荷掛けツールLocust、および、負荷掛けManagerを含むKubernetes Operatorを作成した
 Reconciliationの概念を学ぶことができた
【おまけ】取り組みの中で利用・作成したコードたち
1. 検証環境のセットアップ・サンプルアプリのデプロイ
https://github.com/itohdak/kubernetes-experiment
2. Kubebuilderを用いて作成したOperator
https://github.com/itohdak/maca-operator/tree/deploy

限界性能試験を自動化するOperatorを作ってみた（Kubernetes Novice Tokyo #14 発表資料）

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a 限界性能試験を自動化するOperatorを作ってみた（Kubernetes Novice Tokyo #14 発表資料）

Semelhante a 限界性能試験を自動化するOperatorを作ってみた（Kubernetes Novice Tokyo #14 発表資料） (20)

Mais de NTT DATA Technology & Innovation

Mais de NTT DATA Technology & Innovation (20)

限界性能試験を自動化するOperatorを作ってみた（Kubernetes Novice Tokyo #14 発表資料）