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.

2016/2/20 DevelopersIO 2016 実践 IoT システムで求められる確実なデータ連携

2,090 views

Published on

2016/2/20 DevelopersIO 2016で話をした内容です。

2016/2/20 DevelopersIO 2016
「実践 IoT システムで求められる確実なデータ連携」
株式会社アプレッソ 友松哲也

Published in: Software
  • P34の「耐タイパー性」は「耐タンパー性」の間違いです。。
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

2016/2/20 DevelopersIO 2016 実践 IoT システムで求められる確実なデータ連携

  1. 1. 実践IoTシステムで 求められる確実なデータ連携 株式会社アプレッソ 友松哲也
  2. 2. みなさんIoTのことをどう思ってますか?
  3. 3. 経営者: ビジネスチャンスだ!うちも何かしよう! マーケッター: IoTはバズワードだ。これからはIoxだ! コンサルタント: ビジネスのイノベーションが…
  4. 4. エンジニアとしてはおもしろそう! ハックしがいがある!夢広がる! でも
  5. 5. ガチのIoTのシステムは 今までのシステムとは あきらかに違う なにが? アーキテクチャが
  6. 6. だから、今日はこういうのとか
  7. 7. こういうのとかで
  8. 8. 面白いものを作ってみたみたいな 話じゃなくて、 実際の案件で考えなきゃいけない 泥臭いデータ転送について話をします。 期待していた方すいません。
  9. 9. 自己紹介 • DataSpiderプロダクトマネージャー • HULFT IoTプロダクトマネージャー 友松 哲也 株式会社アプレッソ 製品戦略担当 プロダクトストラテジスト 株式会社セゾン情報システムズ HULFT事業部 製品開発部 担当マネージャー Tetsuya Tomomatsu
  10. 10. • GUIを用いたノンプログラミングな開発環境 • データ変換、クレンジングもアイコンベースで開発可能 ノンプログラミングで連携処理が開発できる • トリガー機能により連携処理の自動化が可能 • ログ管理など運用ツールも提供 開発から運用までカバー • 50種以上の連携先に対応 • 拡張用キットSDKも提供 豊富な連携先
  11. 11. 特長1.信頼性 • 全国銀行協会 会員銀行 導入率100%のHULFT品質 • データの欠落、改ざんチェック 特長2.メンテナンス性 • 転送履歴、転送情報管理、エージェント一括管理 • 業務処理との連携 特長3.ネットワーク負荷軽減 • 圧縮転送 • エラー時の対処(転送リカバリ) IoT時代にマッチした新コンセプトHULFT ファイル転送ツールのデファクトスタンダート「HULFT」のクオリティをそのままに IoTシステムの転送を可能にしたツールです。 絶賛開発中
  12. 12. センサー モバイル 製造装置 IoT Gateway Agent Agent Manager 3G/LTE VPN 設定情報デプロイ 設定情報デプロイ センサーデータ ログデータ ・管理GUI ・Agent の監視 ・他サーバーへ転送 HULFT IoT 構成イメージ
  13. 13. IoT GW インターネット キャリア Device Network Platfome AWS IoT Server side ApplicationTranslation 手組 使いどころ
  14. 14. 導入先工場 工作機器 センサー ログデータ 3G/LTE回線 による転送 クラウド 保守センター センサー ログデータ 解析 業務課題 IoT課題 • 機器問題発生時に保守要員が何度も訪問 • 訪問のコストは保守費としてもらえない • 時間もかかりCSにも課題 • 転送すべきデータのサイズが大きい • コストの問題で3G回線が必須 • 効率のよい転送が必要 事例:工作機器メーカー
  15. 15. 製品の話はほどほどに たずさわったIoTシステムの話を。
  16. 16. M2M Machine to Machine M2H Machine to Human 分析アプリケーション 制御アプリケーション スマートエナジー コネクテッドカー インダストリー4.0 スマートヘルスケア クラウドプラットホーム IoTの全体像
  17. 17. 適用範囲 詳細 テレマティクス 自動車や輸送車両向けの情報提供サービス スマートメーター 電気、ガスなどの利用量測定、コントロール センシング モノや場所のセンシングデータ収集 リモートモニタリング 設備や機器の遠隔サポート/監視 トレース モノの輸送や移動、組み立て/加工などのトレース 決済 リモート端末による決済 セキュリティ ホームセキュリティや見守りサービス IoTのおおまかな種類
  18. 18. 引用:スカイディスク データ 収集 データ 転送 データ 蓄積 データ 分析 可視化 予測 クラウドデバイス アプリケーション データの見える化 センサー、 スマホ 無線、 SIM データベース、 データマート データマイニング、 機械学習 シミュレーション IoTを構成する要素
  19. 19. IoTシステムアーキテクチャ Type1: Device to Cloud Type2: Using Gateway Type3: Using Moblie Type4: Using Server
  20. 20. Type1:Device to Cloud MQTT or Streaming Service Message Broker Mosquitto AWS IoT Spark Streaming Amazon Kinesis Device AppStore
  21. 21. Type1:Device to Cloud 良いところ • デバイスがあれば比較的すぐに始められる • デバイスが増えてもアーキテクチャの変更が少ない • 大量データもクラウドでらくらく対応 悪いところ • デバイスが段階的に増えるときの管理コストで死ねる • デバイスごとにデータが異なるときに後々面倒 • 再送処理どうするんだ • 電池が。。
  22. 22. Type2:Using Gateway Message Broker Device AppStoreIoT Gateway
  23. 23. Type2:Using Gateway 良いところ • デバイスに負荷をかけない(近距離通信) • デバイスが増えた時にデバイスに手を入れなくていい • 転送をコントロールしやすい(再送、フィルタなど) • デバイスをグループで管理 悪いところ • 単純にコストが増える • デバイス管理に別の仕組みが必要 • ゲートウェイが死ぬとそのグループは全滅
  24. 24. Type3:Using Mobile Message Broker Device AppStoreMobile
  25. 25. Type3:Using Mobile 良いところ • みんなが持っているMobileを流用できる • 中継だけでなく他の使いみちにも使える(人が介在) • 転送をコントロールしやすい(再送、フィルタなど) 悪いところ • Mobileが必ずデバイスのそばにあるとは限らない • 動作検証とかどうしよう • デバイスをたくさんぶら下げるのは現実的ではない
  26. 26. Type4:Using Server Message Broker Device AppStoreServer/PLC
  27. 27. Type4:Using Server 良いところ • 中継処理でなんでもできる(配信、変換、ストアなど) • 既存の資産を転用できる • 転送をコントロールしやすい(再送、フィルタなど) 悪いところ • そもそもIoTなのかという疑問が • モビリティにかける(デバイスが固定的) • サーバ追加時のコストがかかる
  28. 28. 構築 容易性 コ ス ト 柔 軟 性 拡 張 性 安 定 性 使いみち Device to Cloud ○ ○ × × △ スマートメーター、リモートモニタリング、 ウェアラブル、数の少ないセンサリング、テレ マティクス Using Gateway ○ △ △ ○ ○ 数の多いセンサリング、ホームセキュリティ、 コネクテッドカー、農業IoT Using Mobile △ ○ ○ △ × ウェアラブル、スマートヘルスケア、スマート ペット、オンライン決済、ビーコン、IoTを 使ったコンシューマサービス Using Server △ × ○ △ ○ 生産管理、予兆検知、ファクトリーオートメー ション、インダストリアル4.0 まとめると
  29. 29. データ転送で考えるべきこと 到達保証 セキュリティ 多重度 圧縮 トランザクション
  30. 30. IoTシステムの大前提 デバイスには極力負荷をかけない スケーラブルなアーキテクチャにする デバイスとクラウドは疎結合にする
  31. 31. データ転送で考えるべきこと 到達保証 セキュリティ 多重度 圧縮 トランザクション
  32. 32. 到達保証 • ほとんどの場合は必要になると考えた方がいい • データをもう一度送信したくない ₋ ストアする必要があるから、もしくは捨てるか • どこまでやるかを明確化する必要がある ₋ 配信だけ保証 ₋ 受信まで保証 ₋ 受け取りの回数まで保証 • HTTP、WebSocket(単体)などは自前で実装する必要がある • MQTTはプロトコルレベルで対応しているので楽 • もしくはミドルウェアを使う
  33. 33. データ転送で考えるべきこと 到達保証 セキュリティ 多重度 圧縮 トランザクション
  34. 34. セキュリティ • これもだいたい言われる • 認証 ₋ MQTTはパスワード認証だけどどうやってデバイスに渡すか ₋ AWS IoTはX.509をサポート • 暗号化 ₋ 経路の暗号化 ₋ 証明書の配布はどうするか • Soracom beamとEndorseがあれば • 本当は耐タイパー性も考えないと
  35. 35. データ転送で考えるべきこと 到達保証 セキュリティ 多重度 圧縮 トランザクション
  36. 36. 多重度 • トラフィックコントロールとして ₋ たとえばスマートメーター(関西電力で約1300万台) これが全部同時に発報したらどうなるか ₋ すべてを受け止めるシステムを本当につくるのか ₋ 発報のタイミングを工夫する ₋ たとえば1万台ごとに時間差で発報する仕組みを作る • 耐障害性として ₋ Gatewayが死んでも転送できるように ₋ 別経路の確保、経路の多重
  37. 37. データ転送で考えるべきこと 到達保証 セキュリティ 多重度 圧縮 トランザクション
  38. 38. 圧縮 • なるだけデータの転送量は圧縮したい • でもデバイスには負荷を掛けたくない →ジレンマ • そもそも圧縮しないアプローチ ₋ メッセージが小さいから問題ないと考える ₋ もしくはMessagePack、細かくちぎって転送 ₋ でも画像やバイナリはどうする? • 圧縮しながら転送 ₋ その都度パケットを圧縮する ₋ プロトコルではサポートしていないので開発する必要がある
  39. 39. データ転送で考えるべきこと 到達保証 セキュリティ 多重度 圧縮 トランザクション
  40. 40. トランザクション • そもそも必要ない場合も多い • 必要になるととっても頭の痛い話 • デバイスとサーバは疎結合なのにどうやって一貫性を担保するの • 案1:HTTPとかWebSocketでがっちり実装 ₋ デバイスをロックする覚悟 • 案2:キューで順序制御 ₋ リアルタイム応答はできないけど ₋ 転送順に処理をする ₋ そうなると到達保証は必須(MQTTでのQoS2レベル) ₋ でも、キューはスケールさせずらい
  41. 41. MQTT一択なのか • プロトコルとしてはIoTと相性はよさそう • それでもMQTTで気になるところ 1. データをストアするとスケールしづらくなる • データ保全を考えるとストアしたくなる • AWS IoT使えば解決できる 2. 大容量データの転送 ₋ 画像とかバイナリデータとかをどうするか ₋ データの欠落のチェックが必要になる 3. データの順序性の制御 ₋ MQTTにキューはありません ₋ 解析を考えると致命的
  42. 42. ファイル転送という選択肢 • 古臭く聞こえるけど • ファイル転送のいいところ ₋ そもそもストアを考えなくてもいい ₋ 順序性の管理がしやすい ₋ ファイルでPub/Subっぽいこともできちゃう ₋ つまりスケールしやすい • 大容量もOK • 動画やバイナリもOK • でも、到達保証/整合性検証の仕組みが必要です。 • でも、トリガー/前後ジョブ連携する機能が必要です。
  43. 43. ご清聴ありがとうございました。

×