こんにちは。よっしーです(^^)
今日は、k6を利用した性能テストの自動化についてご紹介します。
背景
Dockerで構築したWebアプリの開発環境において、k6を利用した負荷テストについて調査したときの内容を備忘として残しました。
開発環境のソースは下記のリポジトリにあります。
背景
性能テストの自動化は、開発およびリリースサイクルの異なる段階で信頼性の問題を確認する、繰り返し可能で一貫性のあるプロセスを確立することに関連しています。たとえば、CI/CDパイプラインや夜間のジョブから性能テストを実行したり、負荷テストを手動でトリガーし、そのリアルタイムの影響を監視したりできます。
性能テストにおいて、自動化は手動でテストを実行する必要をなくすものではありません。それは連続的な性能テストのためにソフトウェア開発ライフサイクル（SDLC）の一部として性能テストを計画することです。
この記事では、自動化された性能テストを実行するための戦略を計画し定義するのに役立つ一般的な推奨事項を提供しています：
- どのテストを自動化するか？
- どの環境をテストするか？
- どのように頻繁にテストを実行し、どのように行うか？
- 性能結果をどのように分析するか？
この記事は、k6に精通しており、すでに性能テストを持っていることを前提としています。
では、自動化の背後にある「なぜ」を考え、性能テストの努力の完全な利点を引き出す方法について考えてみましょう。
なぜ自動化するのか
ウェブサイトの秒単位での読み込み、APIのミリ秒単位でのレスポンス、瞬時の障害応答など、パフォーマンスは直接エンドユーザーエクスペリエンスに影響を与えるため、非常に重要です。しかし、組織内の課題の1つは、パフォーマンスがしばしば機能や要件としての認識を得ないことです。
パフォーマンスは、多くの組織ではまだ具体的ではなく、悪いことが起こったときにのみ反応することがあります。自動化は、この反応的なアプローチから予防的なアプローチへの変更をもたらします。
性能テストでは、実践を一貫して行うためのルーチンを確立することが重要です。自動化は、性能テストの習慣を作成し、その利点をいくつか向上させる必要があります：
- テストカバレッジの増加：自動化は一貫した反復プロセスを作成します。これにより、性能テスト実践への継続的な取り組みが促進され、より広範なテストカバレッジとテストの保守が向上する可能性があります。
- 問題の早期検出：ソフトウェアの提供プロセスの一環として性能テストを自動化することで、アプリケーションが信頼性の目標を満たし、SDLCの早い段階で問題を検出することができます。
- チーム間の協力：自動化は、SDLCや部門全体で戦略と計画を明確にするようチームに促します。それにより、エンジニアリーダーが信頼性を提唱し、共有の実践を実施する手助けをします。
自動化がない場合、共有フレームワークの不在は、孤立した断続的な活動につながることがしばしばあります。自動化は、継続的な性能および信頼性テストを推進し、より効率的で効果的なテストプロセスを導入するのに役立ちます。
CI/CDについて
自動化はしばしば、リリースプロセスの一部としてのテストの実行（合格/不合格条件を含む）を指す言葉であり、通常は継続的インテグレーションまたは継続的デリバリーパイプライン（CI/CD）に統合されます。ただし、性能テストは合格/不合格の結果やリリースプロセスのゲートキーパーであることだけを意味するものではありません。
CI/CDパイプラインへの自動化は選択肢の1つですが、性能テストの実行をスケジュールするための唯一の方法ではありません。性能テスト計画を作成する際には、性能テストを実行する異なる方法があり、包括的な戦略には以下のような方法が含まれる可能性があることを覚えておくことが重要です：
- Cronおよびcronジョブランナーを使用する方法。
- Grafana Cloud k6などのクラウドテストツールを使用する方法。
- 自動化機能を持つテスト管理ツールを使用する方法。
- 手動テストをトリガーする方法。リリースチェックリストプロセスの一環としてこれを含める方法。
つまり、性能テストを自動化する方法は多岐にわたり、CI/CDパイプラインへの統合が選択肢の一つであることを認識することが重要です。プロジェクトの要件や目標に応じて、最適な実行方法を選択できます。
テストの目的を特定する
プロセスの最初のステップは、既存または計画中のテストを見直し、各テストの目的を理解することです。定期的に実行される場合、テストは追加の目的を果たすことができるでしょうか？一般的な目標には以下のようなものがあります：
- 現在のパフォーマンスを既存のパフォーマンスベースラインと比較する。
- 主要なパフォーマンスメトリクスの時間にわたる変動を理解する。平坦なトレンドまたは変動するトレンドを観察する。
- 新しいリリースのリグレッションを検出する。
- 定期的にサービスレベル目標（SLOs）をテストする。
- リリースプロセス中に重要な領域をテストする。
- CI/CDパイプラインで品質ゲートを設定する。
各テストについて一貫性のある継続的な目的を考えると、どのテストを自動化するか、不足している機能やテストスイート内の欠落しているテストを発見することができます。また、各テストを実行する最適なタイミングと方法を決定するのに役立ちます。
どのテストを自動化するかを選択する
性能テストは一般的に次の2つの側面に分けることができます：
- テストシナリオ（テストケース）：何を検証するテストですか？
- テストワークロード（テスト負荷）：どれだけのトラフィックとどのトラフィックパターンを使用するか？
テストスイートは、異なる負荷テストタイプを使用してシステムの重要な領域を検証できる多様なテストを組み込むべきです。
定期的に実行したい既存のテストは、自動化の候補です。基本的に、自動化はテストを頻繁かつ一貫して実行することであり、それが日常的に、週次的に、年次的に行われるかどうかにかかわらずです。
性能テストスイートを自動化する際に考慮すべき2つの重要なポイントは次のとおりです：シンプルに始め、テストをモジュール化することです。
- シンプルに始めて反復的に進化させる：チームが学び、信頼性の問題を調査するためにテストスイートとテストカバレッジが拡大します。
- テストスイートをモジュール化する：k6の場合、シナリオとワークロードのロジックを分離し、異なるテスト間で再利用できます。これにより、さまざまなトラフィックパターンのテストをさまざまな目的に使用するプロセスが簡素化されます。モジュール化により、共通のロジックを複数のテストで再利用できます。
テストカバレッジまたは自動化を計画する際には、以下のテストから始めることを検討してください：
- 製品とビジネスに不可欠なコア機能を検証するテスト。
- トラフィックが多いシナリオでのパフォーマンスを評価するテスト。
- 主要なパフォーマンスメトリクスを追跡し、それらのトレンドを観察し、ベースラインと比較するテスト。
- 合格/不合格基準で信頼性の目標またはSLOを検証するテスト。
おわりに
今日は、k6を利用した性能テストの自動化についてご紹介しました。
何か質問や相談があれば、コメントをお願いします。また、エンジニア案件の相談にも随時対応していますので、お気軽にお問い合わせください。
それでは、また明日お会いしましょう(^^)
コメント