はじめに

Some concerns when doing this type of performance testing are its dependency on fully integrated environments and the cost of scaling. You can test frontend performance only once the application code and infrastructure have been integrated with a user interface. Tools to automate frontend testing are also inherently more resource-intensive, so they can be costly to run at scale and are not suitable for high load tests.

 

引用元：Frontend performance | Load testing websites | k6 | Grafana Labs

この記事で得られること

• k6 と k6 browser の基本的な理解
• AKS 上で k6-operator を使った、分散環境でブラウザベースの負荷試験を実行する基盤の構築方法

前提条件

Azure 環境

• AKS および Azure Container Registry (以下、ACR) を作成できる権限を持つ Azure サブスクリプション
• Azure CLI に適切な認証情報が設定されていること

ローカル環境のツール

• Azure CLI: バージョン 2.81.0
• k8s クラスター: バージョン 1.33.6
• kubectl: バージョン 1.33.0
• Helm: バージョン 3.17.1
• Docker CLI: バージョン 27.5.1-rd で動作確認済み
• コンテナランタイム (Docker Desktop や Rancher Desktop など)
• k6: バージョン 1.4.0
• k6-operator: バージョン 4.2.0

用語説明

k6 とは

k6 の主な特徴

• シンプルな記述: JavaScript でテストシナリオを記述
• 高パフォーマンス: Go 言語で実装されており、軽量で高速
• 豊富なメトリクス: レスポンスタイム、スループット、エラー率など、詳細なメトリクスを収集
• 拡張性: カスタムメトリクスの定義や外部サービスとの連携が可能

• k6 | 公式サイト
• k6 | Grafana Labs
• Using k6 | k6 | Grafana Labs

k6 browser とは

k6 browser の主な特徴

• 実ブラウザでの動作: Chromium を使用し、JavaScript の実行やレンダリングを含めた負荷試験が可能
• k6 との統合: 従来の HTTP ベースの負荷試験と組み合わせて使用できる
• ユーザー操作の再現: クリック、入力、スクロールなど、実際のユーザー操作をシミュレート

• Using k6 browser | k6 | Grafana Labs

k6-operator とは

k6-operator の主な特徴

• カスタムリソースによる管理: TestRun などのカスタムリソースで負荷試験を定義できる
• 分散実行: 複数の Pod で負荷を分散させ、大規模な負荷試験を実行可能
• 宣言的な定義: YAML マニフェストで試験内容を定義し、kubectl で管理
• 自動スケーリング: 指定した並列数に応じて自動的に Pod を起動

• k6-operator | GitHub

ブラウザベースの負荷試験とは

• Load testing websites | k6 | Grafana

Backend testing is less resource-intensive than frontend performance testing and is thus more suitable for generating high load.

 

引用元：Backend performance | Load testing websites | k6 | Grafana Labs

インフラ構成

構成要素

Azure リソース

• AKS (Azure Kubernetes Service): k6-operator と負荷試験用 Pod を実行する k8s クラスタ
• ACR (Azure Container Registry): 負荷試験シナリオを含む Docker イメージを格納

Kubernetes リソース

• k6-operator: TestRun カスタムリソースを監視し、その定義に基づいて負荷試験用の Job を作成
• TestRun (カスタムリソース)**: 負荷試験の定義 (シナリオ、並列数、実行条件など)
• 負荷試験用 Job**: TestRun の定義に基づいて作成される Job
• 負荷試験用 Pod**: 実際に k6 を実行し、対象システムに負荷をかける Pod

名前空間について

負荷試験実施の流れ

リソースの構築と負荷試験の実施

• Azure リソース (AKS、ACR) の作成
• 負荷試験シナリオと Dockerfile の作成

• Docker ファイルのビルド
• Docker イメージを ACR にプッシュ

• Helm を使用して AKS クラスタに k6-operator をインストール

• TestRun カスタムリソースを作成して負荷試験を実行

0. 事前準備

0-1. Azure リソースの作成

# 変数の定義
RESOURCE_GROUP_NAME="rg-k6-loadtest-ve-je"
LOCATION="japaneast"
ACR_NAME="crk6loadtestveje"
AKS_NAME="aks-k6-loadtest-ve-je"

# リソースグループの作成
az group create \
  --name $RESOURCE_GROUP_NAME \
  --location $LOCATION

# ACR の作成
az acr create \
  --resource-group $RESOURCE_GROUP_NAME \
  --name $ACR_NAME \
  --sku Basic

# ACR へのログイン
az acr login --name $ACR_NAME

# AKS クラスタの作成
## クラスターの作成には数分かかります。完了したら、クラスターへの接続情報を取得します。
az aks create \
  --resource-group $RESOURCE_GROUP_NAME \
  --name $AKS_NAME \
  --node-count 2 \
  --node-vm-size Standard_D4ds_v5 \
  --attach-acr $ACR_NAME \
  --generate-ssh-keys
 
 # AKS クラスタの認証情報を取得
az aks get-credentials \
  --resource-group $RESOURCE_GROUP_NAME \
  --name $AKS_NAME

# 接続確認
kubectl config current-context

0-2. 負荷試験シナリオの作成

ディレクトリ構成

k6-browser-test/
├── Dockerfile
└── test/
    └── browser-test.js

# browser-test.js

import { browser } from 'k6/browser';

