Azure Load Testing の主要な概念とコンポーネントについて説明します。 この情報は、アプリケーションのパフォーマンスの問題を特定するためのロード テストをより効果的に設定するのに役立ちます。
ロード テストの一般的な概念
ロード テストの実行に関連する主要な概念について説明します。
仮想ユーザー
仮想ユーザーは、サーバー アプリケーションに対して特定のテスト ケースを実行し、他の仮想ユーザーとは別に実行します。 複数の仮想ユーザーを使用して、サーバー アプリケーションへの同時接続をシミュレートできます。
Apache JMeter は、仮想ユーザーもスレッドと見な します。 JMeter テスト スクリプトでは、 スレッド グループ 要素を使用して、仮想ユーザーのプールを指定できます。 Apache JMeter のドキュメントで スレッド グループ について説明します。
Locust では、仮想ユーザーを "ユーザー" と言います。 テストに必要なユーザーは、Web インターフェイスで、コマンド ライン引数、環境変数、または構成ファイルを使用して指定できます。 詳細については、ラゴのドキュメントの 構成オプション を参照してください。
ロード テストの仮想ユーザーの合計数は、テスト スクリプト内の仮想ユーザーの数と テスト エンジン インスタンスの数によって異なります。
JMeter ベースのロード テストの場合、数式は、仮想ユーザーの合計数 = (JMX ファイル内の仮想ユーザー) * (テスト エンジン インスタンスの数) です。
テスト エンジン インスタンスの数、テスト スクリプト内の仮想ユーザーの数、またはその両方の組み合わせを構成することで、仮想ユーザーのターゲット数を実現できます。
移動子ベースのロード テストの場合、仮想ユーザーの合計数は、任意の構成オプションで指定されたユーザーの数です。 その後、ユーザー の合計数を生成するために必要なテスト エンジン インスタンス の数を構成できます。
ランプアップ時間
ランプアップ時間は、ロード テストの 仮想ユーザー の完全な数に到達するまでの時間です。 仮想ユーザーの数が 20 で、起動時間が 120 秒の場合、20 人の仮想ユーザーすべてに到達するまでに 120 秒かかります。 各仮想ユーザーは、前のユーザーが開始されてから 6 (120/20) 秒後に開始されます。
ラゴの場合は、 生成速度を使用してランプアップを構成できます。 生成率は、1 秒あたりに追加されたユーザーの数です。 たとえば、ユーザー数が 20 で、生成率が 2 の場合、2 人のユーザーが 1 秒ごとに追加され、20 人のユーザーすべてに到達するまでに 10 秒かかります。
応答時間
個々の要求の応答時間( JMeter での経過時間)は、要求を送信する直前から最後の応答を受信した直後までの合計時間です。 応答時間には、応答をレンダリングする時間は含まれません。 JavaScript などのクライアント コードは、ロード テスト中に処理されません。
遅延
個々の要求の待機時間は、要求を送信する直前から最初の応答を受信した直後までの合計時間です。 待機時間には、要求のアセンブルと応答の最初の部分のアセンブルに必要なすべての処理が含まれます。
1 秒あたりの要求数 (RPS)
1 秒あたりの要求数 (RPS) または スループットは、ロード テストで 1 秒あたりに生成されるサーバー アプリケーションへの要求の合計数です。
数式は、RPS = (要求の数) / (合計時間 (秒) です。
時間は、最初のサンプルの先頭から最後のサンプルの最後まで計算されます。 この時間には、テスト スクリプトにタイマーが含まれている場合など、サンプル間の間隔が含 まれます。
RPS を計算するもう 1 つの方法は、アプリケーションの平均 待機時間 と 仮想ユーザーの数に基づいています。 アプリケーションの待機時間を考えると、ロード テストで特定の数の RPS をシミュレートするには、 必要な数の仮想ユーザーを計算できます。
数式は、仮想ユーザー = (RPS) * (秒単位の待機時間) です。
たとえば、アプリケーションの待機時間が 20 ミリ秒 (0.02 秒) の場合、100,000 RPS をシミュレートするには、2,000 人の仮想ユーザー (100,000 * 0.02) でロード テストを構成する必要があります。
Azure Load Testing のコンポーネント
Azure Load Testing の主要な概念とコンポーネントについて説明します。 次の図は、さまざまな概念が相互にどのように関連しているかの概要を示しています。
負荷試験リソース
Azure ロード テスト リソースは、ロード テスト アクティビティの最上位レベルのリソースです。 このリソースは、ロード テスト、テスト結果、および関連する成果物を表示および管理するための一元的な場所を提供します。
ロード テスト リソースを作成するときに、その場所を指定して、 テスト エンジンの場所を決定します。 Azure Load Testing では、リソース内のすべての成果物が自動的に暗号化されます。 Microsoft が管理するキーを選択するか、独自のカスタマー マネージド キーを使用して暗号化を行うことができます。
アプリケーションのロード テストを実行するには、ロード テスト リソースに テスト を追加します。 リソースには、0 個以上のテストを含めることができます。
Azure ロールベースのアクセス制御を使用して、ロード テスト リソースと関連する成果物へのアクセスを許可できます。
Azure Load Testing では、Azure Key Vault にアクセスしてロード テスト シークレット パラメーターまたは証明書を格納したり、Azure Monitor メトリックにアクセスして障害条件を構成したり、マネージド ID ベースの認証フローをシミュレートしたりするなど、さまざまな目的でマネージド ID を使用できます。
テスト
テストでは、アプリケーションのロード テスト構成について説明します。 既存の Azure ロード テスト リソースにテストを追加します。
テストには、アプリケーション エンドポイントを呼び出す手順を説明するテスト 計画が含まれています。 テスト計画は、次の 3 つの方法のいずれかで定義できます。
Azure Load Testing では、HTTP ベースのエンドポイントだけでなく、JMeter と Locust がサポートしているすべての通信プロトコルをサポートしています。 たとえば、テスト スクリプトでデータベースまたはメッセージ キューの読み取りまたは書き込みを行う場合があります。
Azure Load Testingは現在、Apache JMeterとLocustこれ以外のテストフレームワークをサポートしていません。
テストでは、ロード テストを実行するための構成設定も指定します。
- 環境変数、シークレット、証明書などのロード テスト パラメーター。
- 複数のテスト エンジン インスタンスにわたってロード テストをスケールアウトするための構成を読み込みます。
- テスト が合格または失敗するタイミングを判断するための失敗条件。
- テストの実行中に 監視する Azure アプリ コンポーネントとリソース メトリック の一覧を構成するための監視設定。
さらに、CSV 入力データ ファイルとテスト構成ファイルをロード テストにアップロードできます。
テストを開始すると、Azure Load Testing によってテスト スクリプト、関連ファイル、構成がテスト エンジン インスタンスにデプロイされます。 その後、テスト エンジン インスタンスによってテスト スクリプトが開始され、アプリケーションの負荷がシミュレートされます。
テストを開始するたびに、Azure Load Testing によって テスト実行 が作成され、テストにアタッチされます。
テストの実行
テストの実行は、ロード テストの 1 つの実行を表します。 テストを実行すると、テストの実行には、関連付けられているテストの構成設定のコピーが含まれます。
テストの実行が完了したら、Azure portal の Azure Load Testing ダッシュボードでロード テストの結果を表示および分析 できます。
または、 テスト ログをダウンロード し、 テスト結果ファイルをエクスポートすることもできます。
重要
テストを更新しても、既存のテスト実行はテストから新しい設定を自動的に継承しません。 新しい設定は、テストを実行する場合にのみ、新しいテストの実行で使用されます。 既存の テスト実行を再実行すると、テスト実行の元の設定が使用されます。
テストエンジン
テスト エンジンは、テスト スクリプトを実行する Microsoft によって管理されるコンピューティング インフラストラクチャです。 テスト エンジン インスタンスは、テスト スクリプトを並列で実行します。 テスト エンジン インスタンスの数を構成することで、 ロード テストをスケールアウト できます。 仮想ユーザーの数を構成する方法、または 1 秒あたりのターゲット要求数をシミュレートする方法について説明します。
テスト エンジンは、Azure Load Testing リソースと同じ場所でホストされます。 Azure ロード テスト リソースを作成するときに、Azure リージョンを構成できます。
Azure Load Testing では、4 つの vCPU、16 GB メモリ、Azure Linux オペレーティング システムを備えたStandard_D4d_v4 サイズの仮想マシンをテスト エンジンとして使用します。 JMeter ベースのテストの場合、テスト エンジンは JDK 21 と Apache JMeter バージョン 5.6.3 を使用します。 ローカストベースのテストでは、テストエンジンは Python 3.9.19 と Locust バージョン 2.33.2 を使用します。
テスト スクリプトの実行中、Azure Load Testing は、すべてのテスト エンジン インスタンスからテスト フレームワーク ログを収集して集計します。 ロード テスト中にエラーを分析するためのログをダウンロードできます。
アプリ コンポーネント
Azure でホストされるアプリケーションのロード テストを実行すると、さまざまな Azure アプリケーション コンポーネント (サーバー側のメトリック) のリソース メトリックを監視できます。 ロード テストの実行中、およびテストの完了後、 Azure Load Testing ダッシュボードでリソース メトリックを監視および分析できます。
ロード テストを作成または更新するときに、Azure Load Testing が監視するアプリ コンポーネントの一覧を構成できます。 各アプリ コンポーネントの既定のリソース メトリックの一覧を変更できます。
Azure Load Testing で をサポートする Azure リソースの種類について詳しく説明します。
メトリック
ロード テスト中、Azure Load Testing はテストの実行に関するメトリックを収集します。 メトリックには次の 2 種類があります。
クライアント側のメトリック は、テスト エンジンによって報告されます。 これらのメトリックには、仮想ユーザーの数、要求の応答時間、失敗した要求の数、または 1 秒あたりの要求数が含まれます。 これらのクライアント側メトリックに基づいて 、テストの失敗条件を定義 できます。
サーバー側メトリック は、Azure でホストされるアプリケーションで使用でき、Azure アプリケーション コンポーネントに関する情報を提供します。 Azure Load Testing は、Application Insights や Container insights を含む Azure Monitor と統合し、Azure サービスからの詳細を取得します。 サービスの種類によって、さまざまな指標が利用可能です。 次のような例があります。メトリクスはデータベース読み取り回数、HTTP応答のタイプ、またはコンテナのリソース消費量を示します。 これらのサーバー側メトリックに基づいて テストの失敗条件を定義 することもできます。
関連コンテンツ
これで、ロード テストの作成を開始するための Azure Load Testing の主要な概念がわかっています。
- Azure Load Testing のしくみについて説明します。
- Web サイトの URL ベースのロード テストを作成して実行する方法について説明します。
- Azure アプリケーションのパフォーマンスのボトルネックを特定する方法について説明します。
- CI/CD を使用して自動回帰テストを設定する方法について説明します。