More Related Content Similar to ストリーム処理勉強会 大規模mqttを支える技術 (20) ストリーム処理勉強会 大規模mqttを支える技術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
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
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