Azure Load Testing を使ったアプリケーションパフォーマンスの監視

受講生用ラボマニュアル

ラボの要件

このラボには、Microsoft Edge または Azure DevOps 対応ブラウザーが必要です。
Azure DevOps 組織を設定する: このラボで使用できる Azure DevOps 組織がまだない場合は、組織またはプロジェクトコレクションの作成に関するページの手順に従って作成してください。
既存の Azure サブスクリプションを識別するか、新しいものを作成します。
Azure サブスクリプションの所有者ロールと、Azure サブスクリプションに関連付けられた Microsoft Entra テナントの全体管理者ロールを持つ Microsoft アカウントまたは Microsoft Entra アカウントがあることを確認します。詳細については、「Azure portal を使用して Azure ロールの割り当てを一覧表示する」および「Azure Active Directory で管理者ロールを表示して割当てる」を参照してください。

ラボの概要

Azure Load Testing は、大規模な負荷を生成できるフルマネージドのロードテストサービスです。サービスは、アプリケーションがどこにホストされているかにかかわらず、そのトラフィックをシミュレートします。開発者、テスト担当者、品質保証 (QA) エンジニアは、それを使って、アプリケーションのパフォーマンス、スケーラビリティ、または容量を最適化できます。 Web アプリケーションのロードテストは、URL を使用してすぐに作成できます。テストツールの事前の知識は必要ありません。ロードテストを大規模に実行するための複雑さとインフラストラクチャは、Azure Load Testing によって抽象化されます。さらに高度なロードテストシナリオでは、広く使われているオープンソースのロードパフォーマンスツールである既存の Apache JMeter テストスクリプトを再利用してロードテストを作成できます。たとえば、テスト計画が複数のアプリケーション要求から成る可能性がある、HTTP 以外のエンドポイントを呼び出す必要がある、テストをより動的に行うために入力データとパラメーターを使用している、などの場合です。

このラボでは、Azure Load Testing を使って、現在実行されている Web アプリケーションに対するパフォーマンステストをさまざまな負荷シナリオでシミュレートする方法について説明します。最後に、Azure Load Testing を CI/CD パイプラインに統合する方法について説明します。

目標

このラボを完了すると、次のことができるようになります。

Azure App Service Web アプリをデプロイする。
YAML ベースの CI/CD パイプラインを構成して実行します。
Azure Load Testing をデプロイします。
Azure Load Testing を使って Azure Web アプリのパフォーマンスを調べます。
Azure Load Testing を CI/CD パイプラインに統合します。

推定時間:60 分

Instructions

演習 0:ラボの前提条件の構成

この演習では、ラボの前提条件を設定します。これは、eShopOnWeb に基づくリポジトリを含む新しい Azure DevOps プロジェクトで構成されます。

タスク 1: (完了している場合はスキップしてください) チームプロジェクトを作成して構成する

このタスクでは、複数のラボで使用される eShopOnWeb Azure DevOps プロジェクトを作成します。

ラボコンピューターのブラウザーウィンドウで、Azure DevOps 組織を開きます。 [新しいプロジェクト] をクリックします。プロジェクトに eShopOnWeb という名前を付け、 [作業項目プロセス] ドロップダウンで [スクラム] を選びます。 [作成] をクリックします。

タスク 2: (完了している場合はスキップしてください) eShopOnWeb Git リポジトリをインポートする

このタスクでは、複数のラボで使用される eShopOnWeb Git リポジトリをインポートします。

ラボコンピューターのブラウザーウィンドウで、Azure DevOps 組織と、前に作成した eShopOnWeb プロジェクトを開きます。 [リポジトリ] > [ファイル] 、 [インポート] をクリックします。 [Git リポジトリをインポートする] ウィンドウで、URL https://github.com/MicrosoftLearning/eShopOnWeb.git を貼り付けて、 [インポート] をクリックします。
リポジトリは次のように編成されています。
- .ado フォルダーには、Azure DevOps の YAML パイプラインが含まれています
- .devcontainer フォルダーには、コンテナーを使って開発するためのセットアップが含まれています (VS Code でローカルに、または GitHub Codespaces で)
- infra フォルダーには、一部のラボシナリオで使用される Bicep&ARM コードとしてのインフラストラクチャテンプレートが含まれています。
- .github フォルダーには、YAML GitHub ワークフローの定義が含まれています。
- src フォルダーには、ラボシナリオで使用される .NET 8 Web サイトが含まれています。

