Event Hubs と IoT Hub 用のカスタム プラグインを使用した Azure Load Testing

ソリューションのアイデア

この記事ではソリューションのアイデアについて説明します。 クラウド アーキテクトはこのガイダンスを使用すると、このアーキテクチャの一般的な実装の主要コンポーネントを視覚化しやすくなります。 ワークロードの特定の要件に適合する、適切に設計されたソリューションを設計するための出発点として、この記事を使用してください。

Azure Load Testing は、Apache JMeter スクリプトとカスタム プラグインを実行してユーザーとデバイスの動作をシミュレートできるサービスです。このソリューションでは、その使用方法についてガイダンスを提供します。 このソリューションでは、主要業績評価指標 (KPI) を設計し、Azure Functions と Azure Event Hubs を使用してサンプル アプリケーションでロード テストの結果を監視および分析するためのダッシュボードを開発する方法についても説明します。 この例では Event Hubs を使用しますが、Event Hubs クライアントを IoT Hub クライアントに変更することで、Azure IoT Hub にも同じアプローチを適用できます。 この記事では、JMeter、そのプラグインとカスタム プラグイン、Functions と Event Hubs に関する知識があることを前提としています。

IoT Hub には、パーティションを含む Event Hubs よりも多くのコア コンポーネントが含まれています。 そのため、この記事で説明するロード テストアプローチは、最小限の変更で IoT Hub にも適用されます。

建築

ロード テストを実行するには、テスト プランが必要です。これは、テスト中の JMeter の動作を取り決めた一連の手順です。 テスト計画には複数のテスト シナリオを含めることができます。また、各シナリオに異なる設定と構成を含めることができます。 たとえば、1 人のユーザーが Web アプリケーションにアクセスすることをシミュレートするシナリオと、同じアプリケーションに同時にアクセスする複数のユーザーをシミュレートするシナリオがあります。

この図は、ロード テストから Event Hubs と Azure Functions を経由して、SQL Database や Azure Digital Twins などのダウンストリーム サービスにデータがどのように流れるかを示しています。 データは Azure Monitor に戻ります。 ロード テストでは、Azure Monitor からデータが収集され、ダッシュボードに表示されます。

このアーキテクチャの Visio ファイルをダウンロードします。

データフロー

次のデータフローは、前の図に対応しています。

1. シミュレートされたデバイスは、ロード テスト エージェントを介してイベント ハブにデータを送信します。 デバイスの動作は、JMeter カスタム プラグインを使用してシミュレートできます。 Load Testing エージェントは、任意の種類のシミュレートされたデバイスのカスタム プラグインを実行した後、イベント ハブにデータを送信します。

2. イベント ハブは、データを処理し、Azure SQL Database や Azure Digital Twins などの他のダウンストリーム サービスに送信する Azure 関数アプリをトリガーします。

3. Azure Monitor は、関数アプリと Event Hubs を監視します。

4. ロード テストでは、Azure Monitor からデータが収集され、ダッシュボードに表示されます。

コンポーネント

この例では、次のコンポーネントを使用します。

• ロード テスト: ロード テストを使用して Apache JMeter スクリプトとカスタム プラグインを実行し、ユーザーとデバイスの動作をシミュレートします。 ロード テストには、ロード テストを管理および実行するための Web ベースのインターフェイスと、プロセスを自動化するための一連の API が用意されています。 ロード テストはフル マネージド サービスです。つまり、サーバーやインフラストラクチャを管理する必要はありません。 このアーキテクチャでは、ロード テストによって JMeter スクリプトとカスタム プラグインがアップロードされ、これらのスクリプトが実行されるコンピューティングになります。

• Event Hubs: Event Hubs はクラウドベースのイベント処理サービスであり、さまざまなソースからのイベントとストリーミング データをリアルタイムで収集、処理、分析するために使用できます。 Event Hubs では、高度なメッセージ キュー プロトコル (AMQP)、HTTPS、Kafka プロトコル、メッセージ キュー テレメトリ トランスポート (MQTT)、WebSocket 経由の AMQP など、複数のプロトコルがサポートされています。 このアーキテクチャはイベント ベースであるため、ロード テストでは、ワークロードをロード テストするためのイベントが設定されます。

