ストリーム処理勉強会 大規模mqttを支える技術

1. ⼤規模MQTTを⽀える技術(のための相談)
ストリームデータ処理技術勉強会
2017/8/4
Future Architect Inc,
Keigo Suda

2. どういった構成で何がポイントとなったか
ü どういった課題があったか
ü どのように対応したか
ü MQTTにプロトコル仕様などは話しません
物流IoTのメッセージングの話

3. ＊ Technology Innovation Group
＊ ビッグデータユニット リーダー
＊ 最近の専⾨ -> ストリーム処理のあれこれ
須⽥桂伍 (すだ けいご)
@keigodasu

4. もくじ
l 全体の概要
l メッセージングの話
l MQTTプロダクト選定の話
l これからの課題

5. 全体の概要

6. 全体の概要
l 物流系のIoTなシステム
l トラックなど⾞両等から位置情報やイベント情報を収集するための仕組み
l クラウド側(AWS)からデバイスに対する制御処理もあり
l 数⼗万デバイスからの連携

7. システムの全体像
ローデータ配置先
ストリーム
集計・広範囲スキャン
アーカイブデータ配置先
時系列データ
上り受付&プロトコル変換 全システム共通バス
ジオデータ サービスAPI
下り制御処理
サービス間接続
MQTTS
MQTTS
MQTTS
MQTTS
フィールド側 クラウド側

8. システムの全体像
ローデータ配置先
ストリーム
集計・広範囲スキャン
アーカイブデータ配置先
時系列データ
上り受付&プロトコル変換 全システム共通バス
ジオデータ サービスAPI
下り制御処理
サービス間接続
MQTTS
MQTTS
MQTTS
MQTTS
フィールド側 クラウド側
これから話すところ(メッセージング)

9. メッセージングの話

10. メッセージング部分の詳細
イベント/コマンドデータ受付
センサデータ受付
バイナリデータ格納ストレージ
ブリッジアプリ
ブリッジアプリ
MQTT
MQTT
HTTPS
HTTPS
HTTPS
MQTTS
MQTTS
メッセージバス ストリームエンジン
ブローカーにMQTTからHTTPSへ変換し連
携するブリッジアプリケーションを配置
直近の連携されたメッセージデータを永続化MQTTS
時系列データ⽣成
ジオデータ⽣成
通知データ⽣成
利⽤形態/メンテナンス単位に
ストリームアプリケーションはデプロイ
センサストリーム
イベントストリーム
センサデータの連携
イベント/コマンドデータの連携
バイナリデータの連携
センサデータ
イベントデータ
コマンドデータ
デバイスから定常的に発⽣するデータ
デバイスの状態変化などイベントをトリガーに発⽣するデータ
デバイスからのクラウド側へ要求を出す際に発⽣するデータ

11. イベント/コマンドデータ受付
センサデータ受付
定常的に発⽣するセンサデータは、都度最新のデータ
を取得する、時間をおいた再送で情報を補填可能で
あるため、性能を重視しQoS=0(at most once)
で連携
バイナリデータ格納ストレージ
ブリッジアプリ
ブリッジアプリ
センサデータの連携
イベント/コマンドデータの連携
バイナリデータの連携
状態の変化などイベントをトリガーに発⽣するイベント
データは、当該イベントに基づいてクラウド側での判断
及び制御処理が⾏わるため、確実性を重視し
QoS=1(at least once)で連携
画像などの⼀つのサイズが⼤きいバイナリデータは、
バッファリングを⾏いながら連携する必要があるため
HTTP(S)でプロトコルの機能を利⽤し連携
MQTT
MQTT
HTTPS
HTTPS
HTTPS
MQTT
MQTT
MQTT
QoS=0
QoS=1
QoS=1
データ種毎に応じた到達保証
l 連携されるデータの種類や、処理特性に応じてメッセージ到達保証を調整
l ⼊り⼝から分けてしまう⽅が扱いやすい(エラー時の切り分けとか)

12. クラウドからのフィールド制御
l 基本はQoS=1(at least once)で連携し、アプリケーション側でのハンドリング
l プロトコルで到達保証はほどほどに
フィールドトリガー
フェールドからのイベントデータ/コマンドデータをもとに、
クラウド側で判断処理が⾏われ、その結果をもとに
フェールドへの制御処理が⾏われるパターン。
クラウドトリガー
MQTT
MQTTMQTT
publish
publish
subscribe
subscribe
MQTT
HTTP
subscribe publish MQTT
HTTP
1. イベントもしくはコマンドデータが発⽣ 2. データ内容に応じた処理を実施
3. 処理結果もしくは次アクションを⽣成4. 処理結果をより取得し次アクションへ
2. プラットフォームより通知を作成3. 通知内容をプラットフォームより取得
4. 処理結果をもとにした次アクションへ
(例：オブジェクトストレージからのダウンロード)
1. プラットフォームより通知処理が必要な処理が発⽣
(例：エッジからのバイナリダウンロード処理)
クラウド側からエッジへ通知処理が⾏われ、その内容を
もとにデバイスが次アクションを実⾏するパターン。
QoS=1 QoS=1
QoS=1 QoS=1
QoS=1 QoS=1
MQTT

13. MQTT→Kinesisへのブリッジアプリケーション
l ブリッジアプリはMQTTトピックをサブスクライブし、Kinesis Producer
Library(以下KPL)を利⽤してKinesiへProduce処理を実施
Subscriber KPL
ブリッジアプリケーション
MQTT HTTPS
Subscribe Produce
Topic

