新しい Azure Load Testing ユーザー向けの主要な概念

Azure Load Testing の主要な概念とコンポーネントについて説明します。 この情報は、アプリケーションのパフォーマンスの問題を特定するためのロード テストをより効果的に設定するのに役立ちます。

ロード テストの一般的な概念

ロード テストの実行に関連する主要な概念について説明します。

仮想ユーザー

仮想ユーザーは、サーバー アプリケーションに対して特定のテスト ケースを実行します。これは、他の仮想ユーザーとは独立して実行されます。 複数の仮想ユーザーを使用して、サーバー アプリケーションへのコンカレント接続をシミュレートできます。

Apache JMeter では、仮想ユーザーは "スレッド" とも呼ばれます。 JMeter テスト スクリプトでは、"スレッド グループ" 要素を使用して、仮想ユーザーのプールを指定できます。 スレッド グループの詳細については、「Apache JMeter のドキュメント」を参照してください。

ロード テストの仮想ユーザーの合計数は、テスト スクリプト内の仮想ユーザーの数と、テスト エンジン インスタンスの数によって変わってきます。

数式は次のようになります: 仮想ユーザーの合計数 = (JMX ファイル内の仮想ユーザー数) * (テスト エンジン インスタンスの数)。

仮想ユーザーのターゲット数は、テスト エンジン インスタンスの数、テスト スクリプト内の仮想ユーザーの数、またはその両方の組み合わせを構成することで達成できます。

ランプアップ時間

スケールアップ時間は、ロード テストの仮想ユーザーの総数に到達するまでの時間です。 仮想ユーザーの数が 20 で、起動時間が 120 秒の場合、20 人の仮想ユーザーすべてに到達するまでに 120 秒かかります。 各仮想ユーザーは、前のユーザーが開始されてから 6 (120/20) 秒後に開始されます。

応答時間

個々の要求の応答時間( JMeter での経過時間)は、要求を送信する直前から最後の応答を受信した直後までの合計時間です。 応答時間には、応答をレンダリングする時間は含まれません。 JavaScript などのクライアント コードは、ロード テスト中には処理されません。

Latency

個々の要求の待機時間は、要求を送信する直前から最初の応答を受信した直後までの合計時間です。 待機時間には、要求のアセンブルと応答の最初の部分のアセンブルに必要なすべての処理が含まれます。

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 を使用すると、マネージド ID を使用して、ロード テストシークレットのパラメーターまたは証明書を格納するために Azure Key Vault にアクセスできます。 ユーザー割り当てまたはシステム割り当てのマネージド ID のどちらかを使用できます。

テスト

テストでは、アプリケーションのロード テスト構成について説明します。 既存の Azure ロード テスト リソースにテストを追加します。

テストには、アプリケーション エンドポイントを呼び出す手順を説明するテスト 計画が含まれています。 テスト計画は、次の 2 つの方法のいずれかで定義できます。

• JMeter テスト スクリプトをアップロードします。
• テストする URL エンドポイントの一覧を指定します。

Azure Load Testing では、HTTP ベースのエンドポイントだけでなく、JMeter がサポートするすべての通信プロトコルがサポートされています。 たとえば、テスト スクリプトでデータベースまたはメッセージ キューの読み取りまたは書き込みを行う場合があります。

現在、Azure Load Testing では、Apache JMeter 以外のテスト フレームワークはサポートされていません。

テストでは、ロード テストを実行するための構成設定も指定されます。

• 環境変数、シークレット、証明書などのロード テスト パラメーター。
• 複数のテスト エンジン インスタンス間でロード テストをスケールアウトするためのロード構成。
• テストに合格したか失敗したかを判断するための失敗条件。
• テストの実行中に監視する Azure アプリ コンポーネントとリソース メトリックの一覧を構成するための監視設定。

さらに、CSV 入力データ ファイルと JMeter 構成ファイルをテストにアップロードできます。

