チュートリアル: CI/CD でのロード テスト自動化によってパフォーマンスの低下を特定する

このチュートリアルでは、Azure Load Testing プレビューと CI/CD ツールを使用して、パフォーマンスの低下をすばやく特定する方法について説明します。 Azure Pipelines または GitHub Actions でロード テストを実行すると、負荷がかかった状態でアプリケーションのパフォーマンスがいつ低下したかをすばやく特定できます。

このチュートリアルでは、Azure 上でサンプル アプリケーションのロード テストを実行する CI/CD パイプラインを設定します。 負荷がかかった状態にあるアプリケーションの動作を CI/CD ダッシュボードから直接確認します。 その後、ロード テストの失敗条件を使用して、アプリケーションが品質要件を満たしていない場合にアラートを受け取ります。

このチュートリアルでは、サンプルの Node.js アプリケーションと JMeter スクリプトを使用します。 このチュートリアルでは、コーディングや Apache JMeter のスキルは必要ありません。

学習内容は次のとおりです。

  • サンプル アプリケーションの GitHub リポジトリを設定する。
  • CI/CD ワークフローのサービス認証を構成する。
  • ロード テストを実行するように CI/CD ワークフローを構成する。
  • CI/CD ダッシュボードでロード テスト結果を表示する。
  • ロード テストの失敗条件を定義して、パフォーマンスの低下を識別する。

Note

プライベート プロジェクト用に Microsoft がホストするエージェントで実行されるジョブは、Azure Pipelines では 60 分でタイムアウトとなります。 ロード テストを 60 分よりも長い時間実行する場合、追加容量の料金を支払う必要があります。 これを行っていない場合、パイプラインはテスト結果を待たずにタイムアウトとなります。 Azure portal でロード テストの状態を確認できます。

重要

Azure Load Testing は、現在、プレビューの段階です。 ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用される法律条項については、「Microsoft Azure プレビューの追加使用条件」を参照してください。

前提条件

  • アクティブなサブスクリプションが含まれる Azure アカウント。 Azure サブスクリプションをお持ちでない場合は、開始する前に 無料アカウント を作成してください。
  • Azure Pipelines を使用している場合は、Azure DevOps の組織とプロジェクト。 Azure DevOps 組織がない場合は、無料で作成できます。 Azure Pipelines で作業を開始するときに支援が必要な場合は、「最初のパイプラインの作成」を参照してください。
  • リポジトリを作成できる GitHub アカウント。 アカウントをお持ちでない場合は、無料で作成することができます。

サンプル アプリケーション リポジトリを設定する

このチュートリアルを開始するには、まずサンプルの Node.js Web アプリケーションを設定する必要があります。 このサンプル アプリケーションには、Azure にこのアプリケーションをデプロイしてロード テストをトリガーする Azure Pipelines 定義が含まれています。

  1. ブラウザーを開き、サンプル アプリケーションのソース GitHub リポジトリにアクセスします。

    サンプル アプリケーションは、Azure App Service Web コンポーネントと Azure Cosmos DB データベースで構成される Node.js アプリです。

  2. [フォーク] を選択して、サンプル アプリケーションのリポジトリを自分の GitHub アカウントにフォークします。

    サンプル アプリケーションの GitHub リポジトリをフォークするボタンを示すスクリーンショット。

サンプル アプリケーションのリポジトリには SampleApp.jmx という名前の Apache JMeter スクリプトが含まれています。 このスクリプトは、次のようにサンプル アプリケーションで 3 つの API をテストします。

  • add: Azure Cosmos DB で挿入を実行して、Web アプリの訪問者の数を格納します。
  • get: Azure Cosmos DB で読み取り操作を実行して、訪問者の数を取得します。
  • lasttimestamp: 前回のユーザー アクセスのメモリ内タイム スタンプを更新します。

サービス認証を構成する

ロード テストを実行するように CI/CD パイプラインを構成する前に、Azure ロード テスト リソースにアクセスするためのアクセス許可を CI/CD ワークフローに付与します。

Azure Pipelines ワークフローから Azure Load Testing リソースにアクセスするには、まず Azure DevOps プロジェクトでサービス接続を作成します。 サービス接続により、Azure Active Directory のサービス プリンシパルが作成されます。 このサービス プリンシパルは、Azure Active Directory の Azure Pipelines ワークフローを表します。

次に、このサービス プリンシパルにアクセス許可を付与して、Azure Load Testing リソースでのロード テストを作成して実行します。

Azure Pipelines でサービス接続を作成する

