(レポート)MBL305: IoTデータの活用法 #reinvent

2015.10.13

はじめに

IoTについての知識が全くないので、きっかけとしてこのセッションを受けてみましたが、すごく良いセッションでした。 IoT特有の事情や、分析方法の分類から始まり、後半では例をあげて実際に様々な分析をするところが見られました。 特に、分析方法ごとのアーキテクチャの検討は参考になる部分がたくさんあります。

スライド

セッション概要

  • IoTデータの種類を把握する
  • AWSプラットフォームを活用し、データを洞察やアクションにつなげる方法を学ぶ
  • 様々なAWSサービスとIoTの組み合わせについてアイデアとアドバイスを行う

データドリブンIoT

インターネットにつながっている「モノ」は2010年には10億ほどだったが、2020年には500億、2035年には1兆になると言われている。 それらのモノ全てがデータを生み出す。

IoT時代にやるべきことはデータを

  • 集め(Collect)
  • 分析し(Analyze)
  • データに基づいたアクションを起こす(Act on)

ことである。 デバイスからのデータから洞察を得る必要がある。

データ分析の3つの方法

  • 過去のデータの回顧的分析(-> レポーティング)
  • Redshift
  • RDS
  • S3
  • EMR
  • 現在のデータのリアルタイム分析(-> ダッシュボード)
  • Kinesis
  • Lambda
  • DynamoDB
  • EC2
  • 未来に発生するであろうデータを予測分析(-> スマートアプリケーション)
  • Amazon Machine Learning

IoT特有の事情

リアルタイム分析

迅速な処理が求められる

  • センサーからのライブデータからパターンを見つけ出す
  • 発生するイベントを関連づける
  • 付加情報によってライブデータの質を高める

目的は

  • 得られたデータに対して素早く反応し
  • モノの挙動を調整し
  • ユーザが望む素早いフィードバックを返すこと

回顧的分析

過去の文脈が必要

  • 現在のイベントに文脈を与える
  • 文脈によって長期的傾向を捉える

目的は

  • 過去のデータから学ぶことで
  • モノがどのように利用されているのかを明らかにし
  • モノの利用/課金情報の長期的な動向を捉えること

予測分析

IoTはスマートデバイスを利用出来る

  • イベントデータのパターンを推測する
  • データの規則や分散を学ぶ

目的は

  • 未来のイベントを予測し
  • 例えば起こりそうな問題
  • 例えばユーザの次の行動
  • 次にすべきことを予測すること

IoT活用例

スクリーンショット 2015-10-10 4.06.16

利用するデバイス

  • 3つのセンサーを持った複数台の室内エアコン
  • 2秒に1回、「気温」、「湿度」、「気圧」データを送信する
  • クラウドに接続されている
  • あまり安定していない

送られるデータのサンプル

{
  "temperture": "100",
  "humidity": "92",
  "pressure": "8"
}

分析したいこと

回顧的分析

  • 時系列の気温の変化
  • 気圧と気温の関係

リアルタイム分析

  • 現在、何個のセンサーがクラウドにつながっているか?
  • 現在の気温が前日や前年の気温とほぼ同じであるか?

予測分析

  • センサーから送られるデータは正しいか?
  • 壊れているセンサーと正常なセンサーを区別できるか?
  • 出勤時にセータを着ていくべきかどうか?

クラウド上のバックエンド

AWS IoTを利用する

デバイスとのセキュアな接続

スクリーンショット 2015-10-10 4.19.46

  • メッセージのやりとりに複数プロトコル対応
  • HTTP
  • MQTT
  • Pub/Subブローカーは自動でスケール
  • 1接続から10億接続まで
  • セキュアな接続
  • X509証明書
  • TLS v1.2

AWS IoTはAWSサービス群への入り口

