Azure Load Testing

解決する課題

「本番のトラフィックに耐えられるか」を、テスト用サーバー群を自前で用意せずに検証できます。負荷を生成するエージェントの調達・構成・後片付けをマネージドに任せ、結果の収集と可視化までを一気通貫で行います。

• ピーク時の同時アクセスに対し、アプリの応答時間やスループットが要件を満たすか確かめたい
• 1 台のマシンでは出せない大規模な負荷を、複数のエンジンに分散して生成したい
• 負荷テストの実行基盤を都度構築・破棄する手間をなくし、結果だけ受け取りたい
• リリースのたびに性能の回帰を CI/CD で自動検出し、しきい値割れでパイプラインを止めたい

主要概念と用語

• テスト（Test）: 負荷テストの定義。テスト スクリプト、負荷の規模、合否を判定する条件などをまとめた単位
• テスト実行（Test Run）: テストを 1 回走らせた結果。応答時間やエラー率などのメトリクスが紐づく
• テスト エンジン（Engine）: 負荷を生成するマネージドなインスタンス。台数を増やして並列に負荷をスケールアウトできる
• JMeter スクリプト: Apache JMeter の JMX 形式のテスト計画。既存資産をそのまま持ち込める
• Locust スクリプト: Python ベースの負荷テスト定義。コードで負荷シナリオを書きたい場合に使う
• 合否条件（Pass/Fail Criteria）: 平均応答時間やエラー率などのしきい値。超過するとテストを失敗扱いにできる
• テスト プロファイル / 自動停止（Auto Stop）: エラー率が高いときに実行を自動で打ち切る安全装置
• クライアント側メトリクス: 負荷をかける側（エンジン）で観測する応答時間・スループット・エラー率
• サーバー側メトリクス: テスト対象の Azure リソース側で Azure Monitor から取り込む CPU やメモリなどの指標

仕様・制限・クォータ

• スクリプトは **Apache JMeter（JMX）**と Locust に対応する。既存の JMeter 資産を再利用できるのが大きな利点
• 負荷の規模はテスト エンジンの台数でスケールアウトする。1 エンジンあたりの並列ユーザー数には目安があり、台数を増やして大規模化する
• リージョンやサブスクリプションごとに、同時実行できるテスト数やエンジン数などに**上限（クォータ）**があり、必要に応じて引き上げを申請する
• テスト対象はパブリックなエンドポイントのほか、構成すれば仮想ネットワーク内のプライベートな対象にも負荷をかけられる
• 具体的なクォータ数値や上限は変動するため、計画時は対象リージョンの最新値を確認する

内部の仕組み

利用者はテスト スクリプト（JMeter または Locust）と負荷の規模を指定するだけで、Azure Load Testing がマネージドなテスト エンジンを必要台数だけ起動し、各エンジンから対象アプリへ並列に負荷をかけます。エンジンの調達・構成・破棄はサービス側が行うため、負荷生成基盤を自前で運用する必要はありません。

• 複数のテスト エンジンに負荷を分散してスケールアウトし、1 台では到達できない規模のリクエストを生成する
• 実行中はクライアント側メトリクス（応答時間・スループット・エラー率）を集約し、ダッシュボードに可視化する
• テスト対象が Azure リソースなら、Azure Monitor からサーバー側メトリクスを取り込み、負荷時のリソース挙動とつき合わせて分析できる
• 合否条件を満たさない、またはエラー率が高い場合は、テストを失敗扱いにしたり自動停止したりできる

設計パターン / ベストプラクティス

• CI/CD に組み込む: リリース パイプラインに負荷テストを差し込み、合否条件で性能回帰を自動検出してデプロイを止める
• 本番に近い構成で測る: テスト対象の SKU・スケール設定・データ量を本番相当にし、結果の妥当性を担保する
• クライアントとサーバー両側を見る: クライアント側の応答時間だけでなく、サーバー側メトリクスでボトルネック（CPU・DB・スロットリング）を切り分ける
• 段階的にランプアップ: 一気に最大負荷をかけず、徐々に上げてスケール限界とブレークポイントを見つける
• 安全装置を入れる: 自動停止やエラー率しきい値を設定し、暴走したテストが対象環境へ過剰な負荷をかけ続けないようにする
• テストデータを分離: 本番データを壊さないよう、専用のテスト環境やテストアカウントに対して実施する

運用・監視

• 結果はダッシュボードで応答時間・スループット・エラー率の推移として確認し、実行ごとに比較して回帰を追う
• 対象が Azure リソースなら Azure Monitor のサーバー側メトリクスを併せて取り込み、負荷時の CPU・メモリ・スロットリングを突き合わせる
• エラーが急増する場合は、対象側のスケール上限・接続数・スロットリングのほか、テスト スクリプトやエンジン台数の設定を点検する
• 実行は az CLI や REST API、各種パイプライン タスクから自動化し、ニッチな手作業を排除する

コスト

課金は、おおむね実行したテストでの負荷生成量に基づく従量制です。具体的にはエンジンの稼働時間や生成した仮想ユーザー時間といった「使った分」に応じてかかり、テストしていない間の固定的なコストは小さく抑えられます。

セキュリティ

• 認証情報やトークンはスクリプトに直書きせず、シークレットとして安全に渡し、Key Vault などで管理する
• リソースへのアクセスは Microsoft Entra ID と Azure RBAC で制御し、テストの作成・実行権限を最小化する
• プライベートな対象に負荷をかける場合は、仮想ネットワークへ統合してエンジンを対象網内から到達させる
• テスト対象や結果に機微情報を含めないよう注意し、ログやスクリプトに秘匿値を残さない

Well-Architected の観点

• パフォーマンス効率: 本番相当の構成に対して負荷をかけ、応答時間・スループット・スケール限界を定量化する。クライアント側とサーバー側のメトリクスを突き合わせ、ボトルネックを継続的に解消する
• オペレーショナル エクセレンス（補完）: 負荷テストを CI/CD に組み込み、合否条件で性能回帰を自動検出してリリース品質を仕組み化する

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# リソースグループと Load Testing リソースを作成
az group create --name demo-rg --location japaneast
az load create \
  --name demo-loadtest \
  --resource-group demo-rg \
  --location japaneast

# JMeter スクリプトを使うテストを作成（負荷設定はテスト構成 YAML で指定）
az load test create \
  --load-test-resource demo-loadtest \
  --resource-group demo-rg \
  --test-id sample-test \
  --load-test-config-file ./loadtest-config.yaml \
  --test-plan ./sample.jmx

# テストを実行し、結果（応答時間・エラー率など）を生成
az load test-run create \
  --load-test-resource demo-loadtest \
  --resource-group demo-rg \
  --test-id sample-test \
  --test-run-id run-001

# 実行結果のメトリクスを取得して確認
az load test-run show \
  --load-test-resource demo-loadtest \
  --resource-group demo-rg \
  --test-run-id run-001