CI/CD ワークフローから Azure サブスクリプションへのアクセスができるように、Azure Pipelines でサービス接続を作成します。 次の手順では、ロード テストを作成して実行するためのアクセス許可を付与します。

  1. Azure DevOps 組織 (https://dev.azure.com/<your-organization>) にサインインし、プロジェクトを選択します。

  2. [プロジェクトの設定]>[サービス接続] を選択します。

  3. [+ 新しいサービス接続] を選択し、[Azure Resource Manager] サービス接続を選択し、[次へ] を選択します。

  4. [サービス プリンシパル (自動)] 認証方法を選択し、[次へ] を選択します。

  5. サービス接続情報を入力し、[保存] を選択してサービス接続を作成します。

    フィールド
    スコープのレベル [サブスクリプション]
    サブスクリプション ロード テスト リソースをホストする Azure サブスクリプションを選択します。
    リソース グループ 空のままにします。 パイプラインによって、Azure Load Testing リソースの新しいリソース グループが作成されます。
    サービス接続名 サービス接続の一意の名前を入力します。 この名前は、後でパイプライン定義を構成するために使用します。
    すべてのパイプラインへのアクセス許可を与える オン。
  6. 作成したサービス接続を一覧から選び、[サービス プリンシパルの管理] を選択します。

    サービス プリンシパルを管理するための選択を示すスクリーンショット。

  7. Azure portal で、[アプリケーション (クライアント) ID] の値をコピーします。

Azure Cloud Shell を起動する

Azure Cloud Shell は無料のインタラクティブ シェルです。この記事の手順は、Azure Cloud Shell を使って実行することができます。 一般的な Azure ツールが事前にインストールされており、アカウントで使用できるように構成されています。

Cloud Shell を開くには、コード ブロックの右上隅にある [使ってみる] を選択します。 https://shell.azure.com に移動して、別のブラウザー タブで Cloud Shell を起動することもできます。

Cloud Shell が開いたら、お使いの環境に対して Bash が選択されていることを確認します。 後続のセッションでは、Bash 環境で Azure CLI を使用します。[コピー] を選択してコードのブロックをコピーし、Cloud Shell に貼り付けます。その後、Enter キーを押してそれを実行します。

Azure へのサインイン

Cloud Shell は、サインインした最初のアカウントで自動的に認証されます。 別のサブスクリプションを使用してサインインするには、次のスクリプトを使用し、<Subscription ID> をご使用の Azure サブスクリプション ID に置き換えます。 Azure サブスクリプションをお持ちでない場合は、開始する前に Azure 無料アカウントを作成してください。

subscription="<subscriptionId>" # add subscription here

az account set -s $subscription # ...or use 'az login'

詳細については、アクティブなサブスクリプションの設定または対話形式のログインに関する記事を参照してください

Azure Load Testing へのアクセスを許可する

Azure Load Testing リソースへのアクセスを許可するために、ロード テストの共同作成者ロールをサービス プリンシパルに割り当てます。 このロールにより、Azure Load Testing サービスでロード テストを作成して実行するためのアクセス許可がサービス プリンシパルに付与されます。 Azure Load Testing でのユーザーとロールの管理について詳しくは、こちらを参照してください。

  1. Azure CLI を使用してサービス プリンシパル オブジェクトの ID を取得します。 テキスト プレースホルダー <application-client-id> は、コピーした値に置き換えます。

    object_id=$(az ad sp show --id "<application-client-id>" --query "id" -o tsv)
    echo $object_id
    
  2. サービス プリンシパルに Load Test Contributor ロールを割り当てます。

    subscription=$(az account show --query "id" -o tsv)
    echo $subscription
    
    az role assignment create --assignee $object_id \
        --role "Load Test Contributor" \
        --scope /subscriptions/$subscription \
        --subscription $subscription
    

ロード テストを実行するように CI/CD ワークフローを構成する

次に、CI/CD ワークフローを作成し、サンプル アプリケーションのロード テストを作成して実行します。 サンプル アプリケーション リポジトリには、CI/CD ワークフロー定義が既に含まれています。それは、最初にアプリケーションを Azure にデプロイし、次に JMeter テスト スクリプト (SampleApp.jmx) に基づいてロード テストを作成するというものです。 サンプル ワークフロー定義ファイルを更新して、Azure サブスクリプションとアプリケーションの詳細を指定します。

最初の CI/CD ワークフロー実行では、Azure Resource Manager (ARM) テンプレート ARMTemplate/template.json を使用して、Azure サブスクリプションに新しい Azure Load Testing リソースが作成されます。 ARM テンプレートの詳細を確認します。

サンプル アプリケーション リポジトリのフォークにリンクされた新しい Azure パイプラインを作成します。 このリポジトリには、以下が含まれます。

  • サンプル アプリケーションのソース コード。
  • azure-pipelines.yml というパイプライン定義ファイル。
  • SampleApp.jmx という JMeter テスト スクリプト。
  • SampleApp.yaml という Azure Load Testing 構成ファイル。

ロード テストを作成して実行するために、Azure Pipelines 定義では Azure DevOps Marketplace の Azure Load Testing タスク拡張機能が使用されます。

  1. Azure DevOps Marketplace で Azure Load Testing タスク拡張機能を開き、[Get it free] (無料で入手) を選択します。

  2. Azure DevOps 組織を選択し、[インストール] を選択して拡張機能をインストールします。

    選択した Azure DevOps 組織の管理者特権がない場合は、[要求] を選択して、管理者に拡張機能のインストールを依頼します。

  3. 対象の Azure DevOps プロジェクトで、左側のナビゲーションから [パイプライン] を選択し、次に [パイプラインを作成] を選択します。

  4. [Connect] タブで [GitHub] を選択します。

  5. [Authorize Azure Pipelines](Azure Pipelines を承認する) を選択して、Azure Pipelines がワークフローをトリガーするために GitHub アカウントにアクセスできるようにします。

  6. [選択] タブで、サンプル アプリケーションのフォークされたリポジトリを選択します。

    サンプル アプリケーションの GitHub リポジトリを選択する方法を示すスクリーンショット。

    Azure Pipelines により、azure-pipelines.yml パイプライン定義ファイルが自動的に検出されます。

  7. パイプライン定義には、2 つのタスクがある LoadTest ステージが含まれていることに注意してください。

    AzureResourceManagerTemplateDeployment タスクで Azure サブスクリプションに新しい Azure ロード テスト リソースをデプロイします。

    次に、Azure Load Testing タスクAzureLoadTest でロード テストが作成され、開始されます。 このタスクでは、SampleApp.yamlロード テスト構成ファイルを使用します。これには、ロード テストの構成パラメーター (並列テスト エンジンの数など) が含まれています。

    - task: AzureLoadTest@1
      inputs:
        azureSubscription: $(serviceConnection)
        loadTestConfigFile: 'SampleApp.yaml'
        resourceGroup: $(loadTestResourceGroup)
        loadTestResource: $(loadTestResource)
        env: |
          [
            {
            "name": "webapp",
            "value": "$(webAppName).azurewebsites.net"
            }
          ]
    

    ロード テストが既に存在する場合、AzureLoadTest タスクで新しいロード テストは作成せず、このロード テストにテストの実行を追加します。 時間の経過に伴う回帰を特定するために、複数のテストの実行を比較できます。

  8. [確認] タブで、パイプライン定義の先頭にある次のプレースホルダー テキストを置き換えます。

    これらの変数は、サンプル アプリケーションのデプロイを構成し、ロード テストを作成するために使用されます。

    プレースホルダー
    <Name of your webapp> Azure App Service Web アプリの名前。
    <Name of your webARM Service connection> 前のセクションで作成したサービス接続の名前。
    <Azure subscriptionId> Azure のサブスクリプション ID。
    <Name of your load test resource> Azure Load Testing リソースの名前。
    <Name of your load test resource group> Azure Load Testing リソースを含むリソース グループの名前。

    パイプライン作成時の Azure Pipelines の [Review]\(レビュー\) タブを示すスクリーンショット。

  9. [保存および実行] を選択し、[コミット メッセージ] にテキストを入力し、[保存および実行] を選択します。

    Azure Pipelines で CI/CD ワークフローが実行され、サンプル アプリケーションがデプロイされて、ロード テストが作成されます。

  10. 左側のナビゲーションで [パイプライン] を選択し、一覧から新しいパイプラインの実行を選択して状態を監視します。

    パイプライン ジョブを選択すると、詳細な実行ログを表示できます。

    パイプライン ジョブの詳細を表示する方法を示すスクリーンショット。

ロード テストの結果の表示

Azure Load Testing を使用すると、ロード テストの実行結果を CI/CD ワークフロー出力で直接確認できます。 CI/CD ログには、次のクライアント側メトリックが含まれています。

  • 応答時間メトリック: 平均、最小値、中央値、最大値、90-95-99 パーセンタイル。
  • 1 秒あたりの要求回数。
  • 要求の合計数。
  • エラーの総数。
  • エラー率。

さらに、ロード テストの結果ファイルをワークフロー実行の成果物として利用できます。これをダウンロードして詳細なレポートを作成できます。

  1. Azure DevOps プロジェクトで、[パイプライン] を選択し、一覧からパイプライン定義を選びます。

  2. 実行されたパイプラインを選んで、実行の概要を確認します。

    実行されたパイプラインの概要を示すスクリーンショット。

  3. [ジョブ] セクションで [ロード テスト] を選択して、パイプライン ログを表示します。

    Azure Pipelines の実行ログを示すスクリーンショット。

    ロード テストが完了したら、テストの概要情報とクライアント側のメトリックをパイプライン ログで確認できます。 このログでは、このロード テストの Azure Load Testing ダッシュボードに移動するための URL も示されます。

  4. パイプライン ログ ビューで、[ロード テスト] を選択し、[1 artifact produced](1 つの成果物が生成されました) を選択して、ロード テストの結果ファイルをダウンロードします。

    ロード テストの結果をダウンロードする方法を示すスクリーンショット。

テストの不合格の条件を定義する

Azure Load Testing を使用すると、ロード テストの失敗条件を定義できます。 これらの条件によって、ロード テストがどのような場合に合格または失敗になるかが決まります。 たとえば、平均応答時間が特定の値より長い場合や、発生したエラーが多すぎる場合、ロード テストは失敗します。

CI/CD パイプラインの一部としてロード テストを実行すると、パイプライン実行の状態にロード テストの状態が反映されます。 このアプローチを使用すると、アプリケーションの負荷が高い場合にパフォーマンスの低下やアプリケーションの動作の低下をすばやく特定できます。

このセクションでは、平均応答時間とエラー率に基づいてテストの失敗条件を構成します。

テスト構成の YAML ファイルで、Azure Load Testing のロード テストの失敗条件を指定できます。 ロード テストの失敗条件の構成について詳しくは、こちらを参照してください。

  1. サンプル アプリケーションの GitHub リポジトリのフォーク内の SampleApp.yml ファイルを編集します。

  2. ファイルの末尾に次のスニペットを追加します。

    failureCriteria: 
        - avg(response_time_ms) > 100
        - percentage(error) > 20
    

    これで、平均応答時間とエラー率に基づいて、ロード テストの失敗条件を指定できました。 次の条件のうち少なくとも 1 つが満たされている場合、テストは不合格になります。

    • 合計平均応答時間が 100 ミリ秒を超えている場合。
    • エラーの集計割合が 20% を超えている場合。
  3. 変更をコミットし、リポジトリのメイン ブランチにプッシュします。

    この変更を行うと、GitHub Actions CI/CD ワークフローがトリガーされます。

  4. テストが終了したら、CI/CD パイプラインの実行が失敗したことを確認します。

    CI/CD 出力ログで、いずれかの失敗条件が満たされたためにテストが失敗したことがわかります。 ロード テストの平均応答時間が、不合格の条件で指定したよりも大きい値でした。

    テスト条件が満たされなかった後のパイプライン ログを示すスクリーンショット。

    Azure Load Testing サービスは、テストの実行中に条件を評価します。 これらのいずれかの条件が満たされない場合、Azure Load Testing サービスはゼロ以外の終了コードを返します。 このコードは、テストで不合格になったことを CI/CD ワークフローに通知します。

  5. SampleApp.yml ファイルを編集し、テストの失敗条件を変更して、平均応答時間の基準を大きくします。

    failureCriteria: 
        - avg(response_time_ms) > 5000
        - percentage(error) > 20
    
  6. 変更をコミットして Azure Pipelines CI/CD ワークフローをもう一度トリガーします。

    テストが終了すると、ロード テストと CI/CD ワークフローが正常に完了したことがわかります。

リソースのクリーンアップ

重要

作成した Azure Load Testing リソースは、他の Azure Load Testing チュートリアルおよびハウツー記事で再利用できます。

作成したどのリソースも使用する予定がない場合は、追加の課金が発生しないように削除します。 別のリソース グループにサンプル アプリケーションをデプロイした場合は、次の手順を繰り返します。

Azure portal を使用してリソースを削除するには、次のようにします。

  1. 左上隅にあるメニュー ボタンを選択して、[リソース グループ] を選択します。

  2. 一覧から、作成したリソース グループを選択します。

  3. [リソース グループの削除] を選択します。 Azure portal でリソース グループの削除を選択する画面のスクリーンショット。

  4. リソース グループ名を入力します。 次に、 [削除] を選択します。

Azure CLI を使用してリソースを削除するには、次のコマンドを入力します。

az group delete --name <yourresourcegroup>

リソース グループを削除すると、そのグループに含まれるすべてのリソースが削除されるので注意してください。

次のステップ

これで、Azure Load Testing を使用してロード テストの実行を自動化する CI/CD ワークフローが作成されました。 ロード テストの失敗条件を使用すると、CI/CD ワークフローの状態を設定し、パフォーマンスとアプリケーションの動作の低下をすばやく特定できます。

  • サーバー側の監視を構成するについては、こちらを参照してください。
  • 複数のテスト実行間の結果の比較については、こちらを参照してください。
  • ロード テストのパラメーター化の詳細については、こちらを参照してください。
  • テストの不合格の条件を定義する方法については、こちらを参照してください。