MQTT パブリッシュ/サブスクライブパターンの概要 #mqtt

MQTT パブリッシュ/サブスクライブパターン

パブリッシュ/サブスクライブパターンは、メッセージを送信するクライアント (Publisher) とメッセージを受信するクライアント (サブスクライバー) を、直接接続したり、互いの存在を知らなくても通信できるようにすることで分離するメッセージングパターンです。

MQTT のパブリッシュ/サブスクライブパターンの本質は、ブローカーと呼ばれる仲介者の役割がすべてのメッセージのルーティングと配布を担当することです。パブリッシャーはトピックを含むメッセージをブローカーに送信し、サブスクライバーはブローカーからトピックをサブスクライブして関心のあるメッセージを受信します。

MQTT では、トピックやサブスクリプションを事前に登録または作成することはできません。その結果、ブローカーは、特定のトピックに興味を持つサブスクライバーの数を予測できません。パブリッシャーがメッセージを送信すると、ブローカーはそのメッセージを現在トピックにサブスクライブしているサブスクライバーにのみ転送します。トピックの現在のサブスクライバーがいない場合、メッセージは破棄されます。

MQTT パブリッシュ/サブスクライブパターンには、パブリッシャー、サブスクライバー、ブローカー、トピックという 4 つの主要コンポーネントがあります。

パブリッシャー(Publisher)

パブリッシャーはトピックにメッセージをパブリッシュする責任があります。一度にデータを送信できるのは 1 つのトピックのみであり、メッセージを公開するときに購読者がオンラインであるかどうかを気にする必要はありません。
サブスクライバー(Subscriber)

サブスクライバーはトピックをサブスクライブすることでメッセージを受信し、一度に複数のトピックをサブスクライブできます。MQTT は、共有サブスクリプションを介した複数のサブスクライバ間でのサブスクリプションのロードバランシングもサポートします。
ブローカ(Broker)

ブローカーは、パブリッシャーからメッセージを受信し、それらを適切なサブスクライバーに転送する責任があります。さらに、ブローカーは、クライアントからの接続、切断、サブスクライブ、およびサブスクライブ解除のリクエストも処理します。
トピック(Topic)

MQTT はトピックに基づいてメッセージをルーティングします。/通常、トピックはレベル分けされ、レベル間はスラッシュで区切られます。これは URL パスに似ています。たとえば、トピックは次のようになりますsensor/1/temperature。複数のサブスクライバが同じトピックをサブスクライブでき、ブローカはそのトピックに関するすべてのメッセージをこれらのサブスクライバに転送します。複数のパブリッシャーが同じトピックにメッセージを送信することもでき、ブローカーはこれらのメッセージを受信した順序でサブスクライブされたクライアントにルーティングします。

MQTT では、サブスクライバーはトピックワイルドカードを使用して複数のトピックを同時にサブスクライブできます。これにより、単一のサブスクリプションで複数のトピックに関するメッセージを受信できるようになります。詳細については、ブログ「Understanding MQTT Topics & Wildcards by Case」を参照してください。

MQTT パブリッシュ/サブスクライブアーキテクチャ

MQTT パブリッシュ/サブスクライブでのメッセージルーティング

MQTT パブリッシュ/サブスクライブパターンでは、クライアントはパブリッシャー、サブスクライバー、またはその両方として機能できます。クライアントがメッセージをパブリッシュすると、それがブローカーに送信され、ブローカーはそのトピックに関してサブスクライブしているすべてのクライアントにメッセージをルーティングします。クライアントがトピックにサブスクライブすると、そのトピックに対してブローカーが転送したすべてのメッセージを受信します。

パブリッシュ/サブスクライブシステムでメッセージをフィルタリングおよびルーティングするには、一般に 2 つの一般的なアプローチがあります。

トピック別

購読者は、興味のあるトピックをブローカーに購読できます。パブリッシャーがメッセージを送信するとき、そのメッセージには、そのメッセージが属するトピックが含まれます。ブローカーはこの情報を使用して、どのサブスクライバーがメッセージを受信するかを決定し、メッセージを適切なサブスクライバーにルーティングします。
コンテンツベースのフィルタリングによる

