パフォーマンステスト

パフォーマンステストの概要

パフォーマンステストは、定義された同時ユーザー数やリクエスト数をウェブサイト、ウェブアプリケーション、またはAPIにかけ、その負荷を計画された曲線に沿って増加させ、応答時間、スループット、エラー率、システムが追従するために使用したサーバー、データベース、ネットワーク容量などの変化を記録します。出力はターゲットと比較される数値のセットであり、サイトの体感速度の印象ではありません。

ターゲットは、公開サイト、ポータルやSaaSアプリケーションの認証済みの利用経路、API呼び出しのシーケンス、またはファイアウォールの背後にある内部ウェブアプリケーションである場合もあります。

目的はサイト全体を速くすることではありません。最も重要なページ、ワークフロー、およびAPI呼び出しが、期待されるトラフィックレベルで定義された要件を満たすことを確認することです。チェックアウトは1人のユーザーでは正常に動作しても、数百人の顧客が一度に注文をすると遅延やタイムアウトが発生することがあります。

機能テストはページやトランザクションが正しく動作することを確認します。パフォーマンステストはトラフィック増加に伴って速さ、安定性、信頼性が保たれるかを測定します。

何をパフォーマンステストできるか？

パフォーマンステストは一般的に4つのHTTP/Sターゲットをカバーします：ウェブサイト、ウェブアプリケーション、API、および内部ウェブアプリケーション。それぞれ異なるスクリプトと測定が必要です。

パフォーマンステストが重要な理由

パフォーマンス試験の価値は、ユーザーが問題を発見する前に具体的な答えを提供することにあります：

• ボトルネックがリリース前に明らかになる。遅いクエリやサイズ不足の接続プールがテストレポートで検出され、サポートキュー行きになりません。
• 容量とスケーリング計画の検証が行われる。オートスケーリングルール、CDNキャッシュ設定、インスタンスサイズはトラフィックにより実証されるまで仮定です。
• 収益を生む経路が保護される。ログイン、検索、チェックアウト、ファイルアップロード、その背後のAPI呼び出しは最初にテストすべき経路です。
• ピーク時のイベントで遅延、エラー、障害が減る。リリース、キャンペーン、登録期間、季節セールは予測可能なトラフィックパターンがあり事前にテスト可能です。
• リグレッションを検知する。コード、API、データベース、インフラ、外部サービスの変更はパフォーマンスを微妙に変化させ、リリースを重ねるごとに累積します。
• リリース判断やサービスレベル目標に証拠を提供。p95の数値は「サイトが遅いと感じる」という意見よりも行動しやすい指標です。

パフォーマンステストの種類

それぞれの種類は異なる形状のトラフィックを使用して異なる疑問に答えます。多くのプログラムは複数を組み合わせて実施します。

耐久テストとソークテストは同じテストの別名であり、種類は2つではありません。ロードテストとストレステストの境界はチームが最も曖昧にする部分であり、専用ページがあります：ロードテスト vs. ストレステスト。

パフォーマンステストはカテゴリ名であり、その下の各タイプはトラフィックの量、速度、継続時間を変えてテストします。

パフォーマンステストとロードテストの違い

パフォーマンステストは様々な条件下での速度、安定性、スケーラビリティ、リソース使用率を評価する広い範囲の行為です。ロードテストはその一種で、予想される負荷とピーク負荷に焦点を当てています。

用語はしばしば同義に使われますが、ロードテストは多くのチームが最初に実施するパフォーマンステストであるためです。破損点、長期劣化、スケーリング問題の発見には他のテストも必要です。

ストレステストも含めた比較はこちらをご覧ください：パフォーマンステスト vs ストレステスト vs ロードテスト。

パフォーマンステストの実施方法

以下のステップはランディングページ、チェックアウトフロー、認証を伴うAPIシーケンスに適用されます。

1. 目標と合格基準を定義する

テストが証明すべきことを数字で明記します。例：1,500同時ユーザーのチェックアウトでp95応答時間が2秒以下、エラー率0.5%未満、注文APIが400トランザクション/秒を維持など。合格/不合格基準のないテストはデータを生成するだけで判断材料になりません。