テストを開始すると、Azure Load Testing によって JMeter テスト スクリプト、関連ファイル、および構成がテスト エンジン インスタンスにデプロイされます。 次に、テスト エンジン インスタンスによって JMeter テスト スクリプトが開始され、アプリケーションの負荷がシミュレートされます。

テストを開始するたびに、Azure Load Testing によってテスト実行が作成され、テストにアタッチされます。

テスト実行

テストの実行は、1 回のロード テストの実行を表します。 テストを実行すると、テストの実行には、関連付けられているテストの構成設定のコピーが含まれます。

テストの実行が完了したら、Azure portal の Azure Load Testing ダッシュボードでロード テストの結果を表示および分析できます。

または、テスト ログをダウンロードし、テスト結果ファイルをエクスポートすることもできます。

重要

テストを更新しても、既存のテスト実行はテストから新しい設定を自動的に継承しません。 新しい設定は、テストの実行時に新しいテストの実行でのみ使用されます。 既存 のテスト実行を再実行すると、テスト実行の元の設定が使用されます。

テスト エンジン

テスト エンジンは、Microsoft によって管理される、Apache JMeter テスト スクリプトを実行するコンピューティング インフラストラクチャです。 テスト エンジン インスタンスでは、JMeter スクリプトが並列で実行されます。 テスト エンジン インスタンスの数を構成することによって、ロード テストをスケール アウトできます。 仮想ユーザーの数を構成する方法や、1 秒あたりのターゲット要求数をシミュレートする方法について、詳細を確認してください。

テスト エンジンは、Azure Load Testing リソースと同じ場所にホストされます。 Azure ロード テスト リソースを作成する際には、Azure リージョンを構成できます。

テスト スクリプトの実行中には、Azure Load Testing によって Apache JMeter ワーカー ログが収集され、集計されます。 ロード テスト中にエラーを分析するためにログをダウンロードできます。

アプリ コンポーネント

Azure でホストされるアプリケーションに対してロード テストを実行すると、さまざまな Azure アプリケーション コンポーネント (サーバー側のメトリック) のリソース メトリックを監視できます。 ロード テストの実行中、そしてテストの完了後に、Azure Load Testing ダッシュボードでリソース メトリックを監視および分析できます。

ロード テストを作成または更新するときに、Azure Load Testing が監視するアプリ コンポーネントの一覧を構成できます。 各アプリ コンポーネントの既定のリソース メトリックの一覧を変更できます。

Azure Load Testing でサポートされる Azure リソースの種類の詳細について説明します。

メトリック

ロード テストでは、Azure Load Testing によってテストの実行に関するメトリックが収集されます。 メトリックには、次の 2 種類があります。

• クライアント側のメトリック は、テスト エンジンによって報告されます。 これらのメトリックには、仮想ユーザーの数、要求の応答時間、失敗した要求の数、1 秒あたりの要求数が含まれます。 これらのクライアント側メトリックに基づいて、テストの失敗条件を定義できます。

• Azure でホストされるアプリケーションでは、サーバー側のメトリックを使用して、Azure アプリケーション コンポーネントに関する情報を提供できます。 Azure Load Testing は、Application Insights やコンテナーの分析情報などの Azure Monitor と統合して、Azure サービスから詳細をキャプチャします。 サービスの種類に応じて、さまざまなメトリックを使用できます。 たとえば、データベースの読み取り数、HTTP 応答の種類や、コンテナー リソースの消費量に関するメトリックを指定できます。

関連するコンテンツ

ここでは、ロード テストの作成を開始するための Azure Load Testing の主要な概念について説明します。

• Azure Load Testing のしくみについて説明します。
• Web サイトのロード テストを作成して実行する方法について説明します。
• Azure アプリケーションでパフォーマンスのボトルネックを特定する方法について説明します。
• CI/CD を使用して自動回帰テストを設定する方法について説明します。