MQTT Publish-Subscribe Pattern 概要

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

パブリッシュ/サブスクライブ システムでメッセージをフィルタリングおよびルーティングするには、一般に 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 アプリケーションとサービスの開発に役立ちます。