負荷テストとストレステスト：違いと使い分け
Yunhao Jiao
負荷テストとストレステストは、パフォーマンステストにおいて最も混同されやすい2つの概念です。どちらもアプリケーションに負荷をかけてその挙動を測定するという点で関連していますが、答える問いと目的が異なります。
このガイドでは両者の違いを明確にし、それぞれが有効な場面と実践的な実装方法について解説します。
負荷テスト
負荷テストは、想定される負荷条件下でアプリケーションがどのようなパフォーマンスを発揮するかを測定します。中心となる問いは「想定している同時ユーザー数やリクエスト数が実際に発生したとき、アプリケーションはパフォーマンス要件を満たしているか？」です。
負荷テストはパフォーマンス目標の検証を目的としています。目標を設定し（「500同時ユーザーのp95において、APIは200ms以内に応答しなければならない」）、アプリケーションがそれを満たしているかを確認します。
代表的な負荷テストシナリオ：
- 想定されるピーク時のトラフィックをシミュレートする（例：月曜日の朝に500同時ユーザー）
- 通常の運用条件下でSLAが維持されることを検証する
- デプロイまたは最適化の前後でパフォーマンスを比較する
- 新機能が既存機能のパフォーマンスを低下させないことを確認する
負荷テストが答える問い：システムは想定される負荷に耐えられるか？
ストレステスト
ストレステストは、アプリケーションを通常の運用能力を超えた限界まで追い込み、限界点を特定し、どのように障害が発生するかを理解するためのテストです。中心となる問いは「アプリケーションはどこで、どのように障害が発生するか？」です。
ストレステストはシステムの限界と障害モードの把握を目的としています。特定のパフォーマンス目標を持つ必要はなく、システムの実際の限界を発見し、障害が壊滅的（クラッシュ、データ破損、他サービスの停止）ではなく、段階的（エラーの返却、緩やかなパフォーマンス低下）な形で発生することを確認します。
代表的なストレステストシナリオ：
- アプリケーションが障害を起こすまで負荷を増加させ、限界点を特定する
- 過負荷状態においてサーキットブレーカーとレートリミッターが正しく作動することを検証する
- 負荷が正常に戻った際にアプリケーションが適切に回復することを確認する
- 過負荷状態の1つのサービスが他のサービスへの障害連鎖を引き起こさないことをテストする
ストレステストが答える問い：システムはどのように障害を起こすか、そして安全に失敗するか？
その他のパフォーマンステストの種類
スパイクテスト — ストレステストの一種で、段階的な負荷増加ではなく、突発的かつ急激な負荷増加をテストします。バイラルトラフィック、フラッシュセール、または速報ニュースイベントに対してシステムが障害や著しい性能低下なく対応できるかを検証します。主な問い：システムはスパイクを乗り越えられるか、そしてスパイク終了後に回復できるか？
ソークテスト（耐久テスト） — 通常の負荷を長時間（数時間から数日間）継続してアプリケーションを稼働させるテストです。時間の経過とともに表面化する問題を特定します：メモリリーク、コネクションプールの枯渇、ディスク使用量の増加、パフォーマンスを低下させるキャッシュの肥大化など。負荷テストおよびストレステストは数分間で完了するため、数日にわたるこれらの問題を見逃す可能性があります。
ボリュームテスト — 大量のデータを用いてテストを行い、データ量の増加に伴うパフォーマンス低下が発生しないことを検証します。ページネーションやインデックスが適切に実装されていない場合、100件のレコードを50msで返すAPIエンドポイントが、100,000件のレコードを返すのに5秒かかることがあります。
各テスト種別の実施タイミング
CI/CDにおけるパフォーマンステスト：ベースラインアプローチ
すべてのPRに対してフル負荷テストおよびストレステストを実施することは現実的ではありません — 時間がかかりすぎ、コストも高すぎます。CI/CDにおける実践的なアプローチはベースライン比較です：
- 現在のパフォーマンスを計測し、ベースラインを設定する
- すべてのPRに対して軽量なパフォーマンスチェックを実行する（主要エンドポイント、コアフロー）
- PRがパフォーマンスをしきい値以上に低下させた場合にアラートを発報する（例：p95レイテンシが20%以上増加）
- 定期スケジュール、またはメジャーリリース前にフル負荷テスト/ストレステストを実行する
TestSpriteの機能的E2Eテストは、AIが生成するパフォーマンスバグの中で最も一般的なもの — タイムアウトを引き起こすN+1クエリ、リストエンドポイントを低速化する不足したページネーション、レスポンスタイムSLAを破る同期ブロッキング — を機能的な失敗として自然に検出します。専用の負荷テストおよびストレステストには、TestSpriteの機能カバレッジと組み合わせてk6、Artillery、またはGatlingを使用してください。
負荷テストおよびストレステストのツール
k6 — モダンで開発者フレンドリーな負荷テストツール。JavaScriptベースのスクリプト、優れたCLI体験、優秀なCI/CD統合、クラウド実行にも対応。APIの負荷テストに現在推奨されるツールです。
Artillery — YAMLベースの設定を採用した、もう1つの人気負荷テストツール。宣言的なテスト定義を好むチームに適しています。
Gatling — JVMベースで、大規模なシミュレーションに強く、エンタープライズJava環境で広く利用されています。
Locust — Pythonベースで複雑なシナリオを簡単に記述でき、Pythonの知識を持つチームに適しています。
計測すべき指標
負荷テストとストレステストの両方において、重要な指標は以下の通りです：
レスポンスタイムのパーセンタイル — p50（中央値）、p95、p99。p50は一般的なユーザー体験を示し、p95とp99は多くのユーザーに影響するテールレイテンシを示します。
スループット — 目標パフォーマンスレベルでシステムが処理できる1秒あたりのリクエスト数。
エラーレート — 各負荷レベルでリクエストの何パーセントが失敗するか？どの負荷水準からエラーレートが上昇し始めるか？
リソース使用率 — CPU、メモリ、データベース接続数、スレッドプールの使用状況。これらはボトルネックの特定に役立ちます。
回復時間 — ストレステスト後、システムが正常なパフォーマンスに戻るまでの時間。
アプリケーションのパフォーマンスを考慮したテストを設定する →