Azure Load Testing を使用してロード テストの不合格の条件を定義する

この記事では、Azure Load Testing を使用してロード テストの不合格の条件または自動停止の条件を定義する方法について説明します。 不合格の条件によって、負荷がかかるアプリケーションに対するパフォーマンスと品質の想定を定義できます。 Azure Load Testing では、Azure リソースのエラー率や CPU の割合など、不合格条件を定義するためのクライアントおよびサーバーに関するさまざまなメトリックがサポートされています。 自動停止条件を使用すると、エラー率が特定のしきい値を超えたときにロード テストを自動的に停止できます。

前提条件

• アクティブなサブスクリプションが含まれる Azure アカウント。 Azure サブスクリプションをお持ちでない場合は、始める前に無料アカウントを作成してください。
• Azure ロード テスト リソース。 Azure Load Testing リソースを作成する必要がある場合は、ロード テストの作成と実行に関するクイックスタートを参照してください。

ロード テストの不合格の条件

ロード テストの不合格条件は、テストで満たす必要があるメトリックの条件です。 テスト条件は、Azure Load Testing のロード テスト レベルで定義します。 ロード テストには、1 つ以上のテスト条件を設定できます。 テスト条件の少なくとも 1 つが true と評価されると、ロード テストは不合格のステータスになります。

ロード テストには、最大 50 個のテスト条件を定義できます。 同じメトリックに関して複数の条件がある場合は、しきい値が最も低い条件が使用されます。

クライアント メトリックの不合格条件の構造

Azure Load Testing の不合格条件の形式は、サポートされているメトリックの条件ステートメントの形式に従います。 たとえば、1 秒あたりの要求の平均数が 500 を超えていることを確認します。

クライアント側のメトリックについては、テスト条件を次の 2 つのレベルで定義できます。 ロード テストでは、さまざまなレベルで条件を組み合わせることができます。

• ロード テスト レベルで。 たとえば、エラー率の合計がしきい値を超えないようにします。 条件の構造は、Aggregate_function (client_metric) condition threshold です。
• JMeter 要求レベル (JMeter サンプラー) で。 たとえば、getProducts 要求の応答時間のしきい値を指定しつつ、sign in 要求の応答時間は無視するということができます。 条件の構造は、Request: Aggregate_function (client_metric) condition threshold です。

次の表で、各コンポーネントについて説明します。

パラメーター	説明
Client metric	必須。 条件を適用するクライアント メトリック。
Aggregate function	必須。 クライアント メトリックに適用される集計関数。
Condition	必須。 greater than、less than などの比較演算子。
Threshold	必須。 クライアント メトリックと比較する数値。
Request	省略可能。 条件が適用される JMeter スクリプトのサンプラーの名前。 要求名を指定しない場合、条件はスクリプト内のすべての要求の集計に適用されます。 JMeter スクリプトのサンプラー名に個人データを含めないでください。 サンプラー名は、Azure Load Testing 結果ダッシュボードに表示されます。

不合格条件でサポートされているクライアント メトリック

Azure Load Testing では、次のクライアント メトリックがサポートされています。

メトリック	集計関数	Threshold	条件	説明
response_time_ms	avg (平均) min (最小) max (最大) pxx (パーセンタイル): xx は 50、75、90、95、96、97、98、99、999、9999 のいずれかです。	ミリ秒 (ms) を表す整数値。	> (より大きい) < (より小さい)	応答時間または経過時間 (ミリ秒単位)。 経過時間の詳細については、「Apache JMeter のドキュメント」を参照してください。
latency	avg (平均) min (最小) max (最大) pxx (パーセンタイル)、xx は 50、90、95、99 にすることができます	ミリ秒 (ms) を表す整数値。	> (より大きい) < (より小さい)	待機時間 (ミリ秒単位)。 待機時間の詳細については、「Apache JMeter のドキュメント」を参照してください。
error	percentage	パーセントを表す 0 - 100 の範囲の数値。	> (より大きい)	失敗した要求の割合。
requests_per_sec	avg (平均)	小数点以下 2 桁までの数値。	> (より大きい) < (より小さい)	1 秒あたりの要求回数。
requests	count	整数値。	> (より大きい) < (より小さい)	要求の合計数。

