IoTで注目されているMQTT, publish/subscribeとは
 Author: 水卜
IoT

目的

IoT関連の現場でよく聞くMQTTやpub/subとは何なのか、どういった場面で使用されるのかを理解し、簡単に手を動かしてみます。

MQTTとは

MQTT は、Publish/Subscribe メッセージングモデルにより、非同期に 1 対多の通信ができるプロトコルです。
プロトコル仕様は、軽量かつシンプルにデザインされています。IoT（Internet of Things）や M2M（Machine to Machine）などのように、小メモリやネットワーク帯域幅が限られているような環境での利用に適しています。

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

Publish/Subscribeモデル

Publish/Subscribeモデルは、イベントを起こす側と処理を行う側を分離するモデル。

JavaScriptのイベントトリガーをイメージするとわかりやすい。

イベントトリガーは、幾つの、どんなイベントが起こるかを気にすることなく、addEventListenerで追加されたイベントをまとめて発火させることができる。

メッセージを送信する側をPublisher, メッセージを受け取る側をSubscriberとしている。

このモデルでは、PublisherはMQTT Serverを経由してSubscriberにメッセージを送信することができる

PublisherとSubscriberはお互いを知らない。Publisherはどの、何台のSubscriberに届くのかを知らない。同様にSubscriberはどのPublisherからメッセージが届いているのかを知らない。

SubscriberはMQTT Serverにどんなメッセージが欲しいかリクエストを送る。これをSubscribeと呼ぶ。

MQTT ServerはSubscribeを元に、Publisherからの情報を仕分けして、適切なSubscriberに送信する。

Topic

MQTTのメッセージは/区切りのTopicを持つ。

aaa/bbb/ccc
aaa/bbb/ddd
aaa/ccc/eee
Topic 意味
office/fukuoka/3F/temp 福岡オフィス 3 階の温度情報
office/fukuoka/3F/humid 福岡オフィス 3 階の湿度情報
office/tokyo/3F/temp 東京オフィス 3 階の温度情報
office/tokyo/3F/humid 東京オフィス 3 階の湿度情報
office/tokyo/4F/temp 東京オフィス 4 階の温度情報
office/tokyo/4F/humid 東京オフィス 4 階の湿度情報

福岡オフィス 3 階の温度情報メッセージを受け取りたい場合は、Topic office/fukuoka/3F/temp で Subscribe します。

また、福岡オフィス 3 階の温度情報メッセージだけでなく、東京オフィス 3 階の温度情報メッセージも受け取りたい場合は、Topic office/fukuoka/3F/temp と Topic offie/tokyo/3F/temp で Subscribe します。

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

HTTPとの比較

HTTP MQTT
同期/非同期 同期 非同期
送受信対象 1対1 多対多
データ量 大きい（重い） 小さい（軽い）
通信が不安定 ×（送受信不可） ○（再送受信可能）

MQTTは非同期なので、サーバー側の障害によって送信できなかったデータを復帰後に再送信することができます。

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

活用場所

油田パイプラインの監視

使われた場面

油田パイプラインの状態(油圧や油温など)を計測するセンサーと衛星の間の通信。

選ばれた理由

4000台のセンサーを使用中、さらに8000台を追加する必要があり、ネットワークコストを下げたかった。

衛星が通信範囲の外に出てしまうと、データの送受信に失敗する可能性が高くなるので、HTTPのような安定した接続を必要とするプロトコルでは対応できない。

MQTTは非同期プロトコルなので、接続失敗によって送信に失敗しても、再接続したときにデータを届けることができる。

出典: https://amg-solution.jp/blog/15787

Messenger

使われた場面

メッセージの送受信

選ばれた理由

送信データのサイズが小さいため、送受信が他のプロトコルよりも速いこと。

モバイル機器にとっては、帯域幅が狭くても送信できること、バッテリー消費が少ないことが利点になるため。

出典: https://amg-solution.jp/blog/15787

ペースメーカーの監視

使われた場面

患者のペースメーカーの状態を遠隔で監視する。

患者が診療所に通わなくても医者が心臓の動きを監視できるようになった。

心臓の動きに異常があったときに即座にわかるようになった。

選ばれた理由
※MQTTを選んだ理由をはっきり述べた情報を見つけられなかったため、私個人の推測になります。

ペースメーカーのバッテリーの消耗を抑えられる。

管理センター側に障害が発生しても、心臓の動きのデータは復帰時に再送信できる。

患者の近くにあるスマホにデータを送信する場合に、通信のやや不安定なbluetoothを使ってもデータ送信を保証できる。

出典: https://amg-solution.jp/blog/15787

redisのpub/sub機能を試してみる

手元のmacでどんなものか試してみます。

Install, Serve

$ brew install redis
$ redis-server

Subscriberのセットアップ

$ redis-cli
127.0.0.1:6379> SUBSCRIBE sample_channel
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "sample_channel"
3) (integer) 1

これでsample_channelをSubscribeした状態になりました。

次にPublisherをセットアップします。

Publisherのセットアップ

ターミナルをもう一つ起動します。

$ redis-cli
127.0.0.1:6379> PUBLISH sample_channel "First message"
(integer) 1
127.0.0.1:6379>

確認

Subscriberのターミナルに以下が表示されました。送信できているようです。

1) "message"
2) "sample_channel"
3) "First message"