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トピックとワイルドカードの理解をご覧ください。