高スケールな負荷用に Azure Load Testing を構成する

1. Azure portal の Azure Load Testing リソースに移動します。

2. 左側のナビゲーションで、[テスト] を選択してすべてのテストを表示します。

3. 一覧でロード テストを選択し、[編集] を選択します。

   

   または、テストの詳細ページからテスト構成を編集することもできます。 それを行うには、[構成] を選択してから [テスト] を選択します。

4. [基本] ページで、[詳細設定を有効にする] を選択します。

5. [テストの編集] ページで、[読み込み] タブを選択します。

   URL ベースのテストでは、並列テスト エンジン インスタンスの数とロード パターンを構成できます。

6. [エンジン インスタンス] のスライダー コントロールを使用して、並列テスト エンジン インスタンスの数を更新します。 または、入力ボックスにターゲット値を入力します。

   

7. [ロード パターン] の値を一覧から選択します。

   パターンごとに、対応する構成設定を入力します。 グラフには、ロード パターンとその構成パラメーターが視覚的に表示されます。

   

CI/CD ワークフローについては、要求 JSON ファイルで URL ベースのロード テストのロード パラメーターを testSetup プロパティに指定します。

ロード パターン (loadType) に応じて、さまざまなロード パラメーターを指定できます。

ロード テスト構成 YAML ファイルで、testType プロパティを URL に設定し、testPlan プロパティを、要求 JSON ファイルを参照するように設定します。

次のコード スニペットは、URL ベースのロード テストの要求 JSON ファイルの例を示しています。 testSetup は、テスト エンジンごとに 30 秒のランプアップ時間と 5 人の仮想ユーザーで 300 秒間実行される線形ロード パターンを指定します。

{
    "version": "1.0",
    "scenarios": {
      "requestGroup1": {
        "requests": [
          {
            "requestName": "Request1",
            "requestType": "URL",
            "endpoint": "http://northwind.contoso.com",
            "queryParameters": [],
            "headers": {},
            "body": null,
            "method": "GET",
            "responseVariables": [
                {
                  "extractorType": "XPathExtractor",
                  "expression": "/note/body",
                  "variableName": "token"
                }
              ]
          },
          {
            "requestName": "Request2",
            "requestType": "CURL",
            "curlCommand": "curl --location '${domain}' --header 'Ocp-Apim-Subscription-Key: ${token}"
          }
        ],
        "csvDataSetConfigList": [
            {
              "fileName": "inputData.csv",
              "variableNames": "domain"
            }
          ]
      }
    },
    "testSetup": [
      {
        "virtualUsersPerEngine": 5,
        "durationInSeconds": 300,
        "loadType": "Linear",
        "scenario": "requestGroup1",
        "rampUpTimeInSeconds": 30
      }
    ]
}

1. Azure portal の Azure Load Testing リソースに移動します。

2. 左側のナビゲーションで、[テスト] を選択してすべてのテストを表示します。

3. 一覧でロード テストを選択し、[編集] を選択します。

   

   または、テストの詳細ページからテスト構成を編集することもできます。 それを行うには、[構成] を選択してから [テスト] を選択します。

4. [テストの 編集] ページで、[読み込み] タブを選択します。[Engine instances] (エンジン インスタンス) スライダー コントロール を使用して、テスト エンジン インスタンスの数を更新するか、入力ボックスに値を直接入力します。

   

5. [適用] を選択してテストを変更すると、テストを再実行するときに新しい構成が使用されます。

CI/CD ワークフローについて、YAML テスト構成ファイルでエンジン インスタンスの数を構成します。 ロード テスト構成ファイルは、JMeter テスト スクリプト ファイルと共にソース管理リポジトリに格納します。

1. 任意のエディターでロード テスト用の YAML テスト構成ファイルを開きます。

2. engineInstances 設定でテスト エンジン インスタンスの数を構成します。

   次の例では、10 個の並列テスト エンジン インスタンスにわたって実行されるロード テストを構成します。

   version: v0.1
   testId: SampleTestCICD
   displayName: Sample test from CI/CD
   testPlan: SampleTest.jmx
   description: Load test website home page
   engineInstances: 10
   

