ロードパフォーマンステスト

プラン: Premium、Ultimate
提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

ロードパフォーマンステストを使用すると、アプリケーションのバックエンドに対する保留中のコード変更の影響をGitLab CI/CDでテストできます。

GitLabは、アプリケーションのシステムパフォーマンスを測定するために、k6というオープンソースの無料ツールを使用しています。

クライアントブラウザでウェブサイトがどのように動作するかを測定するために使用されるBrowser Performance Testingとは異なり、ロードパフォーマンステストは、API、Webコントローラーなどのアプリケーションエンドポイントに対して様々な種類のロードテストを実行するために使用できます。これは、バックエンドまたはサーバーが大規模にどのように動作するかをテストするために使用できます。

例えば、ロードパフォーマンステストを使用して、アプリケーション内の人気のあるAPIエンドポイントに多くの同時GET呼び出しを実行し、そのパフォーマンスを確認できます。

ロードパフォーマンステストの仕組み

まず、.gitlab-ci.ymlファイルで、ロードパフォーマンスレポートアーティファクトを生成するジョブを定義します。GitLabはこのレポートをチェックし、ソースとターゲットブランチ間の主要なパフォーマンスメトリクスを比較して、マージリクエストのウィジェットに情報を表示します:

次に、テスト環境を設定し、k6テストを作成する必要があります。

テスト完了後にマージリクエストのウィジェットが表示する主要なパフォーマンスメトリクスは次のとおりです:

チェック: k6テストで設定されたチェックの合格率（パーセンテージ）。
TTFB P90: 応答の受信を開始するまでにかかった時間の90パーセンタイル値、別名Time to First Byte（TTFB）。
TTFB P95: TTFBの95パーセンタイル値。
RPS: テストで達成できた平均1秒あたりのリクエスト数（RPS）です。

ロードパフォーマンステストレポートに比較データがない場合、例えば.gitlab-ci.ymlにロードパフォーマンステストジョブを初めて追加した場合、ロードパフォーマンステストレポートのウィジェットは表示されません。そのブランチをターゲットとするマージリクエストに表示される前に、ターゲットブランチ（mainなど）で少なくとも一度実行されている必要があります。

ロードパフォーマンステストジョブを設定する

あなたのロードパフォーマンステストジョブの構成は、いくつかの異なる部分に分けられます:

スループットなどのテストパラメータを決定します。
ロードパフォーマンステスト用のターゲットテスト環境をセットアップします。
k6テストを設計し、作成します。

テストパラメータを決定する

まず、実行したいロードテストの種類と、その実行方法（例えば、ユーザー数、スループットなど）を決定する必要があります。

ガイダンスについては、k6ドキュメント、特にk6テストガイドを参照してください。

テスト環境のセットアップ

ロードパフォーマンステストの取り組みの大部分は、ターゲットテスト環境を高負荷に対応できるよう準備することです。テスト対象となるスループットを処理できることを確認する必要があります。

ロードパフォーマンステストが使用する代表的なテストデータをターゲット環境に用意することも通常必要です。

これらのテストを本番環境に対して実行すべきではありません。代わりに、プリプロダクション環境でテストを実行してください。

ロードパフォーマンステストを作成する

環境が準備できたら、k6テスト自体を作成できます。k6は柔軟なツールであり、様々な種類のパフォーマンステストを実行するために使用できます。テストの作成方法に関する詳細については、k6ドキュメントを参照してください。

GitLab CI/CDでテストを設定する

k6テストの準備ができたら、次のステップはGitLab CI/CDでロードパフォーマンステストジョブを設定することです。これを行う最も簡単な方法は、GitLabに付属のVerify/Load-Performance-Testing.gitlab-ci.ymlテンプレートを使用することです。

大規模なk6テストの場合、実際のテストを実行するGitLab Runnerインスタンスがテストの実行を処理できることを確認する必要があります。仕様の詳細については、k6のガイダンスを参照してください。The デフォルトの共有GitLab.com Runnerは、ほとんどの大規模なk6テストを処理するには仕様が不十分である可能性があります。

