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

みなさん IoT のことをどう思ってますか？

経営者 :ビジネスチャンスだ！うちも何かしよう！

マーケッター :IoT はバズワードだ。これからは Iox だ！

コンサルタント：

ビジネスのイノベーションが…

エンジニアとしてはおもしろそう！ハックしがいがある！夢広がる！

でも

ガチの IoT のシステムは

今までのシステムとはあきらかに違う

なにが？

アーキテクチャが

だから、今日はこういうのとか

こういうのとかで

面白いものを作ってみたみたいな話じゃなくて、

実際の案件で考えなきゃいけない泥臭いデータ転送について話をします。

期待していた方すいません。

自己紹介

• DataSpider プロダクトマネージャー• HULFT IoT プロダクトマネージャー

友松 哲也

株式会社アプレッソ製品戦略担当　プロダクトストラテジスト

株式会社セゾン情報システムズHULFT 事業部　製品開発部　担当マネージャー

Tetsuya Tomomatsu

ノンプログラミングで連携処理が開発できる

• ＧＵＩを用いたノンプログラミングな開発環境• データ変換、クレンジングもアイコンベースで開発可能

開発から運用までカバー

• トリガー機能により連携処理の自動化が可能• ログ管理など運用ツールも提供

豊富な連携先

• ５０種以上の連携先に対応• 拡張用キット SDK も提供

特長１ . 信頼性

• 全国銀行協会　会員銀行　導入率 100% の HULFT 品質• データの欠落、改ざんチェック

特長２ . メンテナンス性

• 転送履歴、転送情報管理、エージェント一括管理• 業務処理との連携

特長３ . ネットワーク負荷軽減

• 圧縮転送• エラー時の対処 ( 転送リカバリ )

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

• でも、到達保証 /整合性検証の仕組みが必要です。

• でも、トリガー /前後ジョブ連携する機能が必要です。

ご清聴ありがとうございました。