• IoT Hub: IoT Hub は、クラウドでホストされるマネージド サービスであり、IoT アプリケーションとその接続されたデバイス間の通信用の中央メッセージ ハブとして機能します。 何百万ものデバイスとそのバックエンド ソリューションとを、高い信頼性で安全に接続することができます。 ほぼすべてのデバイスを IoT ハブに接続できます。 Event Hubs クライアントを IoT Hub クライアントに変更することで、このアーキテクチャを IoT Hub を使用するように調整できます。

• Azure Functions: Functions は、サーバーやインフラストラクチャを管理することなくコードを実行するために使用できるサーバーレス コンピューティング サービスです。 C#、F#、Java、JavaScript、PowerShell、Python、TypeScript など、複数のプログラミング言語がサポートされています。 このアーキテクチャでは、プライマリ コンピューティング レベルとして Functions を使用します。 Event Hubs のイベント データは、関数アプリをトリガーしてスケールアウトします。

• JMeter GUI: JMeter GUI は、主に Web アプリケーションのパフォーマンスをテストするために使用されるオープンソースのロード テスト ツールです。 ただし、SOAP や REST Web サービス、FTP サーバー、データベースなど、他の種類のアプリケーションをテストするためにも使用できます。

• Azure Monitor: Azure Monitor には、Azure リソースに対する監視とアラートの機能が用意されています。 これを使用して、アプリケーションと基になるインフラストラクチャのパフォーマンスと正常性を監視します。 このアーキテクチャでは、Azure Monitor はロード テスト中に Azure インフラストラクチャ コンポーネントの正常性を監視します。

シナリオの詳細

ロード テストを使用して、既存の Apache JMeter スクリプトを適用し、任意の Azure リソースに対してクラウド 規模でロード テストを実行できます。

JMeter を使用すると、テスト担当者はロード テスト、ストレス テスト、機能テストを作成して実行できます。 複数のユーザーが Web アプリケーションに同時にアクセスすることをシミュレートするため、テスト担当者は、高負荷で発生する可能性のある潜在的なパフォーマンスのボトルネックやその他の問題を特定できます。 JMeter を使用して、応答時間、スループット、エラー率など、さまざまなパフォーマンス メトリックを測定できます。

JMeter は GUI ベースのインターフェイスを使用して、ユーザーがテスト 計画を作成できるようにします。これには、異なる設定と構成を持つ複数のテスト シナリオを含めることができます。 テスターは、プラグインを使用するか、カスタム コードを記述して JMeter をカスタマイズすることもできます。 このプラグインは、ユーザーが AMQP や WebSocket などの HTTP 以外のプロトコルを使用するサービスを操作するのに役立ちます。

JMeter にはロード テスト用のさまざまな機能が用意されていますが、組み込みの機能では特定のユース ケースや要件がカバーされない場合があります。 カスタム プラグインを開発することで、テスト担当者は新しい機能を追加したり、ニーズに合わせて既存の機能をカスタマイズしたりできます。

たとえば、特定の種類のユーザー動作をシミュレートしたり、より現実的なテスト データを生成したりするためのカスタム プラグインを開発できます。 また、ログ記録ツールやレポート ツール、継続的インテグレーションおよび継続的配置 (CI/CD) パイプラインなど、JMeter を他のツールやシステムと統合するためのカスタム プラグインを開発することもできます。 カスタム プラグインがあれば、テスト プロセスを合理化し、ソフトウェア開発ワークフロー全体にロード テストを簡単に組み込むことができます。 テスト担当者は、特定のニーズに合わせて JMeter を調整し、ロード テスト作業の精度と有効性を向上させることができます。