スクリーンショット 2015-10-10 4.20.09

  • デバイスの登録
  • 登録されたデバイスはRESTフルなアクセスを行う
  • AWS IoTに届いたデータは設定されたルールに沿って、他のAWSサービスに送られる、もしくはAWS IoTに再送される。

AWS IoTルールエンジン

スクリーンショット 2015-10-10 4.20.24

AWS IoTのルールエンジンは設定したルールに基づいて、届いたメッセージを加工し、適切なエンドポイントに配送する。 AWSエンドポイントとして指定できるのは

  • Lambda
  • S3
  • DynamoDB
  • SNS
  • Kinesis Stream
  • Kinesis Firehose
  • AWS IoT

外部のエンドポイントに配送する場合は、LambdaかSNSを利用する。

以下はルールの例 スクリーンショット 2015-10-10 4.20.46 特徴は

  • SQLライクなシンタックス
  • 対象メッセージをWHERE句で絞り込み
  • インラインでアクションを指定できる

実際の分析方法

回顧的分析

目的

  • 全データの保存
  • 保存されたデータを後から分析できるようにしておく
  • レポーティング
  • 課金
  • 詳細分析
  • 機械学習

手順

  • ルールを作成し、届いたデータをキャプチャ、加工する
  • アクションを定義し、データを保存する
  • 保存されたデータを分析する
ルール例

スクリーンショット 2015-10-10 5.24.27

データ保存先

選択肢は4つ。 スクリーンショット 2015-10-10 5.24.39 1

  • S3
  • メッセージはそのままS3オブジェクトとして保存される
  • 保存先のバケット名を指定するだけ
  • 1イベント1オブジェクト
  • 小さいファイルが大量に発生
  • EMRでの処理やRedshiftへの取り込みが非効率に
  • イベントの頻度が低い場合は良いかも

あいだにKinesis Firehoseを挟むと複数のイベントを1つのオブジェクトにまとめることができる。 スクリーンショット 2015-10-10 5.29.30

  • Redshift
  • Kinesis Firehose経由でデータロードする

スクリーンショット 2015-10-10 5.29.43

  • DynamoDB
  • アクションによって直接テーブルに書き込まれる
  • 1イベント1行
  • テーブル名とフィールド名を指定するだけ
  • DynamoDBインデックスが利用できる
  • データの内容をすぐに確認できる スクリーンショット 2015-10-10 5.30.24

Lambdaを挟むことでより柔軟なデータ保存が可能

  • データの加工
  • 複数のテーブルに保存
  • 他のデータソースからのデータと組み合わせ

スクリーンショット 2015-10-13 10.29.39

おすすめ
  • 常にたくさんのクエリを発行する場合はFirehose -> Redshift
  • すぐにデータを見たい場合はDynamoDB
  • 思いクエリが必要な場合はFirehose -> S3に保存しEMRで集計
クエリ発行例

スクリーンショット 2015-10-13 10.43.12

スクリーンショット 2015-10-13 10.43.22

エアコン分析の例

①全データをFirehoseに流すルールを作成し スクリーンショット 2015-10-13 10.58.12

②全データをFirehose経由でRedshiftに保存 スクリーンショット 2015-10-13 10.58.27

③Amazon QuickSightで分析 スクリーンショット 2015-10-13 10.58.38

分析結果

回顧分析で分析したいのは下記の2つ。

  • 時系列の気温の変化
  • 気圧と気温の関係

気温変化をQuickSightで見てみると次のグラフのようになっていた。 スクリーンショット 2015-10-13 11.15.18

1つだけ離れているセンサーがあるので、トレンドグラフから平均値の棒グラフに変えて確認してみる。 平均値でも同じセンサーが離れているので、実際にその地点だけ温度が低いのか、もしくはセンサーが壊れているのか調査が必要。 スクリーンショット 2015-10-13 11.16.09

また、気温と気圧の関係を見てみる。 (こちらのグラフの意味はうまく聞き取れませんでした。) スクリーンショット 2015-10-13 11.17.27