3. YAML 構成ファイルを保存し、ソース管理に変更をコミットします。

1. Azure portal の Azure Load Testing リソースに移動します。

2. 左側のナビゲーションで、[テスト] を選択してすべてのテストを表示します。

3. 一覧でロード テストを選択し、[編集] を選択します。

   

   または、テストの詳細ページからテスト構成を編集することもできます。 それを行うには、[構成] を選択してから [テスト] を選択します。

4. [ テストの編集] ページで、[ 読み込み ] タブを選択します。それぞれの入力ボックスに、必要なユーザー全体と全体的な産卵率の値を入力します。 この負荷を生成するために必要なエンジン インスタンス数が自動で算出されます。 テスト スクリプトが複雑でリソースを大量に消費する場合は、 エンジン インスタンス スライダー コントロールを使用してテスト エンジン インスタンスの数を更新するか、入力ボックスに値を直接入力します。

   

または、テスト スクリプトまたは子構成ファイルでユーザー数と生成率を構成し、必要なエンジン インスタンスの数を指定することもできます。

1. [適用] を選択してテストを変更すると、テストを再実行するときに新しい構成が使用されます。

CI/CD ワークフローについて、YAML テスト構成ファイルでエンジン インスタンスの数を構成します。 YAML ファイルでは、ユーザー全体と生成速度を環境変数として構成できます。 または、テスト スクリプトまたはLocust構成ファイルで構成することもできます。 ロードテスト構成ファイルは、ソース管理リポジトリにあるLocustテストスクリプトファイルと共に保存します。

1. 任意のエディターでロード テスト用の YAML テスト構成ファイルを開きます。

2. engineInstances 設定でテスト エンジン インスタンスの数を構成します。 ユーザー全体と生成速度を環境変数として構成します。

   次の例では、10 個の並列テスト エンジン インスタンスにわたって実行されるロード テストを構成します。

   version: v0.1
   testId: SampleTestCICD
   displayName: Sample test from CI/CD
   testPlan: SampleTest.jmx
   description: Load test website home page
   engineInstances: 4
   env:
     - name: LOCUST_USERS
       value: 2000
     - name: LOCUST_SPAWN_RATE
       value: 100
     - name: LOCUST_RUN_TIME
       value: 20
   

3. YAML 構成ファイルを保存し、ソース管理に変更をコミットします。

エンジン インスタンスのメトリックを監視する

テスト エンジン インスタンス自体がパフォーマンスのボトルネックにならないように、テスト エンジン インスタンスのリソース メトリックを監視できます。 テスト インスタンスのリソース使用率が高いと、ロード テストの結果に悪影響を及ぼす可能性があります。

Azure Load Testing では、インスタンスごとに 4 つのリソース メトリックがレポートされます。

• CPU の割合。
• メモリの割合。
• 1 秒あたりのネットワーク バイト数。
• 仮想ユーザーの数。

テストの実行期間中の平均 CPU 使用率またはメモリの割合が 75% を下回っている場合、テスト エンジン インスタンスは正常と見なされます。

エンジンのリソース メトリックを表示するには:

1. Load Testing リソースにアクセスします。 左側のウィンドウで [テスト] を選択して、ロード テストの一覧を表示します。

2. 一覧でロード テストを選択して、テスト実行の一覧を表示します。

3. テスト実行の一覧で、目的のテスト実行を選択します。

4. テスト実行ダッシュボードで [エンジンの状態] を選択して、エンジンのリソース メトリックを表示します。

   必要に応じて、フィルター コントロールを使用して特定のテスト エンジン インスタンスを選択します。

異常なエンジン インスタンスのトラブルシューティング

1 つまたは複数のインスタンスでリソースの使用状況が高い場合は、テスト結果に影響する可能性があります。 この問題を解決するには、次の手順のうち 1 つ以上を試してください。

• テスト エンジンあたりのスレッド (仮想ユーザー) の数を減らす。 仮想ユーザーの目標数を達成するために、ロード テストのエンジン インスタンスの数を増やすことが必要になる場合があります。

• スクリプトが効果的で、冗長なコードが使用されていないことを確認する。

• エンジンの正常性状態が不明な場合は、テストを再実行します。