2. ウェブサイト、アプリケーション、APIのトラフィックモデルを作成

ウェブ解析、アクセスログ、APMデータ、ビジネス予測を抽出。重要ページ/経路、トラフィックの分配、ピーク同時接続数、リクエストレート、ステップ間の思考時間、地理的分布、API呼び出し回数を特定。ページビューは同時ユーザーではありません：日間10万PVでもピークでは数百の同時セッションでモデルは明示すべきです。

3. 代表的なテスト環境を準備

本番のウェブスタック、アプリビルド、DBサイズ、CDN・キャッシュ動作、API依存関係、統合、スケーリングルールを可能な限り一致させます。安全なテストアカウントや決済サンドボックスを利用。環境差異は記録し、誤って本番保証と解釈されぬようにします。

4. テストタイプと実施方法の選択

ステップ1の質問に基づきロード、ストレス、スパイク、耐久、ボリューム、スケーラビリティのいずれかまたは組み合わせを選択。トラフィックの生成方法も選択。HTTP/Sテストはリクエストを直接送り高量リクエストに効率的。リアルブラウザテストはJavaScript実行やマルチステップ利用者行動を測定、実際に人が待つ時間を表す。多くのチームは規模のためにプロトコルテストを、UXのために少人数のリアルブラウザユーザーを組み合わせる。

5. ベースライン確立

変更前に中程度の負荷で制御されたテストを実施。スクリプトの完了、テストデータの有効性、ロードジェネレーターがボトルネックでないことを確認。結果と条件を記録、キャッシュや環境差異で後の比較が不正確になるのを避ける。

6. テスト実施とシステム全体の監視

計画された負荷曲線に沿って需要を増加（連続的に増やす、ステップアップ、または突然の急増）し、同時に不明なユーザー数を一括適用しない。Webサーバー、アプリケーション、インフラ、DB、ネットワーク、外部サービスのデータを結果に添えて取得。サーバーデータがなければ、遅延は分かっても原因は不明のまま。

7. ボトルネックの分析

まず合格基準と比較、その後遅延トランザクションやエラーをCPU、メモリ、DB、キャッシュ、キュー、接続プール、ネットワーク、依存動作と照合。平均応答時間ではなく、劣化するコンポーネントと条件が特定できた時点で終了。

8. 修正、再テスト、自動化

可能な場合は重要な要素を1つずつ変更して同じシナリオを再実行しベースラインと比較。重要トランザクションの短期リグレッションをCI/CDに組み込み、主要リリースやキャンペーンの前に大規模テストをスケジュール。

主要パフォーマンステスト指標

テスト指標はユーザー体験を示し、システム指標は原因解明に役立ちます。原因を特定するにはテストの同一時間帯の両方が必要です。

テスト指標は症状を示し、サーバー、データベース、観測データが原因を特定します。LoadViewのパフォーマンスレポートはサマリーチャートから各セッションのウォーターフォールチャートまでテスト側をカバーしますが、サーバー側は独自の監視やAPMから取得しテストタイムラインに合わせる必要があります。

パフォーマンステスト結果の読み方

多くのウェブシステムで共通するいくつかのパターンがあります。一つで根本原因を証明することはなく、調査の方向性を示すものです。

スループットが横ばいになり応答時間が急増し始めた場合、システムはほぼ容量限界に達しています。

パフォーマンステストを実施すべきタイミング

パフォーマンステストはローンチ前の一度限りの作業ではありません。有効なトリガーは：

• 設計の早期に、アーキテクチャと重要なユーザー経路が決定され変更が安価な時。
• コード、DBスキーマ、インフラ、統合、外部スクリプト、CDN設定の意義深い変更後。
• CI/CD内で、最重要トランザクションへの短期リグレッションチェックとして。
• 主要リリース、キャンペーン、シーズンピーク、移行の前に、そのイベントで想定されるトラフィックレベルで。
• 本番インシデント後、原因となった条件下で修正が保持されていることを確認。
• 定期スケジュールで、単一リリースでは説明できないパフォーマンスのドリフトを検出。

パフォーマンステストとウェブサイト速度テストの違い

