負荷テストに関しては常に「パフォーマンスの観点から、クライアントは自分たちのアプリケーションおよびシステムで何をしたいのか？」という百万ドルの質問があります。この質問に簡単に答えが得られることはまずなく、多くの場合私たちはいくつかの仮定をしてパフォーマンステストを実施しますが、それが重要な部分のテスト漏れにつながり、結果的にクライアントを不満足にさせてしまうことがあります。不満足なクライアントは組織のビジネス損失であり、パフォーマンスエンジニアとしてのキャリアの下降も意味します。しかし、ご安心ください。本記事では、そのような質問に対応するためのチェックリストの作成について解説します。
このチェックリストは、あなたのパフォーマンステストのライフサイクルに適応可能なステップバイステップのプロセスのようなものです。今回のシナリオでは、初めはクライアントが望む正確なパフォーマンス成果を知らない場合もあるため、常にクライアントのせいにはできません。しかし、アプリケーションが異なる条件下でどのように動作するかについては明確な知識を持っています。優れたパフォーマンステスターは、よく定義されたアンケートでこの曖昧さを管理できます。これがチェックリストの最初の項目である、要件収集のアンケートです。
要件収集アンケート
以下はプロジェクトで活用できるアンケートフォーマットです。できるだけ多くの質問に対する回答を取得する必要があります。これらの質問を議論するために通話を行うのが望ましいです。アプリケーションアーキテクトや開発者がクライアントと一緒に通話に参加していることを確認してください。追加の担当者がいることで、より多くの洞察が得られ、これまで考慮していなかった質問を明らかにできることがあります。以下の質問は、より効率的かつ効果的な負荷テストを作成するためのロードマップを提供します。
| 番号 | トピック | 質問 |
| 1 | アプリケーション | テスト対象となるアプリケーションの種類（例：ウェブアプリケーション、モバイルアプリケーションなど）。 |
| 2 | アプリケーションのアーキテクチャと技術/プラットフォーム。 | |
| 3 | 使用されているロードバランシング技術。 | |
| 4 | クライアントとサーバー間の通信プロトコル（例：HTTP/S、FTP）。 | |
| 5 | パフォーマンステストの目的。監視するパフォーマンス指標（例：各操作の応答時間、同時ユーザー数など）。 | |
| 6 | パフォーマンステストで考慮すべき重要なシナリオ。 | |
| 7 | バックグラウンドで実行されるスケジュールされたジョブやプロセスの詳細があれば。 | |
| 8 | セッション管理に使用されている技術とサポートされる並行セッション数。 | |
| 9 | 顧客SLA/要件 | 予想される同時ユーザー数および総ユーザーベース。対象シナリオにおけるユーザー分布。 |
| 10 | パフォーマンステスト対象全取引のSLA（期待スループット、応答時間など）。 | |
| 11 | 実施するパフォーマンステストの種類（ロードテスト、耐久テストなど）。 | |
| 12 | システム/環境 | テスト環境の詳細（ウェブ/アプリ/DBなど、ノード数含む）。パフォーマンステスト実施には本番に近い環境が推奨される。 |
| 13 | 本番環境とパフォーマンステスト環境の比較。 | |
| 14 | パフォーマンステスト実行中にアプリケーションを他のアプリケーションとの相互作用を避けて隔離するかどうか。 | |
| 15 | 組み込みのログ機能やモニタリング機構の詳細。 | |
| 16 | その他 | アプリケーションのパフォーマンスベースライン結果。 |
| 17 | 現在のパフォーマンス問題があれば。 | |
これらの質問への回答は、高品質なテスト戦略/テスト計画の作成に役立ちます。クライアントがすべての質問に答えられない場合でも心配はいりません。常にテスト対象のアプリケーションを調査し、答えを見つけることが可能です。例えば、APM/ログツールが導入されている場合、本番システムから同時ユーザー数、スループット、応答時間を取得できます。必要なものを要求せずに手に入ると決めつけないでください。
適切なパフォーマンステストツールの選択
パフォーマンステスターは、最適なパフォーマンステストツールを慎重に選択する必要があります。ツールを確定し提案する前に検討すべき多くの要素があります。クライアントの予算がパフォーマンステストツール選びで常に重要な要素であることを忘れないでください。パフォーマンステストツールの選択において重要です。
コスト効率が良く、使いやすく、完全なパフォーマンスソリューションを提供できるパフォーマンステストツールをお探しなら、ぜひLoadViewを試してください。従来の負荷テストツールと比較して、LoadViewは高額な投資や時間のかかるセットアップ、スクリプトフレームワークの事前知識が不要です。さらに、このプラットフォームは20を超えるグローバルロケーションからロードインジェクターを起動でき、各テストで複数の場所からのパフォーマンスを測定・評価できます。
すべての種類のパフォーマンステストは時間と労力がかかります。負荷テストを実施することで組織は潜在的な不名誉を回避できますが、JMeterのような無料オープンソースツールでのテストではその投資価値が正当化されない場合があります。ユーザーの視点からウェブサイトやアプリケーションのパフォーマンスを真に理解するためには、プロトコルベースのテストだけでは不十分です。クライアントサイドの操作やステップのパフォーマンスも測定する必要があります。こちらはLoadViewと他のパフォーマンス/負荷テストソリューションの比較と、なぜLoadViewがパフォーマンステストに最適なのかの理由です。
サイトやアプリケーションの読み込みが遅いと、顧客はすぐにイライラし、期待に応えなければ離れて他の代替品を探します。サイトやアプリケーションがどれだけ処理可能かを知ることは様々な理由から非常に重要です。LoadViewプラットフォームが支援できる主なシナリオはいくつかあります：
- 適応性とスケーラビリティ。複数ユーザーがアクセスした際にサイトやアプリケーションが遅くなる理由を判断。
- インフラストラクチャ。必要ならハードウェアのアップグレードの理解。追加ハードウェアの導入および保守コストは資源の無駄になり得る。
- パフォーマンス要件。サイトやアプリは少数のユーザーには対応可能だが、実際の状況ではどうか。
- サードパーティサービス。通常およびピーク時の負荷条件で外部サービスの挙動を把握。
パフォーマンステスト計画/戦略
クライアントの要件収集と適切なパフォーマンステストツール選択が済んだら、テスト計画/戦略を文書化する必要があります。パフォーマンス活動を開始する前に必ずクライアントからテスト計画の承認を得てください。これは非常に重要で、後の不必要な問題回避に役立ちます。テスト計画に含めるべきポイントは以下の通りです。
- パフォーマンステストの目的。何を達成するのか。
- プロジェクトの範囲。例：スクリプト数、テスト期間など。
- アプリケーションアーキテクチャ。アプリケーションサーバー、DBサーバーの詳細や可能であればアーキテクチャ図。
- 環境の詳細。テスト環境の説明。パフォーマンステストには隔離環境が望ましい。
- インフラセットアップ。パフォーマンステストの初期セットアップ例（クラウド環境、ツールインストールなど）。
- パフォーマンステストのアプローチ。小規模ユーザーでのベースラインテストから始め、段階的にユーザーを増やしてストレス・耐久テストなどを実施する計画。
- 開始および終了基準。機能障害がゼロの状態で始め、終了時も文書化すること。
- 欠陥管理。クライアントが使うツールや方法に従いパフォーマンス関連の欠陥を記録する。
- 役割と責任。パフォーマンステスト時の様々な活動に関与するステークホルダーの詳細。
- 仮定とリスク。パフォーマンステストにリスクとなり得る要件を記録。
- テストデータ戦略。テストデータの戦略と取得方法の詳細。
- テスト計画のタイムラインと主要なアウトプット。スクリプト作成、テスト実行、分析、クライアントレビューのスケジュール。
実際のパフォーマンステストは複数の手法の組み合わせに依存します。目標達成のためには、それぞれのパフォーマンステストの要件に合わせて異なる戦略を策定する必要があります。ユーザー負荷、同時ユーザー数、ワークロードモデルなどの様々な指標を考慮して負荷を計画すべきです。ワークロードモデリングに携わったことがあれば、Littleの法則を聞いたことがあるでしょう。テスト計画前にこれを学び、実践して望む結果を得られるようにしてください。
リアルタイムパフォーマンススクリプト/シナリオ
クライアントとパフォーマンス計画や戦略の合意ができたら、選択したパフォーマンステストツールを使ってスクリプト作成の準備に入ります。高品質なスクリプトの作成は成功するパフォーマンステストの鍵であり、さまざまな重要点に注意する必要があります。
まず、スクリプト作成時には必ずドキュメント化されたテストケース手順に従い、正確さを保ってください。単一ユーザーでのリプレイから始め、相関関係やパラメータ化の必要性を解決します。パラメータ化にはヘッダー、クッキー、ボディパラメータなどが含まれることがあります。単一ユーザーで問題なく動作するようになったら、複数反復や異なるユーザーデータでテストしてください。新しいデータにより相関やパラメータ化の調整が必要になる場合があります。
場合によっては、特定のユースケースを実現するためにカスタムコードブロックを書く必要があるかもしれません。例えば、あるユーザーの応答からデータを抽出し別のリクエストで操作するなどです。また、ワークロードモデルに基づいた待機時間、間隔調整、エラーハンドリングの機構を含めることも忘れないでください。スクリプトの機能検証にはテキストや画像のチェックも重要で、要求の結果が得られることを確認します。
スクリプト作成以外にも、キャッシュ、クッキー、ネットワーク状況のシミュレーションなど現実的なシナリオを反映させる要素を考慮してください。パフォーマンスエンジニアとして、リアルな仮想ユーザーの行動を創出することが重要です。このプロセスは、要件フェーズで正確な情報を収集することから始まります。
以下のような重要な質問に答える必要があります。
- 営業時間中にアプリケーションとやりとりするユーザーの総数は？
- ユーザーは通常どのような操作をどのくらいの頻度で行うか？
- ピーク時にどのくらいのユーザーがアクセスするか？
これらの回答は要件収集アンケートで得るか、APMソリューションやGoogle Analyticsなどのツールから収集した統計データの分析で把握できます。取引分析は特に、重要な業務取引を特定し、現実的な使用状況を反映したパフォーマンステストシナリオ設計に役立ちます。これらのステップに取り組むことで、効果的なパフォーマンステストの実行と信頼できる結果の提供が可能になります。
ワークロードモデリング
ワークロードモデルは様々な方法で計画できます。パフォーマンスエンジニアはワークロードモデルを選択する前に「Littleの法則」コンセプトを学び実践するべきです。以下は既存のワークロードモデルの一部です。パフォーマンスエンジニアはその時点での要件に基づいてワークロードモデルを選ぶべきです。
ワークロードモデル1。単純なモデルで、テスト進行に伴いユーザー数が継続的に増加します。例：テスト完了まで毎秒1ユーザーずつ増加。
ワークロードモデル2。このモデルではテスト全体の期間にわたりステップ的にユーザー数が増加します。例：最初の15分は100ユーザー、次の15分は200ユーザーなど。耐久テストに適しています。
ワークロードモデル3。最も一般的なパフォーマンステストモデルです。一定期間ユーザー数を連続的に増加させ（ランプアップ期間）、その後一定時間安定した状態（ステディステート）を保ち、さらにランプダウンしてテストを終了します。例：1.5時間のテスト計画であれば、15分間のランプアップ、15分間のランプダウン、1時間のステディステートを設けます。結果分析はステディステートのみを対象とします。
ワークロードモデル4。このモデルではテスト全体を通じてユーザー数が急激に増減します。この種のテストはモンキーテストやスパイクテストなどと呼ばれることもあります。
パフォーマンステストには明確な目標と要件を設定する必要があります。パフォーマンスパラメータを定義し、それぞれの受け入れ基準を決めてください。テスト要件も望む成果もわからない場合、パフォーマンステストは時間の無駄になります。
データ収集
以下はパフォーマンスワークロードモデリング時に観測すべき非常に重要な指標の一例です。
応答時間：サーバーがクライアントのリクエストに応答するのにかかる時間です。応答時間に影響を与える多くの要素が存在し、負荷テストによってそれらの要素を特定して排除できます。
平均応答時間：負荷テストのステディステート全期間における応答時間の平均値です。
90パーセンタイル応答時間：90パーセンタイルの応答時間とは、全応答時間の90％がその値以下であることを示します。例えば500リクエストがあり、それぞれ異なる応答時間の場合、90パーセンタイルは90％の値がこの値未満であり、10％のみが上回る値です。平均応答時間を歪める大きな応答時間が一部に存在するときに有用です。
1秒あたりのリクエスト数：この値はAPMツールや本番ログから取得します。同時ユーザー数に基づきサーバーへのリクエスト数を計画します。
メモリ使用率：インフラ側の指標で、ボトルネックの発見に役立ちます。可能な限りリアルタイムのワークロードを計画し、サーバーへの連続リクエスト過多を避けていることを確認してください。
CPU使用率：メモリ使用率と同様、パフォーマンステスト実行中に監視すべき指標です。
エラーレート：合格取引と不合格取引の比率を追跡します。エラーレートは合格取引の2％を超えないようにします。エラーレートが同時ユーザー増加に伴い増加する場合、潜在的なボトルネックの可能性があります。
同時ユーザー数：APMツールまたは本番ログから取得します。通常は典型的な業務日の値を基に算出します。
スループット：スループットはサーバーが同時ユーザーを処理できる能力を示します。同時ユーザー数とスループットには直接的な関係があります。ユーザー数の増加に伴いスループットが増加すべきで、減少する場合はボトルネックの可能性があります。
ユーザーロード分布：ユーザーロード分布はワークロード設計時に考慮すべき重要な要素です。仮に異なる5つの機能を担う5つのスクリプトがある場合、実際の本番やAPMツールの調査に基づきできるだけ現実的なユーザーロード分布に分割する必要があります。
これらはワークロードモデル設計時に念頭に置くべき非常に重要な指標です。クライアントのアプリケーションアーキテクチャや要件に応じて他にも指標はあります。
パフォーマンステスト環境のチェックリスト（実行前）
以下のチェックリストの例は、非常に多数のシステムが関わるエンタープライズレベルのエンドツーエンドパフォーマンステストで一般的に用いられます。小規模のスケールのパフォーマンステストでも環境チェックリストを活用することが推奨されます。アクティビティはアプリケーション環境により変動します。クラウド上のアプリケーションとオンプレミスのアプリケーションでは大きな差があります。
まとめ：負荷テスト準備チェックリスト
成功するソフトウェアのパフォーマンステストは偶然に起こるものではありません。アーキテクト、プロダクトオーナー、開発者、パフォーマンステストチームは協力し、ソフトウェア評価の前にパフォーマンステスト要件を解決する必要があります。LoadViewプラットフォームの詳細な背景については、技術概要記事をご覧いただき、パフォーマンステストを最大限に活用する方法をご確認ください。パフォーマンステストは継続的なプロセスであるべきです。ウェブサイトやウェブアプリケーションが成長し始めると、より多くのユーザーベースに対応するための変更が必要になります。どんなアプリケーションやテストにも常に改善の余地があります。
これがパフォーマンステストのベストプラクティスについて良い洞察を提供したことを願っています。LoadViewソリューションの完全なデモをご希望の場合は、デモ申し込みでパフォーマンスエンジニアとステップバイステップでプロセスを案内してもらってください。ロードテストスクリプトとテスト構成の作成から実行、結果分析まで説明します。
また、すぐに負荷テストを始めたい場合はLoadView無料トライアルにサインアップしてください。負荷テストを始めるための無料テストをご提供します。負荷テストをお楽しみください！