Load Testing（ロードテスティング）

3. エラー率（Error Rate）

全リクエストのうち、HTTP 5xx（サーバーエラー）やHTTP 429（Too Many Requests）などのエラーが占める割合です。

• 目標値: 運用環境においては、エラー率を 0.1%未満 に抑えることが一般的です。

4. リソース利用率（Resource Utilization）

負荷がかかっている最中の、サーバー内部の健康状態を示す数値です。

• CPU Usage: CPU使用率が80%を超えると、キューイングが発生し、レスポンスタイムが悪化する危険があります。
• Memory Usage: 物理メモリ（例: 16GB RAM）の消費量。
• Disk I/O: ディスクの読み書き速度（IOPS）。
• Network Bandwidth: ネットワーク帯域の消費量（例: 1Gbps）。

負荷テストに使用される主要なツールとクラウドサービス

負荷テストを実現するためには、大量の仮想ユーザー（Virtual Users）を生成し、クラウド上のターゲットに対してリクエストを送信する「負荷発生器（Load Generator）」が必要です。以下に、業界標準となっているツールと、クラウドネイティブなサービスを紹介します。

各ツールの活用例とスペックの検討

例えば、k6 を使用して、Amazon EC2 の m7g.large インスタンス（2 vCPU, 8GB RAM）上で負荷発生エージェントを稼働させる場合、以下のような設計が考えられます。

1. シナリオの作成: JavaScriptを用いて、ログイン → 商品検索 → カート追加 → 決済 という一連のフローを記述します。
2. 負荷の増幅: 単一のインスタンスでは限界があるため、複数のエージェントに分散させ、合計で 5,000 Concurrent Users（同時接続ユーザー） を生成します。
3. 監視の統合: 負荷を与えながら、Amazon CloudWatch や Grafana を通じて、ターゲットとなるサーバーのCPU使用率やメモリ消費量（例: 4GBから12GBへの推移）をリアルタイムで可視化します。

負荷テストの設計・実行プロセス

効果的な負荷テストを行うためには、場当たり的な実行を避け、構造化されたプロセスを踏む必要があります。

1. テスト目標の策定: 「何を、どの程度の規模で、どのレベルの精度で検証するか」を定義します。
2. テストシナリオの作成: 実際のユーザー行動（User Journey）をモデル化します。
   • ログイン率、検索率、購入率などの比率を決定。
   • Think Time（ユーザーがページを見てから次の操作をするまでの待機時間）の設定。
3. テスト環境の構築: 本番環境と可能な限り同一のスペック（CPU、メモリ、ネットワーク構成）を持つ環境、あるいは本番のコピーを作成します。
4. 負荷発生器（Load Generator）の準備: 前述の Locust や k6 を配置します。
5. 実行（Ramp-up / Ramp-down）:
   • Ramp-up: ユーザー数を徐々に増やしていくプロセス。
   • Steady State: 設定した目標負荷を一定時間維持するプロセス。
   • Ramp-down: 負荷を徐々に下げていくプロセス。
6. 結果の分析とレポート作成: エラー率、レイテンシ、リソース使用率を比較し、ボトルネック（例: データベースのロック、ネットワーク帯域の不足）を特定します。
7. 改善と再テスト: ボトルネックを解消（例: インスタンスのアップグレード、インデックスの追加）した後、再度テストを行い、効果を検証します。

2025年・2026年の最新トレンド：AIと自律型テストの到来

負荷テストの分野は、現在大きな変革期にあります。2025年から2026年にかけて、以下の「次世代」の技術が主流になると予想されています。

AI-Driven Load Testing（AI駆動型負荷テスト）

従来のテストシナリオ作成は、人間が手動でスクリプトを書く必要がありました。しかし、最新のAI技術（LLM: 大規模言語モデル）の統合により、実際のアクセスログからユーザーの行動パターンを学習し、「自動的にテストシナリオを生成する」 技術が普及し始めています。これにより、人間では気づかなかった複雑なエッジケース（稀な操作パターン）をカバーすることが可能になります。

Chaos Engineering（カオスエンジニアリング）の融合

Netflixが提唱したカオスエンジニアリング（意図的にシステムに障害を起こして耐性を確認する手法）と、負荷テストの境界が曖昧になっています。単に負荷をかけるだけでなく、「負荷が高い状態で、特定のマイクロサービスを停止させる」「ネットワーク遅延を意図的に発生させる」 といった、より過酷でリアルなシナクトラン（実行環境）の検証が、クラウドネイティブなインフラにおいて標準的なプロセスとなりつつあります。

Observability（オブザーバビリティ）との統合

負荷テストの結果を単なるグラフとして見るのではなく、分散トレーシング（Distributed Tracing）と連携させ、「どのSQLクエリが、どのマイクロサービスの、どのスレッドで遅延を引き起こしたか」 を、リクエスト単位で特定することが可能になります。これにより、トラブルシューティングの時間は大幅に短縮されます。

負荷テストに関するよくある質問 (FAQ)

Q1: 負荷テストとストレステストの違いは何ですか？ A1: 負荷テストは「想定内の負荷（期待されるピーク時）」に対してシステムが正常に動作するかを確認するものです。一方で、ストレステストは「想定外の過剰な負荷」を与え、システムがどのように壊れるか、そして壊れた後に自動復旧（Self-healing）できるかを確認するためのものです。

Q2: 負荷テストを行う際、コストを抑える方法はありますか？ A2: 全てのテストを本番同等の巨大な環境で行うと、膨大なクラウド利用料金（例: 数十万円〜）が発生します。そのため、まずは軽量な環境でスケーラビリティの傾向を把握し、重要な検証ポイントに絞って、AWS Distributed Load Testing のようなマネージドサービスを活用して、必要な時だけ大規模なリソースを動員する「エフェメラル（一時的）なインフラ構成」を採用するのが賢明です。

Q3: 負荷テストはどのタイミングで行うべきですか？ A3: 開発の初期段階（Shift-Left Testing）から継続的に行うことが理想的です。新しい機能を追加したり、インフラの構成（例: インスタンスタイプを t3 から c7g に変更したり）を変更したりした際には、必ず回帰テスト（Regression Testing）として負荷テストを実施し、パフォーマンスの退行（デグラデーション）が発生していないかを確認してください。