はじめに
本調査の目的
本調査は、Webサーバーに対する負荷テストの基本を分かりやすくまとめたものです。テストの目的や代表的な種類、実施手順、さらによく使われるツールの使い方まで順を追って解説します。実際の現場で役立つ具体例を交えて説明します。
なぜ負荷テストが必要か
負荷テストはシステムの安定性や応答性、容量を確かめるために行います。例えば、オンラインショップのセール時にアクセスが急増してページ表示が遅くなったり、ログイン処理が失敗したりする問題を事前に検出できます。結果をもとにサーバー構成やアプリの改善点を決めます。
想定する読者
開発者、運用担当者、品質保証担当者、導入検討中の管理者など、幅広い層を想定します。専門知識が浅くても理解できるよう、専門用語は最小限にし、具体例で補足します。
本書の使い方
各章は段階的に学べる構成です。まず本章で全体像をつかみ、続く章で基礎知識、テスト種類、実施フロー、ツール選定へと進んでください。実施時のチェックリストや注意点も後の章で詳述します。
Webサーバー負荷テストの基礎知識
概要
負荷テストは、サーバーに意図的にアクセスを増やしてシステムの挙動を確認する作業です。目的はボトルネックの発見と障害予防です。たとえば、セール時に一時的にアクセスが急増したときに問題が起きないかを確かめます。
負荷テストの目的
- 最大同時接続数や処理能力を把握します。
- レスポンスタイムが目標内か確認します。
- 障害発生時の影響範囲を予測します。
確認する主な項目
- レスポンスタイム（応答速度）: ユーザー体感に直結します。
- エラー率: エラーが増えるとサービス停止の兆候です。
- CPU・メモリ・ディスク・ネットワーク: 資源のどこが限界かを見ます。
負荷パターンの決め方（具体例）
1) 平常時のピークを基準に、1.5倍、2倍などを試します。
2) 短時間で急増するケース（スパイク）をシミュレーションします。
3) 長時間の高負荷で持続性を確認します。
実施前の準備と注意点
- テスト対象範囲を明確にします（本番環境かステージングか）。
- ログや監視を用意し、影響範囲を記録します。
- 関係者へ事前連絡を行い、誤検知を防ぎます。
結果の見方（簡単な指標）
- 目標レスポンスより遅い割合を確認します。
- エラー増加の閾値を設定します。
- ボトルネック箇所が特定できたら、改善→再検証を繰り返します。
負荷テストの種類と特徴
この章では代表的な負荷テストの種類と、それぞれの目的や注意点を分かりやすく説明します。具体例を交えて、どの場面でどのテストが必要かを示します。
ロードテスト
- 目的: 通常時や想定ピーク時の応答性と処理能力を確認します。
- 実施例: 平日昼の最大同時接続数を想定して一定時間負荷をかけます（例: 1000ユーザーを10分間）。
- 主な指標: 応答時間、スループット、エラー率。
- 注意点: テスト環境を本番に近づけ、データの整合性を保ちます。
ストレステスト
- 目的: システムの限界と障害時の挙動を評価します。
- 実施例: 同時接続数やリクエスト量を段階的に増やし、どこで障害が出るか確認します。
- 主な指標: 障害発生点、回復時間、障害時のログ。
- 注意点: 障害発生が想定されるため、復旧手順や監視を事前準備します。
キャパシティテスト
- 目的: 必要なリソース量（サーバ数、CPU、メモリ）を算出します。
- 実施例: 将来のアクセス増を想定し、どの程度リソースを増やせば対応できるか検証します。
- 主な指標: 最大同時接続数、リソース使用率、SLA達成可否。
- 注意点: コストと性能のバランスを考慮します。
スパイクテスト
- 目的: 短時間で急激に増えるアクセスに対する耐性を確認します。
- 実施例: キャンペーン開始直後の瞬間的なアクセス増を再現します（例: 1分間でアクセスを10倍に）。
- 主な指標: 瞬間的なエラー率、レスポンスの急激な悪化、キュー遅延。
- 注意点: キャッシュやレート制限の挙動を評価します。
ロングラン（ソーク）テスト
- 目的: 長時間稼働時の安定性やメモリリークを検出します。
- 実施例: 24時間や72時間など、長時間にわたり通常負荷を継続します。
- 主な指標: メモリ使用量の増加、ディスクI/O、スループットの低下。
- 注意点: ログ容量や監視の準備を忘れずに行います。
各テストは目的が異なるため、複数を組み合わせて実施するとより確実にシステムの弱点を見つけられます。
詳細なテスト種類と実施内容
オンライン単性能試験
目的: 通常運用時の応答性を確認します。\
実施方法: 実ユーザーに近いリクエストを再現し、レスポンス時間と成功率を測定します。具体例: ログイン→一覧表示→詳細表示の順を100ユーザーで実行。\
注意点: テストシナリオは実運用の割合に合わせます。測定項目: 平均/95パーセンタイル応答時間、エラー率、スループット。\
ピーク性能試験
目的: 短時間の高負荷に対する耐性を確認します。\
実施方法: 想定される最大同時接続数を短時間で与え、ボトルネックを確認します。具体例: セール開始時の瞬間アクセスを再現。\
注意点: キャッシュやCDNの挙動も確認します。測定項目: 最大同時接続数時のレスポンス、タイムアウト率。\
限界性能試験
目的: システムが耐えられる限界を特定します。\
実施方法: 徐々に負荷を増やし、性能が劣化し始めるポイントを探します。具体例: ユーザー数を段階的に増加。\
注意点: 障害発生時のログ収集を準備します。測定項目: 限界スループット、リソース飽和点。\
長時間負荷試験
目的: 長時間稼働での性能劣化やメモリリークを検出します。\
実施方法: 数時間から数日単位で一定負荷を継続します。具体例: 平常負荷で24時間稼働。\
注意点: ログローテーションやバックアップにも配慮。測定項目: 時間経過による応答変化、メモリ/コネクションの増減。\
バッチ単性能試験
目的: 夜間バッチ処理など単独ジョブの性能を確認します。\
実施方法: バッチを単独で実行し、処理時間やI/O負荷を測ります。具体例: 大量データインポートの所要時間測定。\
注意点: リソース確保と影響範囲の把握。測定項目: 処理時間、ディスク/DB負荷。\
バッチ複合試験
目的: バッチとオンライン処理が同時に動く際の影響を評価します。\
実施方法: バッチ実行中に一定のオンライン負荷を与えます。具体例: 深夜バッチ中のユーザーアクセスを模擬。\
注意点: 優先順位やレート制限の検討が有効です。測定項目: オンライン応答時間の変化、バッチ完了時間。
測定と報告の共通ポイント
- 主要指標はレスポンス時間、スループット、リソース使用率、エラー率です。\
- テスト実行前に監視項目とログ取りの手順を明確にします。\
- 実施後は再現手順と改善案をセットで報告します。
負荷テストの実施フロー
1. 目的・目標の決定
まず何を確かめたいかを明確にします。例：同時接続1,000人でレスポンスタイムが3秒以内か、ピーク時のスループットが毎秒500リクエストを維持できるか、などです。合格基準（パス／フェイル）を数値で決めます。
2. テスト環境の準備
本番に近い環境を用意します。サーバー構成、ネットワーク、データベースのサイズやテストデータを揃え、監視ツールを設定します。監視項目はCPU、メモリ、ディスク、ネットワーク、DBロック、エラーログなどです。実行前に時間同期や外部サービスの動作も確認します。
3. シナリオ設定と実行
代表的なユーザーの操作フローをシナリオ化します（ログイン→検索→詳細→購入など）。リクエストの間隔（think time）、段階的な負荷増加（ramp-up）、同時ユーザー数を設定します。スクリプトは検証ポイント（応答確認、エラー検出）を含めます。
4. テスト実行と分析
まず小さな負荷で確認し、段階的に増やします。実行中は監視データとアプリケーションログを収集します。結果はレスポンスタイム分布、スループット、エラーレート、リソース使用率で評価します。ボトルネックを特定したら対策を行い、再テストして改善を確認します。
簡単なチェックリスト：目的設定、環境整備、シナリオ作成、監視準備、段階的実行、結果分析、再検証。これを順に行うことで信頼できる負荷評価ができます。
負荷テストツールの選択と使用
ツールの代表例
- Apache Benchmark（ab）: 軽量で単純なコマンドラインツール。単一URLの簡易確認に向く。
- JMeter: GUIで設定しやすく、複数シナリオを組める。非技術者にも扱いやすい。
- k6: スクリプトで再現性のあるテストが書け、CIと連携しやすい。
- Gatling / Locust: 大規模や複雑なユーザー挙動を表現するのに適する。
選び方のポイント
- 目的（簡易チェックか本番近似か）
- スケール（同時接続数や分散実行の必要性）
- 使いやすさ（GUIかコードか）
- レポートと解析機能
- CI連携やプロトコル対応（HTTP以外が必要か）
abの簡単な使い方例
ab -n 1000 -c 50 http://example.com/index.html
– -n: 総リクエスト数、-c: 同時クライアント数
このコマンドは合計1000回を、同時50接続で送り負荷をかけます。
実践時の注意点
- 本番環境で実行する場合は必ず許可を得る。誤ってサービスを停止させる恐れがあります。
- ウォームアップ（短時間の事前実行）でキャッシュ効果を安定させる。
- サーバー側のCPU・メモリ・I/Oも同時に監視する。
- 実ユーザーの待ち時間（think time）を取り入れ、現実に近い負荷にする。
結果の見方（基本）
- スループット（requests/sec）: 処理能力の目安
- レイテンシ（平均・中央値・95%）: 体感速度の指標
- エラー率: 正常応答が得られているか
上記を踏まえ、まずは小さなテストから始めツールの特性を確認してください。
