最新 IoT デザインパターン AWS IoT と AWS Greengrass を用いた構築パターン Amazon Web Services Japan Soution Architect Takashi KOYANAGAWA / Atushi FUKUI 2017/6/1 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
自己紹介
自己紹介 名前 小梁川貴史 ( こやながわ たかし ) 所属 前職 技術統括本部 IoT Solution Design Team ソリューションアーキテクト 電機メーカー自社サービスの開発 運用元 AWS ユーザ 好きな AWS サービス AWS IoT AWS Lambda(python) Amazon Kinesis 名前 福井厚 ( ふくいあつし ) 所属 前職 技術統括本部エンタープライズソリューション部 ソリューションアーキテクト エンタープライズアプリケーション開発コンサルタント 好きな AWS サービス AWS Code シリーズ AWS IoT AWS Lambda(C#)
このセッションの対象者 IoTに興味がある AWSのマネージドサービスを利用したことがある アーキテクチャの設計に関わる人材 アーキテクト デベロッパー マネージャ
このセッションで持ち帰って頂きたいこと AWS IoT の機能を理解する AWS GreenGrass の機能を理解する AWS を利用した IoT デザインパターンを理解する
AWS における IoT Solution のご紹介
IoT を構成する 3 要素 センシングデバイスネットワークコネクティビティ処理 分析を実行するサーバー 誰もがすぐに調達可能でアイデアと実行能力があれば市場参入が容易イノベーションにより市場に破壊が起きる
さまざまな IoT ユースケース 製造 交通 エネルギー リテール メンテナンス / 異常検知 車両センサー スマートメータ 動線把握 モニタリング ドライバーの安全 メンテナンス / 異常検知 O2O 家電 スマート家電 オートメーション ヘルスケア 医療機器管理 遠隔医療 農業 モニタリング 遠隔制御
IoT の代表的な要件 モニタリング位置情報管理 状態監視 実績把握 動線把握 データ連携 / モバイル 保守作業 スマートデバイス 企業連携 オープンデータ 予防予知保全 異常検知 故障予測 遠隔制御 機器運用 ファームアップ
IoT プラットフォーム データ収集 分析 データ収集 データ処理 分析 データ保存 活用 Report/Dashboard ( 故障予知 予測 ) アラート 業務支援システム デバイス制御 デバイス管理 リモート制御 デバイス管理
AWS IoT Solution AWS IoT Solution データ収集 IoT データ活用データ処理 分析 Kinesis Analytics EMR Machine Learning QuickSight Report/Dashboard ( 故障予知 予測 ) エッジ Greengrass Kinesis S3 Athena データ保存 Redshift Lambda S3 Elasticache RDS DynamoDB ElasticSearch SNS アラート 業務支援システム デバイス制御 デバイス管理 AI 関連 IoT IoT API GW Lambda デバイス管理
AWS IoT 全体構成 認証と認可 ルールエンジン AWS サービス - - - - - その他のサービス デバイス SDK デバイスゲートウェイ デバイスシャドウ アプリケーション デバイスレジストリ AWS IoT API
ルールエンジン { color = red } シンプル & 慣れた構文 SQL 文を使ったトピックのフィルタ オプションの WHERE 句で条件を記述することが可能 JSON サポート SELECT Data FROM topic WHERE 条件 SELECT * FROM things/thing-2/color WHERE color = red メッセージ変換機能 文字列操作 ( 正規表現サポート ) 算術計算 コンテキストベースのヘルパー 暗号 UUID, Timestamp, 乱数など.
ルールエンジンの活用例 select * from /Factory1/sensor1 => S3(bucket1) select * from /Factory1/sensor2 => S3(bucket2) select * from # where Temp > 25 => SNS Factory1 Amazon S3 Temp:25 /Factory1/sensor1 Gateway Sensors Gatewayで生成 { Device : temp01, Temp :25, Ttimestamp :yyyy-mmdd %h:%m%s } Amazon SNS
ルールエンジンの活用例 select * from /Factory1/sensor1 => S3(bucket1) select * from /Factory1/sensor2 => S3(bucket2) select * from # where Temp > 25 => SNS Factory1 Amazon S3 /Factory1/sensor2 Gateway Temp:28 Sensors Gatewayで生成 { Device : sensor2, Temp :28, Ttimestamp :yyyy-mmdd %h:%m%s } Amazon SNS
データ収集のユースケース ルールエンジンから 以下に挙げるサービスとの連携 など12のアクションが定義可能 temp sensor/# water Amazon Amazon Amazon DynamoDB Kinesis S3 Amazon RDS Amazon Glacier Amazon Redshift Amazon EC2 sensor/water/room1 Amazon AWS Amazon SNS Lambda SQS door 外部エンドポイント (LambdaやSNS経由)
便利な機能がいろいろ ルールエンジンとアクション デバイスシャドー SQL ライクな構文でルールの設定ルールに合致した場合 AWS の各種サービスとのインテグレーション デバイスが物理的に接続されてなくてもコマンドを伝達できる デバイスとクラウドとの相互認証 デバイスレジストリ TLS1.2 を用いた相互認証証明書に対するポリシ設定も可能 多くのデバイスを管理 Key-Value 形式でファームバージョンなどの属性情報も管理可能
IoT における クラウドデザインパターン
IoT におけるクラウドデザインパターン データ収集 活用のユースケース shadow 活用のユースケース その他
IoT におけるクラウドデザインパターン データ収集 活用のユースケース shadow 活用のユースケース その他
課題 ルールエンジンから S3 へファイルを送信しているが 1file/1data の単位でデータ解析に使いづらい ルールエンジン temp:25 time: x AWS IoT Amazon S3 temp:28 time:y
バッチデータストアパターン 利用用途 - センサーデータなどのバックアップ - 機械学習などのモデル作成に向けた準備 メリット 注意点 - メッセージを時間またはサイズ指定で 1 ファイルに複数データをかけるために今後データ活用がやりやすくなる - 128kb 以内のメッセージを推奨 ルールエンジン Amazon Elasticsearch Service AWS IoT Amazon Kinesis Firehose Amazon S3
課題 backend システムで正常終了したかや エラーが発生したことを知りたい AWS IoT 送信用 topic
QoS2 エミュレートパターン 対象シーン - データの到達通知 / エラー発生をデバイスで確実に受取たい 条件 - デバイス側で送信したデータに識別子を付与し その識別子の データ処理が正しく処理されたかを別トピックをサブスクライブ して待ち受けることができる 注意点 - 受信を必ず返却するので必要なメッセージ数が 2 倍になる AWS IoT 送信用 topic AWS Lambda エラー DB Storage など 受信用 topic
課題 ニアリアルタイムの処理 / スライディングウィンドをマネージド サービスで実現したい ルールエンジン AWS IoT Amazon Elasticsearch Service
リアルタイム異常検知パターン 対象シーン - ニアリアルタイムでの異常検知 スライディングウィンドウを作 成したい 条件 - Kinesis analytics の利用 注意点 - 現在 Tokyo region に kinesisn analytics がローンチされていない AWS IoT Kinesis Streams Kinesis Streams Lambda SNS RANDOM_CUT_FOREST 関数による異常検知を実行 Kinesis Analytics http://docs.aws.amazon.com/ja_jp/kinesisanalytics/latest/sqlref/random-cut-forest.html
IoT におけるクラウドデザインパターン データ収集 活用のユースケース shadow 活用のユースケース (2) その他
課題 遠隔地にあるデバイス管理はコストが掛かる または大量にあるデバイスのバージョン管理 /update 指示をしたい
ファームアップパターン 対象シーン - 特定のデバイスに対してファームアップを指示 条件 - Device Registryにデバイスとファームバージョンを管理している - Device Shadowを使ってコマンドの実行が可能 - HTTPSでファームをダウンロード可能 注意点 - ファームバージョンアップのプログラムはお客様にて実装 3 Delta 2 対象デバイスの Shadow の更新 Shadow 4 ファームダウンロード 1 ファームをストア
課題 デバイスの一覧 状態を管理できるデータベースが欲しい IoT shadow の thing status コマンドに list コマンドがない
インテリジェントシャドウパターン 対象シーン - Web/ スマホアプリなどからデバイスをコントロールしたい 条件 - 特になし 注意点 - シャドウを利用することが必須 ( シャドウは8Kbの制約 ) 4 状態をアップデート 5Dynamo の仕掛りを完了に 1 アプリからアップデート要求 AWS IoT DynamoDB API Gateway 3AWS IoTにpublish Lambda 2DynamoDB ストリームに更新内容を put
IoT におけるクラウドデザインパターン データ収集 活用のユースケース shadow 活用のユースケース その他
課題 AWS IoT では payload の観点から転送しにくい大きめのデータ転送をセキュアに送信したい (Gateway へ Thing に IAM は発行したくない ) デバイスから写真や動画を S3 へ ログファイルを kinesis へ
Kinesis S3 テンポラリトークン取得パターン 対象シーン - AWS IoTの証明書を利用したセキュアな接続を利用してデバイ スへAWSリソースに対してアクセス権を付与 条件 注意点 - 事前に利用する IAM が必要 - 特になし 2 トークン取得リクエストを publish 送信用 topic AWS IoT Lambda 2 トークンの取得 IAM 1 トークンを subscribe token 受信用 topic 5 トークンを使ってアクセス 3 トークンを publish あらかじめテンポラリトークンに割り当てるロールを作成
課題 いつどのくらい必要になるかわからない証明書を事前に作りたくない デバイスが使われるときに証明書を有効化したい
持ち込み証明書によるJust in time registrationパターン 対象シーン - デバイスを製造する段階でデバイス証明書を書き込む 条件 - 特になし 注意点 - CAの構築 / 運用が必要 中間 CA 事前に CA としての登録 IoT Policy AWS IoT ポリシーアタッチ AWS Lambda 出荷
AWS IoT におけるアンチパターン
データ収集のアンチパターン AWS IoT から S3 RDS EC2 へのサービスへの接続 スケーラビリティがある 突発的な需要増に答えにくい ( コネクション数などの制約 ) Amazon EC2 Device AWS IoT Amazon kinesis AWS Lambda Kinesis を挟まないパターン : 同時イベント数 =Lambda 同時起動数 Kinesis を挟むパターン :Kinesis stream の shard 数 = Lambda 同時起動数 Amazon RDS
Kinesis 利用上の注意 データ容量に応じて Shard を分割 結合する必要がある 1 シャードあたり 1,000 レコード /s または 1MB/s Primary key は Shard が分散するように設計 Shard Shard Shard Shard Shard あたり 1Lambda が起動 Lambda の同時実行数もデフォルト 1000 まで
データ送受信 (Ingest) AWS IoT Amazon Kinesis Amazon S3 ペイロード長 1 メッセージあたり 128KB 1 レコードあたり 1MB 1 オブジェクトあたり 5TB プロトコル MQTTS/HTTPS /Websocket HTTPS HTTPS 料金 512Byte を 1 メッセージとして $8/ 百万メッセージ 1 シャード $0.0195/ 時ペイロードユニットを 25KB として $0.0215/ 百万ペイロード (Streams) $0.025/GB( 最初の 50TB, 月 ) 認証 クライアント証明書 SigV4 SigV4 SigV4 使いどころ ペイロードが小さく送信頻度も低いデバイスとクラウド間の双方向通信が必要高いセキュリティを求められる ペイロードが大きく 送信頻度が高い メディアなどデータサイズが大きい場合 ファイル単位でデータを扱う場合
Data Sources Transactional Data Amazon S3 を中心としたデータレイクを構成 Amazon DynamoDB & ElastiCache NoSQL DB & Redis Amazon Aurora Relational Database Amazon Athena Clusterless SQL Query Amazon Redshift Amazon S3 Data Lake Data Warehouse Amazon Kinesis Streams & Firehose Any Open Source Tool of Choice on EC2 Amazon Machine Learning Machine Learning Amazon EMR Hadoop / Spark
エッジコンピューティング
AWS IoT Solution AWS IoT Solution データ収集 EMR IoT Kinesis データ活用 データ処理 分析 Kinesis Machine Learning Analytics Lambda Redshift Report/Dashboard (故障予知 予測) QuickSight データ保存 業務支援 システム ElasticSearch S3 Greengrass デバイス制御 IoT S3 Glacier デバイス管理 IoT RDS アラート DynamoDB SNS API GW Lambda デバイス管理
AWS Greengrassのオーバービュー Status Sync バージョン/配信管理 Local環境 AWS IoT MQTT Lambda Device shadow Greengrass SDK Greengrass Core サービスとの接続 Greengrass要求スペック CPU １GHz single 以上 Memory 128MB 以上 OS: Linux Kenel 4.4以上
AWS GreenGrass ローカル環境にある Gateway などの機器に クラウドで開発したのモジュールを配布 / 管理可能かつ ローカルで実行することにより Latency の向上 ネットワーク常時接続性が不要 センシティブ情報の処理し クラウドへデータ送信可能にできる リリース当初の Lambda は python2.7 をサポート予定
AWS IoT Starting in the cloud AWS Services Messages Things Sense & Act Authentication & Authorization Cloud Messages Storage Device & Compute Gateway Action Intelligence Insights & Logic Action Applications Device State Registry AWS IoT API AWS Greengrass
AWS IoT Going to the edge Introducing AWS Greengrass AWS Services Messages Messages Messages Action Action Authentication Authentication & Authorization & Authorization Device Gateway Device Gateway Security Applications Device State Registry Device State AWS IoT API *Note: Greengrass is NOT Hardware (You bring your own)
エッジコンピューティング デザインパターン
課題 設置場所に NW がなく SIM の電波もとどかない Cloud 経由の Latency ではユースケース上 遅い
データアグリゲーションパターン 対象シーン - 通信の数を減らし データをバルクでアップロードしたい - 常時ネットワークコネクティビティがない環境でのデータ収集 条件 - 特になし 注意点 - リアルタイム性が落ちる リアルタイムの異常検知が必要な場合は Greengrass 上とローカル環境で実装 local 環境 Gateway N 分間のデータをまとめてダイレクトに S3 へ Greengrass Amazon S3
課題 データペイロードの一部にセンシティブ情報が含まれているのでクラウドを使いにくい
センシティブ情報マスキングパターン 対象シーン - クラウドでのデータ活用がしたいがセンシティブ情報が含まれているためにクラウ ドへデータが送れないケース ( 社内規定などで ) 条件 - 特になし 注意点 - masking された情報や削除した情報の管理はユーザサイドでの検討が必要 ID: 12345, heart rate :100 local 環境 Greengrass ID: 827ccb0eea8a706c4c34a16 891f84e7b, heart rate :100 ID を hash 化 AWS IoT ユーザ ID 管理 DB
デザインパターンを使ったデモ
テンポラリートークンパターンでのデモ テンポラリートークンパターン Amazon S3 事前に顔辞書作成済み 1)upload 権限の取得 Source bucket Lambda function 3) 画像解析 Face_Index から名前を返却 2) 写真の upload 結果表情サイト Output bucket 4) 名前から情報を引き出す Amazon Rekognition Amazon Cognito DynamoDB 5) 結果を通知
まとめ AWS IoT の機能を理解する ルールエンジン / デイバスシャドウ / 認証機能を有効利用し クイックな IoT 環境の構築が可能 AWS GreenGrass の機能を理解する ネットワークコネクティビティがない や センシティブ情報を含むために利用しにくかった IoT ユースケースに対応できるようになる AWS を利用した IoT デザインパターンを理解する メリット 注意点を理解した上で利用をする
Thank you