負荷テストとストレステスト：その違いと使い分け
Yunhao Jiao
負荷テストとストレステストは、パフォーマンステストにおいて最もよく混同される概念の二つです。両者は関連しており——どちらもアプリケーションに負荷をかけて何が起きるかを測定します——が、それぞれ異なる問いに答え、異なる目的を果たします。
このガイドでは両者の違いを明確にし、それぞれが有効な場面を説明し、実践的な実装方法を解説します。
負荷テスト
負荷テストは、想定される負荷条件下でアプリケーションがどのようにパフォーマンスを発揮するかを測定します。中心となる問いは「想定している同時ユーザー数やリクエスト数が実際に発生したとき、アプリケーションはパフォーマンス要件を満たせるか」です。
負荷テストは、パフォーマンス目標を検証するためのものです。「500人の同時ユーザーに対してAPIがp95で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ベースの設定を採用した人気の負荷テストツールです。宣言的なテスト定義を好むチームに適しています。
Gatling — JVMベースで大容量シミュレーションに強く、エンタープライズJava環境で広く利用されています。
Locust — Pythonベースで複雑なシナリオを記述しやすく、Pythonに精通したチームに適しています。
計測すべき指標
負荷テスト・ストレステストの両方において、重要な指標は以下のとおりです：
レスポンスタイムのパーセンタイル — p50（中央値）、p95、p99。p50は典型的なユーザー体験を示し、p95とp99は多くのユーザーに影響するテールレイテンシを示します。
スループット — 目標パフォーマンスレベルでシステムが処理できる1秒あたりのリクエスト数。
エラーレート — 各負荷レベルでリクエストが失敗する割合は？どの負荷でエラーレートが上昇し始めるか？
リソース使用率 — CPU、メモリ、データベース接続数、スレッドプールの使用状況。ボトルネックの特定に役立ちます。
回復時間 — ストレステスト後、システムが通常のパフォーマンスに戻るまでにかかる時間。
アプリケーションのパフォーマンス対応テストを設定する →