export const options = {
  scenarios: {
    phase1: {
      executor: 'constant-vus',
      vus: 1,
      duration: '25s',
      startTime: '0s',
      gracefulStop: '5s',
      options: {
        browser: {
          type: 'chromium',
        },
      },
    },
    phase2: {
      executor: 'constant-vus',
      vus: 2,
      duration: '25s',
      startTime: '30s',
      gracefulStop: '5s',
      options: {
        browser: {
          type: 'chromium',
        },
      },
    },
    phase3: {
      executor: 'constant-vus',
      vus: 3,
      duration: '25s',
      startTime: '60s',
      gracefulStop: '5s',
      options: {
        browser: {
          type: 'chromium',
        },
      },
    },
  },
  // 閾値は仮置きです。
  thresholds: {
    checks: ['rate==1.0'],
  },
};

export default async function () {
  const page = await browser.newPage();
 
  try {
    await page.goto('https://test.k6.io/');
    await page.screenshot({ path: 'screenshots/screenshot.png' });
  } finally {
    await page.close();
  }
}

• 30秒ごとに仮想ユーザー数が増え、段階的に負荷をかける
• 仮想ユーザー一人あたりの操作は、テスト用に用意されているk6の Web サイトにアクセスをし、スクリーンショットを取得することの繰り返し操作

• Browser options
• Scenario executors
• Scenario options

# Dockerfile

FROM grafana/k6:latest-with-browser
 
COPY --chown=k6:k6 test/ /test/ 

RUN chown -R k6:k6 /test/ && \
    chmod -R 755 /test/ 
    
# 非ルートユーザーに切替
USER k6 

WORKDIR /test/ 

# 実行結果の確認を行うため、コンテナを起動し続ける。
ENTRYPOINT ["tail", "-f", "/dev/null"]

1. 負荷試験シナリオの登録

# 変数の初期化
IMAGE_NAME='k6-browser-test'
IMAGE_TAG='v1.0.0'

# k6-browser-test ディレクトリに移動
cd $HOME/k6-browser-test

# イメージのビルド
docker build -t ${IMAGE_NAME}:${IMAGE_TAG} .

# イメージのタグ付け
## ACR のログインサーバー名を取得
ACR_LOGIN_SERVER=$(az acr show --name $ACR_NAME --query loginServer --output tsv)

## イメージにタグを付ける
docker tag ${IMAGE_NAME}:${IMAGE_TAG} ${ACR_LOGIN_SERVER}/${IMAGE_NAME}:${IMAGE_TAG}

# イメージをプッシュ
docker push ${ACR_LOGIN_SERVER}/${IMAGE_NAME}:${IMAGE_TAG}

2. k6-operator のインストール 

# k6-operator の Helm リポジトリの追加
helm repo add grafana https://grafana.github.io/helm-charts

# リポジトリの更新
helm repo update

# k6-operator のインストール
helm install k6-operator grafana/k6-operator --version 4.2.0

# k6-operator のリソースの状態を確認
# Pod の状態が Running になっていない場合は、少し待ってから再実行
# wait コマンドで deploy の状態に基づいて待機してもいい
kubectl get all -n k6-operator-system

3. TestRun の作成と負荷試験の実施

3-1. TestRun マニフェストの作成 

# testrun.yaml
apiVersion: k6.io/v1alpha1
kind: TestRun
metadata:
  name: k6-browser-test
  namespace: k6-load-testing
spec:
  parallelism: 3 # シナリオテストで指定している VUs の最大値に設定しています。
  script:
    localFile: /test/browser-test.js
  runner:
    image: crk6loadtestveje.azurecr.io/k6-browser-test:v1.0.0 # grafana/k6:latest-with-browser イメージから作成したカスタムイメージ
    topologySpreadConstraints: # Pod の配置を複数のノードに分散し、各ノードごとに配置される負荷試験用の Pod の数の差分が 1 以内にする。
      - maxSkew: 1
        whenUnsatisfiable: DoNotSchedule
        topologyKey: kubernetes.io/hostname
        labelSelector:
          matchLabels:
            k6_cr: k6-browser-test # metadata.name の値と一致させる

3-2. TestRun の作成

# TestRun を作成するための名前空間を作成する。
kubectl create namespace k6-load-testing

# TestRun を作成
kubectl apply -f testrun.yaml

# TestRun の確認
kubectl get testrun -n k6-load-testing

3-3. Job と Pod の確認

# Job の確認
kubectl get jobs -n k6-load-testing

# Pod の確認
kubectl get pods -n k6-load-testing

# TestRun の確認
kubectl get testrun -n k6-load-testing

実行結果の確認方法

Pod のログ確認

# Pod 名を確認
kubectl get pods -n k6-load-testing
 
# 特定の Pod のログを確認
# ${POD_NAME} は実際の Pod の名前に置き換えてください。
kubectl logs pod/${POD_NAME} -n k6-load-testing

# TestRun の削除
kubectl delete -f ./testrun.yaml

まとめ

おまけ

負荷試験の種類について

k6 のデフォルトイメージでは k6 browser が使用できない

負荷試験実行時に CPU やメモリなどのリソースが不足する

シナリオテストのファイルの管理方法

• ConfigMap
• VolumeClaim
• LocalFile

インフラランニングコスト

送信元 IP 制限やポート枯渇

その他参考

• Kubernetes上に負荷試験基盤を構築した話