MQTT パフォーマンス テストの開始: 一般的なテスト シナリオとメトリック

導入

モノのインターネットの分野では、リソースに制約のある多数のセンサーや産業用制御デバイスが低帯域幅で不安定なネットワーク環境で動作しているため、MQTT はモノのインターネット シナリオにおける理想的なメッセージ送信プロトコルとなっています。したがって、MQTT ブローカーは、IoT アプリケーションの要件を満たす優れたパフォーマンスと高い信頼性を保証する必要があります。

システム テストに進む前に、基本的なテスト シナリオとパフォーマンス メトリックを理解することが重要です。この記事では、EMQX チームのテスト経験に基づいて詳細な説明を提供します。これは他の MQTT ブローカー テストにも適用できます。

用語集

MQTT プロトコル: MQTT (Message Queuing Telemetry Transport) は、パブリッシュ/サブスクライブ モデルに基づく軽量のメッセージ送信プロトコルです。名前に「メッセージ キュー」という言葉が含まれていますが、メッセージ キューとは何の関係もありません。このプロトコルは、そのシンプルさ、柔軟性、実装の容易さ、QoS のサポート、およびメッセージ サイズの小ささにより、モノのインターネットの分野で推奨されるプロトコルとなっています。

パフォーマンス テスト: パフォーマンス テストとは、テスト ツールを使用してさまざまな正常、ピーク、または異常な負荷状態をシミュレートし、さまざまなパフォーマンス指標に基づいてテスト対象のシステムのパフォーマンスを評価することを指します。その目的は、システムがユーザーの期待に応えられるかどうかを検証し、システム内のパフォーマンスのボトルネックや問題を見つけることです。

一般的な MQTT テスト シナリオ

MQTT ブローカーには主に 2 つのテスト シナリオがあります。

• 同時接続数と接続率を含む同時接続。
• メッセージの送受信のスループットを含むメッセージ スループット、および QoS、ペイロード サイズ、トピック ワイルドカードなど、運用環境システムのパフォーマンスに影響を与えるいくつかの要素。

特定のパフォーマンス テスト シナリオを設計するとき、特に PoC または導入前テストを実施するときは、次の 2 つの点に常に留意する必要があります。

• 実際の運用環境での使用状況を可能な限りシミュレートするようにしてください。
• 起こり得るピーク負荷をカバーします。

テスト シナリオは、接続とメッセージ スループットの 2 つの基本的な側面に従って分割できます。

同時接続テスト

MQTT 接続は、TCP に基づく長い接続です。クライアントはまず MQTT ブローカーとの TCP 接続を確立し、次に MQTT ログイン要求を送信します。接続が正常に確立された後、クライアントと MQTT ブローカーはハートビート パケットを定期的に送信することで接続状態を維持します。したがって、MQTT 接続を長時間確立して維持するには、MQTT ブローカーの特定のリソースが必要となり、同時実行性が高いシナリオでは、このような長時間の接続はブローカーのリソースを大量に消費します。したがって、パフォーマンス テストを通じて、限られたリソースの下で MQTT ブローカーが維持できる同時接続数を評価できます。

さらに、接続速度 (つまり、1 秒あたりの新しい接続の数) が高くなるほど、より多くのコンピューティング リソースが必要になります。シナリオによっては、多数のデバイスが接続されるため、テスト シナリオを作成する際には、この要素を考慮する必要があります。同時にオンラインになり、ブローカーをテストする機能、またはシステム容量を計画するときにこの指標が必要です。

同時接続テストでは、プレッシャーマシンやMQTTブローカーの追加リソースオーバーヘッドが増加するため、TLS/SSL暗号化通信を使用するかどうかも検討する必要があります。テストを計画するときは、テストがパフォーマンスに与える影響を評価する必要があります。

要約すると、MQTT 同時接続テストでは、次の 3 つのシナリオを考慮する必要があります。

1. 一定の低い接続速度で同時接続の数を徐々に増やして、システムの応答とリソース消費をテストします。これにより、システムが特定のハードウェアおよびネットワーク リソースで維持できる同時実行の最大数が決まります。
2. 指定された同時接続数を使用して、さまざまな接続速度でシステムの応答とリソース消費をテストします。
3. 1) と 2) を設計するときは、通常の TCP 接続と TLS/SSL 暗号化接続を区別してください。

メッセージスループットテスト

前述したように、MQTT はパブリッシュ/サブスクライブ モデルに基づくメッセージ送信プロトコルであり、1 対 1、1 対多、多対 1 の 3 種類のパブリッシュ / サブスクライブを実装した非同期プロトコルです。さまざまな IoT シナリオで広く使用されています。したがって、メッセージ スループット テストは次の 3 つのシナリオをカバーする必要があります。

1. 1 対 1: パブリッシャーとサブスクライバーの数が同じです。各パブリッシャーには、パブリッシュするトピックをサブスクライブするサブスクライバーが 1 人だけ存在します。つまり、MQTT ブローカーへのメッセージの流入速度と流出速度は同じです。
2. 多対 1 (レポート): パブリッシャとして多数の IoT デバイスが存在するが、ステータスやデータを報告する多数のデバイスなど、少数または単一のサブスクライバのみが存在する典型的な IoT アプリケーション シナリオ。
3. 1 対多: ブロードキャスト モードでは、少数のクライアントがメッセージをパブリッシュし、多数のデバイスがメッセージをサブスクライブして消費します (制御端末からの命令の送信など)。

また、メッセージ スループット シナリオを設計するときは、QoS、メッセージ ペイロード サイズ、ワイルドカードを使用したサブスクリプション トピックなどの要素を無視しないでください。さまざまな QoS は、負荷テストのパフォーマンスとリソース消費に大きな影響を与えます。実際の使用状況に応じて可搬質量を決定できます。

