Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

2,596 views

Published on

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

Published in: Internet

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

  1. 1. ⼤規模MQTTを⽀える技術(のための相談) ストリームデータ処理技術勉強会 2017/8/4 Future Architect Inc, Keigo Suda
  2. 2. どういった構成で何がポイントとなったか ü どういった課題があったか ü どのように対応したか ü MQTTにプロトコル仕様などは話しません 物流IoTのメッセージングの話
  3. 3. * Technology Innovation Group * ビッグデータユニット リーダー * 最近の専⾨ -> ストリーム処理のあれこれ 須⽥桂伍 (すだ けいご) @keigodasu
  4. 4. もくじ l 全体の概要 l メッセージングの話 l MQTTプロダクト選定の話 l これからの課題
  5. 5. 全体の概要
  6. 6. 全体の概要 l 物流系のIoTなシステム l トラックなど⾞両等から位置情報やイベント情報を収集するための仕組み l クラウド側(AWS)からデバイスに対する制御処理もあり l 数⼗万デバイスからの連携
  7. 7. システムの全体像 ローデータ配置先 ストリーム 集計・広範囲スキャン アーカイブデータ配置先 時系列データ 上り受付&プロトコル変換 全システム共通バス ジオデータ サービスAPI 下り制御処理 サービス間接続 MQTTS MQTTS MQTTS MQTTS フィールド側 クラウド側
  8. 8. システムの全体像 ローデータ配置先 ストリーム 集計・広範囲スキャン アーカイブデータ配置先 時系列データ 上り受付&プロトコル変換 全システム共通バス ジオデータ サービスAPI 下り制御処理 サービス間接続 MQTTS MQTTS MQTTS MQTTS フィールド側 クラウド側 これから話すところ(メッセージング)
  9. 9. メッセージングの話
  10. 10. メッセージング部分の詳細 イベント/コマンドデータ受付 センサデータ受付 バイナリデータ格納ストレージ ブリッジアプリ ブリッジアプリ MQTT MQTT HTTPS HTTPS HTTPS MQTTS MQTTS メッセージバス ストリームエンジン ブローカーにMQTTからHTTPSへ変換し連 携するブリッジアプリケーションを配置 直近の連携されたメッセージデータを永続化MQTTS 時系列データ⽣成 ジオデータ⽣成 通知データ⽣成 利⽤形態/メンテナンス単位に ストリームアプリケーションはデプロイ センサストリーム イベントストリーム センサデータの連携 イベント/コマンドデータの連携 バイナリデータの連携 センサデータ イベントデータ コマンドデータ デバイスから定常的に発⽣するデータ デバイスの状態変化などイベントをトリガーに発⽣するデータ デバイスからのクラウド側へ要求を出す際に発⽣するデータ
  11. 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. 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. 13. MQTT→Kinesisへのブリッジアプリケーション l ブリッジアプリはMQTTトピックをサブスクライブし、Kinesis Producer Library(以下KPL)を利⽤してKinesiへProduce処理を実施 Subscriber KPL ブリッジアプリケーション MQTT HTTPS Subscribe Produce Topic
  14. 14. ブリッジのシーケンス Subscirber KPLMQTTブローカー Kinesis Subscirber KPLMQTTブローカー Kinesis データをSubscribe KPLへメッセージをPut KPLへメッセージをPut KPLへメッセージをPut データをSubscribe データをSubscribe メッセージをバッファリング メッセージに集約してKinesisへProduce ブリッジアプリケーション
  15. 15. どのようにスケーラビリティを確保する? l MQTTブローカーにはクラスタリング機能を備えているものも多いが、あくまで内部 ルーティング,フォワード機能であることが多い l Apache Kafkaと同じノリで処理性能をスケールできない(できるものもある?) MQTTブローカー#2 Publisher MQTTブローカー#3MQTTブローカー#1 topic/a Topic/b Topic/c Topic/aにPublish forward
  16. 16. じゃあ・・・ l トピックをシャーディングする?(some-topic/1, some-topic/2 ・・・) l クライアント側でシャーディングを意識する必要あり。。。 l クライアント側はロジックをあまり持たせたくない(不特定多数なので変更時の対応・・・)
  17. 17. ストレートレスに並べていく ブリッジアプリ MQTTブローカー MQTTブローカー MQTTブローカー 同⼀名の トピック トピック 同⼀キュー名で全ブローカーにキューを作成 どのノードにもパブリッシュできるようにする ローカルのキューのみをサブスクライブし、 KinesisへメッセージをProduce オートスケーリング時はトピックキュー情報を取得し、 同⼀の構成に初期化後参加する 構成情報管理 MQTT 全システム共通バス ブリッジアプリトピック ブリッジアプリトピック
  18. 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. 19. MQTTプロダクト選定
  20. 20. プロダクト選定にあたっての⽐較ポイント l ⽐較の際によく取り上げらえるポイント l 対応しているMQTTバージョン l サポートされているQoSレベル l SSL/TLS対応 l Retain対応 l Will対応 l WebSocket対応 l クラスタリング機能 etc
  21. 21. 実際のところ(今回の場合) l よく違いがでるのはサポートするQoSレベルとクラスタリング可能か、それ以外はだいたいサポートされて いることが多い(と思う)。 l Exactly Onceの保証はそもそも難しい。(メッセージング/ストリーム処理でいつも話題にあがるあれ) l 前述したようにデータ種や処理に応じてメッセージ到達保証はどのみち妥協しなくちゃいけない。 l となると、QoSは0,1さえサポートされていれば⼗分で、クラスタリング可能かどうかは前述したとおり重 要ではなかった。(リトライ/冪等/アプリで重複排除・・・)
  22. 22. 選定候補 l 実績、情報が多いものから優先的に選択(ただでさえ情報少ないのに・・・) l スクラッチも考えたが、ただでさえ情報が少ないなか冒険かと思い⼀旦除外 vs
  23. 23. 負荷実施条件を記載 l メッセージサイズ 1KB l クライアント数 1,000 l リクエスト数 10req/sec(1クライアントあたり) l Retainはなし l Gatling + MQTTプラグイン+ ECSでクライアント数を調整(すごい便利!!) MQTT MQTT MQTT MQTT MQTT
  24. 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. 25. それぞれの特徴(QoS=0の時) Mosquitto(c4.large) RabbitMQ(c4.large) 処理がはけきれず途中で打ち切り
  26. 26. RabbitMQのMQTTプラグイン l MQTTプラグインは、RabbitMQのExchange/Queueの仕組みの上で動く l Exchangeでの配送⽅法はTopic l この機構が原因?調査しきれず。。。
  27. 27. いろいろプロダクトいじってみてのつらみ l ノウハウ少ない。。(本当にこれでいいのか常に不安) l チューニングポイントのあたりをつけるところから⼿探りでスタート l 詳細な事例も少ないので構成パターンの検討も⼿探りでスタート l パラメータが少ない。。 l いざパラメーターチューニングをはじめだすと設定できる箇所が少ない l ⼿持ちが少なすぎて性能が頭打ちになった時に毎回詰んだ気持ちになる
  28. 28. 課題とまとめ
  29. 29. 結構⼼配。。。 l 暖気なしELBがどれぐらい安定してリクエスト受け切れるか。。。 l ELBが暖気なし状態でさばける具合の探りが必要 l IoTってアクセスピーク特性ってあるようなないような
  30. 30. ありがとうございました!!

×