[レポート] サーバーレスアナリティクスと異常検出のためのIoTビッグデータパイプライン CMY305 – IoT big data pipeline for serverless analytics and anomaly detection #reinvent

CX事業本部@大阪の岩田です。 本エントリはCMY305 - IoT big data pipeline for serverless analytics and anomaly detection

のレポートとなります。

セッション概要

In this talk, we walk through the process of building an end-to-end big data pipeline using AWS managed services. Follow along and learn how to detect anomalous trajectories across different transportation industries ingesting IoT geo-referenced data and receiving real-time insights with Amazon Kinesis Data Analytics and AWS Glue. At the end of this session, you’ll understand how to customize and deploy this solution at scale.

レポート

Serverless Big Data Pipelines

ストリームデータとは何か？

• ストリームデータ=スピード
• リアルタイム性を持ったデータ
• 通常6秒以内程度のレベルを指す
• 逆にバッチデータはデータの発生~処理まで1時間程度の遅延
• ETLのようなデータの加工も含まれる

解決すべき課題

• データは継続的に作られる
• C/S構成は様々な問題を抱えている
  • リトライ
  • 多過ぎるリクエスト
  • スロットリング
  • サーバーのメモリ超過

スケーラブルな構成

• ELB, EC2, DynamoDBを使う構成
• 引き続きEC2の監視やスケールに課題が残る
• サーバーレスへ

信頼性の高いサーバーレスソリューション

• API GW,SQS,Lambda,DynamoDBを使うような構成へ

Amazon Kinesis

• ストリーミングデータを継続的にデータを読み込むためにはKinesisファミリーが有効

Kinesisのユースケース

• 交通
  • 経路の最適化
  • 予防保守
• IT
  • ログ解析
  • レコメンデーションエンジン
• 監視カメラ
  • 監視システム
  • オブジェクト検出
• テレマティック(移動体通信システム)
  • 故障検知
  • センサー

Kinesisのスループットについて

• シャードという概念でスループットを管理
  • 1シャードで1MB書き込み,2MBの読み込み
• シャードは拡張/再編成することが可能
• パーティションキーを使うことでデータとシャードを関連付けることができる
• データの生成元(LambdaとEC2など)でパーティションを分ける　といった制御が可能

Kinesis Firehose

• 分析
  • 異常検出
  • 「ウインドウ」単位でデータの集計が可能
• 柔軟性
  • 標準的なSQLを使って分析が可能
  • Window関数やMLとの統合
• 管理不要
• Amazon ES,Redshift,S3にデータを流すことが可能

データの価値は時間経過とともに薄れていく

• バッチ分析を使うと、結果が得られるまでに時間がかかり、ビジネスに活用するための価値が薄れる
• データ発生直後に分析/検知しないと意味がない

リアルタイム分析

• Kinesis Data Analyticsでは複数のウインドウが選択可能
• Stagger Window

  

• Tumbling Window

  • 定期的なレポート用途に有効
  • 直近5分間のセンサーデータなど

• Sliding Window
  • リアルタイムモニタリングに有効

異常検知

• Kinesis Data Analyticsは分析用の関数が利用可能
  • 例えばランダムカットフォレスト
  • データストリームから動的に異常検知が可能

Lambda Architecture

• リアルタイム&バッチでデータを可視化するためのデザインパターン
• Add onlyでUpdateは行わない
• Lambda architectureのコンポーネントは以下の4つ
  • Producer
  • Batch
  • Speed(real time)Layer
  • View layer

Buisiness Case

• 億単位の車両管理
• 毎秒大量のデータを生成
• AWS Connected Vehicle Solutionというドキュメントが公開されている

AWS Connected Vehicle Solutionのアーキテクチャ

Speed Layer

• IoT Coreから Kinesis Firehose -> Data Anlytics -> Kinesis Data Stream-> Lambda -> DynamoDB
  • Kinesis Data AnalyticsのタンブリングWindowで分析
• Lambdaが異常検知したらDynamoDBに永続化
• locationベースのマーケテイングとかに使える？
• IoT Coreでデータを受けてKinesisに流し、Lambdaで処理
• Greengrassを使うことでエッジ側に処理をオフロードできる

Batch Layer & Speed Layer

• S3やDynamoDBに永続化したデータをAthenaやRedshiftで分析する
• Athenaにフェデレーション機能が追加されたため、様々なデータソースとの連携が可能になった

車両管理システムのデモ

• Kinesis Data Generatorでデータを生成

• 参考: Kinesis Data GeneratorでKinesis Data Streamsにテストデータを投入する
• Kinesis Data Streamにデータを流す
  • センサーの温度、デバイスID
  • 300rec/s
• Data Analyticsのアプリ
  • ストリームに流れてきたデータを可視化
  • 異常検出したデータはDynamoDBに入る
  • Lambdaが異常検出したらSNSで通知

まとめ

Producer、Batch、Speed(real time)Layer、View layerというレイヤー分けの考え方が新鮮でした。また、AWS Connected Vehicle Solutionも初耳で、面白そうな内容だなと感じました。最近車と絡めたIoT案件相談も増えてきているので、このあたりの情報もしっかりキャッチアップしていきたいと思います。