この例では、デバイスは特定の期間にわたって温度と湿度を報告します。 この例では、カスタム JMeter プラグインを使用してこの動作をシミュレートします。 カスタム プラグインの現在の実装では、指定されたテンプレートを使用してランダム なデータが生成されます。 ただし、プラグインには、任意のデバイスで可能な複雑な動作を含めることができます。 この例では、デバイスは Azure のイベント ハブにデータを送信します。 イベント ハブは、データを処理し、SQL Database などの他のダウンストリーム サービスに送信する Azure 関数アプリをトリガーします。 Azure Functions は、アーキテクチャがテストするサービスです。 テスト プランは、このデバイスの動作をシミュレートし、イベント ハブにデータを送信するように設計されています。

考えられるユース ケース

カスタム プラグインでロード テストを使用すると、次のようなさまざまなシナリオで役立ちます。

• AMQP や WebSocket などの HTTP 以外のプロトコルを使用するアプリケーションのパフォーマンスをテストします。
• カスタム プロトコルを使用するアプリケーションのパフォーマンス テスト。
• Microsoft 以外の SDK を使用するアプリケーションのパフォーマンス テスト。
• 特定の種類のユーザーまたはデバイスの動作をシミュレートする。
• より現実的なテスト データの生成。

カスタム プラグイン

JMeter では、カスタム プラグインは、既定の機能を拡張するために追加できるソフトウェア コンポーネントです。 カスタム プラグインは、JMeter に新しい機能、関数、または統合を追加します。 Java プログラミング言語と JMeter プラグイン開発キット (PDK) を使用して、カスタム プラグインを開発できます。 PDK には、GUI 要素、リスナー、サンプラーなど、新しいプラグインの作成に役立つ一連のツールと API が用意されています。

JMeter で Event Hubs 用のカスタム サンプラーを実装するには、 JMeter プラグインのロード テストの手順に従います。 カスタム サンプラーを実装した後は、他のサンプラーと同様に、ロード テストの JMeter テスト プランで使用できます。

仮想ユーザーやデバイスなどのスレッド数を制御するスレッド グループを使用して、特定のシナリオを実行することで、テスト計画を実装できます。 スレッド グループごとに、スレッド数、ランプアップ期間、ループ数、期間を別々に設定できます。 スレッド グループは、テスト 計画の構成とアプリケーションの要件に応じて、順番に、または並列に実行できます。 サンプラーをスレッド グループに追加してパラメーターを設定し、必要に応じて構成できます。 カスタム サンプラーは、組み込みのサンプラーでサポートされていない複雑なシナリオや要求をシミュレートできる、JMeter の強力なツールです。

カスタム プラグインを使用して Apache JMeter スクリプトを作成する

このセクションでは、Event Hubs でアプリケーションのロード テストを行うためのサンプル JMeter テスト スクリプトを作成します。

サンプル JMeter テスト スクリプトを作成するには:

