ウェブサイトが高トラフィックになると、適切にテストされていなければ速度が低下したり、エラーを返したり、クラッシュすることもあります。これは、ウェブサイトが一度に多くのユーザーをさばけないときに起こることです。
これを避けるためには、基本的な機能が動作するか確認するだけでなく、ウェブサイトが負荷に対してどう動作するかをテストする必要があります。これをロードテストまたはストレステストと呼びます。橋をテストすることに例えると、ただ一度歩くだけでなく、重い交通量や極端な条件に耐えられるかを確かめるのと同じです。ロードテストはウェブサイトが多くのユーザーをスムーズにさばけるか、クラッシュしないかを見るのに役立ちます。
ロードテストの計画：正しい質問をする
ロードテストを開始する前に、いくつかの重要な質問に答える必要があります：
- どれくらいのユーザーをシミュレートすべきですか？最混雑時に予想されるユーザー数を見積もる必要があります。
- 実際のユーザーは何をしますか？実際のユーザーの操作を模倣したテストシナリオを作成する必要があります。
- ユーザーの所在地はどこですか？世界の異なる地域からのユーザーをシミュレートし、全ユーザーに対するパフォーマンスを確認すべきです。
- どのくらいのペースで負荷を増やすべきですか？突然大量のユーザーを増やすのではなく、徐々に増やしてウェブサイトの反応を見るべきです。
- テストはどれくらいの時間実施すべきですか？有意義な結果を得るために十分な時間テストを行う必要があります。
ロードテストを綿密に計画することで、ピークトラフィック時にもすべてのユーザーにスムーズで快適な体験を提供できることを保証できます。
2026年アップデート： 現代のアプリケーションは従来のウェブブラウザ以外に、モバイルアプリ、API、サードパーティ統合など多様なソースからトラフィックを生成します。このため、ロードテスト戦略はユーザー行動とAPIトラフィックの混合をシミュレートし、より実運用環境を反映することが多くなっています。
ロードテストに必要な同時ユーザー数
現実に近いユーザー行動を反映するテストを設定する前に、テストでシミュレートすべき同時ユーザー数を特定する必要があります。同時ユーザー数は、特定の時間にウェブサイトまたはウェブアプリケーションを閲覧し、取引を行うユーザー数を定義します。サイトやアプリケーションへのトラフィックは週を通じて上下しますが、適切にテストするためにはピークトラフィック時より少なくとも高い時間帯でテストを設定するべきです。しかし、正しい同時ユーザー数をどのように見つけるのでしょうか？
ウェブ解析ツールを使い、現在のトラフィック統計を調べ、訪問数やウェブサイトでのセッション時間などを確認できます。Google Analyticsや多くの解析ツールは、定期的なタイムスタンプごとのセッション数や平均セッション時間、ユーザーのサイト滞在時間のデータを提供します。以下の式で同時ユーザー数を推定できます：
同時ユーザー数 = 時間あたりセッション数 × 平均セッション時間（分） ÷ 60
ウェブ解析データがない場合は、予想訪問数を使って同時ユーザー数を計算できます：
同時ユーザー数 = 1分あたりの予想訪問数 × 訪問時間（分）
現在のユーザー数設定に関する詳細やヒントについては、弊社ナレッジベースのウェブ解析から同時ユーザー数を計算する方法をご覧ください。
実際のユーザーテストシナリオのシミュレーション
同時ユーザー数が決まったら、ストレステストに取り入れる頻繁で高トラフィックなテストシナリオを探します。すべての状況に多数のスクリプトを使う必要はありません。通常、ほんのわずかなユースケースだけで全取引の実際の負荷を判断できます。
適切な同時ユーザー数が決まったら、テスト対象のアプリケーションに基づき、適切なロードテストのタスクシミュレーション方法を選びます。
ウェブアプリケーション及びウェブページのロードテスト
ウェブアプリケーションやウェブサイトのユーザーシナリオや取引をシミュレートするために、テストシナリオのユーザージャーニーをスクリプト化する必要があります。この用途には、EveryStep Web Recorder を利用できます。これはブラウザの操作を記録してスクリプトを作成し、ロードテストに使用できます。EveryStep Web Recorderは使いやすく、複雑なシナリオもスクリプト化可能です。さらに遅延設定、キーワードやフィールド変数の編集、ネットワークスロットリング設定なども行えます。スクリプト編集についてはナレッジベースをご参照ください。
ウェブページのロードテスト実行には、LoadViewのWeb Pageオプションを使用すると、同時ユーザーによるウェブページのテストプロセスを開始できます。
さらに、LoadViewプラットフォームは、開発チームがAPIやストリーミングメディアのロードテストを行えるようにしています。APIやストリーミングメディアページに関する詳細は製品ページをご覧ください。
地理分散型仮想負荷
ご承知の通り、ネットワーク遅延はウェブサイトに大きな影響を与えるため、ストレステスト中に同時ユーザーを地理的に分散させることが重要です。これにより、実運用環境と同様の挙動をシミュレートし、データセンターから遠いユーザーのレスポンスタイムもチェックできます。例えばリフレッシュ時に2MBのコンテンツをダウンロードし、各バックエンド要求に10msかかるページを考えます。データセンター内での負荷時間は近接性と低遅延のため5秒未満になります。
しかし、アジアなど特定海外地域では200msの遅延があり、このウェブサイトのバックエンド応答時間は5秒以上になり、ネットワーク転送は200ms超になります。レスポンスタイムをデータセンター内だけで測るのは誤りです。ここではLoadViewを利用し、世界中の負荷注入マシンを幅広く使えます。その中から顧客の通常の所在地を代表する地域を選択できます。
スケール間のランプアップ期間
通常、ウェブサイトの同時ユーザーは一日の中でばらつきがあり、ピーク時間帯に最大トラフィックがあります。アプリケーションのスケールアウトとストレステストにも同様のランプアップ戦略を用いるべきです。LoadViewではランプアップ時間、ホールドタイム、必要に応じたランプダウンの速度設定が可能です。
ロードテストの継続時間
テスト継続時間は、レスポンスタイム、スループット、キャッシュ機構があればテスト中のキャッシュの蓄積など、リアルな結果をアプリケーションに生成させるため非常に重要です。テスト継続時間を決めるにはテストシナリオと要件を考慮する必要があります。以下のケースを参考にすると良いでしょう：
- 各リクエストやテストステップは最低10回は実行する必要があります。長いシナリオは短いものより長めの継続時間に設定すべきです。
- アプリケーションの安定性やパフォーマンス特性の長期検証を行う場合は、より長いテスト時間を設定すべきです。
- 上記の通り、ウォームアップのために数分のバッファ時間を必ず追加してください。
まとめ：ウェブサイトやウェブアプリケーションのトラフィックを正しくシミュレートする方法
ご覧の通り、ロードテストの設定と実行には多くの要因を考慮する必要があります。ウェブアプリとサイトがユーザーに完璧に動作することはビジネス成功の鍵です。LoadViewプラットフォームは、ステップバイステップでテストの設定を迅速かつ簡単に案内します。複数のロケーションからの実際のシナリオ設定やパフォーマンス評価も可能です。
LoadViewの無料トライアルに登録して無料ロードテストを始めるか、LoadViewのデモにお申込みください。パフォーマンスエンジニアがソリューション全体を案内し、プラットフォームやロードテストのプロセスに関するご質問にお答えします。