他のシーン

共有サブスクリプション、データベースまたは他のメッセージ キュー (MQ) へのメッセージ ダンプ、大規模なトピック サブスクリプション、多数の MQTT クライアントの同時接続/切断などの極端な状況など、その他の MQTT 機能については、実際のニーズに応じて設計およびテストできます。シーン。

パフォーマンス指標

テスト シナリオを設計した後、テストの成功を評価するための指標を作成する必要があります。

パフォーマンス テストでは、インジケーターは一般に、アプリケーション システム インジケーター (MQTT ブローカー インジケーターなど) とコンピューティング リソース インジケーターの 2 つのカテゴリに分類できます。

• アプリケーション システムのインジケーターは、応答時間 (または遅延)、同時実行性などのユーザー シナリオと要件に関連しています。
• コンピューティング リソースのメトリクスは、ハードウェア リソースの消費に関連しています。ここで説明する MQTT テストの場合、これらのメトリクスは、CPU、メモリ、ネットワーク、ディスク I/O などの他のソフトウェア パフォーマンス テストのメトリクスと似ています。

MQTT システム指標はテスト シナリオと密接に関連しており、一般的な指標を次の表に示します。

パフォーマンステストツール

大規模なパフォーマンス テストでは、高同時実行性と高スループットのシナリオを迅速、現実的、かつ安定してシミュレートできる必要があります。同時に、多くのマシンとリソースを管理および保守する必要があります。適切なテスト ツールを選択すると、次の 2 つの目標を達成できます。半分の労力で結果が得られます。

EMQX チームは、emqtt_bench と XMeter という 2 つのパフォーマンス テスト ツールを使用します。

emqtt_bench

emqtt_bench は、Erlang に基づいて EMQX 研究開発チームによって作成された MQTT プロトコル パフォーマンス テスト ツールです。インストールが完了すると、コマンドラインから使用できるようになります。

用法：emqtt_bench pub | sub | conn

他のツールと比較した場合、emqtt_bench の利点は、インストールと使用が簡単で、使用するコンピューティング リソースが少ないことです。ただし、サポートされるシナリオは比較的限られており、インジケーター データをテストするには他の監視ツールと組み合わせる必要があります。

具体的なインストール方法や使用方法については、https://github.com/emqx/emqtt-benchを参照してください。

Xメーター

emqtt_bench は、開発段階での迅速なパフォーマンス検証に適しています。大規模なテストまたは正式なテストを実施したい場合は、別のより専門的なパフォーマンスおよび負荷テスト ツールであるXMeterをお勧めします。

XMeter は JMeter をベースにしたパフォーマンス テスト ツールで、JMeter のアーキテクチャを変革して完全な水平拡張機能を実現しました。大量のデータを簡単に処理し、高頻度のテストを実行します。XMeter は、JMeter の強力な機能を継承するだけでなく、多くの新機能を追加します。テストプロセス中に、豊富なリアルタイムのテストレポートが提供されるため、テスト担当者はいつでもスループット、応答時間、成功率などの MQTT の主要なパフォーマンス指標を確認できます。同時に、XMeter には監視システムが組み込まれており、MQTT ブローカーのリソース消費をリアルタイムで監視できます。

さらに、XMeter は、自動化された一元化されたテスト リソース管理機能を提供します。テスト マシン (コンテナー) はテストの開始時に自動的に作成され、テストの終了時に破棄されます。

図 1 ～ 5 に示すように、テスト フェーズ全体を通じて、XMeter は MQTT パフォーマンス インジケーターとコンピューティング リソースの使用状況をリアルタイムでグラフィック表示します。

XMeter ユーザーガイド

XMeter には 2 つのエディションがあります。

• XMeter のローカル プライベート展開。テスト環境を完全に制御する必要があり、厳格なセキュリティとデータ プライバシーの規制を遵守する必要がある組織に最適です。このバージョンを使用するには、次のものが必要です。

  • XMeter チームによって開発されたオープンソースの mqtt-jmeter プラグインをGitHub (emqx/mqtt-jmeter: MQTT JMeter Plugin)からダウンロードします。

  • jar ファイルを JMeter ディレクトリに置きます。

  • アプリケーション シナリオに従って、図 6 に示すように JMeter でテスト スクリプトを作成します。

  • スクリプトを XMeter にアップロードし、MQTT に対するパフォーマンス テストを開始します。

    

• XMeter Cloud: フルマネージドの MQTT 負荷テスト クラウド サービス、使いやすい:

  • ワンクリックで MQTT パフォーマンス テストを開始し、テスト リソースを手動でデプロイする必要はありません
  • わずか 3 ステップで MQTT テスト設定が完了し、シナリオスクリプト作成の負担が軽減されます。
  • テスト リソースはクラウド上でオンデマンドで作成され、テスト環境は高度に自動化されているため、時間と人件費が大幅に節約されます。

当社Web サイトで無料トライアル アカウントを登録し、このドキュメントのガイダンスに従ってXMeter の利用を開始するだけです。

要約する

この記事では、MQTT ブローカーのパフォーマンスを評価するために使用されるいくつかの一般的なテスト シナリオと主要な指標について説明しました。これらのテスト手法と指標を理解して適用することで、MQTT システムのパフォーマンスと信頼性を最適化し、IoT とメッセージング インフラストラクチャの全体的なレベルを向上させることができます。

著作権に関する声明: この記事は EMQ によるオリジナルです。転載する場合は出典を明記してください。

元のリンク: https://www.emqx.com/zh/blog/getting-started-with-mqtt-performance-testing-a-primer-on-scenarios-and-metrics