1 秒あたりの要求数を測定する

Azure Load Testing でロード テスト用に生成できる "1 秒あたりの要求" (RPS: Requests Per Second) の最大数は、アプリケーションの "待ち時間" と "仮想ユーザー" (VU) の数によって異なります。 アプリケーションの待ち時間は、テスト エンジンによるアプリケーション要求の送信から応答の受信までの合計時間です。 仮想ユーザー数は、Azure Load Testing が特定の時点で実行する並列要求の数です。

1 秒あたりの要求数を計算するには、RPS = (VU の数) * (1/待機時間の秒数) の数式を適用します。

たとえば、アプリケーションの待ち時間が 20 ミリ秒 (0.02 秒) で、2,000 VU の負荷を生成している場合、約 100,000 RPS (2000 x 1/0.02 秒) を実現できます。

1 秒あたりの要求の目標数を達成するには、ロード テストの仮想ユーザーの合計数を構成します。

JMeter ベースのテスト用のテスト エンジン インスタンスと仮想ユーザー

Apache JMeter スクリプトでは、並列スレッドの数を指定できます。 各スレッドは、アプリケーション エンドポイントにアクセスする仮想ユーザーを表します。 スクリプト内のスレッドの数は 250 以下に維持することをお勧めします。

Azure Load Testing では、"テスト エンジン" インスタンスが Apache JMeter スクリプトの実行を担います。 すべてのテスト エンジン インスタンスは並列で実行されます。 ロード テストのインスタンス数は構成可能です。

ロード テストの仮想ユーザーの合計数は、次のようになります: VU 数 = (スレッド数) * (テスト エンジン インスタンスの数)。

目標数の仮想ユーザーをシミュレートするには、JMeter スクリプトで並列スレッドを構成し、それに応じてロード テスト用のエンジン インスタンスを構成します。 テスト エンジンのメトリックを監視して、インスタンスの数を最適化してください。

たとえば、1,000 人の仮想ユーザーをシミュレートするには、Apache JMeter スクリプトでスレッド数を 250 に設定します。 次に、4 つのテスト エンジン インスタンスでロード テストを構成します (つまり、4 x 250 スレッド)。

Azure Load Testing リソースの場所によって、テスト エンジン インスタンスの場所が決定されます。 ロード テスト リソース内のすべてのテスト エンジン インスタンスは、同じ Azure リージョンにホストされます。

Locustベースのテスト用エンジンインスタンスと仮想ユーザー

ロード テストに必要なユーザーの合計数を構成します。 これは、Locust ユーザーの同時実行のピーク数を表します。 これは、Azure Load Testing でテストを作成するときに、ロード構成で構成できます。 この設定は、テスト スクリプトまたはLocustの構成ファイルで行うこともできます。 テスト エンジン インスタンスから最大 500 人のユーザーを実行することをお勧めします。

Azure Load Testing では、 テスト エンジン インスタンスが、子スクリプトを実行する役割を担います。 すべてのテスト エンジン インスタンスは並列で実行されます。 ロード テストのインスタンス数は構成可能です。

ロード テストに必要なエンジンの合計数は、エンジンの数 = (ユーザーの合計数) / 500 です。

負荷構成で合計ユーザー数を構成すると、Azure Load Testing によってエンジン数が自動的に設定されます。 必要に応じて、エンジンの数を更新できます。 テスト エンジンのメトリックを監視して、インスタンスの数を最適化してください。

たとえば、2,000 人のユーザーをシミュレートするには、[負荷構成の ユーザーの合計数] を 2,000 に設定します。 Azure Load Testing では、エンジン数が 4 として自動的に設定されます。 必要に応じてエンジン数を更新します。 テスト スクリプトまたは子構成ファイルでユーザーを 2,000 として構成した場合は、ロード構成でエンジン インスタンスを 4 に設定します。

Azure Load Testing リソースの場所によって、テスト エンジン インスタンスの場所が決定されます。 ロード テスト リソース内のすべてのテスト エンジン インスタンスは、同じ Azure リージョンにホストされます。

関連コンテンツ

• Azure Load Testing でのサービス制限とクォータの詳細について説明します。