ウェブサイト速度テストは通常1ページまたは1セッションを単一時点で他トラフィックなしに読み込み、その所要時間を報告します。フロントエンド最適化やビルドの比較に有用です。

パフォーマンステストはトラフィック量や同時利用者数を変化させ、需要増加時の動作を評価します。両者ともページ・応答時間を報告しますが、パフォーマンスはシステムがどれだけのユーザーをサポートするか、ピーク時のエラー率、スループットの頭打ち、システムの安定持続時間など速度テストでは答えられないことを測定します。また速度テストで良いスコアを取っても500同時セッションで失敗する可能性があります。

パフォーマンステストツールの選び方

クラウドのパフォーマンス＆ロードテストツールは必要なテストに照らして判断すべきで、機能数で選ぶべきではありません：

• ウェブサイト、マルチステップウェブアプリ、使用するAPIプロトコル（認証フロー含む）をサポート。
• 現実的なトラフィックモデル（ブラウザ経路、APIシーケンス、思考時間、データ変動、調整可能な負荷曲線）を構築可能。
• ユーザー所在に合ったロケーションからピーク負荷に十分なスケール。
• プロトコルテスト、リアルブラウザテスト、または両方をサポートし測定ニーズに対応。
• 実用的なパーセンタイル、エラー内訳、トランザクション毎の結果を提供しテスト実施者以外にも共有可能なレポート。
• CI/CDおよびサーバー側の監視・可観測性ツールと連携可能。
• ファイアウォール背後の内部ウェブアプリケーションテストをサポート。
• テスト作成・再実施担当者が運用可能。

パフォーマンステストのベストプラクティス

• 具体的なビジネスまたは技術課題から始めて、それに答えるテストを設計する。
• 分析、ログ、予測からワークロードを構築し推測では作らない。
• ホームページだけでなくログイン、検索、チェックアウトもテスト。
• 現実的なデータ量と可能な限り本番の環境を利用し、違いは文書化。
• テスト対象システムの問題と負荷発生環境の限界を分離。負荷生成器のCPUとネットワークを先にチェック。
• パーセンタイル、エラー、スループット、サーバー資源を同じテスト時間帯で追跡。
• 改善解析時は変数を1つずつ変更。
• ベースラインを保存し毎回同じシナリオで比較。
• 外部依存性と地理的レイテンシを含める。なぜなら本番ユーザーはそれらをスキップしないため。

LoadViewによるパフォーマンステスト

LoadViewはウェブサイト、マルチステップウェブアプリ、APIのトラフィック下のパフォーマンス測定のためのクラウドロードテスティングプラットフォームです。ロードはマネージドクラウドから提供され、負荷生成のインフラ構築や維持は不要です。

リクエスト量に関する質問では、HTTP/Sテストが数千の同時リクエストを送信し応答時間、スループット、エラーをエンドポイント毎に報告。ユーザージャーニーを問う場合はウェブアプリロードテストが実ブラウザでスクリプトを実行しJavaScript実行時間やレンダリング時間を含めて測定します。スクリプトはEveryStep Web Recorderでジャーニーを一度クリックして記録。APIロードテストはRESTおよびSOAPエンドポイントをカバーし、認証やマルチステップ呼び出しシーケンスも対象。

負荷曲線は調整可能：負荷ステップ曲線は一定期間で同時ユーザー数を段階的に変化、ゴールベース曲線は固定時間に必要トランザクション率を生成、動的調整曲線はテスト中にユーザー負荷を変えられます。トラフィックは地理的に分散した40以上のゾーンから配信可能で、地域レイテンシやCDN挙動も結果に反映。

レポートは実行計画、分毎トランザクション数、応答時間、エラータイプ別を示し、遅延トランザクションを特定のリクエストに追跡できる各セッションのウォーターフォールチャート付き。LoadViewはJenkins、Azure DevOps、CircleCIと統合。JenkinsとCircleCIはFailed Sessions Thresholdで失敗セッション率が閾値超過時にビルドを失敗と認識。内部アプリはホワイトリスト化された固定IPやオンプレミスに設置するロードインジェクターを使ったファイアウォール背後のテストが可能。

パフォーマンステストFAQ