次の方法で共有


Azure App Service アプリケーションのロード テスト

この記事では、Azure Load Testing を使用して、Azure App Service にホストされたアプリケーションをテストする方法について説明します。 Azure App Service は、クラウドで Web アプリケーションと API を構築、デプロイ、スケーリングできるフル マネージド サービスです。

Azure Load Testing を使用すると、アプリケーションとサービスへの実際の大規模なトラフィックをシミュレートできます。 Azure App Service は自動でのスケーリングに対応していますが、Azure Load Testing を使用してロード テストを実行すると、信頼性、パフォーマンスの向上とコストの最適化に加えて、次のことを実現できます。

  • Web アプリケーションだけでなく、すべてのアプリケーション コンポーネントで予想される負荷を処理できることを確認します。

  • アプリケーションがパフォーマンスと安定性の要件を満たしていることを確認します。

  • アプリケーション リソースのメトリックと診断を使用して、アプリケーション全体のパフォーマンスのボトルネックを特定します。

  • コンピューティング リソースの過剰な割り当てを回避し、コストの非効率性を削減します。

  • CI/CD パイプラインにロード テストを統合し、テストの失敗条件を指定することで、パフォーマンスの低下を早期に検出します。

ロード テストによるトラフィックのシミュレーション

ロード テストを作成して、Azure App Service でアプリケーションへのトラフィックをシミュレートできます。 Azure Load Testing には、ロード テストを作成するための 2 つのオプションがあります。

  • URL ベースのクイック テストを作成する
  • Apache JMeter スクリプト (JMX ファイル) を使用する

ロード テストを作成して実行した後、Web アプリケーションと依存するすべての Azure コンポーネントのリソース メトリックを監視して、パフォーマンスとスケーラビリティの問題を特定できます。

URL ベースのロード テストを作成する

URL ベースのロード テストを、Azure portal の Azure App Service Web アプリから直接作成できます。 ロード テストを作成するときは、特定のデプロイ スロットを選択し、事前入力されたエンドポイント URL を使用できます。

次のスクリーンショットは、Azure portal で URL ベースのロード テストを作成する方法を示しています。

Azure App Service の URL ベースのロード テストを作成することから始めます。

JMeter スクリプトをアップロードすることでロード テストを作成する

Azure Load Testing では、JMeter の高忠実度サポートが提供されます。 Apache JMeter スクリプトをアップロードすることで新しいロード テストを作成できます。 このアプローチは次のシナリオで使用できます。

  • 1 つのテストで複数のページまたはエンドポイントをテストする
  • 認証されたエンドポイントをテストする
  • 環境変数やシークレットなどのパラメーターをロード テストに渡す
  • データベース接続など、HTTP ベース以外のエンドポイントをテストする
  • より高度な負荷パターンを構成する
  • 既存の JMeter スクリプトを再利用する

JMeter スクリプトをアップロードしてロード テストの作成を開始します。

以前に URL ベースのテストを作成した場合、Azure Load Testing によって JMeter テスト スクリプトが生成されます。 生成されたこのテスト スクリプトをダウンロードし、変更または拡張してから、スクリプトを再アップロードできます。

ボトルネックやプロビジョニングの問題がないかアプリを監視する

ロード テストでは、Azure Load Testing によってテストの実行に関するメトリックが収集されます。

  • クライアント側のメトリック: エンド ツー エンドの応答時間、1 秒あたりの要求数、エラーの割合などのテスト エンジン メトリック。 これらのメトリックでは、アプリケーションがシミュレートされたユーザー負荷をサポートできるかどうかが全体的に示されます。

  • サーバー側のメトリック: App Service プランの CPU 使用率、HTTP 応答コード、データベース リソース使用率など、Azure アプリケーション コンポーネントのリソース メトリック。

Azure Load Testing ダッシュボードを使用して、テスト実行メトリックを分析し、アプリケーションのパフォーマンスのボトルネックを特定するか、一部のコンピューティング リソースを過剰にプロビジョニングしたかどうかを確認します。 たとえば、サービス プラン インスタンスがワークロードに適したサイズであるかどうかを評価できます。

Azure portal の [ロード テストの結果] ダッシュボードを示すスクリーンショット。

Azure Load Testing でサーバー側のメトリックを監視する方法についてご覧ください。

Azure App Service でホストされているアプリケーションの場合は、App Service 診断を使用して、アプリケーションのパフォーマンスと正常性に関する追加の分析情報を取得できます。 ロード テスト構成に App Service アプリケーション コンポーネントを追加すると、ロード テスト ダッシュボードには、App Service リソースの App Service 診断ダッシュボードへの直接リンクが表示されます。

Azure portal のロード テスト ダッシュボードの 'App Service' セクションを示すスクリーンショット。

ロード テストの失敗条件をカスタマイズする

テストの失敗条件を使用すると、ロード テストのクライアント側のメトリックの条件を構成できます。 ロード テストの実行がこれらの条件を満たしていない場合、テストは失敗したと見なされます。 ロード テストの失敗条件の構成を開始します。

たとえば、要求の平均応答時間、または失敗した要求の割合が、指定したしきい値を超えていることを指定できます。 クイック テストであるのか JMeter スクリプトをアップロードしたのかに関係なく、いつでもロード テストに失敗条件を追加できます。

CI/CD パイプラインの一部としてロード テストを実行する場合は、テストの失敗条件を使用して、アプリケーション ビルドでパフォーマンスの低下を特定できます。

Azure portal のロード テストの [テスト条件] ページを示すスクリーンショット。

パラメーターを使用してデプロイ スロット間でテストする

ロード テストを構成するときに、環境変数またはシークレットをロード テスト スクリプトに渡すパラメーターを指定できます。 これらのパラメーターを使用すると、テスト スクリプトを再利用および再構成できるようになります。 パラメーターを使用して環境変数をロード テストに渡す方法についてご覧ください。

1 つの例は、環境変数としてパラメーターを使用することです。これにより、アプリケーション エンドポイント URL がテスト スクリプトに格納されるのを防ぐことができます。 環境変数を使用して、他の構成設定を JMeter テスト スクリプトに渡すこともできます。 たとえば、仮想ユーザーの数や CSV 入力ファイルのファイル名をテスト スクリプトに渡すことができます。

パラメーターのもう 1 つの使用例は、複数の Azure App Service デプロイ スロット間でテスト スクリプトを再利用したい場合です。 デプロイ スロットは、固有のホスト名と別個の URL を持つライブ アプリです。 アプリケーション エンドポイントにパラメーターを使用することで、アプリケーション用のステージング環境を設定できます。

Azure portal のクイック テストの [パラメーター] ページを示すスクリーンショット。ターゲット URL のパラメーターが強調表示されています。

次のステップ

具体的には、次の方法を学習します。