k6入門：性能テストの自動化について -その3-

今日は、k6を利用した性能テストの自動化についてご紹介します。

背景

Dockerで構築したWebアプリの開発環境において、k6を利用した負荷テストについて調査したときの内容を備忘として残しました。

開発環境のソースは下記のリポジトリにあります。

結果の分析プロセスを計画する

前回の記事に従って、初期のパフォーマンステスト計画ができたはずです。では、パフォーマンス結果をどのように分析し解釈できるかを見てみましょう。

最初のステップは、パフォーマンス結果を出力するためのオプションを理解することです。k6を使用している場合、いくつかの選択肢があります。これらのオプションとk6のメトリクスを確認し、テスト自動化計画の結果を分析するための長期的なソリューションを決定できます。

以下は、結果の分析プロセスを作成する際に考慮すべきいくつかの質問です。

パフォーマンス結果をどのように保存するか

k6では、テストの最後に集計された結果またはリアルタイムのタイムシリーズメトリクスを取得できます。両方のオプションをカスタマイズできます。

お勧めするプロセスは次のとおりです。

1. ストレージバックエンドを選択します。
2. それがテストデータをどのように保存し、その特定の機能を理解します。
3. 結果をクエリおよび視覚化し、制限を確認します。
4. 古いテスト結果を削除するポリシーを確立し、基準となるパフォーマンスデータなどの重要なパフォーマンス結果を将来の比較のために保持できるようにします。
5. ソリューションをテストし、この重要なコンポーネントを頻繁に変更しないようにするための長期的なストレージの選択を決定します。

重要なパフォーマンスメトリクスはどれに焦点を当てるか

特定のテストの目標を考え、テストの目標に依存するメトリクスを追跡することを確認してください。

k6は、SUTに対するすべての相互作用を集計する組み込みのメトリクスを提供しています。また、タグとカスタムメトリクスを使用して、特定の相互作用または特定のタイプの結果をカテゴリ別にフィルタリングできます。

自分自身のパフォーマンス基準とその視覚化を定義することを検討してください。たとえば、良いもの、許容できるもの、わずかに懸念があるもの、または問題があるものに対して異なる色を設定して、特定のパフォーマンス結果セットが問題ないかをすばやく視覚化できるようにします。

パフォーマンスの変更を考えてみてください。変更を比較したり、時間の経過とともにその傾向を追跡するための特定のメトリクスはありますか？ほとんどのテストの視覚化選択肢は、個々のテスト実行の結果に焦点を当てています。重要なパフォーマンスメトリクスの結果を時間の経過にわたって視覚化する方法を実装し、変更とトレンドを特定できるように検討してください。

結果をどのくらいの頻度で分析しますか

自動化されたテストの最新の結果の概要を迅速に提供できるダッシュボードやカスタム通知を作成することを検討してください。これらのダッシュボードは、調査が必要な問題を示す最初のラインです。

また、重要な問題に対するアラートの設定をお勧めします。優先度と非優先度のレベル、およびフォローアップアクションについて考えてください。アラートを設計するためのヒントを考慮に入れてください。

テストと観測データを相関させる

最後に、システムアンダーテスト（SUT）の適切な計測を設定し、システムおよびアプリケーションデータの監視と観測を理解します。

パフォーマンステストの結果は、遅い応答などのパフォーマンスの低下を示すことがあります。しかし、それはSUT内部で何が起こっているか、例えば遅いSQLクエリやCPUおよびメモリの過負荷などを示しません。

このギャップを埋めるために、テスト結果とインフラストラクチャおよびアプリケーションコードの計測方法を相関させる方法を考え出します。たとえば、テスト結果を使用したり、テストからのトレースデータを使用したりして、テスト結果と連携したカスタムダッシュボードを接続したり構築したりします。

継続的なテストは、テスト結果またはシステムデータからの問題やパフォーマンスの低下を検出するのに役立ちます。適切な観測は、ルート原因を見つけるのに役立ちます。

計画の例

計画を最終化する際、テストがどのくらいの頻度で実行され、その結果を分析するオプション、およびその後のアクションを考慮してテスト計画を整理できます。たとえば：