タスク 2: Azure リソースを作成する

このタスクでは、Azure portal でクラウドシェルを使って Azure Web アプリを作成します。

ラボのコンピューターで Web ブラウザーを起動し、Azure portal に移動します。このラボで使用する Azure サブスクリプションで、所有者のロールがあり、このサブスクリプションに関連付けられている Microsoft Entra テナントで全体管理者のロールがあるユーザーアカウントを使ってサインインします。
Azure portal のツールバーで、検索テキストボックスのすぐ右側にある Cloud Shell アイコンをクリックします。
Bash または PowerShell の選択を求めるメッセージが表示されたら、[Bash] を選択します。

注: Cloud Shell を初めて起動し、[ストレージがマウントされていません] というメッセージが表示された場合は、このラボで使用しているサブスクリプションを選択し、[ストレージの作成] を選択します。
Bash プロンプトの [Cloud Shell] ペインで、次のコマンドを実行してリソースグループを作成します (<region> プレースホルダーを ‘eastus’ などのご自分の場所に最も近い Azure リージョンの名前に置き換えます)。
```
 RESOURCEGROUPNAME='az400m09l16-RG'
 LOCATION='<region>'
 az group create --name $RESOURCEGROUPNAME --location $LOCATION
```

次のコマンドを実行して Windows App Service プランを作成するには、次のようにします。

 SERVICEPLANNAME='az400l16-sp'
 az appservice plan create --resource-group $RESOURCEGROUPNAME \
     --name $SERVICEPLANNAME --sku B3

一意の名前を指定して Web アプリを作成します。
```
 WEBAPPNAME=az400eshoponweb$RANDOM$RANDOM
 az webapp create --resource-group $RESOURCEGROUPNAME --plan $SERVICEPLANNAME --name $WEBAPPNAME
```
注:Web アプリの名前を記録します。このラボで後ほど必要になります。

演習 1:Azure DevOps で YAML を使用して CI/CD パイプラインをコードとして構成する

この演習では、Azure DevOps で YAML を使用して CI/CD パイプラインをコードとして構成します。

タスク 1: YAML ビルドとデプロイ定義を追加する

このタスクでは、既存のプロジェクトに YAML ビルドの定義を追加します。

[パイプライン] ハブで [パイプライン] に戻ります。
[新しいパイプライン] (または、初めて作成する場合は [パイプラインの作成]) をクリックします。

注: ウィザードを使い、プロジェクトに基づいて新しい YAML パイプラインの定義を作成します。
[コードはどこにありますか?] ペインで [Azure Repos Git (YAML)] オプションをクリックします。
[リポジトリの選択] ペインで eShopOnWeb をクリックします。
[パイプラインの構成] ペインで下にスクロールして [スタートパイプライン] を選びます。
[スタートパイプライン] のすべての行を選択し、削除します。

以下から完全なテンプレートパイプラインをコピーします。ただし、変更を保存する前に、パラメーターを変更する必要があります。

    
 #Template Pipeline for CI/CD
 # trigger:
 # - main

 resources:
   repositories:
     - repository: self
       trigger: none

 stages:
 - stage: Build
   displayName: Build .Net Core Solution
   jobs:
   - job: Build
     pool:
       vmImage: ubuntu-latest
     steps:
     - task: DotNetCoreCLI@2
       displayName: Restore
       inputs:
         command: 'restore'
         projects: '**/*.sln'
         feedsToUse: 'select'

     - task: DotNetCoreCLI@2
       displayName: Build
       inputs:
         command: 'build'
         projects: '**/*.sln'

     - task: DotNetCoreCLI@2
       displayName: Publish
       inputs:
         command: 'publish'
         publishWebProjects: true
         arguments: '-o $(Build.ArtifactStagingDirectory)'

     - task: PublishBuildArtifacts@1
       displayName: Publish Artifacts ADO - Website
       inputs:
         pathToPublish: '$(Build.ArtifactStagingDirectory)'
         artifactName: Website

 - stage: Deploy
   displayName: Deploy to an Azure Web App
   jobs:
   - job: Deploy
     pool:
       vmImage: 'windows-2019'
     steps:
     - task: DownloadBuildArtifacts@1
       inputs:
         buildType: 'current'
         downloadType: 'single'
         artifactName: 'Website'
         downloadPath: '$(Build.ArtifactStagingDirectory)'