このテンプレートは、ジョブでk6 Dockerコンテナを実行し、ジョブをカスタマイズするいくつかの方法を提供します。

設定ワークフローの例:

GitLab Runnerをセットアップして、Docker-in-DockerワークフローのようにDockerコンテナを実行します。
あなたの.gitlab-ci.ymlファイルで、デフォルトのロードパフォーマンステストCI/CDジョブを設定します。テンプレートを含め、CI/CD変数で設定する必要があります:
```
include:
  template: Verify/Load-Performance-Testing.gitlab-ci.yml

load_performance:
  variables:
    K6_TEST_FILE: <PATH TO K6 TEST FILE IN PROJECT>
```

前の例では、k6テストを実行するCI/CDパイプラインにload_performanceジョブを作成します。

Kubernetesのセットアップの場合、異なるテンプレートを使用する必要があります: Jobs/Load-Performance-Testing.gitlab-ci.yml。

k6には、テストの実行方法を設定するための様々なオプションがあります。例えば、どのスループット（RPS）で実行するか、テストの実行時間などです。ほとんどすべてのオプションはテスト自体で設定できますが、K6_OPTIONS変数を介してコマンドラインオプションを渡すこともできます。

例えば、CLIオプションを使用してテストの期間をオーバーライドできます:

  include:
    template: Verify/Load-Performance-Testing.gitlab-ci.yml

  load_performance:
    variables:
      K6_TEST_FILE: <PATH TO K6 TEST FILE IN PROJECT>
      K6_OPTIONS: '--duration 30s'

GitLabは、k6の結果がサマリーエクスポートによってロードパフォーマンステストレポートアーティファクトとして保存された場合にのみ、MRのウィジェットに主要なパフォーマンスメトリクスを表示します。利用可能な最新のロードパフォーマンスアーティファクトが常に使用され、テストからのサマリー値が用いられます。

If GitLab Pagesが有効になっている場合、レポートをブラウザで直接表示できます。

レビューアプリにおけるロードパフォーマンステスト

以前のCI/CD YAML設定の例は静的環境に対するテストで機能しますが、いくつかの追加ステップでレビューアプリまたは動的環境で機能するように拡張できます。

最良のアプローチは、動的なURLを共有するジョブアーティファクトとして.envファイルにキャプチャし、次にK6_DOCKER_OPTIONSという名前のカスタムCI/CD変数を使用してk6 Dockerコンテナを設定してファイルを使用することです。これにより、k6は標準JavaScriptを使用するスクリプトで.envファイルからの任意の環境変数を使用できます。例: http.get(`${__ENV.ENVIRONMENT_URL}`)。

例:

reviewジョブで:
1. 動的なURLをキャプチャし、.envファイルに保存します。例えば、echo "ENVIRONMENT_URL=$CI_ENVIRONMENT_URL" >> review.envです。
2. .envファイルをジョブアーティファクトとして設定します。
load_performanceジョブで:
1. レビュージョブに依存するように設定して、環境ファイルを継承させます。
2. K6_DOCKER_OPTIONS変数を環境ファイル用Docker CLIオプション（例: --env-file review.env）で設定します。
k6テストスクリプトを設定して、そのステップで環境変数を使用するようにします。

あなたの.gitlab-ci.ymlファイルは次のようになるでしょう:

stages:
  - deploy
  - performance

include:
  template: Verify/Load-Performance-Testing.gitlab-ci.yml

review:
  stage: deploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: http://$CI_ENVIRONMENT_SLUG.example.com
  script:
    - run_deploy_script
    - echo "ENVIRONMENT_URL=$CI_ENVIRONMENT_URL" >> review.env
  artifacts:
    paths:
      - review.env
  rules:
    - if: $CI_COMMIT_BRANCH  # Modify to match your pipeline rules, or use `only/except` if needed.

load_performance:
  dependencies:
    - review
  variables:
    K6_DOCKER_OPTIONS: '--env-file review.env'
  rules:
    - if: $CI_COMMIT_BRANCH  # Modify to match your pipeline rules, or use `only/except` if needed.