MQTTとは? MQTTがIoTに最適なプロトコルである理由は?
EMQX Team
目次
IoT Analytics の調査レポート「Status of the IoT Spring 2022」によると、IoT 市場は 2022 年までに 18% 成長し、アクティブ接続数が 144 億に達すると予想されています。
このような大規模な IoTシステムにより、大量のデバイス アクセスとデバイス管理がネットワーク帯域幅、通信プロトコル、プラットフォーム サービス アーキテクチャに大きな課題をもたらします。IoT プロトコルは、複雑で信頼性の低いネットワーク環境、小さいメモリとフラッシュ メモリ容量、限られた処理能力など、IoT デバイス通信におけるいくつかの重要な問題に対処する必要があります。
MQTT プロトコルは、これらの問題に対処するために作成されました。長年にわたる開発を経て、軽量、効率性、信頼性の高いメッセージング、大規模な接続のサポート、安全な双方向通信という利点により、IoT 業界で推奨されるプロトコルになりました。
MQTT プロトコルの概要
MQTT は、パブリッシュ/サブスクライブ モデルに基づく軽量のメッセージング プロトコルで、特に低帯域幅で不安定なネットワーク環境の IoT アプリケーション向けに設計されています。最小限のコードで、ネットワークに接続されたデバイスにリアルタイムで信頼性の高いメッセージング サービスを提供できます。MQTT プロトコルは、IoT、モバイル インターネット、スマート ハードウェア、車両のインターネット、スマート シティ、遠隔医療、電力、石油、エネルギーなどの分野で広く使用されています。
IBM のAndy Stanford-Clarkと Arlen Nipper (当時 Arcom Systems、そして Eurotech の CTO)によって作成されました。Nipper 氏によると、MQTT には次の機能が必要と定義した：
- シンプルで実装が簡単
- QoSサポート（複雑なデバイスネットワーク環境）
- 軽量で帯域幅を節約できる (当時は帯域幅が高価だったため)
- データは無関係 (ペイロードのデータ形式は関係ありません)
- 継続的なセッション認識 (デバイスがオンラインかどうかを常に把握)
IBM Podcast の Arlen Nipper によると、MQTT は元々 MQ TT という名前でした。MQ と TT の間のスペースに注意してください。正式名は MQ Telemetry Transport です。これは、1990 年代初頭にコノコ フィリップスの原油パイプライン SCADA システムに取り組んでいる間に彼が開発したリアルタイム データ送信プロトコルです。その目的は、帯域幅が限られているVSATを介してセンサーが IBM の MQ Integrator と通信できるようにすることでした。Nipper はリモート センシング、データ収集、監視の専門家であるため、MQ TT という名前は業界の慣例に従って選ばれました。
MQTT と他の IoT プロトコルの比較
MQTT と HTTP
HTTP またはハイパーテキスト転送プロトコルは、World Wide Web 上のデータ通信のバックボーンとなっているプロトコルです。HTTP は要求/応答プロトコルであり、クライアントがサーバーにデータを要求し、サーバーが要求されたデータで応答することを意味します。
これに対して、MQTT は、前述したようにパブリッシュ/サブスクライブ プロトコルです。これは、MQTT デバイスがサーバーとの継続的な接続を維持し、データが利用可能になったときにデバイスにプッシュされることを意味します。データがリアルタイムで送信されるシナリオでは、これは HTTP よりも効率的です。
MQTT と HTTP の比較:
- MQTT は最小メッセージ サイズが 2 バイトであるため、HTTP よりもネットワーク オーバーヘッドが少なくなります。
- MQTT と HTTP はどちらも TCP 接続を使用でき、安定した信頼性の高いネットワーク接続を実現できます。
- MQTT はパブリッシュ/サブスクライブ モデルに基づいており、HTTP はリクエスト/レスポンスに基づいているため、MQTT は二重通信をサポートします。
- MQTT はリアルタイムでメッセージをプッシュできますが、HTTP ではデータ更新のためにポーリングが必要です。
- MQTT はステートフルですが、HTTP はステートレスです。
- MQTT は、HTTP では実現できない、異常な切断から接続を回復できます。
MQTT と XMPP
XMPP (Extensible Messaging and Presence Protocol) は、もともとチャットなどのリアルタイム通信用に設計された通信プロトコルです。XMPP は拡張性が高く、IoT アプリケーションでの使用に採用されています。
XMPP と MQTT は両方とも集中サーバー (ブローカー) を使用し、両方ともパブリッシュ/サブスクライブ モデルをサポートします。MQTT プロトコルは、設計がシンプルかつ軽量で、ルーティングが柔軟です。これは、モバイル インターネットと IoT メッセージングの分野で、PC 時代の XMPP プロトコルを完全に置き換えます。
MQTT と XMPP の比較:
- MQTT メッセージは小さく、エンコードとデコードが簡単ですが、XMPP は重い XML に基づいているため、メッセージが大きく、やり取りが面倒です。
- MQTT はパブリッシュ/サブスクライブ モデルに基づいており、XMPP の JID ベースのポイントツーポイント メッセージ ルーティングよりも柔軟です。
- MQTT は、JSON、バイナリなどのさまざまなタイプのメッセージをサポートします。XMPP は XML を使用してメッセージを伝送します。バイナリは Base64 でエンコードされ、他のメソッドで処理される必要があります。
- MQTT は、QoS を通じて信頼性の高いメッセージ送信を保証します。XMPP プロトコルでは同様のメカニズムが定義されていません。
MQTT と CoAP
Constrained Application Protocol (CoAP) は、IoT アプリケーション用に設計されたもう 1 つのプロトコルです。CoAP は、MQTT と同様に、制約のあるデバイスおよびネットワーク向けに設計されていますが、いくつかの点で異なります。
まず、MQTT はパブリッシュ/サブスクライブ モデルを使用しますが、CoAP はクライアント/サーバー モデルを使用します。これにより、MQTT はデータを複数のクライアントに分散する必要があるアプリケーションにより適しており、CoAP は 1 対 1 の通信により適しています。次に、MQTT は永続的な TCP 接続を必要としますが、CoAP はより軽量で制約のあるデバイスに適した UDP を使用します。
MQTT と CoAP の比較:
- CoAP はトランスポート メカニズムにステートレスな UDP を使用しますが、MQTT はステートフルな TCP を使用します。
- CoAP は主に 1 対 1 の通信用に設計されていますが、MQTT のパブリッシュ/サブスクライブ モデルは 1 対多または多対多の状況に最適です。
- CoAP にはサービスとリソースの検出が組み込まれていますが、MQTT は事前定義されたトピック名前空間に依存します。
- CoAP は、マルチキャスト、プロキシ、キャッシングなど、MQTT では利用できない機能をサポートします。
MQTT と AMQP
AMQP または Advanced Message Queuing Protocol は、堅牢なメッセージング機能を提供するプロトコルです。AMQP はバイナリ プロトコルであるため、MQTT や HTTP などのテキストベースのプロトコルよりも効率的です。
AMQP は、メッセージ指向、キューイング、ルーティング、信頼性、セキュリティなど、すぐに使える多くの機能を提供します。ただし、AMQP の複雑さは、制約のある環境では欠点になる可能性があります。MQTT は軽量でシンプルなので、このようなシナリオに適しています。
MQTT と AMQP の比較:
- AMQP は MQTT よりもプロトコル オーバーヘッドが高いため、MQTT は制約のある環境により適しています。
- MQTT のトピックベースのフィルタリングは、AMQP の交換やバインディング キーと比較して、よりシンプルかつ直感的です。
- MQTT はより軽量なプロトコルであり、AMQP に比べて機能が少ないですが、これは、展開がより簡単で、多くの IoT アプリケーションに対してより高いパフォーマンスを提供することを意味します。
- AMQP にはピアツーピア機能がありますが、MQTT は厳密にブローカー中心のパブリッシュ/サブスクライブ プロトコルです。
- MQTT には組み込みのメッセージ確認応答がなく、明示的な PUBACK が必要ですが、AMQP には組み込みのメッセージ確認応答機能があります。
IoT 向け MQTT の独特な機能
軽量で効率的
MQTT は、プロトコル自体が占める余分な消費を最小限に抑え、最小限のメッセージ ヘッダーが占める必要があるのは 2 バイトだけです。帯域幅に制約のあるネットワーク環境でも安定して実行できます。同時に、MQTT クライアントは非常に小さなハードウェア リソースを必要とし、リソースに制約のあるさまざまなエッジ デバイス上で実行できます。
信頼性の高いメッセージ配信
MQTT プロトコルは、メッセージングに 3 つのレベルのサービス品質を提供し、さまざまなネットワーク環境で信頼性の高いメッセージングを保証します。
- QoS 0 : メッセージは最大 1 回送信されます。その時点でクライアントが利用できない場合、メッセージは失われます。パブリッシャーはメッセージを送信した後は、それが相手側に送信されるかどうかを気にしなくなり、再送信メカニズムはセットアップされません。
- QoS 1 : メッセージは少なくとも 1 回送信されます。これには単純な再送信メカニズムが含まれています。発行者はメッセージを送信し、受信者からの ACK を待ち、ACK が受信されない場合はメッセージを再送信します。このモデルは、メッセージが少なくとも 1 回到着することを保証しますが、メッセージが繰り返されることは保証しません。
- QoS 2 : メッセージは 1 回だけ送信されます。再送信および重複メッセージ検出メカニズムは、メッセージが確実に相手側に到達し、厳密に 1 回だけ到着するように設計されています。
MQTT QoS の詳細については、ブログ「MQTT QoS の概要」を参照してください。
QoS に加えて、MQTT はClean Sessionのメカニズムを提供します。オフライン期間中に受信できなかったメッセージを再接続後に受信したいクライアントの場合は、接続時に Clean Session を false に設定できます。この時点で、サーバーはクライアントのサブスクリプション関係とオフライン メッセージを保存し、クライアントが再びオンラインになったときにそれらをクライアントに送信します。
大規模な IoT デバイスの接続
MQTT プロトコルはその誕生以来、IoT デバイスの増大を考慮してきました。その優れた設計のおかげで、MQTT ベースの IoT アプリケーションとサービスは、高い同時実行性、高いスループット、および高いスケーラビリティの機能を簡単に実現できます。
巨大なIoTデバイスの接続にはMQTTブローカーのサポートが不可欠です。現在、最大数の同時接続をサポートする MQTT ブローカーは EMQX です。最近リリースされたEMQX 5.0 は、23 ノードのクラスターを通じて1 億の MQTT 接続+ 1 秒あたり 100 万のメッセージを達成し、これまでで世界で最もスケーラブルな MQTT ブローカーとなりました。
安全な双方向通信
MQTT は、パブリッシュ/サブスクライブ モデルに基づいて、デバイスとクラウド間の双方向メッセージングを可能にします。パブリッシュ/サブスクライブ モデルの利点は、パブリッシャーとサブスクライバーが直接接続を確立したり、同時にオンラインになったりする必要がないことです。代わりに、メッセージ サーバーがすべてのメッセージのルーティングと配布を担当します。
セキュリティはすべての IoT アプリケーションの基礎です。MQTT は TLS/SSL を介した安全な双方向通信をサポートしていますが、MQTT プロトコルで提供されるクライアント ID、ユーザー名、パスワードを使用すると、ユーザーはアプリケーション層で認証と認可を実装できます。
キープアライブとステートフルセッション
ネットワークの不安定性に対処するために、MQTT はキープアライブメカニズムを提供します。クライアントとサーバーの間でメッセージのやり取りが長期間行われない場合でも、キープアライブにより接続が切断されなくなります。接続が切断された場合、クライアントはそれを即座に感知し、すぐに再接続できます。
同時に、MQTT はLast Willを使用して設計されており、クライアントが異常にオフラインであることが判明した場合に、サーバーがクライアントが指定されたMQTT トピックに Will メッセージを投稿できるようにします。
さらに、EMQX などの一部の MQTT ブローカーは、オンラインおよびオフラインのイベント通知も提供します。バックエンド サービスが特定のトピックをサブスクライブすると、すべてのクライアントのオンライン イベントとオフライン イベントを受信できるため、バックエンド サービスがクライアントのオンライン イベントとオフライン イベントの処理を統合しに役立ちます。
IoT における MQTT の使用例
インダストリアルIoT
MQTT は、産業用 IoT ( IIoT ) アプリケーションでも広く使用されています。これらのアプリケーションでは、工場内のさまざまなセンサーやデバイスが中央サーバーに接続され、デバイスが監視および制御されます。
たとえば、炉内の温度センサーは、その測定値をサーバー上の MQTT ブローカーに公開する場合があります。センサーのトピックにサブスクライブされているサーバーは測定値を受信し、温度が特定のしきい値を超えた場合に適切なアクションを実行できます。これにより、工場の稼働状況をリアルタイムで監視および制御できるようになり、効率と安全性が向上します。
コネクテッドカー
最後に、MQTT は車両テレマティクス システムで使用され、車両と中央サーバー間の通信を容易にします。これらのシステムでは、位置、速度、燃料レベルなどの車両からのデータが収集され、サーバー上の MQTT ブローカーに公開されます。車両のトピックをサブスクライブしたサーバーはデータを受信し、車両管理、車両メンテナンス、ドライバーの安全などのさまざまな目的に使用できます。
たとえば、配送トラックはその位置データをサーバーに公開する場合があります。サーバーはこのデータを使用してトラックのルートを追跡し、顧客にリアルタイムの最新情報を提供できます。これにより、顧客満足度が向上し、配送エクスペリエンスが向上します。
ホームオートメーション システム
MQTT は、軽量で使いやすいため、ホーム オートメーション システムで広く採用されています。これらのシステムでは、照明、サーモスタット、セキュリティ カメラなどのデバイスが中央ハブに接続されており、スマートフォン アプリを介してリモート制御できます。MQTT は、ハブとデバイス間の通信を容易にするために使用されます。
たとえば、アプリを使用して照明を点灯すると、アプリはハブ上で実行されている MQTT ブローカーにメッセージを発行します。関連するトピックにサブスクライブされているライトがメッセージを受信して点灯します。これにより、デバイスのリアルタイム制御が可能になり、ユーザー エクスペリエンスが向上します。
ウェアラブル デバイス
フィットネス トラッカーやスマートウォッチなどのウェアラブル デバイスも通信に MQTT を使用します。これらのデバイスは心拍数や歩数などのさまざまなデータを収集し、スマートフォンまたはクラウド サーバー上の MQTT ブローカーに公開します。デバイスのトピックをサブスクライブしているサーバーはデータを受信し、それをユーザーに表示したり、さらなる分析に使用したりできます。
たとえば、フィットネス トラッカーは、運動中の心拍数データを公開する場合があります。サーバーはデータを受信し、心拍数が安全な制限を超えた場合に警告を発します。これにより、リアルタイムの健康状態の監視が可能になり、命を救う可能性があります。
IoT ユースケースにおける MQTT 5.0 と MQTT 3.1.1
MQTT 3.1.1 がリリースされ、OASIS 標準となった 4 年後に、MQTT 5.0 がリリースされました。これは大きな改善とアップグレードです。現在の業界のニーズを満たすだけでなく、業界の将来の発展に備えるように設計されています。
MQTT 5.0 では、セッション/メッセージ遅延、理由コード、トピック エイリアス、ユーザー プロパティ、共有サブスクリプションなど、最新の IoT アプリケーションのニーズをより適切に満たすいくつかの重要な機能が追加されています。大規模システムのパフォーマンス、安定性、拡張性が向上します。現在、MQTT 5.0 はほとんどの IoT 企業で優先されるプロトコルとなっており、MQTT を初めて使用する開発者にはこのバージョンを直接使用することをお勧めします。
MQTT 5.0 についてさらに詳しく知りたい場合は、MQTT 5.0 の重要な機能をわかりやすい方法で紹介するMQTT 5.0 Exploreシリーズの記事を読んでみてください。
主要な MQTT コンポーネントを理解する
MQTT ブローカー
MQTT ブローカーは、クライアントによって開始された接続を受信し、クライアントによって送信されたメッセージを他の適格なクライアントに転送する責任を負います。成熟した MQTT ブローカーは、大規模な接続と数百万のメッセージ スループットをサポートできるため、IoT ビジネス プロバイダーがビジネス機能に集中し、信頼性の高い MQTT アプリケーションを迅速に作成できるようになります。
EMQX は、広く使用されている IoT 用の大規模分散 MQTT ブローカーです。2013 年に GitHub でオープンソース リリースされて以来、世界中で 1,000 万回以上ダウンロードされ、接続されている IoT キー デバイスの累計数は 1 億台を超えています。
次の Docker コマンドを使用して EMQX 5.0 オープンソース バージョンをインストールして体験できます。
docker run -d --name emqx -p 1883 : 1883 -p 8083 : 8083 -p 8084 : 8084 -p 8883 : 8883 -p 18083 : 18083 emqx/emqx:latest
完全にホストされた MQTT サービスを EMQX クラウド上に直接作成することもできます。EMQX Cloud の無料トライアルは、クレジット カード設定しなくても利用できます。
MQTT クライアント
MQTT アプリケーションは通常、MQTT クライアント ライブラリに基づいて MQTT 通信を実装する必要があります。現在、基本的にすべてのプログラミング言語には、成熟したオープンソースの MQTT クライアント ライブラリがあります。したがって、EMQ によって照合されたMQTT クライアント ライブラリのリストを参照して、ビジネス ニーズを満たす MQTT クライアントを構築するための適切なクライアント ライブラリを選択できます。EMQ が提供するMQTT プログラミングブログ シリーズにアクセスして、Java、Python、PHP、Node.js およびその他のプログラミング言語で MQTT を使用する方法を学ぶこともできます。
MQTT アプリケーションの開発は、MQTT テスト ツールのサポートとも切り離せません。使いやすく強力な MQTT テスト ツールは、開発者が開発サイクルを短縮し、安定した IoT アプリケーションを作成するのに役立ちます。
MQTTX は、オープンソースのクロスプラットフォーム デスクトップ クライアントです。使いやすく、包括的な MQTT 5.0 機能、機能テストを提供し、macOS、Linux、および Windows 上で実行できます。また、さまざまなシナリオでの MQTT テストのニーズを満たすコマンド ライン バージョンとブラウザ バージョンも提供します。https://mqttx.app/ja にアクセスしてダウンロードして試すことができます。
EMQX を使用した IoT 環境向けの MQTT クイック スタート
この時点で、MQTT プロトコルについては予備的に理解できたと思います。次に、ブログ「MQTTプロトコル解説：基礎知識とクイック・チュートリアル」にアクセスしてMQTT の使用を開始する方法を学習したり、MQTT ガイドシリーズの記事を参照して MQTT プロトコルの機能を学習し、MQTT のより高度なアプリケーションを探索したり、MQTT のアプリケーションやサービスの開発を開始したりできます。