この記事では、Azure Load Testing を使用して高スケール用にロード テストを構成する方法について説明します。 Azure Load Testing は、大規模なトラフィックをシミュレートするためのインフラストラクチャのプロビジョニングの複雑さを抽象化します。 ロード テストをスケールアウトするには、並列テスト エンジン インスタンスの数を構成します。 最適な負荷分散を実現するために、Azure Load Testing ダッシュボードでテスト インスタンスの正常性メトリックを監視できます。
[前提条件]
アクティブなサブスクリプションを持つ Azure アカウント。 Azure サブスクリプションをお持ちでない場合は、開始する前に 無料アカウント を作成してください。
既存の Azure Load Testing リソース。 Azure Load Testing リソースを作成するには、ロード テストの作成と実行に関するクイックスタートを参照してください。
ロード テストのロード パラメーターを構成する
アプリケーションのユーザー トラフィックをシミュレートするには、読み込みパターンと、読み込みをシミュレートする仮想ユーザーの数を構成します。 Azure Load Testing では、多数の並列テスト エンジン インスタンスでロード テストを実行することで、アプリケーションへのトラフィックをシミュレートする仮想ユーザーの数をスケールアウトできます。 ロード パターンは、ロード テストの期間中に負荷がどのように分散されるかを決定します。 ロード パターンの例としては、線形、階段状、またはスパイク ロードがあります。
ロード テストの種類、URL ベース、JMeter ベース、または子ベースに応じて、ターゲットの負荷とロード パターンを構成するためのさまざまなオプションがあります。 次の表に、テストの種類の違いを示します。
| テストの種類 | 仮想ユーザーの数 | ロード パターン |
|---|---|---|
| URLに基づく(基本) | ロード テスト構成の仮想ユーザーのターゲット数を指定します。 | 仮想ユーザーのランプアップ時間と数に基づく線形ロードパターン。 |
| URL ベース (詳細) | ロード テスト構成で、テスト エンジンの数とインスタンスあたりの仮想ユーザー数を指定します。 | 負荷パターン (線形、ステップ、スパイク) を構成します。 |
| JMeter ベース | テスト スクリプト内のインスタンスあたりの仮想ユーザー数を指定します。 ロード テスト構成のテスト エンジンの数を指定します。 | テスト スクリプトでロード パターンを構成します。 |
| Locust ベース | ロード テスト構成、子構成ファイル、またはテスト スクリプト内のユーザーの合計数を指定します。 ロード テスト構成のテスト エンジンの数を指定します。 | テスト スクリプトでロード パターンを構成します。 |
URL ベース テストのロード パラメーターを構成する
URL ベースのロード テストのロード パラメーターを指定するには:
Azure portal の Azure Load Testing リソースに移動します。
左側のナビゲーションで、[テスト] を選択してすべてのテストを表示します。
一覧でロード テストを選択し、[編集] を選択します。
または、テストの詳細ページからテスト構成を編集することもできます。 それを行うには、[構成] を選択してから [テスト] を選択します。
[基本] ページで、[詳細設定を有効にする] を選択します。
[テストの編集] ページで、[読み込み] タブを選択します。
URL ベースのテストでは、並列テスト エンジン インスタンスの数とロード パターンを構成できます。
[エンジン インスタンス] のスライダー コントロールを使用して、並列テスト エンジン インスタンスの数を更新します。 または、入力ボックスにターゲット値を入力します。
[ロード パターン] の値を一覧から選択します。
パターンごとに、対応する構成設定を入力します。 グラフには、ロード パターンとその構成パラメーターが視覚的に表示されます。
JMeter ベースのテストの読み込みパラメーターを構成する
JMeter ベースのロード テストのロード パラメーターを指定するには:
Azure portal の Azure Load Testing リソースに移動します。
左側のナビゲーションで、[テスト] を選択してすべてのテストを表示します。
一覧でロード テストを選択し、[編集] を選択します。
または、テストの詳細ページからテスト構成を編集することもできます。 それを行うには、[構成] を選択してから [テスト] を選択します。
[テストの 編集] ページで、[読み込み] タブを選択します。[Engine instances] (エンジン インスタンス) スライダー コントロール を使用して、テスト エンジン インスタンスの数を更新するか、入力ボックスに値を直接入力します。
[適用] を選択してテストを変更すると、テストを再実行するときに新しい構成が使用されます。
ローカストベースのテストの負荷パラメーターを構成する
ローカストベースのロードテストのロードパラメータを指定するには
Azure portal の Azure Load Testing リソースに移動します。
左側のナビゲーションで、[テスト] を選択してすべてのテストを表示します。
一覧でロード テストを選択し、[編集] を選択します。
または、テストの詳細ページからテスト構成を編集することもできます。 それを行うには、[構成] を選択してから [テスト] を選択します。
[ テストの編集] ページで、[ 読み込み ] タブを選択します。それぞれの入力ボックスに、必要なユーザー全体と全体的な産卵率の値を入力します。 この負荷を生成するために必要なエンジン インスタンス数が自動で算出されます。 テスト スクリプトが複雑でリソースを大量に消費する場合は、 エンジン インスタンス スライダー コントロールを使用してテスト エンジン インスタンスの数を更新するか、入力ボックスに値を直接入力します。
または、テスト スクリプトまたは子構成ファイルでユーザー数と生成率を構成し、必要なエンジン インスタンスの数を指定することもできます。
- [適用] を選択してテストを変更すると、テストを再実行するときに新しい構成が使用されます。
エンジン インスタンスのメトリックを監視する
テスト エンジン インスタンス自体がパフォーマンスのボトルネックにならないように、テスト エンジン インスタンスのリソース メトリックを監視できます。 テスト インスタンスのリソース使用率が高いと、ロード テストの結果に悪影響を及ぼす可能性があります。
Azure Load Testing では、インスタンスごとに 4 つのリソース メトリックがレポートされます。
- CPU の割合。
- メモリの割合。
- 1 秒あたりのネットワーク バイト数。
- 仮想ユーザーの数。
テストの実行期間中の平均 CPU 使用率またはメモリの割合が 75% を下回っている場合、テスト エンジン インスタンスは正常と見なされます。
エンジンのリソース メトリックを表示するには:
Load Testing リソースにアクセスします。 左側のウィンドウで [テスト] を選択して、ロード テストの一覧を表示します。
一覧でロード テストを選択して、テスト実行の一覧を表示します。
テスト実行の一覧で、目的のテスト実行を選択します。
テスト実行ダッシュボードで [エンジンの状態] を選択して、エンジンのリソース メトリックを表示します。
必要に応じて、フィルター コントロールを使用して特定のテスト エンジン インスタンスを選択します。
異常なエンジン インスタンスのトラブルシューティング
1 つまたは複数のインスタンスでリソースの使用状況が高い場合は、テスト結果に影響する可能性があります。 この問題を解決するには、次の手順のうち 1 つ以上を試してください。
テスト エンジンあたりのスレッド (仮想ユーザー) の数を減らす。 仮想ユーザーの目標数を達成するために、ロード テストのエンジン インスタンスの数を増やすことが必要になる場合があります。
スクリプトが効果的で、冗長なコードが使用されていないことを確認する。
エンジンの正常性状態が不明な場合は、テストを再実行します。
1 秒あたりの要求数を測定する
Azure Load Testing でロード テスト用に生成できる "1 秒あたりの要求" (RPS) の最大数は、アプリケーションの "待ち時間" と "仮想ユーザー" (VU) の数によって異なります。 アプリケーションの待ち時間は、テスト エンジンによるアプリケーション要求の送信から応答の受信までの合計時間です。 仮想ユーザー数は、Azure Load Testing が特定の時点で実行する並列要求の数です。
1 秒あたりの要求数を計算するには、RPS = (VU の数) * (1/待機時間の秒数) の数式を適用します。
たとえば、アプリケーションの待ち時間が 20 ミリ秒 (0.02 秒) で、2,000 VU の負荷を生成している場合、約 100,000 RPS (2000 x 1/0.02 秒) を実現できます。
1 秒あたりの要求の目標数を達成するには、ロード テストの仮想ユーザーの合計数を構成します。
注
Apache JMeter では、サーバーに送信された要求が正常に戻ったかどうかのみが報告されます。 Apache JMeter からアプリケーションに接続できない場合、実際の 1 秒あたりの要求数は最大値よりも少なくなります。 原因としては、サーバーがビジー状態で要求を処理できないこと、または TLS/SSL 証明書がないことが考えられます。 接続の問題を診断するには、ロード テストのダッシュボードで [エラー] グラフを確認し、ロード テストのログ ファイルをダウンロードします。
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 でのサービス制限とクォータの詳細について説明します。