YAML 定義の最後で新しいライン上にカーソルを配置します。 必ず前のタスクレベルのインデントにカーソルを置いてください。

注:これは、新しいタスクが追加される場所になります。
ポータルの右側にある [アシスタントを表示する] をクリックします。タスクの一覧で [Azure App Service デプロイ] タスクを見つけて選びます。
[Azure App Service のデプロイ] ペインで次の設定を指定して、[追加] をクリックします。
- [Azure サブスクリプション] ドロップダウンリストで、ラボで前に Azure リソースをデプロイした Azure サブスクリプションを選びます。必要に応じて (これが初めて作成するパイプラインの場合のみ)、[承認] をクリックし、メッセージが表示されたら、Azure リソースのデプロイ時に使ったのと同じユーザーアカウントを使って認証を行います。
- [App Service の種類] で Windows 上の Web アプリが指定されていることを確認します。
- [App Service の名前] ドロップダウンリストで、ラボで以前にデプロイした Web アプリの名前を選びます (**az400eshoponweb…)。
- [パッケージまたはフォルダー] テキストボックスで、既定値を $(Build.ArtifactStagingDirectory)/**/Web.zip に更新します。
- [アプリケーションと構成の設定] を展開し、値 -UseOnlyInMemoryDatabase true -ASPNETCORE_ENVIRONMENT Development を追加します
[追加] ボタンをクリックし、[アシスタント] ペインで設定を確認します。

注:これにより、デプロイタスクが YAML パイプラインの定義に自動的に追加されます。

エディターには次のようなコードスニペットが追加されていて、azureSubscription と WebappName パラメーターには実際の名前が反映されている必要があります。

     - task: AzureRmWebAppDeployment@4
       inputs:
         ConnectionType: 'AzureRM'
         azureSubscription: 'AZURE SUBSCRIPTION HERE (b999999abc-1234-987a-a1e0-27fb2ea7f9f4)'
         appType: 'webApp'
         WebAppName: 'az400eshoponWeb369825031'
         packageForLinux: '$(Build.ArtifactStagingDirectory)/**/Web.zip'
         AppSettings: '-UseOnlyInMemoryDatabase true -ASPNETCORE_ENVIRONMENT Development'

注:packageForLinux パラメーターは、このラボの状況では不適切ですが、Windows または Linux では有効です。

更新を yml ファイルに保存する前に、もっとわかりやすい名前を付けます。 yaml エディターウィンドウの上部に、EShopOnweb/azure-pipelines-#.yml と表示されます。 (# は数字で、通常は 1 ですが、設定によっては異なる場合があります。)そのファイル名を選び、名前を m09l16-pipeline.yml に変更します
[保存] をクリックし、[保存] ペインでもう一度 [保存] をクリックして、master ブランチに変更を直接コミットします。

注: 元の CI-YAML は新しいビルドを自動的にトリガーするように構成されていなかったため、手動で開始する必要があります。
Azure DevOps の左側のメニューから [パイプライン] に移動し、もう一度 [パイプライン] を選びます。次に、[すべて] を選んで、最近使ったものだけでなく、すべてのパイプライン定義を開きます。

