MQTT コアコンセプト

MQTT（Message Queue Telemetry Transport）は、IoT（モノのインターネット）で最も広く使われている軽量メッセージングプロトコルです。このプロトコルはメッセージ通信においてパブリッシュ／サブスクライブ（pub/sub）パターンに基づいています。シンプルかつ効率的なメッセージフォーマットを用いることで、ネットワークのオーバーヘッドを最小限に抑え、消費電力を削減しながら、デバイスやアプリケーション間でリアルタイムにデータ交換が可能です。

MQTTメッセージングプラットフォームとして機能するEMQXは、MQTTのメッセージング機能を完全にサポートしています。本節ではMQTTのコアコンセプトを簡潔に紹介します。各コンセプトの詳細やMQTT全般については、MQTTブログシリーズのリンクからさらに学習できます。

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

このプロトコルはイベント駆動型で、pub/subパターンを用いてデバイスを接続します。従来のクライアント／サーバパターンとは異なり、送信者（パブリッシャー）が特定の受信者（サブスクライバー）に直接メッセージを送るのではなく、パブリッシャーはメッセージをトピックに分類し、サブスクライバーは関心のあるトピックをサブスクライブします。パブリッシャーがトピックにメッセージをパブリッシュすると、MQTTブローカーがすべての受信メッセージをルーティングおよびフィルタリングし、そのトピックに関心を示したすべてのサブスクライバーにメッセージを配信します。

パブリッシャーとサブスクライバーは互いに独立しており、お互いの存在を知る必要はありません。両者の唯一の接点は、メッセージに関する事前の取り決めに基づいています。Pub/Subパターンは柔軟なメッセージ通信を可能にし、サブスクライバーやパブリッシャーは必要に応じて動的に追加・削除できます。また、メッセージのブロードキャスト、マルチキャスト、ユニキャストの実装も容易になります。

Pub/Subパターンの詳細については、Introduction to MQTT Publish-subscribe Patternをご覧ください。

MQTTサーバー

MQTTサーバーは、パブリッシュするクライアントとサブスクライブするクライアントの間でブローカーとして機能し、受信したすべてのメッセージを該当するサブスクライバーに転送します。そのため、サーバーはしばしばMQTTブローカーと呼ばれます。

MQTTクライアント

クライアントとは、MQTTプロトコルを使ってMQTTサーバーに接続できるデバイスやアプリケーションを指します。クライアントはパブリッシャーおよびサブスクライバーの両方の役割を担うことも、どちらか一方の役割だけを担うことも可能です。

トピックとワイルドカード

トピックは異なるメッセージを識別・区別するために使われ、MQTTメッセージのルーティングの基盤となります。パブリッシャーはメッセージをパブリッシュする際にトピックを指定し、サブスクライバーは関心のあるトピックをサブスクライブして関連メッセージを受信します。

サブスクライバーは、サブスクライブするトピックにワイルドカードを使うことで、複数のトピックを一度にサブスクライブすることができます。MQTTは、単一レベルワイルドカードとマルチレベルワイルドカードという2種類のトピックワイルドカードを提供し、さまざまなサブスクリプションニーズに対応しています。

トピックとワイルドカードの詳細については、Understanding MQTT Topics & Wildcards by Caseをご覧ください。

QoS（サービス品質）

MQTTは、メッセージの信頼性レベルを提供するために3つのQoSレベルを定義しています。各メッセージはパブリッシュ時に独立してQoSレベルを設定できます。

• QoS 0：メッセージを最大1回配信し、失われる可能性があります。
• QoS 1：メッセージを少なくとも1回配信し、到達を保証しますが重複する可能性があります。
• QoS 2：メッセージを正確に1回配信し、重複なく到達を保証します。

QoSレベルが上がるほどメッセージ送信の複雑さも増します。実際のシナリオに応じて適切なQoSレベルを選択する必要があります。

