mqttmt.jpg

今日は仕事をちょっと早く切り上げて、株式会社ドワンゴさんで行われた「MQTT Meetup Tokyo」に参加してきました。実は先週同じイベントがあったのですが、そちらは人気があって急遽同じ会を行う事になったそうです。

今回は、ツキノワ株式会社の若山氏(@r_rudi)と、株式会社時雨堂の@voluntas氏の講演が行われました。

MQTTの機能概要 〜新仕様の紹介も少し〜

MQTT meetup in Tokyo 機能概要 from r_rudi

MQTTの特徴を、できたてホヤホヤのMQTTクライアントを使ったデモを交えてご紹介。特にWill/Retain/CleanSessionのデモは、「確かに遺言だー」「CleanSession復帰した瞬間送られてきたー」というのが分かりやすくてよかったです。

休憩の際にどら焼きを頂きました。

dorayaki.jpg

MQTTブローカーAKANEの実装にあたってつらかった話

時雨堂 MQTT ブローカー (AKANE)

先月末にサービスインしたばかりのMQTT as a ServiceのSangoで、Erlang製MQTTブローカーAKANEを実装するにあたって、仕様周りやそれに素直に従った際のつらみなどを面白おかしく聞かせて頂きました。

メモ

  • 固定ヘッダは2バイトだけど、ペイロードが大きければHTTPと変わらない
    • MQTTではクライアントが万単位で接続される世界を想像する
    • ペイロードにはJSONやMessagePackを積む事が多い
  • （PublisherがSubscriberにもなれる事から）Microservice的プロセス間通信に使えそう
    • TopicにUUIDを指定してPub/Subすれば一対一の通信ができる
  • NATを超えて双方向通信できる
  • Topicは#や+を使って特定の階層や合致するもの全てを対象とする事ができる
    • SNMPのMIBみたいな感じ？
  • 最新のMQTT仕様が今月27日に確定する予定
    • Topic名がUTF-8固定に
  • 商用MQTTブローカーは世の中に2製品しかない
  • Will/Retain/CleanSessionのクライアント側負担が小さい分サーバ側は負担が大きい
    • QoSダウングレード
    • リトライとRetain
      • これら全てQoSダウングレード＆リトライ＆Retaionの面倒見る必要あり
    • $SYS Topicの統計情報管理
  • github.comはWebhookで既にMQTT対応済み（！）
    • Facebookメッセンジャーの通信もMQTTらしい
  • Erlangはメッセージパッシングすると性能劣化する
  • 同期通信をやりたいならHTTPの方が向いている
  • サービス名であるsangoの由来は色
    • 他のプロダクトも色由来らしい
  • MQTTはエラー定義が少ない
  • クライアント側でもバッファ処理などはある程度必要
  • QoS2はDBの二相コミットと同じ

meijiza.jpg

感想など

個人的な興味から参加した会でしたが、やはり文章で見るより面と向かって語られた方が可能性をより感じる事ができました。

元々はモバイルアプリの行動ログ送信や、リアルタイムチャットのプロトコルとして使ったら面白そうと思っていたのですが、ほとんどがQoS2の送達保証を選ぶ事になりそうで、HTTPとの差別化をどう出していくかが難しそうに感じました。

とりあえず、自宅で部屋の温度を測定し続けているRaspberry PiにでもMQTTをしゃべってもらって、引き続き可能性を探っていきたいと思います。
（ちなみに部屋の温度はXivelyに送っているのですが、普通にMQTTに対応してました。そりゃ"IoT Platform"を名乗るだけあって当たり前か^^;）