FJCT_ニフクラ mobile backend(mBaaS)お役立ちブログ

スマホアプリ開発にニフクラ mobile backend(mBaaS)。アプリ開発に役立つ情報をおとどけ!

今後注目のプロトコルであるMQTTを知ろう

https://cdn-ak.f.st-hatena.com/images/fotolife/f/fjct/20171017/20171017171838.png

現在、WebアプリやWeb APIはHTTPを使って提供されています。しかし今後インターネットに接続するデバイスが増加し、それに伴ったネットワーク量が増大するのを見込んで新しいプロトコルに注目が集まっています。それがMQTTです。

MQTTはHTTPにとって代わるものではありませんが、特にIoTデバイスのような小型、かつ無数のデバイスに対して安定的なネットワークを提供する上で注目のプロトコルになっています。今回はその特徴と、簡単な使い方を紹介します。

そもそもMQTTとは?

MQTTとはMQ Telemetry Transportの略語で、PubSubに基づく軽量なメッセージプロトコルになっています。PubSubとはPublisher(発行者=送信側)とSubscriber(購読者=受信者)に分かれるメッセージングの仕組みになります。これまでのHTTPの仕組みでは、Webサーバがあって、そこにWebブラウザなどが接続する、いわゆるプル型でした。

それに対してMQTTの場合、SubscriberがPublisherに対してメッセージの購読を希望します。そしてPublisherが発行したメッセージをSubscriberが受け取って、処理を行います。この時、Subscriberは直接Publisherにつなぐのではなく、Broker(ブローカー=仲介者)に接続して購読します。

つまりPublisherはBrokerにだけメッセージを発信すればよく、かつそのタイミングは任意で良くなります。そして各Subscriberはメッセージができたタイミングで受け取れるようになるので、よりリアルタイムになります。なお、この時Publisherが発行するメッセージはトピックと呼ばれるカテゴリをつけて送ります。また、Subscriberもトピックを指定して受信します。そのため不要なメッセージを受け取らずに済んだり、複数のメッセージによる処理分けが簡単にできるようになります。

利用例

IoT分野において注目を集めていますが、例えばFacebookメッセンジャーでもMQTTが使われています。また、MQTTではありませんがGoogleのインデックス化を高速化するための仕組みとしてPubSubHubbubがあります。こちらも更新されたWebサーバ側からブローカーになるURLに対して通知を行うことでGoogleのクローラーが検知してインデックス化する仕組みです。

さらにIntel社が販売しているIntel EdisonにおいてはデフォルトでMQTTのPublisherが立ち上がっています。これはIntel社が提供するIoTデバイス向けサービスで使われているためです。

なぜMQTTなのか?

MQTTが注目を集めているのはHTTPに比べてオーバーヘッドが小さいということが挙げられます。固定長2バイトで、HTTPに比べると1/10〜1/100くらいの大きさになります。その分、スループットが大きくなります。ネットワーク転送量が小さくなれば、それだけ電力消費量も小さくて済むのが利点です。

また、PubSub型ということで、各サービス間の接続は疎結合に保たれるということです。Publisherは誰が購読しているのか気にする必要はありません。とにかくBrokerに対して発信するだけです。その逆にSubscriberは自分が購読したいトピックだけ指定すれば、必要な情報のみ処理できるようになります。もしSubscriberが増えたとしても、Publisherの負荷は変わりませんので、Brokerを増やせば良いだけになります。従来のインターネットの場合、各サーバは独立していますので、3つのサービスがあった場合、Aの負荷が高まるとサーバを増強しなければならず、BやCに負荷を分散することはできませんでした。MQTTのようなPubSub型の場合、Publisherは台数を増やさず、その間にあるBrokerで負荷分散が可能になります。

双方向通信

MQTTではお互いにPublisher、Subscriberの関係になれます。そのため互いにメッセージ交換が可能になります。また、それをさらに複雑化することでn対mの通信も可能になります。ただしネットワーク、Brokerの負荷は増えますので、購読するトピックを予め決めたり、発信側の仕様を考えるなど、設計が重要になってくると思われます。

品質

ネットワークのことなので、その品質はとても大事です。MQTTではメッセージの品質を3段階で決められるようになっています。正確に1回配信するQoS 2、少なくとも1回(ただし重複する可能性あり)なQoS 1、最高1回(届く保証なし)なQoS 0の3つです。普段のメッセージはQoS 0で発信しつつ、重要なものについてはQoS 2で配信するなどといった使い分けが必要でしょう。

また、Subscriberが再接続後に切断中に発信されたメッセージを受け取れるDurable subscribe、Publisherが切断した際に予め決めておいたメッセージを流すLast Will and Testament、そして後から購読してきた時に最後のメッセージを配信するRetainといった仕組みが用意されています。この辺りもHTTPにはない機能なのでMQTTを用いる時の設計として考える必要があるでしょう。

さいごに

いかがでしょうか。今回はMQTTの概要を紹介しました。次回はMQTTを実際に使ってみたいと思います。