購読者は、メッセージが配信されるために満たす必要がある条件を指定できます。メッセージの属性またはコンテンツがサブスクライバによって定義された条件と一致する場合、メッセージはそのサブスクライバに配信されます。メッセージが購読者の条件を満たさない場合、メッセージは配信されません。

EMQX は、トピックに基づいたメッセージのルーティングに加えて、バージョン 3.1 以降、SQL ベースのルールエンジンを通じて高度なメッセージルーティング機能を提供します。この機能により、メッセージの内容に基づいてメッセージをルーティングできます。ルールエンジンとその仕組みの詳細については、EMQX ドキュメントを参照してください。

MQTT と HTTP のリクエストとレスポンス

HTTP は、そのシンプルさと使いやすさにより、World Wide Web で広く使用されている通信プロトコルです。特定のクライアントを必要とせず、モノのインターネット (IoT) 分野を含むさまざまな業界で使用できます。IoT では、HTTP を使用して IoT デバイスと Web サーバーを接続し、デバイスのリモート監視と制御を可能にします。

HTTP は使いやすく、開発サイクルが早いですが、IoT アプリケーションで使用する場合にはいくつかの制限があります。欠点の 1 つは、HTTP メッセージはプロトコルレベルで MQTT に比べてネットワークオーバーヘッドが大きいことです。さらに、HTTP はステートレスプロトコルです。つまり、サーバーはリクエストの処理時にクライアントの状態に関する情報を保持せず、異常な切断から回復できません。最後に、HTTP の Request/Response モデルでは更新を取得するためにポーリングが必要ですが、MQTT はサブスクリプションを通じてリアルタイムの更新を提供できます。

MQTT パブリッシュ/サブスクライブパターンには、その疎結合の性質により、固有の制限がいくつかあります。たとえば、パブリッシャはサブスクライバの状態に関する情報を持たないため、サブスクライバがメッセージを受信したか、正しく処理したかを知ることができません。この問題に対処するために、MQTT 5.0 では、サブスクライバーがメッセージの受信後にトピックに応答を送信し、パブリッシャーが応答の受信後にフォローアップできるようにするリクエスト/レスポンス機能が導入されています。

MQTT とメッセージキューの比較

MQTT とメッセージキューには、パブリッシュ/サブスクライブパターンなど多くの類似点がありますが、異なる目的で使用されます。メッセージキューは主に、通常は大量のデータを処理するがクライアントの数が少ないサーバー側アプリケーション間でメッセージを保存および送信するために使用されます。一方、MQTT は、主に IoT デバイス間の通信に使用されるメッセージングプロトコルであり、多くの場合、アクセス、管理、通信が必要なデバイスが多数存在します。

実際の状況では、MQTT サーバーがデバイスへの接続とデバイス間のメッセージのルーティングに集中できるようにするために、MQTT がメッセージキューと一緒に使用されることがよくあります。たとえば、MQTT サーバーは IoT デバイスからデータを受信し、それをメッセージキュー経由で処理するためにさまざまなビジネスシステムに送信します。

メッセージキューとは異なり、MQTT トピックを事前に作成する必要はありません。いつでも新しいトピックにメッセージを公開できます。もちろん、誰かが購読した場合に限り、これらのメッセージは Broker によって直接破棄されるのではなく、消費されます。

まとめ

MQTT パブリッシュ/サブスクライブメカニズムは、1 対 1、1 対多、多対 1 の通信ニーズを簡単に満たすことができます。その柔軟性により、Web キャストやモバイルプッシュ通知など、IoT 分野以外の業界での使用にも適しています。

ここまでで、MQTT のパブリッシュ/サブスクライブパターンについて十分に理解できたはずです。次のブログをチェックして、MQTT 接続を作成する方法を学ぶことができます。

MQTT の入門から上級へシリーズのガイドにアクセスして、MQTT のトピックや、ワイルドカード、保持メッセージ、意志メッセージなどの関連概念について学び、MQTT のより高度なアプリケーションを探索することもできます。これらのリソースは、MQTT アプリケーションとサービスの開発に役立ちます。

MQTT パブリッシュ/サブスクライブ パターンの概要