クライアント メトリックに関するロード テストの不合格条件を定義する

Azure Portal

このセクションでは、Azure portal で、クライアント メトリックに関するロード テストのテスト条件を構成します。

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

2. 左側のウィンドウで [テスト] を選択して、ロード テストの一覧を表示します。

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

   

4. [テスト条件] ペインで、テストの [メトリック]、[集計関数]、[条件]、[しきい値] を入力します。

   

   必要に応じて、[要求名] 情報を入力して、特定の JMeter 要求に対するテスト条件を追加します。 値は、JMX ファイル内の JMeter サンプラーの名前と一致する必要があります。

   

5. 適用を選択して、変更を保存します。

   ロード テストを実行すると、Azure Load Testing はテスト条件を使用してロード テストの実行のステータスを判断するようになります。

6. テストを実行し、ロード テスト ダッシュボードでステータスを表示します。

   ダッシュボードに各テスト条件とそのステータスが表示されます。 少なくとも 1 つの条件が満たされた場合、テストの全体的なステータスは不合格となります。

   

Azure Pipelines / GitHub Actions

このセクションでは、CI/CD ワークフローの一部として、クライアント メトリックに関するロード テストのテスト条件を構成します。 CI/CD を使用して自動パフォーマンス テストを設定する方法について説明します。

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

YAML 構成ファイルで不合格条件を指定するには次のようにします。

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

2. failureCriteria 設定にテスト条件を追加します。

   前に説明したように、不合格条件の形式を使用します。 ロード テストには複数の不合格条件を追加できます。

   次の例では、3 つの不合格条件を定義しています。 最初の 2 つの条件はロード テスト全体に適用され、最後の条件は GetCustomerDetails 要求についての条件を指定しています。

   version: v0.1
   testId: SampleTestCICD
   displayName: Sample test from CI/CD
   testPlan: SampleTest.jmx
   description: Load test website home page
   engineInstances: 1
   failureCriteria:
     - avg(response_time_ms) > 300
     - percentage(error) > 50
     - GetCustomerDetails: avg(latency) >200
   

   特定の JMeter 要求についてのテスト条件を定義する際、要求名は JMX ファイル内の JMeter サンプラーの名前と一致している必要があります。

   

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

4. CI/CD ワークフローの実行後、CI/CD ログでテスト ステータスを確認します。

   ログには、テストの全体的なステータスと、各テスト条件のステータスが表示されます。 CI/CD ワークフローの実行の状態には、テストの実行の状態も反映されます。

   

サーバー メトリックの条件をテストするためにアプリ コンポーネントにアクセスする

アプリ コンポーネントのメトリックに対して不合格条件を設定すると、ロード テスト リソースは、そのコンポーネントにアクセスするためにマネージド ID を使用します。 マネージド ID を構成した後、これらの値をアプリ コンポーネントから読み取るためのアクセス許可をロード テスト リソースのマネージド ID に付与する必要があります。

メトリックをアプリ コンポーネントから読み取るためのアクセス許可を Azure Load Testing リソースに付与するには、次の手順を行います。

1. Azure portal で、アプリ コンポーネントに移動します。

2. 左側のメインで、[アクセスの制御 (IAM)]、[+ 追加]、[ロールの割り当ての追加] の順に選択します。

   

3. [ロール] タブの [ジョブ機能のロール] で、監視閲覧者または監視共同作成者を検索します。

4. [メンバー] タブの [アクセス権の割り当て先] で、[マネージド ID] を選択します。

5. [メンバーの選択] をクリックし、ロード テスト リソースのマネージド ID を検索して選択し、[次へ] を選択します。 システム割り当てマネージド ID を使用している場合、マネージド ID 名は Azure ロード テスト リソースの名前と一致します。

6. [確認と割り当て] を選択して、ID にアクセス許可を割り当てます。

   

テストの実行時に、ロード テスト リソースに関連付けられているマネージド ID で、アプリ コンポーネントからロード テストのメトリックを読み取ることができるようになりました。

サーバー メトリックに関するロード テストの不合格条件を定義する

重要