14. ブリッジのシーケンス
Subscirber KPLMQTTブローカー Kinesis
Subscirber KPLMQTTブローカー Kinesis
データをSubscribe
KPLへメッセージをPut
KPLへメッセージをPut
KPLへメッセージをPut
データをSubscribe
データをSubscribe
メッセージをバッファリング
メッセージに集約してKinesisへProduce
ブリッジアプリケーション

15. どのようにスケーラビリティを確保する？
l MQTTブローカーにはクラスタリング機能を備えているものも多いが、あくまで内部
ルーティング,フォワード機能であることが多い
l Apache Kafkaと同じノリで処理性能をスケールできない(できるものもある？)
MQTTブローカー#2
Publisher
MQTTブローカー#3MQTTブローカー#1
topic/a Topic/b Topic/c
Topic/aにPublish
forward

16. じゃあ・・・
l トピックをシャーディングする？(some-topic/1, some-topic/2 ・・・)
l クライアント側でシャーディングを意識する必要あり。。。
l クライアント側はロジックをあまり持たせたくない(不特定多数なので変更時の対応・・・)

17. ストレートレスに並べていく
ブリッジアプリ
MQTTブローカー
MQTTブローカー
MQTTブローカー
同⼀名の
トピック
トピック
同⼀キュー名で全ブローカーにキューを作成
どのノードにもパブリッシュできるようにする
ローカルのキューのみをサブスクライブし、
KinesisへメッセージをProduce
オートスケーリング時はトピックキュー情報を取得し、
同⼀の構成に初期化後参加する
構成情報管理
MQTT
全システム共通バス
ブリッジアプリトピック
ブリッジアプリトピック

18. オートスケール時のステップ
1. EC2起動 2. 初期化 3. スケールアウト 4. スケールイン
1
2 1 2
1
2
負荷状況をもとにアラームが発⽕し、
オートスケーリング(スケールアウト)が発動
EC2が新たに起動し、Lifecycle hook発⽕
1
2
MQTTブローカー上に存在するキュー情報を取得
取得したキュー情報をもとに同⼀のキューを作成
1 キュー作成後、ELBにアタッチされ処理を開始 1
2
負荷状況をもとにアラームが発⽕し、
オートスケーリング(スケールイン)が発動
EC2がELBから外され、Lifecycle hookが発⽕
3 Lifecycle hookでキュー内の未処理データを
全てKafkaへProduce後、Terminate
2
1
1
3

19. MQTTプロダクト選定

20. プロダクト選定にあたっての⽐較ポイント
l ⽐較の際によく取り上げらえるポイント
l 対応しているMQTTバージョン
l サポートされているQoSレベル
l SSL/TLS対応
l Retain対応
l Will対応
l WebSocket対応
l クラスタリング機能 etc

21. 実際のところ(今回の場合)
l よく違いがでるのはサポートするQoSレベルとクラスタリング可能か、それ以外はだいたいサポートされて
いることが多い(と思う)。
l Exactly Onceの保証はそもそも難しい。(メッセージング/ストリーム処理でいつも話題にあがるあれ)
l 前述したようにデータ種や処理に応じてメッセージ到達保証はどのみち妥協しなくちゃいけない。
l となると、QoSは0,1さえサポートされていれば⼗分で、クラスタリング可能かどうかは前述したとおり重
要ではなかった。(リトライ/冪等/アプリで重複排除・・・)

22. 選定候補
l 実績、情報が多いものから優先的に選択(ただでさえ情報少ないのに・・・)
l スクラッチも考えたが、ただでさえ情報が少ないなか冒険かと思い⼀旦除外
vs

23. 負荷実施条件を記載
l メッセージサイズ 1KB
l クライアント数 1,000
l リクエスト数 10req/sec(1クライアントあたり)
l Retainはなし
l Gatling + MQTTプラグイン+ ECSでクライアント数を調整(すごい便利！！)
MQTT
MQTT
MQTT
MQTT
MQTT

24. 実施結果
ブローカー インスタンスタイプ
QoS＝0 QoS=1
CPU Ave 99th CPU Ave 99th
c4.large
(2 vCPU)
70% 0msec 1msec 70% 100msec 639msec
c4.xlarge
(4 vCPU)
20% 0msec 1msec 20% 4msec 4msec
c4.xlarge
(2 vCPU)
100%
終わらず
打ち切り
終わらず
打ち切り 100%
終わらず
打ち切り
終わらず
打ち切り
c4.xlarge
(4 vCPU)
100% 0msec 1msec 100% 999msec 4,753msec

25. それぞれの特徴(QoS=0の時)
Mosquitto(c4.large) RabbitMQ(c4.large)
処理がはけきれず途中で打ち切り

26. RabbitMQのMQTTプラグイン
l MQTTプラグインは、RabbitMQのExchange/Queueの仕組みの上で動く
l Exchangeでの配送⽅法はTopic
l この機構が原因？調査しきれず。。。

27. いろいろプロダクトいじってみてのつらみ
l ノウハウ少ない。。(本当にこれでいいのか常に不安)
l チューニングポイントのあたりをつけるところから⼿探りでスタート
l 詳細な事例も少ないので構成パターンの検討も⼿探りでスタート
l パラメータが少ない。。
l いざパラメーターチューニングをはじめだすと設定できる箇所が少ない
l ⼿持ちが少なすぎて性能が頭打ちになった時に毎回詰んだ気持ちになる

28. 課題とまとめ

29. 結構⼼配。。。
l 暖気なしELBがどれぐらい安定してリクエスト受け切れるか。。。
l ELBが暖気なし状態でさばける具合の探りが必要
l IoTってアクセスピーク特性ってあるようなないような

30. ありがとうございました!!