MQTTのコアコンセプト

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

MQTTメッセージングプラットフォームとして機能するEMQXは、MQTTメッセージング機能の完全なセットをサポートしています。本セクションでは、MQTTのコアコンセプトについて簡単に紹介します。各コンセプトの詳細やMQTT全般については、MQTTブログシリーズをご参照ください。

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

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

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

Pub/Subパターンの詳細については、MQTTパブリッシュ・サブスクライブパターン入門をご覧ください。

MQTTサーバー

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

MQTTクライアント

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

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

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

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

トピックとワイルドカードの詳細については、ケースで理解するMQTTトピックとワイルドカードをご覧ください。

QoS（サービス品質）

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

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

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

QoSの詳細については、MQTT QoS 0, 1, 2入門をご参照ください。

セッション

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

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

セッションの詳細については、MQTT永続セッションとクリーンセッションの解説をご覧ください。

リテインドメッセージ

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

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

MQTTXクライアントを使ってリテインドメッセージをパブリッシュする方法は、リテインドメッセージをご参照ください。

リテインドメッセージ技術の詳細については、MQTTリテインドメッセージ初心者ガイドをご覧ください。

ウィルメッセージ

Pub/Subパターンの特徴として、サーバー以外のクライアントは他のクライアントが通信ネットワークを離れたことを認識できません。しかし、ウィルメッセージは切断されたクライアントが他のクライアントに通知する機能を提供します。

クライアントは接続時にサーバーに自身のウィルメッセージを設定でき、クライアントが予期せず切断された場合にサーバーは即座に、または指定した遅延後にこのメッセージをパブリッシュします。対応するウィルメッセージトピックをサブスクライブしているクライアントはこのメッセージを受け取り、例えばそのクライアントのオンライン状態の更新など適切な処理を行います。

MQTTXクライアントを使ってウィルメッセージをパブリッシュする方法は、ウィルメッセージをご参照ください。

ウィルメッセージ技術の詳細については、MQTTウィルメッセージの利用をご覧ください。

共有サブスクリプション

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

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

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

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

システムトピック

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

システムトピックの詳細については、ケースで理解するMQTTトピックとワイルドカードをご覧ください。