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