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

この記事では、Azure Load Testing を使用して高スケール用にロード テストを構成する方法について説明します。 Azure Load Testing は、大規模なトラフィックをシミュレートするためのインフラストラクチャのプロビジョニングの複雑さを抽象化します。 ロード テストをスケールアウトするには、並列テスト エンジン インスタンスの数を構成します。 最適な負荷分散を実現するために、Azure Load Testing ダッシュボードでテスト インスタンスの正常性メトリックを監視できます。

前提条件

  • アクティブなサブスクリプションが含まれる Azure アカウント。 Azure サブスクリプションをお持ちでない場合は、始める前に無料アカウントを作成してください。

  • 既存の Azure Load Testing リソース。 Azure Load Testing リソースを作成するには、ロード テストの作成と実行に関するクイックスタートを参照してください。

ロード テストのロード パラメーターを構成する

アプリケーションのユーザー トラフィックをシミュレートするには、読み込みパターンと、読み込みをシミュレートする仮想ユーザーの数を構成します。 Azure Load Testing では、多数の並列テスト エンジン インスタンスでロード テストを実行することで、アプリケーションへのトラフィックをシミュレートする仮想ユーザーの数をスケールアウトできます。 ロード パターンは、ロード テストの期間中に負荷がどのように分散されるかを決定します。 負荷パターンの例としては、線形、階段状、スパイク荷重があります。

ロード テストの種類、URL ベース、または JMeter ベースに応じて、ターゲットの負荷と読み込みパターンを構成するさまざまなオプションがあります。 次の表に、2 つのテストの種類の違いを示します。

テストの種類 仮想ユーザーの数 ロード パターン
URL ベース (基本) ロード テスト構成の仮想ユーザーのターゲット数を指定します。 仮想ユーザーの増加時間と数に基づく線形読み込みパターン。
URL ベース (詳細) ロード テスト構成で、テスト エンジンの数とインスタンスあたりの仮想ユーザー数を指定します。 負荷パターン (線形、ステップ、スパイク) を構成します。
JMeter ベース ロード テスト構成のテスト エンジンの数を指定します。 テスト スクリプト内の仮想ユーザーの数を指定します。 テスト スクリプトでロード パターンを構成します。

URL ベースのテストの読み込みパラメーターを構成する

URL ベースのロード テストのロード パラメーターを指定するには:

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

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

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

    Screenshot that shows the list of load tests and the 'Edit' button.

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

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

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

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

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

    Screenshot of the 'Load' tab on the 'Edit test' pane.

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

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

    Screenshot of the 'Load' tab when editing a load test, showing how to configure the load pattern.

JMeter ベースのテストの読み込みパラメーターを構成する

JMeter ベースのロード テストのロード パラメーターを指定するには:

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

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

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

    Screenshot that shows the list of load tests and the 'Edit' button.

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

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

    Screenshot of the 'Load' tab on the 'Edit test' pane.

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

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

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

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

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

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

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

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

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

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

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

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

Screenshot that shows the load engine health metrics on the test run dashboard.

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

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 秒あたりの要求の目標数を達成するには、ロード テストの仮想ユーザーの合計数を構成します。

Note

Apache JMeter では、サーバーに送信された要求が正常に戻ったかどうかのみが報告されます。 Apache JMeter からアプリケーションに接続できない場合、実際の 1 秒あたりの要求数は最大値よりも少なくなります。 考えられる原因は、サーバーがビジー状態で要求を処理できない、または TLS/SSL 証明書がない可能性があります。 接続の問題を診断するには、ロード テストのダッシュボードで [エラー] グラフを確認し、ロード テストのログ ファイルをダウンロードします。

テスト エンジン インスタンスと仮想ユーザー

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

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

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

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

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

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