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