1. テキスト エディターで LoadTest.jmx ファイルを作成し、次のコード スニペットをファイルに貼り付けます。 このスクリプトは、イベント ハブにイベントを同時に送信する 36 台の仮想マシンのロード テストをシミュレートします。 完了するまでに 10 分かかります。

   <?xml version="1.0" encoding="UTF-8"?>
   <jmeterTestPlan version="1.2" properties="5.0" jmeter="5.5">
       <hashTree>
       <TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="Test Plan" enabled="true">
           <stringProp name="TestPlan.comments"></stringProp>
           <boolProp name="TestPlan.functional_mode">false</boolProp>
           <boolProp name="TestPlan.tearDown_on_shutdown">true</boolProp>
           <boolProp name="TestPlan.serialize_threadgroups">false</boolProp>
           <elementProp name="TestPlan.user_defined_variables" elementType="Arguments" guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true">
               <collectionProp name="Arguments.arguments"/>
           </elementProp>
           <stringProp name="TestPlan.user_define_classpath"></stringProp>
       </TestPlan>
       <hashTree>
           <ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Thread Group" enabled="true">
               <stringProp name="ThreadGroup.on_sample_error">continue</stringProp>
               <elementProp name="ThreadGroup.main_controller" elementType="LoopController" guiclass="LoopControlPanel" testclass="LoopController" testname="Loop Controller" enabled="true">
                   <boolProp name="LoopController.continue_forever">false</boolProp>
                   <intProp name="LoopController.loops">-1</intProp>
               </elementProp>
               <stringProp name="ThreadGroup.num_threads">36</stringProp>
               <stringProp name="ThreadGroup.ramp_time">20</stringProp>
               <boolProp name="ThreadGroup.scheduler">true</boolProp>
               <stringProp name="ThreadGroup.duration">600</stringProp>
               <stringProp name="ThreadGroup.delay"></stringProp>
               <boolProp name="ThreadGroup.same_user_on_next_iteration">false</boolProp>
           </ThreadGroup>
           <hashTree>
                <com.microsoft.eventhubplugin.EventHubPlugin guiclass="com.microsoft.eventhubplugin.EventHubPluginGui" estclass="com.microsoft.eventhubplugin.EventHubPlugin" testname="Azure Event Hubs Sampler" enabled="true">
                   <!-- Azure Event Hub connection configuration using Managed Identity (see repository for instructions) -->
                   <boolProp name="useManagedIdentity">true</boolProp>
                   <stringProp name="eventHubNamespace">telemetry-ehn.servicebus.windows.net</stringProp>
                   <stringProp name="eventHubName">telemetry-data-changed-eh</stringProp>
                   <stringProp name="liquidTemplateFileName">StreamingDataTemplate.liquid</stringProp>
               </com.microsoft.eventhubplugin.EventHubPlugin>
           </hashTree>
       </hashTree>
       </hashTree>
   </jmeterTestPlan>
   

   com.microsoft.eventhubplugin.EventHubPluginGuiとcom.microsoft.eventhubplugin.EventHubPluginの実装は、Azure サンプルで入手できます。

2. ファイルで、テスト ランナーの割り当てられたマネージド ID を使用して、Event Hubs 接続の値を設定します。 その ID には、Event Hubs インスタンスへの書き込みアクセス権が必要です。

3. このファイル内で、eventHubName ノードの値をイベント ハブ名 (telemetry-data-changed-eh など) に設定します。

4. liquidTemplateFileName ノードの値を、イベント ハブに送信されるメッセージを含むファイルに設定します。 たとえば、次のように、StreamingDataTemplate.liquid という名前のファイルを作成します。

   {
       {% assign numberOfMachines = 36 %}
       {% assign machineId = dataGenerator.randomNaturalNumber | modulo: numberOfMachines %}
       "MachineId": "{{machineId | prepend: '0000000000000000000000000000000000000000' | slice: -27, 27 }}"
       "Temperature": {{dataGenerator.randomInt | modulo: 100 }},
       "Humidity": {{dataGenerator.randomInt | modulo: 100 }}
   }
   

   この例では、イベント ハブ メッセージのペイロードは、 MachineId、 Temperature、 Humidityの 3 つのプロパティを持つ JSON オブジェクトです。 MachineId はランダムに生成される 27 文字の ID で、 Temperature と Humidity は 100 未満のランダムな整数です。 このファイルは、Liquid テンプレートの構文です。 Liquid テンプレートは、さまざまな Web 開発フレームワークで使用される一般的なテンプレート言語です。 Liquid テンプレートを使用すると、開発者は簡単に更新および変更できる動的コンテンツを作成できます。 これにより、変数、条件、ループ、およびその他の動的要素をイベント ハブ メッセージに挿入できます。 構文は簡単で、作業を開始するために役立つ豊富なオンライン リソースが用意されています。 Liquid テンプレートは、動的でカスタマイズ可能なメッセージを作成するための強力で柔軟な方法を提供します。