DEPLOYMENT ENV.	TEST TYPE	FREQUENCY	ALERTS	TEST OVERVIEW	ACTION
QA	Smoke tests	CI on Branch changes	CI		Fix broken tests
Pre-release	All performance tests except smoke tests	2 or 3 times daily during the QA/pre-release period		Validate the release after assessing performance results
Staging	Baseline performance tests	Schedule 2 times per week	Only for critical issues	Custom dashboard	Oversee test results
Production	Baseline performance tests	Weekly schedule	Priority and Non-priority issues	Custom dashboards and notifications	Oversee test results
Production	Synthetic tests	Hourly schedule	Custom alerts		Respond to alerts

考慮事項

シンプルに始めてから進化させる

パフォーマンステスト計画や自動化を開始する際、多くのシナリオをテストすることを考えることは一般的ですが、計画の麻痺を避けるために小規模から始めることが重要です。

お勧めするのは、テスト環境を横断するいくつかの異なるテストから始めることです。

徐々に、さらに多くのテストを追加して、パフォーマンステストスイートは徐々にテストカバレッジを増やしていきます。

ソフトウェアリリースプロセス全体でテスト自動化計画とソリューションを証明することに焦点を当ててください。成功した実装は、他のチームとの協力を促進し、継続的なパフォーマンステストの価値を宣伝する道を開きます。

テストの一貫性が重要です

継続的なパフォーマンステストの主要な目標の1つは、信頼性とパフォーマンスの目標を定義する主要なメトリクスの変化を評価することです。これを達成するためには、一定の期間内でテスト実行間のこれらのメトリクスの値を比較する必要があります。

同じテストのテスト実行結果を比較することが重要です。そうでなければ、りんごとオレンジを比較していることになります。同一のテストラン、同じワークロード、同じシナリオ、同じテストデータ、同じ環境で実行される同じテストランの結果を比較することが重要です。

テストラン間で変動を導入しないように注意してください。変更が必要な場合は、テストの名前を変更したり新しいテストを作成したりして、テスト結果をゼロから比較できるようにしてください。

また、同じテストを2回ほぼ連続して実行するようにスケジュールすることをお勧めします。これにより、より良い比較のために1つの追加のテストラン結果が収集され、潜在的に信頼性の低いテストを無視できるようになります。

自動化に反復可能なQAプロセスを補完する

このガイドの冒頭で触れましたが、パフォーマンステストにおける自動化は反復可能で一貫性のあるテストプロセスを確立することに関するものです。

特定のパフォーマンステスト、特に重荷テストは、障害を引き起こす可能性があります。これらのテストは制御された実行とリアルタイムの分析を必要とし、システムが反応しなくなるのを防ぐために注意が必要です。これらのテストの実行を監視なしに自動化することは望ましくないかもしれませんが、それは避けるべきではありません。

また、手動でトリガーされ、実行中にシステムの監視が必要なテストの頻度も計画する必要があります。これらの異なるケースが一貫してテストされるようにするために、リマインダーを設定し、それらをQAプロセスおよびリリースチェックリストの一部として文書化します。一般的な例は以下です：

• 四半期ごとにSoakテストを実行する。
• 重要な季節イベントの2か月前に重負荷テストを実行する。
• 重要なリリースの前にプリリリース環境で重負荷テストを実行する。

CI/CDの品質ゲートは誤った保証をもたらすかもしれない

パフォーマンステストの品質ゲートは、リリースが信頼性の目標を満たしているかどうかを検証するPass/Fail基準として定義されることがよくあります。

ただし、数千または数百万の相互作用をテストする場合、信頼性のある品質ゲートを設定することは難しいです。テストスクリプト、特定の環境のSLO、Pass/Fail基準は簡単に誤る可能性があります。

信頼性チェックに誤った陰性がある可能性を仮定し（その逆も然り）、パフォーマンステストが誤ってリリースをブロックしないようにします。

確認プロセスが成熟していない場合、信頼性の確保に完全にPass/Failの結果を頼らないでください。不確かな場合は、Pass/Failの結果を使用して深刻な調査が必要な可能性がある問題に警告を発するように始め、自信を持つまで基準を継続的に調整してください。

さらに、ロードテストの実行時間は通常3分から15分以上かかります。そのため、パフォーマンステストをCI/CDに導入すると、リリースプロセスの時間が大幅に増加します。これは、自動デプロイメント向けのパイプラインで大規模なテストを実行しないよう勧める別の理由です。代わりに、専用の環境でリリース前のパフォーマンステストに1日以上を計画してください。

おわりに

今日は、k6を利用した性能テストの自動化についてご紹介しました。