IoT向け通信プロトコルのMQTTとは？

【結論】

• MQTTは通信プロトコルの一つで、パブリッシュ/サブスクライブ方式を採用している。
• MQTTでは送受信するデータをトピックと呼ぶ。
• MQTTは、現実世界の新聞の配達方式を採用した通信方式である。
• 新聞社(送信する機器)が新聞(トピック)を発行(パブリッシュ)し、新聞(トピック)を読みたい人(トピックを受信したい機器)が購読(サブスクライブ)する。

【目次】

はじめに

以前、転職活動時のポートフォリオとして、LINEへのメッセージ送信でエアコンを制御するシステムを作成しました。下図はその際に書いたシーケンス図です。

スマホからエアコンは制御できないので、スマホ→LINE→AWS→RasberryPi→エアコンの流れで制御するようにしています。

動くものを作って「やったー!!」で終わってはもったいないので、ブログのネタにします。

と言っても、一気に全部ネタにすると尽きてしまうため、今回はAWSとRaspberryPi間で通信する際に使用するMQTTプロトコルについて書いていきます。

MQTTとは

Message Queue Telemetry Transportの略で、1999年にIBMとEurotech社によって作られ始めた通信プロトコル。TCP/IP上で使われることを想定しており、インターネットを介したマシン間通信や、マシンと別のインターネット上のリソースとの通信を行うことに特化している。

パブリッシュ/サブスクライブ(PubSub)モデルを採用している。

データを送信(パブリッシュ：発行)する側をパブリッシャ、データを受信(サブスクライブ：購読)する側をサブスクライバと呼ぶ。データはトピックという単位で扱われ、サブスクライバは受信したいトピックをサブスクライブ(購読)することで、パブリッシャがそのトピックにパブリッシュ(発行)したデータを受け取ることができる。

マシン側では接続先のマシンについての考慮が不要になる。

パブリッシュ/サブスクライブモデルでは、マシンとマシンの間に仲介役のブローカ(実態はサーバ)がいて、トピックの管理やサブスクライバ/パブリッシャとなるクライアントの接続管理している。マシン側では接続先のマシンは気にせず、ブローカが管理するトピックに対してデータをパブリッシュ/サブスクライブすることだけを考えればいい。

データ通信はバイナリ形式で行うため、通信量が少ない。

同じデータをHTTP通信で送る時と比較すると通信料が少ないようです。

本当は実際にPCで動かしてみたかったのですが今回はスルーします。

通信品質(QoS)の設定を0,1,2の三段階で設定できる。

QoS0:メッセージ到達は最大で1回、届かなかったとしても再送しない。

QoS1:メッセージ到達は少なくとも1回は保証するが重複する可能性もある。

QoS2:メッセージ到達は1回だけ、重複もなく確実に1回送る。

パブの後からサブした人にも届けるRETAIN機能がある。

トピックをサブスクライブ(購読)すると、基本的にはそれ以降にパブリッシュ(発行)されたトピックに対しては、データを受け取ることができるが、サブスクライブする前にパブリッシュされたデータは受け取れない。

RETAIN機能を有効にすると、そのトピックに対してパブリッシュされたデータの最新の1件だけMQTTブローカが保持してくれる。

サブスクライバの突然死を監視するWill機能がある。

Willとは「遺言」の意味で、サブスクライブする際に、Will用のトピックへ遺言メッセージを残すことができる。Willを設定したサブスクライバは、ブローカとの通信が途切れると、遺言メッセージがWillトピックに対して自動的にパブリッシュされます。このWillトピックを、例えばシステム管理者のような役割のアプリケーションがサブスクライブすることで受け取り、今ちゃんと生きているサブスクライバを一元管理できます。

参考情報

http://devcenter.magellanic-clouds.com/learning/mqtt-spec.html

http://public.dhe.ibm.com/software/dw/jp/websphere/wmq/mqtt31_spec/mqtt-v3r1_ja.pdf

さいごに

底無し沼にハマったみたいにやる気がでないけど、ブログ更新したいから昔まとめたメモを引っ張り出してきました。