5. ファイルを保存して閉じます。

   重要

   JMeter スクリプトのサンプラー名に個人データを含めないでください。 サンプラー名は、ロード テスト テストの結果ダッシュボードに表示されます。 液体テンプレートのサンプルと JMeter スクリプト ファイルは、 Azure のサンプルからダウンロードできます。

Event Hubs から IoT Hub にカスタム プラグインを更新する

カスタム プラグインは、プライマリ ターゲット リソースとして Event Hubs を使用します。 次の構成は、Event Hubs の SDK クライアントセットアップです。

EventHubProducerClient producer = null;
EventHubClientBuilder producerBuilder = new EventHubClientBuilder();

producerBuilder.credential(getEventHubNamespace(), getEventHubName(), new DefaultAzureCredentialBuilder().build());
producer = producerBuilder.buildProducerClient();

EventDataBatch batch = producer.createBatch(new CreateBatchOptions());
batch.tryAdd(new EventData(msg));
producer.send(batch);

次の例は、同じソリューションを再利用し、IoT 依存関係を追加し、IoT Hub を使用するように SDK クライアントを変更する方法を示しています。

IotHubServiceClientProtocol protocol = IotHubServiceClientProtocol.AMQPS;
ServiceClient client = new ServiceClient(getIoTHostName(), new DefaultAzureCredentialBuilder().build(), protocol);
client.open();

Message message = new Message(msg);
client.send(getDeviceName(), message);

client.close();

新しいプラグインを使用してロード テストを実行する

ロード テストがロード テストを開始すると、最初に JMeter スクリプトと他のすべてのファイルがテスト エンジン インスタンスにデプロイされます。 テストを実行する前に、パラメーター タブに移動して、必要なパラメーターを定義して設定します。 詳細については、「 Apache JMeter プラグインを使用してロード テストをカスタマイズする」と「ロード テスト」を参照してください。

環境のパフォーマンス テストを設定する

パフォーマンス テストでは、テスト環境が運用環境に似ていることが重要です。 この例では、システムの容量とパフォーマンスをより深く理解するために、パフォーマンス テストに次の環境を使用します。

サービス	構成
イベント ハブ	1 つの処理装置を備えた Premium
Azure Functions (アジュール ファンクションズ)	Linux、Premium プラン (EP1) - 210 ACU、3.5 GB メモリ、vCPU x 1 相当の Standard_D1_v2
リージョン	米国東部

Event Hubs や Azure Functions など、Azure サービスに適したサービス レベルを選択することは複雑なプロセスであり、多くの要因によって異なります。 詳細については、「 Event Hubs の価格 」と 「Functions の価格」を参照してください。

パフォーマンス テスト用の KPI を設計する

パフォーマンス テスト用の KPI を設計する前に、ビジネス要件とシステム アーキテクチャを定義する必要があります。 ビジネス要件により、測定する KPI (応答時間、スループット、エラー率など) が示されます。 システム アーキテクチャは、Web サーバー、データベース、API など、各コンポーネントのパフォーマンスをどのようにテストするのか、その方法を知るために必要な情報です。 この情報は、ロード テスト、ストレス テスト、耐久テストなど、最適なパフォーマンス テスト戦略を選択するためにも役立ちます。

この例には、次のビジネス要件があります。

• システムは、1 秒あたり 1,000 件の要求を処理できます。
• システムの信頼性が 0.99 を超えています。
• システムは、個人データ情報を報告する 1,000 台の同時デバイスを処理できます。
• サポートできるデバイスの数の観点から、システムの最大容量を指定できます。 たとえば、システムは現在の容量の 3 倍の 1,000 台の同時デバイスをサポートできます。

システムがこれらの要件を満たしているかどうかを測定するには、パフォーマンス テストに次の KPI を使用できます。

