「セールが始まった瞬間にECサイトが繋がらなくなった」——このような事態は、多くの場合、事前の負荷テストが不十分だったことに起因します。機能面のテストが「正しく動くか」を確認するのに対し、負荷テストは「想定される負荷に耐えられるか」「限界はどこにあるか」を確認するテストです。

本記事では、負荷テストの基本的な考え方と、代表的なツールであるJMeterとk6を使った実践方法を解説します。

負荷テストは、システムに対して意図的に負荷(リクエスト数、同時接続数など)をかけ、以下を明らかにするために行います。

・想定される最大アクセス数に対して、レスポンスタイムがどう変化するか
・どの程度のアクセス数でエラー率が上昇し始めるか(限界点=ブレークポイント)
・CPU・メモリ・DB接続数など、どのリソースがボトルネックになるか
・負荷が去った後、システムが正常に回復するか

似た用語に「性能テスト」「ストレステスト」「スパイクテスト」などがありますが、本記事ではまとめて「負荷テスト」として扱い、後半でそれぞれのシナリオの違いに触れます。

ツールを触る前に、以下を整理しておくことが重要です。曖昧なまま実行すると、結果を評価する基準がなく、テストの意味が薄れてしまいます。

・対象シナリオ:トップページの閲覧か、商品検索か、購入処理か。ビジネス上重要な操作を選定する
・想定同時ユーザー数:過去のアクセスログやセール時のピーク実績から、現実的な数値を設定する
・合格基準(SLA):例えば「レスポンスタイムのp95が1秒以内」「エラー率1%未満」など、具体的な数値目標を決める
・テスト環境:本番同等の環境で実施するのが理想だが、難しい場合はスペック差を考慮して結果を解釈する

合格基準を決めずに負荷テストを実施すると、「レスポンスタイムが2秒でした」という結果だけが得られ、それが許容範囲なのかどうかの判断ができなくなってしまいます。

JMeterの特徴
Apache JMeterは、GUIベースでテストシナリオを組み立てられる、歴史の長い負荷テストツールです。HTTPだけでなく、JDBC、FTP、メッセージキューなど幅広いプロトコルに対応しており、複雑な業務シナリオの再現に強みがあります。

基本的なテスト計画の構成
JMeterのテスト計画は、主に以下の要素で構成されます。

・Thread Group:仮想ユーザー数、Ramp-up期間(ユーザー数を徐々に増やす時間)、繰り返し回数を設定
・HTTP Request:実際にリクエストを送るエンドポイントとパラメータ
・Listener:結果を集計・可視化する要素(グラフ、テーブルなど)

GUIで作成したテスト計画は .jmx ファイルとして保存され、コマンドラインからも実行できます。CI/CDパイプラインに組み込む場合はこちらの形式が基本になります。

jmeter -n -t checkout-load-test.jmx -l results.jtl -e -o report-output/

・-n:非GUIモードで実行(サーバー上での実行に必須)
・-t:テスト計画ファイルを指定
・-l:結果ログの出力先
・-e -o:テスト終了後、HTML形式のレポートを自動生成

Thread Groupの設定例
例えば「500ユーザーが60秒かけて徐々にアクセスし始め、5分間継続してアクセスする」というシナリオは、以下のように設定します。

・Number of Threads(users):500
・Ramp-up period:60秒
・Duration:300秒

Ramp-upを0秒(全ユーザーが同時アクセス)に設定すると、現実のアクセスパターンとは異なる極端な負荷になるため、通常はある程度の時間をかけて段階的に負荷を上げる設定が現実的です。

k6の特徴
k6は、JavaScriptでテストシナリオを記述する、比較的新しい負荷テストツールです。CLIベースで動作が軽量、CI/CDへの組み込みが容易という点で、近年採用が広がっています。GUIを介さずコードでシナリオを管理できるため、Gitでのバージョン管理とも相性が良好です。

基本的なスクリプト例

thresholds に合格基準を直接コードとして記述できる点がk6の大きな特徴です。基準を満たさない場合、k6の実行自体が失敗扱い(終了コード非ゼロ)になるため、CI/CDパイプラインに組み込んで自動的にパフォーマンス劣化を検知する仕組みが作りやすくなります。

実行方法

k6 run checkout-load-test.js

クラウド上での大規模負荷生成や結果の可視化ダッシュボードが必要な場合は、Grafana k6 Cloudとの連携も選択肢になりますが、まずはローカルまたはCI環境での実行から始めるのが取り組みやすい方法です。

複雑な業務プロトコル(JDBC直接テストなど)を含む場合はJMeter、Web APIが中心でCI/CDに組み込みたい場合はk6、という使い分けが一般的な指針になります。両方を併用し、「複雑なシナリオはJMeter、日常的な回帰チェックはk6」と役割分担するチームもあります。

負荷テストと一口に言っても、目的によっていくつかのパターンに分かれます。

・負荷テスト(Load Test):想定される通常〜ピーク時のアクセス数を再現し、性能要件を満たすか確認する
・ストレステスト(Stress Test):想定を超える負荷をかけ、限界点(ブレークポイント)とその際の挙動(エラーの出方、復旧の可否)を確認する
・スパイクテスト(Spike Test):短時間で急激にアクセスが増加するシナリオ(セール開始直後など)を再現する
・ソークテスト(Soak Test):長時間(数時間〜数日)にわたり一定の負荷をかけ続け、メモリリークなど時間経過で顕在化する問題を検出する

セール前の準備としては、通常の負荷テストに加えてスパイクテストを実施し、「アクセス集中の瞬間」に耐えられるかを確認しておくことが特に重要です。

負荷テスト実行中は、アプリケーション側の指標だけでなく、インフラ側のメトリクスも合わせて監視します。

・アプリケーション側:レスポンスタイム(平均・p95・p99)、エラー率、スループット(RPS)
・インフラ側:CPU使用率、メモリ使用率、DB接続数、ディスクI/O

レスポンスタイムが劣化し始めたタイミングと、CPU使用率やDB接続数が上昇したタイミングを突き合わせることで、「アプリケーションサーバーのCPUがボトルネックなのか」「DBの接続プールが枯渇しているのか」といった原因の切り分けが可能になります。前回までに扱ったCloudWatchでのモニタリングは、こうした負荷テスト実施時の観測基盤としても活用できます。

負荷テストは、システムの限界を知るためだけのものではありません。実際の利用状況を想定した負荷を与え、その結果をもとにボトルネックを改善していくことで、安定したサービス提供につなげるための重要な取り組みです。

また、JMeterやk6といったツールを活用することで、負荷テストを一度きりのイベントではなく、CI/CDパイプラインに組み込んだ継続的な品質管理の一部として運用できるようになります。機能テストと同様に性能面も継続的に確認することで、リリースごとの性能劣化を早期に検知し、安心して機能改善やシステム拡張を進められる環境を構築できます。

クラウド環境では、負荷テストの結果をもとにスケーリング設定やリソース構成を最適化できるため、必要以上のリソースを確保することなく、コストと性能のバランスを取れる点も大きなメリットです。感覚や経験だけに頼るのではなく、データに基づいて性能を評価・改善することが、安定したシステム運用につながります。