注: 前のラボ演習のパイプラインをすべて残している場合、次のスクリーンショットで示すように、パイプラインの既定の eShopOnWeb (#) シーケンス名がこの新しいパイプラインで再利用されている可能性があります。パイプラインを選択します (おそらくシーケンス番号が最も大きいものを選び、[編集] を選択して、m09l16-pipeline.yml コードファイルを指していることを確認します)。
表示されるペインで [実行] をクリックしてこのパイプラインが実行することを確認し、もう一度 [実行] をクリックして確認します。
[Build .Net Core Solution] (.Net Core ソリューションをビルドする) と [Deploy to Azure Web App] (Azure Web アプリにデプロイする) という 2 つの異なるステージが表示されることに注意してください。
パイプラインが開始するまで待ちます。
ビルドステージの間に表示される警告はすべて無視します。ビルドステージが正常に完了するまで待ちます。 (実際のビルドステージを選んで、ログからさらに詳しく確認できます)。
デプロイステージが開始できる状態になると、 [アクセス許可が必要です] というプロンプトとオレンジ色のバーが表示されます。
```
 This pipeline needs permission to access a resource before this run can continue to Deploy to an Azure Web App
```
[表示] をクリックします
[レビューを待機しています] ペインで、 [許可] をクリックします。
[許可] ポップアップウィンドウでメッセージを確認し、 [許可] をクリックして確認します。
これにより、デプロイステージが開始します。これが正常に完了するまで待ちます。

タスク 2: デプロイされたサイトを確認する

Azure portal を表示している Web ブラウザーウィンドウに戻り、Azure Web アプリのプロパティが表示されているブレードに移動します。
[Azure Web アプリ] ブレードで [概要] をクリックします。[概要] ブレードで [参照] をクリックし、新しい Web ブラウザータブでサイトを開きます。
デプロイされたサイトが新しいブラウザータブに期待どおりに読み込まれ、eShopOnWeb eコマース Web サイトが表示されることを確認します。

演習 2: Azure Load Testing をデプロイして設定する

この演習では、Azure Load Testing リソースを Azure にデプロイし、現在実行されている Azure App Service に対してさまざまな Load Testing シナリオを構成します。

タスク 1: Azure Load Testing をデプロイする

このタスクでは、Azure Load Testing リソースを Azure サブスクリプションにデプロイします。

Azure Portal (https://portal.azure.com) から、[Azure リソースの作成] に移動します。
[Search Services and marketplace] (サービスとマーケットプレースの検索) 検索フィールドに「Azure Load Testing」と入力します。
検索結果から (Microsoft が公開した) [Azure Load Testing] を選びます。
[Azure Load Testing] ページの [作成] をクリックしてデプロイプロセスを開始します。
[Create a Load Testing Resource] (Load Testing リソースの作成) ページで、リソースのデプロイに必要な詳細を指定します。
- サブスクリプション: Azure サブスクリプションを選びます
- リソースグループ: 前の演習で Web App Service のデプロイに使ったリソースグループを選びます
- 名前: eShopOnWebLoadTesting
- リージョン: 自分の地域に近いリージョンを選びます
注: Azure Load Testing サービスは、すべての Azure リージョンで使用できるわけではありません。
[確認および作成] をクリックして設定を検証します。
[作成] をクリックして確定し、Azure Load Testing リソースをデプロイします。
[デプロイが進行中です] ページに切り替わります。デプロイが正常に完了するまで数分待ちます。
デプロイの進行状況ページから [リソースに移動] をクリックして、eShopOnWebLoadTesting Azure Load Testing リソースに移動します。

注: Azure Load Testing リソースのデプロイ中にブレードを閉じたり、Azure Portal を閉じたりした場合は、Azure Portal の検索フィールド、リソース、リソースの最近のリストからもう一度見つけることができます。

タスク 2: Azure Load Testing テストを作成する

このタスクでは、さまざまな負荷構成設定を使って、さまざまな Azure Load Testing テストを作成します。

eShopOnWebLoadTesting Azure Load Testing リソースブレード内から、[テスト] に移動します。 [+ 作成] メニューオプションをクリックして、[Create a URL-based test] (URL ベースのテストの作成) を選びます。
ロードテストを作成するには、次のパラメーターと設定を完了します。
- [Test URL] (テストの URL): 前の演習でデプロイした Azure App Service の URL を https:// を含めて入力します (az400eshoponweb…azurewebsites.net)
- Specify Load (負荷の指定) : 仮想ユーザー
- Number of Virtual Users (仮想ユーザーの数) : 50
- [Test Duration (minutes)] (テストの継続時間 (分)): 5
- [Ramp-up time (minutes)] (ランプアップ時間 (分)): 1
[確認と作成] をクリックして、テストの構成を確認します (他のタブは変更しないでください)。もう一度 [作成] をクリックします。
これにより、Load Testing のテストが開始され、テストが 5 分間実行されます。
テストを実行した状態で eShopOnWebLoadTesting Azure Load Testing リソースページに戻り、[テスト] に移動して [テスト] を選び、テスト Get_eshoponweb… を確認します
上部のメニューから [作成]、[Create a URL-based test] (URL ベースのテストの作成) の順にクリックして、2 つ目のロードテストを作成します。
もう 1 つのロードテストを作成するには、次のパラメーターと設定を完了します。
- [Test URL] (テストの URL): 前の演習でデプロイした Azure App Service の URL を https:// を含めて入力します (eShopOnWeb…azurewebsites.net)
- Specify Load (負荷の指定) : 1 秒あたりの要求数 (RPS)
- Requests per second (RPS) (1 秒あたりの要求数 (RPS)) : 100
- Response time (milliseconds) (応答時間 (ミリ秒)) : 500
- [Test Duration (minutes)] (テストの継続時間 (分)): 5
- [Ramp-up time (minutes)] (ランプアップ時間 (分)): 1
[確認と作成] をクリックしてテストの構成を確認し、[作成] をもう一度クリックします。
テストが約 5 分間実行されます。

タスク 3: Azure Load Testing の結果を検証する

このタスクでは、Azure Load Testing TestRun の結果を検証します。

両方のクイックテストが完了したら、それらにいくつか変更を加え、結果を検証しましょう。

Azure Load Testing から [テスト] に移動します。いずれかのテスト定義を選び、テストの 1 つをクリックして、より詳細なビューを開きます。これにより、より詳細なテストページにリダイレクトされます。ここで、結果の一覧から TestRun_mm/dd/yyh-hh:hh を選ぶことで、実際の実行の詳細を確認できます。
詳細な TestRun ページから、Azure Load Testing シミュレーションの実際の結果を特定します。値の一部を次に示します。
- 負荷と合計要求数
- Duration
- 応答時間 (90 パーセンタイルの応答時間を反映した結果を秒単位で示します。これは、要求の 90% について、応答時間が所定の結果の範囲内になることを意味します)
- 1 秒あたりの要求数のスループット
以下に、これらの値のいくつかをダッシュボードのグラフの折れ線とグラフビューを使って表します。
数分かけて両方のシミュレートテストの結果を相互に比較します。また、より多くのユーザーが App Service のパフォーマンスに与える影響を特定します。

演習 2:Azure Pipelines で CI/CD を使用してロードテストを自動化する

CI/CD パイプラインにロードテスト追加して、Azure Load Testing でのロードテストの自動化を開始します。 Azure portal でロードテストを実行した後、構成ファイルをエクスポートし、Azure Pipelines で CI/CD パイプラインを構成します (GitHub Actions 用に対して機能があります)。

この演習を完了すると、Azure Load Testing でロードテストを実行するように構成された CI/CD ワークフローが作成されます。

タスク 1: ADO サービス接続の詳細を特定する

このタスクでは、Azure DevOps Service Connection のサービスプリンシパルに必要なアクセス許可を付与します。

Azure DevOps Portal (https://dev.azure.com) から eShopOnWeb プロジェクトに移動します。
左下隅にある [プロジェクトの設定] を選びます。
[パイプライン] セクションで、 [サービス接続] を選びます。
[サービス接続] には、このラボ演習の開始時に Azure リソースのデプロイに使った Azure サブスクリプションの名前が含まれていることに注目してください。
[サービス接続] を選びます。 [概要] タブから [詳細] に移動し、 [サービスプリンシパルの管理] を選びます。
これで Azure Portal にリダイレクトされ、ID オブジェクトのサービスプリンシパルの詳細が開きます。
[表示名] の値 (Name_of_ADO_Organization_eShopOnWeb_-b86d9ae1-7552-4b75-a1e0-27fb2ea7f9f4 のような形式です) をコピーしておきます。これは次の手順で必要になります。

タスク 2: サービスプリンシパルのアクセス許可を付与する

Azure Load Testing では、Azure RBAC を使用して、ロードテストリソースで特定のアクティビティを実行するためのアクセス許可を付与します。 CI/CD パイプラインからロードテストを実行するには、ロードテスト共同作成者ロールをサービスプリンシパルに付与します。

Azure portal で Azure Load Testing リソースに移動します。
[アクセス制御 (IAM)] > [追加] > [ロールの割り当ての追加] の順に選びます。
[ロール] タブのジョブ関数ロールの一覧で [ロードテスト共同作成者] を選びます。
[メンバー] タブで [メンバーの選択] を選び、先ほどコピーした表示名を使ってサービスプリンシパルを検索します。
サービスプリンシパルを選び、 [選択] を選びます。
[確認と割り当て] タブで、[確認と割り当て] を選択してロールの割り当てを追加します。

Azure Pipelines ワークフロー定義でサービス接続を使用して、Azure ロードテストリソースにアクセスできるようになりました。

タスク 3:ロードテスト入力ファイルをエクスポートし、Azure Repos にインポートする

CI/CD ワークフローで Azure Load Testing を使用してロードテストを実行するには、ロードテスト構成設定と入力ファイルをソース管理リポジトリに追加する必要があります。既存のロードテストがある場合は、構成設定とすべての入力ファイルを Azure portal からダウンロードできます。

次の手順を実行して、Azure portal の既存のロードテスト用の入力ファイルをダウンロードします。

Azure portal で Azure Load Testing リソースに移動します。
左側のペインで [テスト] を選んでロードテストの一覧を表示し、対象のテストを選びます。
使っているテストの実行の横にある省略記号 ( … ) を選び、 [Download input file] (入力ファイルのダウンロード) を選びます。
ブラウザーは、ロードテスト入力ファイルを含む zip 形式のフォルダーをダウンロードします。
任意の zip ツールを使用して、入力ファイルを抽出します。このフォルダーには次のファイルが格納されています。
- config.yaml: ロードテストの YAML 構成ファイル。このファイルは、CI/CD ワークフロー定義で参照します。
- quick_test.jmx: JMeter テストスクリプト
抽出されたすべての入力ファイルをソース管理リポジトリにコミットします。これを行うには、Azure DevOps Portal (https://dev.azure.com) に移動し、eShopOnWeb DevOps プロジェクトに移動します。
[リポジトリ] を選びます。ソースコードフォルダー構造の tests サブフォルダーを選びます。省略記号 (…) を選び、 [新規作成] > [フォルダー] を選びます。
フォルダー名として jmeter、ファイル名として placeholder.txt を指定します (注: フォルダーを空として作成することはできません)
[コミット] をクリックして、プレースホルダーファイルと jmeter フォルダーの作成を確認します。
[フォルダー構造] から、新しく作成された jmeter サブフォルダーに移動します。 省略記号 (…) をクリックし、 [ファイルのアップロード] を選びます。
[参照] オプションを使って、抽出した zip ファイルの場所に移動し、config.yaml と quick_test.jmx の両方を選びます。
[コミット] をクリックして、ソース管理へのファイルのアップロードを確認します。

タスク 4: CI/CD ワークフロー YAML 定義ファイルを更新する

このタスクでは、Azure Load Testing - Azure DevOps Marketplace 拡張機能をインポートし、AzureLoadTest タスクを使って既存の CI/CD パイプラインを更新します。

ロードテストを作成して実行するために、Azure Pipelines ワークフロー定義には Azure DevOps Marketplace の Azure Load Testing タスク拡張機能が使われます。 Azure DevOps Marketplace で Azure Load Testing タスク拡張機能を開き、[Get it free] (無料で入手) を選択します。
Azure DevOps 組織を選択し、[インストール] を選択して拡張機能をインストールします。
Azure DevOps Portal と [プロジェクト] 内から [パイプライン] に移動し、この演習の開始時に作成したパイプラインを選びます。編集をクリックします。
YAML スクリプトで行 56 に移動し、Enter/Return キーを押して新しい空行を追加します (これは YAML ファイルのデプロイステージの直前です)。
57 行目で、右側にある [タスクアシスタント] を選び、Azure Load Testing を検索します。
シナリオの正しい設定を使ってグラフィカルペインを完了します。
- Azure サブスクリプション: Azure リソースを実行するサブスクリプションを選びます
- ロードテストファイル: ‘$(Build.SourcesDirectory)/tests/jmeter/config.yaml’
- ロードテストリソースグループ: Azure Load Testing リソースを保持するリソースグループ
- ロードテストリソース名: ESHopOnWebLoadTesting
- ロードテストの実行名: ado_run
- ロードテストの実行の説明: ADO からのロードテスト
[追加] をクリックして YAML のスニペットとしてパラメーターの挿入を確認します
YAML スニペットのインデントでエラー (赤い波線) が発生している場合は、スニペットを正しく配置するために 2 つのスペースまたはタブを追加して修正します。

次のサンプルスニペットは、YAML コードがどのようになるかを示しています

      - task: AzureLoadTest@1
       inputs:
         azureSubscription: 'AZURE DEMO SUBSCRIPTION(b86d9ae1-1234-4b75-a8e7-27fb2ea7f9f4)'
         loadTestConfigFile: '$(Build.SourcesDirectory)/tests/jmeter/config.yaml'
         resourceGroup: 'az400m05l11-RG'
         loadTestResource: 'eShopOnWebLoadTesting'
         loadTestRunName: 'ado_run'
         loadTestRunDescription: 'load testing from ADO'

挿入された YAML スニペットの下に、Enter/Return キーを押して新しい空行を追加します。
この空行の下に、パイプライン実行中の Azure Load Testing タスクの結果を表示する発行タスクのスニペットを追加します。
```
     - publish: $(System.DefaultWorkingDirectory)/loadTest
       artifact: loadTestResults
```
YAML スニペットのインデントでエラー (赤い波線) が発生している場合は、スニペットを正しく配置するために 2 つのスペースまたはタブを追加して修正します。
両方のスニペットが CI/CD パイプラインに追加されたら、変更を [保存] します。
保存したら、 [実行] をクリックしてパイプラインをトリガーします。
ブランチ (main) を確認し、 [実行] ボタンをクリックしてパイプラインの実行を開始します。
パイプラインの状態ページで [ビルド] ステージをクリックし、パイプライン内の異なるタスクの詳細ログを開きます。
パイプラインがビルドステージをキックオフし、パイプラインのフロー内の AzureLoadTest タスクに到達するまで待ちます。
タスクが実行されている間に、Azure Portal で Azure Load Testing を参照して、パイプラインによって adoloadtest1 という新しい RunTest がどのように作成されるかを確認します。これを選ぶと、TestRun ジョブの結果値が表示されます。

Azure DevOps CI/CD のパイプライン実行ビューに戻ります。AzureLoadTest タスクは正常に完了しています。詳細ログの出力から、ロードテストの結果の値も表示されます。

 Task         : Azure Load Testing
 Description  : Automate performance regression testing with Azure Load Testing
 Version      : 1.2.30
 Author       : Microsoft Corporation
 Help         : https://docs.microsoft.com/azure/load-testing/tutorial-cicd-azure-pipelines#azure-load-testing-task
 ==============================================================================
 Test '0d295119-12d0-482d-94be-a7b84787c004' already exists
 Uploaded test plan for the test
 Creating and running a testRun for the test
 View the load test run in progress at: https://portal.azure.com/#blade/Microsoft_Azure_CloudNativeTesting/NewReport//resourceId/%2fsubscriptions%4b75-a1e0-27fb2ea7f9f4%2fresourcegroups%2faz400m05l11-rg%2fproviders%2fmicrosoft.loadtestservice%2floadtests%2feshoponwebloadtesting/testId/0d295119-12d0-787c004/testRunId/161046f1-d2d3-46f7-9d2b-c8a09478ce4c
 TestRun completed
    
 -------------------Summary ---------------
 TestRun start time: Mon Jul 24 2023 21:46:26 GMT+0000 (Coordinated Universal Time)
 TestRun end time: Mon Jul 24 2023 21:51:50 GMT+0000 (Coordinated Universal Time)
 Virtual Users: 50
 TestStatus: DONE
    
 ------------------Client-side metrics------------
    
 Homepage
 response time        : avg=1359ms min=59ms med=539ms max=16629ms p(90)=3127ms p(95)=5478ms p(99)=13878ms
 requests per sec     : avg=37
 total requests       : 4500
 total errors         : 0
 total error rate     : 0
 Finishing: AzureLoadTest

パイプライン実行の一環として自動ロードテストが実行されました。最後のタスクでは、失敗の条件を指定します。つまり、Web アプリのパフォーマンスが一定のしきい値を下回っている場合、デプロイステージの開始は許可されません。

タスク 5: ロードテストパイプラインに失敗と成功の条件を追加する

このタスクでは、ロードテストの失敗条件を使って、アプリケーションが品質要件を満たさない場合にアラートを受け取ります (結果として失敗したパイプラインが実行されます)。

Azure DevOps から eShopOnWeb プロジェクトに移動し、[リポジトリ] を開きます。
[リポジトリ] 内で、先ほど作成し、使った /tests/jmeter サブフォルダーに移動します。
Load Testing の *config.yaml** ファイルを開きます。 [編集] をクリックすると、ファイルを編集できます。

failureCriteria: [] を次のコードスニペットに置き換えます。

 failureCriteria:
   - avg(response_time_ms) > 300
   - percentage(error) > 50

[コミット] と [コミット] をもう一度クリックして、config.yaml への変更を保存します。
[パイプライン] に戻り、eShopOnWeb パイプラインをもう一度実行します。数分後、AzureLoadTest タスクの失敗した状態で実行が完了します。

パイプラインの詳細ログビューを開き、AzureLoadtest の詳細を検証します。同様の出力例を次に示します。

 Creating and running a testRun for the test
 View the load test run in progress at: https://portal.azure.com/#blade/Microsoft_Azure_CloudNativeTesting/NewReport//resourceId/%2fsubscriptions%2fb86d9ae1-7552-47fb2ea7f9f4%2fresourcegroups%2faz400m05l11-rg%2fproviders%2fmicrosoft.loadtestservice%2floadtests%2feshoponwebloadtesting/testId/0d295119-12d0-a7b84787c004/testRunId/f4bec76a-8b49-44ee-a388-12af34f0d4ec
 TestRun completed
    
 -------------------Summary ---------------
 TestRun start time: Mon Jul 24 2023 23:00:31 GMT+0000 (Coordinated Universal Time)
 TestRun end time: Mon Jul 24 2023 23:06:02 GMT+0000 (Coordinated Universal Time)
 Virtual Users: 50
 TestStatus: DONE
    
 -------------------Test Criteria ---------------
 Results          :1 Pass 1 Fail
    
 Criteria                     :Actual Value        Result
 avg(response_time_ms) > 300                       1355.29               FAILED
 percentage(error) > 50                                                  PASSED
    
    
 ------------------Client-side metrics------------
    
 Homepage
 response time        : avg=1355ms min=58ms med=666ms max=16524ms p(90)=2472ms p(95)=5819ms p(99)=13657ms
 requests per sec     : avg=37
 total requests       : 4531
 total errors         : 0
 total error rate     : 0
 ##[error]TestResult: FAILED
 Finishing: AzureLoadTest

ロードテスト出力の最後の行に ##[error]TestResult: FAILED という出力があることに注目してください。平均応答時間が > 300 であるか、エラーの割合が > 20 という FailCriteria を定義したので、300 を超える平均応答時間が表示されると、タスクは失敗としてフラグが付けられます。

注: App Service のパフォーマンスを検証するという実際のシナリオを想像してください。パフォーマンスが一定のしきい値を下回る場合 (通常は Web アプリの負荷が高いことを意味します)、追加の Azure App Service への新しいデプロイをトリガーできます。 Azure ラボ環境では応答時間を制御できないため、失敗を保証するロジックに元に戻すことにしました。
パイプラインタスクの失敗状態は、実際には Azure Load Testing の要件条件の検証の成功を反映しています。

演習 3:Azure ラボリソースを削除する

この演習では、このラボでプロビジョニングした Azure リソースを削除し、予期しない料金を排除します。

注:新規に作成し、使用しなくなったすべての Azure リソースを削除することを忘れないでください。使用していないリソースを削除することで、予期しない料金が発生しなくなります。

タスク 1:Azure ラボリソースを削除する

このタスクでは、Azure Cloud Shell を使用して、このラボでプロビジョニングされた Azure リソースを削除し、不要な料金を排除します。

Azure portal で、Cloud Shell ウィンドウ内で Bash シェルセッションを開きます。
次のコマンドを実行して、このモジュールのラボ全体で作成したすべてのリソースグループのリストを表示します。
```
 az group list --query "[?starts_with(name,'az400m09l16')].name" --output tsv
```
次のコマンドを実行して、このモジュールのラボ全体を通して作成したすべてのリソースグループを削除します。
```
 az group list --query "[?starts_with(name,'az400m09l16')].[name]" --output tsv | xargs -L1 bash -c 'az group delete --name $0 --no-wait --yes'
```
注:コマンドは非同期に実行されるので (–nowait パラメーターで決定される)、同じ Bash セッション内ですぐに別の Azure CLI コマンドを実行できますが、リソースグループが実際に削除されるまでに数分かかります。

確認

この演習では、Azure Pipelines を使って Azure App Service に Web アプリをデプロイし、TestRuns を使って Azure Load Testing Resource をデプロイしました。次に、JMeter ロードテストの config.yaml ファイルを Azure Repos ソース管理に統合し、Azure Load Testing を使って CI/CD パイプラインを拡張しました。最後の演習では、LoadTest の成功条件を定義する方法を学習しました。

Azure Load Testing を使ったアプリケーション パフォーマンスの監視

受講生用ラボ マニュアル