KPI	説明
RPS	イベント ハブの 1 秒あたりの要求数
負荷	パフォーマンス テスト中にイベント ハブに送信されたロードまたは要求の数
IR	関数呼び出しまたはインジェスト率の数
RT	Azure Functions の平均実行時間
AMU	Azure Functions の平均メモリ使用量
SR	すべての関数アプリ呼び出しの成功率
アルス	SQL サーバーやマイクロサービスなどのサービスのダウンストリーム サービス応答時間の平均
DF	内部関数アプリのエラーを含む依存関係エラーの数
MRPS	イベント ハブにバックログがない最大 RPS (システム容量)

KPI の測定

KPI を測定するには、パフォーマンス テスト戦略が必要になります。 この戦略では、各コンポーネントのパフォーマンス テスト アプローチを定義します。 この例では、次のパフォーマンス テスト戦略を使用します。

• Event Hubs: イベント ハブのパフォーマンス テストアプローチは、多数のメッセージをイベント ハブに送信し、RPS と LOAD を測定することです。 RPS は、1 秒あたりにイベント ハブに送信されたメッセージの数です。 LOAD は、パフォーマンス テスト中にイベント ハブに送信されたメッセージの合計数です。 ロード テストでは、RPS と LOAD を測定できます。

• Azure Functions: Functions のパフォーマンス テストアプローチは、次のメトリックを測定することです。

  • IR
  • RT
  • AMU
  • SR
  • アルス
  • DF

Azure Monitor では AMU、ARS、DF を測定できますが、IR、RT、SR は測定できません。 Azure Monitor を使用して KPI を測定するには、Azure Functions の Application Insights を有効にします。 詳細については、「Application Insights との統合を有効にする」を参照してください。

Azure Monitor を有効にした後、次のクエリを使用して KPI を測定できます。

• IR: FunctionAppLogs | where Category startswith "name-space-of-your-function" and Message startswith "Executed" | summarize count() by FunctionName, Level, bin(TimeGenerated, 1h) | order by FunctionName desc

• RT: FunctionAppLogs| where Category startswith "name-space-of-your-function" and Message startswith "Executed "| parse Message with "Executed " Name " (" Result ", Id=" Id ", Duration=" Duration:long "ms)"| project TimeGenerated, Message, FunctionName, Result, FunctionInvocationId, Duration

• SR: FunctionAppLogs| where Category startswith "name-space-of-your-function" and Message startswith "Executed" | summarize Success=countif(Level == "Information" ), Total=count() by FunctionName| extend Result=Success*100.0/Total| project FunctionName, Result| order by FunctionName desc

Azure Monitor ダッシュボードのサンプル

次の図は、Azure Monitor ダッシュボードのサンプルを示しています。 前のクエリに基づいて、Azure Functions の KPI が表示されます。

まとめ

この記事では、KPI を設計し、ロード テスト用のダッシュボードを開発する方法について説明しました。 また、JMeter でカスタム プラグインを使用して、Event Hubs と統合された Azure Functions に対するロード テストを実行する方法についても学習しました。 同じ方法を使用して、他の Azure サービスについてロード テストを実行することもできます。 Azure DevOps を使用して、ロード テスト スクリプトの CI/CD パイプラインを設定することもできます。

詳細については、「 ロード テスト」を参照してください。

寄稿者

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

主な作成者:

• Mahdi Setayesh | プリンシパル ソフトウェア エンジニア
• オスカー・フィンブル |シニア ソフトウェア エンジニア

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ

• ロードテスト
• カスタム JMeter プラグインのサンプル コード
• 新しいカスタム プラグインを開発する方法
• Apache JMeter プラグインとロード テストを使用してロード テストをカスタマイズする
• Application Insights とは何か?
• Azure App Service アプリケーションのロード テスト
• クイック スタート: ロード テストを使用してロード テストを作成して実行する
• ロード テストで JMeter スクリプトを使用して Web サイトをロード テストする
• クイックスタート: CI/CD を使用して既存のロード テストを自動化する
• チュートリアル: ロード テストを実行して Web アプリのパフォーマンスのボトルネックを特定する