io t縛りの勉強会 #4

Copyright © NIFTY Corporation All Rights Reserved.

ニフティのIoTへの取り組みと、Iotを支えるMQTTサービスについて

Copyright © NIFTY Corporation All Rights Reserved. ‹#›

僕です

ニフティ8～9年目モバイル・IoTビジネス部


僕です

ニフティ8～9年目モバイル・IoTビジネス部

危ない！

バズワードだ

！


僕です

ニフティ8～9年目モバイル・IoTビジネス・ビッグデータ部危うくこうなるところだったらしい


僕です

ニフティ8～9年目モバイル・IoTビジネス・ビッグデータ部

危ない！

バズワードだ

！


はい


Table of Contents

MQTT とは / 特徴 / 事例ニフティクラウド MQTT とはニフティクラウド MQTT の特徴向いているケース / 向いていないケース MQTT 適用において考えるべきこと


MQTT とは


通信のヘッダが最小2バイト

送受信のコストが小さく「非力なデバイス」でもOK 送受信のコストが小さく「ネットワークが不安定な場所」でもOK


Topic ベースでの Pub/Sub

N x M の通信路ではなく、 N + M の通信路でメッセージング


MQTT の事例

Facebook Messenger

https://github.com/mqtt/mqtt.github.io/wiki/Example%20Uses


MQTT の事例

IECC Scalable列車運行の次世代システム



MQTT の事例



実家の電力量が増えると青く、家の電力量が増えると赤く光るだけのおもちゃ


非力なデバイス電池交換が手間電波状況が悪い通信が頻繁小さなデータにベストマッチ！

通信のヘッダが最小2バイト

Topic ベースでの Pub/Sub


ニフティクラウド MQTT とは



MQTT ブローカーをコンパネ上で作成できるサービス 2015年5月11日リリース !できたてほやほや


ニフティクラウド MQTT の特徴


MQTT 市場 ~ 競合 ~

マルチテナント型 sango (時雨堂)

シングルテナント型 CloudMQTT NIFTY Cloud MQTT

OSS mosquitto hiveMQ



同時接続数メッセージ数スループットメッセージサイズ他社A (無料) 6 50,000/月 - 6KB他社A (500円/月) 50 120,000/月 - 50KB他社B (無料) 10 - 10Kbit/Sec -他社B ($299/月) 10,000 - 10Mbit/Sec -NIFTY Cloud MQTT 100 無制限 50KB/Sec

Will Retain QoS TLS WebSocket WebSocket Secure サポート他社A (無料) ✔ ✔ 0 - ✔ - -他社A (500円/月) ✔ ✔ 0,1,2 ✔ ✔ ✔ ✔

他社B (無料) ✔ ✔ 0 ✔ - ✔ ✔

他社B ($299円) ✔ ✔ 0 ✔ - ✔ ✔

NIFTY Cloud MQTT ✔ ✔ 0,1,2 ✔ ✔ ✔ -



同時接続数メッセージ数スループットメッセージサイズ他社A (無料) 6 50,000/月 - 6KB他社A (500円/月) 50 120,000/月 - 50KB他社B (無料) 10 - 10Kbit/Sec -他社B ($299/月) 10,000 - 10Mbit/Sec -NIFTY Cloud MQTT 100 無制限 50KB/Sec

Will Retain QoS TLS WebSocket WebSocket Secure サポート他社A (無料) ✔ ✔ 0 - ✔ - -他社A (500円/月) ✔ ✔ 0,1,2 ✔ ✔ ✔ ✔

他社B (無料) ✔ ✔ 0,1,2 ✔ - ✔ ✔

他社B ($299円) ✔ ✔ 0 ✔ - ✔ ✔

NIFTY Cloud MQTT ✔ ✔ 0,1,2 ✔ ✔ ✔ -

同時接続数

100

メッセージ数

/サイズ無

制限(※)

※ Pub/Su

b 合計スルー

プットでの制

限


向いているケース / 向いていないケース


MQTT の特徴 (再掲)

ヘッダーサイズが最小で 2 byte 送受信のコストが小さく「非力なデバイス」でもOK 送受信のコストが小さく「ネットワークが不安定な場所」でもOK

Topic ベースでの Pub/Sub 1対1、1対N、N対Nのメッセージ配布 MQTT プロトコルを話せる「(MQTT) ブローカー」と呼ばれるサーバが必要


MQTT の特徴

ヘッダが小さい MQTT 最小のヘッダ: 2byte HTTP 最小のヘッダ: 14byte “GET / HTTP/1.1”

➔たかだか12byte Pub/Sub型ブローカーが必要スター型


つまり

ヘッダメッセージ数のサイズに依存して、12byteの価値が変わる 50KBのペイロードを送るなら MQTT 5122 vs. HTTP 5132 …

その他の情報に依存して、12byteの価値が変わる TLS (mqttブローカーの実装依存)の情報の交換が発生して、かつ 1 Connect 1 Publish という利用実態だと2byteの価値がない

メッセージサイズが小さい(温度・デシベル)都度 TLS Connection をしない発砲頻度が少ない(日に1回など)

※ 日に1億 Publish されれば 12byte でもネットワーク流量全体としては価値になる

向いているケース


つまり

Pub/Sub型スター型 p2p でコネクションの数が少ない(特定の間でしかやりとりがない場合)は、価値がでない N:M であれば MQTT: Publish N + Subscribe M HTTP: Publish N * Subscribe M

N:M の複数のクライアント間でのメッセージ交換

向いているケース


MQTT 適用において考えるべきこと


考えるべきこと

MQTT の特徴を理解した上で

それ、本当に MQTT だとメリットがあるの？枯れた HTTP/S の方がいいんじゃないの？

HTTP2 もあるよ！

を俯瞰して判断する

io t縛りの勉強会 #4

Software