新しい 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 Load Testing のさまざまな概念が相互にどのように関連しているかを示す図。

ロード テスト リソース

Azure ロード テスト リソースは、ロード テスト アクティビティのトップ レベルのリソースです。 このリソースによって、ロード テスト、テスト結果、および関連する成果物を表示および管理するための一元的な場所が提供されます。

ロード テスト リソースを作成するときは、その場所を指定します。これにより、テスト エンジンの場所が決まります。 Azure Load Testing では、リソース内のすべての成果物が自動的に暗号化されます。 暗号化には、Microsoft マネージド キーを選択することも、独自のカスタマー マネージド キーを使用することもできます。

アプリケーションのロード テストを実行するには、ロード テスト リソースにテストを追加します。 リソースには、0 個以上のテストを含めることができます。

Azure ロールベースのアクセス制御を使用して、ロード テスト リソースと、関連する成果物へのアクセスを許可できます。

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

テスト

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

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

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

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

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

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

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

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

テスト実行

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

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

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

重要

テストを更新しても、そのテストの新しい設定は、既存のテストの実行に自動的には継承されません。 新しい設定は、その "テスト" を実行する際に、新しいテストの実行によってのみ使用されます。 既存の "テストの実行" を再実行した場合、そのテストの実行の元の設定が使用されます。

テスト エンジン

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

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

テスト スクリプトの実行中には、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 やコンテナーの分析情報などの Azure Monitor と統合して、Azure サービスから詳細をキャプチャします。 サービスの種類に応じて、さまざまなメトリックを使用できます。 たとえば、データベースの読み取り数、HTTP 応答の種類や、コンテナー リソースの消費量に関するメトリックを指定できます。

関連するコンテンツ

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