ロードパフォーマンステスト
- プラン: Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
ロードパフォーマンステストを使用すると、保留中のコード変更が、アプリケーションのバックエンドに与える影響をGitLab CI/CDでテストできます。
GitLabでは、k6(無償のオープンソースツール)を使用して、ロード時のアプリケーションのシステムパフォーマンスを測定します。
Webサイトがクライアントブラウザでどのようにパフォーマンスを発揮するかを測定するために使用されるブラウザパフォーマンステストとは異なり、ロードパフォーマンステストは、API、Webコントローラーなどのアプリケーションエンドポイントに対して、さまざまな種類の負荷テストを実行するために使用できます。これは、バックエンドまたはサーバーがスケール時にどのようにパフォーマンスを発揮するかをテストするために使用できます。
たとえば、ロードパフォーマンステストを使用して、アプリケーション内の一般的なAPIエンドポイントに対して多くの同時GET呼び出しを実行し、そのパフォーマンスを確認できます。
ロードパフォーマンステストの仕組み
まず、.gitlab-ci.ymlファイルで、Load Performance reportアーティファクトを生成するジョブを定義します。GitLabはこのレポートをチェックし、ソースブランチとターゲットブランチ間のキーとなるロードパフォーマンステストのメトリクスを比較し、マージリクエストウィジェットに情報を表示します:
次に、テスト環境を設定し、k6テストを作成する必要があります。
テスト完了後、マージリクエストウィジェットに表示されるキーとなるパフォーマンスメトリクスは次のとおりです:
- チェック: k6テストで設定されたチェックの合格率(パーセント)。
- TTFB P90: 応答の受信開始にかかった時間(つまり、Time to First Byte(TTFB))の90パーセンタイル。
- TTFB P95: TTFBの95パーセンタイル。
- RPS: テストで達成できた1秒あたりの平均リクエスト数(RPS)レート。
ロードパフォーマンストレポートに比較するデータがない場合(たとえば、.gitlab-ci.ymlにロードパフォーマンスジョブを初めて追加した場合など)、ロードパフォーマンストレポートウィジェットは表示されません。そのブランチをターゲットとするマージリクエストに表示する前に、ターゲットブランチ(mainなど)で少なくとも1回は実行されている必要があります。
ロードパフォーマンステストジョブを設定する
ロードパフォーマンステストジョブの設定は、いくつかの異なる部分に分類できます:
- スループットなどのテストパラメータを決定します。
- ロードパフォーマンステストのターゲットテスト環境をセットアップします。
- k6テストを設計および作成します。
テストパラメータを決定する
最初に、実行する負荷テストのタイプと、その実行方法(たとえば、ユーザー数、スループットなど)を決定する必要があります。
ガイダンスについては、k6ドキュメント 、特にk6テストガイドを参照してください。
テスト環境のセットアップ
ロードパフォーマンステストに関する作業の大部分は、高負荷に対応できるようにターゲットテスト環境を準備することです。テスト対象のthroughputスループットを処理できることを確認してください。
通常、ロードパフォーマンステストで使用するために、ターゲット環境に代表的なテストデータを含める必要もあります。
本番環境に対してこれらのテストを実行しないことを強くお勧めします。
負荷パフォーマンステストの作成
環境を準備したら、k6テスト自体を作成できます。k6は柔軟なツールであり、多くの種類のパフォーマンステストを実行するために使用できます。テストの作成方法の詳細については、k6ドキュメントを参照してください。
GitLab CI/CDでのテストの設定
k6テストの準備ができたら、次のステップは、GitLab CI/CDで負荷パフォーマンステストジョブを設定することです。これを行う最も簡単な方法は、GitLabに含まれているVerify/Load-Performance-Testing.gitlab-ci.ymlテンプレートを使用することです。
このテンプレートは、ジョブでk6 Dockerコンテナを実行し、ジョブをカスタマイズするためのいくつかの方法を提供します。
設定のワークフローの例:
Docker-in-Dockerワークフローのように、Dockerコンテナを実行するようにGitLab Runnerをセットアップします。
.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の結果がサマリーエクスポートとしてLoad Performance reportアーティファクトとして保存されている場合にのみ、MRウィジェットにキーとなるパフォーマンスメトリクスを表示します。利用可能な最新のロードパフォーマンスアーティファクトは常に使用され、テストからのサマリー値が使用されます。
GitLab Pagesが有効になっている場合は、ブラウザでレポートを直接表示できます。
レビューアプリでのロードパフォーマンステストテスト
前のCI/CD YAML設定の例は、静的環境に対するテストで機能しますが、いくつかの追加手順でレビューアプリまたは動的環境で動作するように拡張できます。
最適なアプローチは、共有されるジョブアーティファクトとして.envファイルに動的URLを取り込み、ファイルを使用するようにk6 Dockerコンテナを設定するために、提供されたカスタムCI/CD変数K6_DOCKER_OPTIONSを使用することです。これにより、k6は、.envファイルの環境変数を標準のJavaScriptを使用したスクリプトで使用できます(例: http.get(`${__ENV.ENVIRONMENT_URL}`))。
例:
reviewジョブ内:- 動的URLを取り込み、
.envファイルに保存します(例:echo "ENVIRONMENT_URL=$CI_ENVIRONMENT_URL" >> review.env)。 .envファイルをジョブアーティファクトとして設定します。
- 動的URLを取り込み、
load_performanceジョブ内:- レビュージョブに依存するように設定して、環境ファイルを継承します。
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.