負荷テスト

負荷テストとは

負荷テスト（Load Testing） は、システムに擬似的なトラフィックをかけて、想定する利用量に耐えられるかを検証する 性能テストです。本番でユーザーが殺到してから「捌けませんでした」となるのを避けるため、事前に・安全な環境で 限界や弱点を確かめます。

機能テストが「正しく動くか」を見るのに対し、性能テストは「どれだけ・どれだけ速く・どこまで 動くか」を見ます。セールやキャンペーン、メディア露出でアクセスが増える前に、容量が足りるか・どこが先に詰まるかを把握するのが狙いです。

性能テストの種類

「負荷テスト」は広義には性能テスト全般を指し、目的別にいくつかの型があります。かける負荷のパターンが違う のがポイントです。

種類	かける負荷	何を知りたいか
ロードテスト（狭義）	想定される通常〜ピークの負荷	平常時に要件（SLO）を満たせるか
ストレステスト	限界を超えるまで増やし続ける	どこで壊れるか・限界はどこか
スパイクテスト	短時間に急増させる	急なアクセス増に耐え、回復できるか
ソーク（耐久）テスト	中程度の負荷を長時間かけ続ける	時間経過で劣化しないか（メモリリーク等）

• ロードテスト：想定トラフィックを与え、レイテンシやエラー率が許容範囲に収まるかを確認する基本形。
• ストレステスト：あえて限界突破まで負荷を上げ、破綻点（どこで・どう壊れるか） と、その際の挙動（綺麗に劣化するか、巻き添えで全滅するか）を見る。
• スパイクテスト：販売開始やテレビ放映のような 瞬間的な急増 を模す。急増に耐えるか、そして 負荷が引いた後に正常へ戻れるか を確認する。
• ソークテスト：数時間〜数日、負荷をかけ続け、じわじわ悪化する問題（メモリリーク、接続枯渇、ディスク逼迫）を炙り出す。短時間テストでは見えない不具合が出る。

見るべき指標

負荷テストの価値は、測る指標を正しく選ぶ ことで決まります。代表的なものは次の通りです。

• スループット：単位時間あたりに処理できた量（例：requests/sec、RPS）。
• レイテンシ（応答時間）：1リクエストの応答にかかる時間。平均だけでなく p95 / p99（パーセンタイル） を見るのが必須。
• エラー率：失敗した応答の割合。負荷を上げたときに急増する点が限界の目安。
• リソース使用率：CPU・メモリ・ディスク I/O・ネットワーク・コネクション数。何が先に枯渇するか がボトルネックのヒント。

ボトルネックの見つけ方

負荷テストの最終目的は、合否判定そのものより 「どこが先に詰まるか（ボトルネック）」の特定 にあります。負荷を段階的に上げると、たいていどこか1か所が先に限界を迎えます。

• レイテンシが急に跳ね上がった、エラー率が立ち上がった 負荷量 を押さえる。
• そのときの リソース指標 を突き合わせる（DB の CPU が張り付いた、コネクションプールが尽きた等）。
• 観測には オブザーバビリティ の仕組み（メトリクス・分散トレース）が効く。どのサービス・どのクエリが遅いかを切り分けられる。

ボトルネックを1つ潰すと、次のボトルネックが現れます。負荷テストは 一度きりではなく、改善と再計測を繰り返す 営みです。

実施上の注意

• 本番に近い環境で：構成やデータ量が本番とかけ離れていると、結果は当てになりません。可能な限り本番相当で行います。
• CI/CD に組み込む：リリースのたびに性能が劣化していないかを自動で検査する（/devops/ci-cd/）と、性能リグレッション を早期に捕まえられます。
• 負荷生成側がボトルネックにならないように：テストを打つ側のマシンが先に限界だと、対象システムの限界を測れません。

まとめ

• 負荷テストは 擬似トラフィックで想定負荷への耐性を事前検証 する性能テスト。
• 目的別に ロード／ストレス／スパイク／ソーク を使い分ける（負荷のかけ方が違う）。
• 指標は スループット・レイテンシ（p95/p99）・エラー率・リソース使用率。平均だけで判断しない。
• 真の狙いは ボトルネックの特定と改善の反復。本番相当の環境で、CI に組み込むと効果的。