• ロード・パフォーマンス・テストの仕組み
• 負荷パフォーマンステストジョブの設定
  • 試験パラメーターの決定
  • テスト環境のセットアップ
  • 負荷性能テストの記述
  • GitLab CI/CDでテストを設定します。
  • レビューアプリの負荷パフォーマンステスト

負荷性能試験

GitLab 13.2 で導入されました。

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

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

クライアント・ブラウザでのウェブサイトのパフォーマンスを測定するために使われるブラウザ・パフォーマンス・テストとは異なり、ロード・パフォーマンス・テストはAPIやウェブ・コントローラなどのアプリケーション・エンドポイントに対して様々なタイプの負荷テストを実行するために使うことができます。これは、バックエンドまたはサーバーがスケール時にどのように動作するかをテストするために使用できます。

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

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

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

次に、テスト環境を設定して k6 テストを書く必要があります。

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

• チェック：チェック： k6 テストで設定したチェックの合格率。
• TTFB P90: レスポンスの受信開始までに要した時間の 90 パーセンタイル、別名Time to First Byte (TTFB)。
• TTFB P95: TTFBの95パーセンタイル。
• RPS：テストが達成できた平均リクエスト/秒(RPS) レート。

負荷パフォーマンステストジョブの設定

Load Performance Testing ジョブの設定は、いくつかの異なる部分に分けることができます：

• スループットなどのテスト・パラメータを決定します。
• 負荷性能試験の対象試験環境を設定します。
• k6テストの設計と記述

試験パラメーターの決定

最初に行う必要があるのは、実行したい負荷テストのタイプと、それを実行する方法（たとえば、ユーザー数、スループットなど）を決定することです。

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

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

負荷性能テストに関する労力の大部分は、高負荷に対応するターゲットテスト環境を準備することです。テスト対象のスループットを処理できるようにする必要があります。

また、通常、負荷性能テストで使用する代表的なテストデータをターゲット環境に用意する必要があります。

本番環境に対してこれらのテストを実行しないことを強くお勧めします。

負荷性能テストの記述

k6 は柔軟なツールであり、様々な種類のパフォーマンステストを実行することができます。テストの書き方の詳細については、k6のドキュメントを参照してください。

GitLab CI/CDでテストを設定します。

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

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

設定ワークフローの例です：

1. Docker-in-Dockerワークフローのように、Dockerコンテナを実行するためにGitLab Runnerを設定します。

2. .gitlab-ci.yml ファイルにデフォルトの Load Performance Testing 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テストを実行するload_performance ジョブをCI/CDパイプラインに作成しています。

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 の結果がLoad Performance レポートアーティファクトとして サマリーエクスポートによって保存されている場合にのみ、主要なパフォーマンスメトリクスを MR ウィジェットに表示します。利用可能な最新の Load Performance アーティファクトが常に使用され、テストのサマリー値が使用されます。

GitLab Pagesが有効な場合は、ブラウザで直接レポートを表示できます。

レビューアプリの負荷パフォーマンステスト

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

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

使用例：

1. review のジョブの場合：
   1. 動的URLをキャプチャし、.env ファイルに保存します。例えば、echo "ENVIRONMENT_URL=$CI_ENVIRONMENT_URL" >> review.env 。
   2. .env ファイルをジョブのアーティファクトに設定します。
2. load_performance のジョブの場合：
   1. レビュアー・ジョブに依存するように設定し、環境ファイルを継承します。
   2. 環境ファイル用のDocker CLIオプションで K6_DOCKER_OPTIONS 変数を設定します。例えば--env-file review.env 。
3. 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.