QoSの詳細については、Introduction to MQTT QoS 0, 1, 2をご覧ください。

セッション

QoSは信頼性の高いメッセージ配信を実現するための理論的な仕組みですが、セッションはQoS 1および2のプロトコル手順を正しく実装するための状態管理を担います。

セッションとは、クライアントとサーバー間の状態を持つやり取りを指し、ネットワーク接続の継続時間と同じ期間持続する場合もあれば、複数のネットワーク接続にまたがって持続する場合もあります。後者は一般に永続セッションと呼ばれます。接続は既存のセッションから再開することも、新しいセッションから開始することも可能です。

セッションの詳細については、MQTT Persistent Session and Clean Session Explainedをご覧ください。

保持メッセージ（Retained Message）

通常のメッセージとは異なり、保持メッセージはMQTTサーバーに保存されます。新しいサブスクライバーが保持メッセージのトピックにマッチするトピックをサブスクライブすると、そのメッセージが即座に配信されます。これは、そのメッセージがサブスクライブ前にパブリッシュされていた場合でも同様です。

保持メッセージ機能により、サブスクライバーは接続直後にデータ更新を受け取ることができ、パブリッシャーが再度メッセージをパブリッシュするのを待つ必要がありません。保持メッセージはある意味でメッセージの「クラウドドライブ」のように考えられます。いつでもメッセージを「クラウドドライブ」にアップロードし、いつでもそこからメッセージを取得できます。ただし、この「クラウドドライブ」はトピックごとに最新の保持メッセージ1件のみ保存可能です。

MQTTXクライアントを使って保持メッセージをパブリッシュする方法は、Retained Messageの手順をご参照ください。

保持メッセージ技術の詳細については、The Beginner's Guide to MQTT Retained Messagesをご覧ください。

遺言メッセージ（Will Message）

Pub/Subパターンの特性上、サーバー以外のクライアントは通信ネットワークから離脱したクライアントの存在を知ることができません。しかし、遺言メッセージを使うことで、切断されたクライアントが他のクライアントに通知を行うことが可能になります。

クライアントは接続時にサーバーに遺言メッセージを設定でき、クライアントが予期せず切断された場合にサーバーはこのメッセージを即時または指定した遅延後にパブリッシュします。対応する遺言メッセージのトピックをサブスクライブしているクライアントはこのメッセージを受信し、該当クライアントのオンライン状態更新など適切な処理を行います。

MQTTXクライアントを使って遺言メッセージをパブリッシュする方法は、Will Messageの手順をご参照ください。

遺言メッセージ技術の詳細については、Use of MQTT Will Messageをご覧ください。

共有サブスクリプション（Shared Subscription）

通常、メッセージは該当するすべてのサブスクライバーに転送されますが、複数のクライアントで受信メッセージを水平スケーラブルに処理し、負荷能力を向上させたい場合や、プライマリクライアントがオフラインになった際にシームレスに切り替わるバックアップクライアントを追加し、高可用性を確保したい場合があります。

共有サブスクリプション機能はこのような要件に対応します。クライアントを複数のサブスクリプショングループに分け、メッセージはすべてのグループに転送されますが、各グループ内では一度に1つのクライアントのみがメッセージを受信します。

MQTTXクライアントを使って共有サブスクリプションを作成する方法は、Shared Subscriptionの手順をご参照ください。

共有サブスクリプション技術の詳細については、Shared subscription - MQTT 5.0 new featuresをご覧ください。

システムトピック（System Topic）

$SYS/で始まるトピックは、サーバーが特定のメッセージ（サーバーのアップタイム、クライアントのオンライン／オフラインイベント通知、現在接続中のクライアント数など）をパブリッシュするために予約されています。これらのトピックは一般にシステムトピックと呼ばれ、クライアントはこれらをサブスクライブすることでサーバーの情報を取得できます。

システムトピックの詳細については、Understanding MQTT Topics & Wildcards by Caseをご覧ください。