リアルタイム分析

目的

  • 大きな気温変化があった時にアラートを発生させる
  • センサーから送られてくる値を集め、可視化する

手順

回顧的分析とほぼ同じ ただし、データは保存せずにその場で処理する

  • ルールを作成し、届いたデータをキャプチャ、加工する
  • アクションを定義し、データを処理する
  • 処理されたデータを可視化する
ルール例

気温95度を超えたデータだけを抽出 スクリーンショット 2015-10-13 12.37.05

データ処理方法

選択肢は4つ

スクリーンショット 2015-10-13 13.59.16

  • Lambda
  • 1回で1イベントを処理(バッチ処理はできない)
  • 他のデータと組み合わせてデータの質を高める
  • データ変換
  • インフラ不要

  • SNS

  • アラートに最適
  • HTTP POSTを使って別システムにwebhook
  • LambdaやSQSと連携

  • SQS

  • イベントが不定期に発生する時に便利
  • 非同期処理のバッファに
  • イベントの取りこぼしがないことを保障する
  • SNSとの連携
  • Elastic Beanstalkで簡単にWorker作成

  • Kinesis

  • rolling windowサイズを指定して複数のイベントをまとめて処理できる
  • 複数のイベントソースからのイベントを処理できる
  • 同時に複数の処理が可能
  • ストリーム処理のハブとなる
おすすめ
  • 個別のイベントだけが問題ならlambda
  • 複数のイベントを処理したい、もしくはより柔軟な処理をしたいならKinesis + Lambda

Kinesisをハブとして使うのがベストプラクティス

現在の値の可視化

Amazon Elasticserch + Kibana

分析結果

スクリーンショット 2015-10-13 14.27.50

予測分析

機械学習について

機械学習とはデータのパターンを自動で見つけ出す技術 見つかったパターンを利用して将来に発生するであろうデータを予測する

デイバス + 機械学習 = スマートデバイス

IoTにおける機械学習のユースケース
  • パターンから問題を発見
  • 壊れそうなエンジンを特定
  • 供給量が足りなくなる時期を予測
  • 誤ったデータを送るセンサーを特定

  • 車の次の動きを予測

  • ドライバーや他の車の動きから予測
  • 交通渋滞を予測
Amazon Machine Learning
  • リアルタイム分析
  • 教師あり学習モデル
  • モデルとパラメータを選択し、トレーニングデータを作成する

手順

①データの収集と教師データの作成

  • センサーの過去データ(気温、湿度、気圧)をインプットとして指定
  • データの正/不正を定義し、教師データとして利用

スクリーンショット 2015-10-13 14.42.55

②機械学習モデルを作成 ③リアルタイム予測用のエンドポイントを作成 スクリーンショット 2015-10-13 14.43.04 スクリーンショット 2015-10-13 14.43.30

④リアルタイム予測 Amazon Machine Learningへのデータ投入にはLambdaを利用 スクリーンショット 2015-10-13 14.43.38

まとめ

1つのデータソースに対して、回顧的分析、リアルタイム分析、予測分析の3つの分析を行った。

スクリーンショット 2015-10-13 15.00.17

感想

IoTというと自分の手の届かない分野と思っていましたが、いったんデータをクラウド上に持っていけば、従来のやり方がそのまま使えるという印象を持ちました。 モノとクラウドをつなぐ部分はAWS IoTが担ってくれるので、ここら辺の記事を見て勉強してみたいと思います。

【速報】新サービス「AWS IoT」 登場! #reinvent (レポート) MBL312: AWS IoT Deep Dive #reinvent AWS IoT Message BrokerのMQTTでpub/subをやってみた #reinvent AWS IoTのいろいろなルールを見てみる&ちょっと試してみる #reinvent AWS IoT Device GatewayにHTTPでPublishしてみた #reinvent AWS IoTのThing Shadowsを図と実行例で理解する #reinvent