Azure Load Testing では、Azure Pipelines または GitHub Actions からサーバー側のメトリックに対する不合格情報を構成する方法はサポートされていません。

このセクションでは、Azure portal で、サーバー側のメトリックに対するロード テストのテスト不合格条件を構成します。

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

2. [テストの作成] を選択します。

3. [監視] タブで、テスト中に監視するアプリ コンポーネントを構成します。

4. [メトリック参照 ID] を構成します。 ID は、ロード テスト リソースのシステム割り当て ID、またはユーザー割り当て ID のいずれかを指定できます。 必ず以前にアクセスを許可したものと同じ ID を使ってください。

   

5. [テスト条件] ペインで、テストの [リソース ID]、[名前空間]、[メトリック]、[集計]、[条件]、[しきい値] の値 を入力します。 不合格条件は、テスト中に監視するリソースまたはアプリのコンポーネントに対してのみ設定できます。

   

6. 適用を選択して、変更を保存します。 ロード テストを実行すると、Azure Load Testing はテスト条件を使用してロード テストの実行のステータスを判断するようになります。

7. テストを実行し、ロード テスト ダッシュボードでステータスを表示します。 ダッシュボードに各テスト条件とそのステータスが表示されます。 少なくとも 1 つの条件が満たされた場合、テストの全体的なステータスは不合格となります。

   

自動停止の構成

Azure Load Testing は、エラー率が特定の時間枠で指定されたしきい値を超えた場合、ロード テストを自動的に停止します。 自動的に停止することで、エンドポイント URL が正しく構成されていないなど、テストの失敗でさらにコストが発生することを防ぎます。

ロード テスト構成では、自動停止機能を有効または無効にし、エラー率のしきい値と時間枠を構成できます。 既定では、Azure Load Testing は、60 秒の時間枠内で少なくとも 90% のエラー率となったロード テストを自動的に停止します。

Azure Load Testing の自動停止機能は、JMeter スクリプトの AutoStop リスナーと組み合わせて使用できます。 ロード テストは、自動停止構成または JMeter AutoStop リスナーのいずれかの条件が満たされると、自動的に停止します。

注意事項

ロード テストの自動停止を無効にすると、ロード テストが正しく構成されていない場合でもコストが発生する可能性があります。

Azure Portal

Azure portal でロード テストの自動停止を構成するには

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

2. 左側のウィンドウで [テスト] を選択して、ロード テストの一覧を表示します。

3. 一覧からロード テストを選択し、[編集] を選択します。 または、新しいテストを作成する場合は、[作成] > [JMeter スクリプトをアップロード] を選択します。

4. [テスト条件] タブに移動して、自動停止機能を構成します。

   • 自動停止テスト コントロールを使用して、ロード テストの自動停止を有効または無効にします。

   • 自動停止を有効にした場合は、[エラー率] と [時間枠] フィールドに入力できます。 時間枠を秒単位で指定します。

     

5. 新しいロード テストを作成する場合は、[適用]、または、[確認と作成] を選択して変更を保存します。

Azure Pipelines / GitHub Actions

CI/CD ワークフローでロード テストの自動停止を構成するには、ロード テスト構成 YAML ファイルを更新します。

YAML 構成ファイルで自動停止設定を指定するには次のようにします。

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

   • 自動停止を有効にするには、 autoStop 設定を追加し、 errorPercentage と timeWindow を指定します。

     次の例では、2 分の時間枠でエラー率が 80% を超えると、ロード テストが自動的に停止されます。

     version: v0.1
     testId: SampleTestCICD
     displayName: Sample test from CI/CD
     testPlan: SampleTest.jmx
     description: Load test website home page
     engineInstances: 1
     autoStop:
       errorPercentage: 80
       timeWindow: 120
     

   • 自動停止を無効にするには、構成ファイルに autoStop: disable を追加します。

     次の例では、ロード テストの自動停止を無効にします。

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

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

CI/CD を使用して自動パフォーマンス テストを設定する方法について説明します。

次のステップ

• シークレットを使用してロード テストをパラメーター化する方法については、ロード テストのパラメーター化に関する記事を参照してください。

• パフォーマンス テストの自動化については、自動パフォーマンス テストの構成に関する記事を参照してください。