Article 04
負荷試験（ロードテスト）とは？アクセス集中でWEBサイトが落ちる原因と対策
アクセス集中によるエラーと機会損失を防ぐための処方箋
負荷試験（ロードテスト）とは？
負荷試験（ロードテスト）とは、専用ツールを用いて「大量のアクセス」を意図的に発生させ、WEBサイトがどれくらいのアクセスまでなら耐えられるか、WEBサイトが重くなる原因を探すテスト工程です。
詳しく言うと？（仕組みと具体例）
サーバーの処理能力とアクセス集中の関係は、学校やオフィスでの「避難訓練」に似ています。負荷試験は、いわば災害発生時を想定した「全員が一斉に動いた場合のシミュレーション」です。
- 避難訓練の人の動きを考えてみましょう：
避難時、一人ひとりの細かい動きは異なりますが、「席を立ち、廊下に出て、階段を下り、非常口から外へ出る」という大きな動線には規則性があります。 - 人が詰まる箇所が見つかります：
人の動きを見てみると、「3階の踊り場が狭くて人が詰まる」「1階のメイン扉の開くスピードが遅い」といった人が詰まりやすいポイントがわかります。
どれくらいの人が一斉に避難が可能か、詰まりやすいポイントがどこかを明らかにするのが負荷試験の役割と同じです。
🏢 【当社の見解】私たちが考える、負荷試験の重要性
負荷試験・ボトルネック分析・チューニングについて
平時のトラフィックであれば問題なくても、突発的なアクセスが殺到すると、サーバーの処理が追いつかずにエラーを返してしまいます。この「アクセスしたくても繋がらない」という機会損失を防ぐためのインフラ対策が、負荷試験です。
負荷対策として「サーバーの台数を増やせば大丈夫だろう（スケールアウト）」と考えるケースがあります。もちろん、スケールアウトで解決する場合もありますが、もしスケールアウトで解決しないボトルネックが存在していた場合、機会損失につながってしまいます。
だからこそ、私たちはApache JMeter等のツールを用いた負荷試験・ボトルネック分析・チューニングを重要だと考えているのです。
クラウド（Auto Scaling）の落とし穴
AWSのAuto Scalingは優秀ですが「検知してからサーバーが立ち上がるまでに数分かかる」という弱点があります。数秒でアクセスが急増する垂直スパイクには間に合いません。そのため、事前に負荷試験を行ってシステムの限界値を把握し、手動でサーバーを広げておく「事前プロビジョニング」と組み合わせることが現実解となります。
💡 【もっと詳しく知りたい方へ】負荷試験の専門的なアプローチ
ツール紹介
- Apache JMeter：
複雑なシナリオもGUIで直感的に作成できる、負荷試験ツールのデファクトスタンダード。
※参考：公式リンク - k6：
JavaScriptでテストシナリオをプログラマブルに記述できるモダンなツール。CI/CDへの組み込みが容易です。
※参考：公式リンク - Locust：
Pythonでシナリオを記述する分散負荷テスト環境。大量の仮想ユーザーを高い柔軟性でシミュレート可能です。
※参考：公式リンク
よくあるボトルネック
- N+1問題：
プログラムの設計不備により、ループ処理の中で無駄に大量のデータベースへの問い合わせ（クエリ）が発生してしまう問題。 - データ量依存のスロークエリ：
システム運用に伴いデータが増加した際に、インデックス設計の妥当性が欠けているため検索処理に膨大な時間がかかってしまう状態。 - Webサーバー / DBのプロセス・コネクション設定：
Apache/Nginxのワーカー数上限や、データベースへの同時接続数（max_connections）などのミドルウェア設定上限到達による待機状態。 - 外部API呼び出しの遅延・タイムアウト：
決済ゲートウェイなど外部システムのレスポンス低下に引っ張られ、自社サーバーの処理プロセスが長時間占有されてしまい、システム全体が共倒れになるケース。 - CDNのキャッシュ設計漏れ：
本来CDN（エッジ）で捌けるはずの静的コンテンツやAPIレスポンスが、キャッシュ設定の不備により大元のサーバーまで貫通してしまい、想定外の負荷を生むケース。
関連する実績・事例
疑問は解決しましたか？