AWS-IoT①-IoTのデザインパターンとGreengrass

someone
20 2月, 2020
AWS Summit 2017の講演
「最新 IoT デザインパターン　〜AWS IoT と AWS Greengrass を用いた構築パターン〜」
の文字起こしコンテンツです。


テーマ

IoTのデザインパターンとGreengrass(2016)の活用について。
  • 小梁川様:IoT支援、ユーザーのインフラリーダ
  • ふくい様:エンタープライズ支援、DevOps

セッションの対象者

  • IoTに興味ある人
  • AWSのマネージドサービスの利用者
  • アーキテクト設計人材

セッションの目的

  • AWS IoTの機能の理解
  • AWS GreenGrassの機能の理解
  • AWSを利用したデザインパターンを理解する

AWSにおけるIoTソリューション

概念的な話ですが、IoTには構成要素が三つ存在している
  • センサデバイス
  • ネットワークコネクティビティ
  • サーバ
これまではネットワークがなかったのでモノがつながらなかったが、LTEの発展やLPWAといったネットワークの普及によって誰もが早く始められるようになった。

IoTユースケース

ほとんどすべての産業において活用可能と想定している。
  • 農業
  • 製造業
  • エネルギー
これまでは勘と経験でやってた仕事をデータ集計によって俗人性を排除した作業とするためにIoTは活用されている。
その人(Professional)の技術を数値化することによって適用するのが利用フェーズの一つ

IoTの代表的な要件

全産業において実現する最後は違うが、やりたいことは同じである。
  1. モニタリング:状態監視
  2. 予防保全:データを集めて、壊れる前に壊れることに気づくこと、クラウドという計算リソース
  3. データ連携・モバイル:スマートフォンからのコントロール要件
  4. 遠隔制御:コントロール要件

IoTプラットフォーム

AWSプラットフォームが得意とする領域
クラウドで、データを集積・処理・保存することが得意。
たまったデータを活用すること。
クラウドを通して遠くにあるデバイスを制御することが得意。

IoTソリューション

AWSがIoTにおいて提供できるサービスの一覧。
今回は、この中からAWS IoTとAWS GreenGrassを説明すること

AWS IoTの全体構成


メッセージを貯めるだけでなく、認証認可というセキュリティ、大量のメッセージを受け付けるデバイスゲートウェイ、入ったデータを次のアクションにコントロールするルールエンジン、クラウドのDBとデバイスの状態とSyncさせるデバイスシャドウ、デバイス自体を登録するレジストリ。
認証認可は、クライアントに証明書を置いてXpoint509の照明、通信はHTTPS、ゲートウェイについては自動スケールする仕組み。プロトコル、HTTP,MQTT,WebSocketが使えるがそれ専用のサーバを立てる必要もない。

ルールエンジン

ルールエンジンはNo CodeでSQLで書ける。
条件は全てSQLで指定する。MQTTの場合はトピック単位で指定。
SELECT:飛ぶデータ
FROM:トピック
WHERE:条件
jsonの中のデータを条件にすることができる。
select * は飛んでくるjson全て。
from :topic 'things/things-2/color'
where color = 'red'
柔軟なフレームワーク作成ができる

ルールエンジンの活用例


  • 工場の一番から、センサーの一番二番によって格納先を変えたい。
  • 異常値が飛んで来たら、SNSで警報をついでに鳴らしたい。
センサーデバイス自体はjsonを生成できないので、ゲートウェイ上でjsonにして、ゲートウェイから飛ばす。
Gatewayで生成したjsonデータ
{ ”Device”:”temp01”, “Temp”:25, “Ttimestamp”:yyyy-mmdd %h:%m%s }
ルールエンジンの条件
select * from /Factory1/sensor1 => S3(bucket1)
Gatewayで生成したjsonデータ
{ ”Device”:”sensor2”, “Temp”:28, “Ttimestamp”:yyyy-mmdd %h:%m%s } 

ルールエンジンの条件
select * from /Factory1/sensor2 => S3(bucket2)
select * from # where Temp > 25 => SNS

クラウドデザインパターン

デザインパターンとは過去のいくつかのやり方のうち、こういう課題ではこういう構成が使えるよねという事例集

  • データ収集のユースケース
  • シャドウ活用のユースケース
課題1
ルールエンジンからS3ファイルに送信しているが1data/1fileになる。
解決
バッチストアデザインパターンにすること
AWSIoT-S3間にkinesis-firehorseをかませることによって、ストリーム処理をバッチ型に変更できる
課題2
バックエンドの正常終了/収集エラーを知りたい
解決
QoS2エミュレートパターンを作成する
トピックを送信用と受信用に分ける。これで通信のハンドシェイクを自分で実装できる

課題3
ニアリアルタイムの異常検知を行いたい
解決
 kinesis analyticsを使用する。
→リアルタイムストリームの中でスライドウィンドウの移動平均を検索する。ゆえにほぼリアルタイムで活用できる。
これをlamda,sqsに入れることが可能。
 
random cut forest

シャドウ活用のパターン

課題
デバイスの数が多くて管理が難しい。
解決
例えば、ファームのアップデート
  • device registoryにデバイスとバージョンを管理
  • device shadowでデバイスのアップデートコマンドの実行が可能
  • HTTPSでファームのダウンロードが可能
解決
AWSでpayloadの観点から大きなデータを送信したい
解決
テンポラリトークンを取得することでセキュリティ要件をクリアして、labdaをキックして大量データを取得できる


データ収集のアンチパターン
AWSIoT-Kinesis-lambda-S3,RDS
kinesisを挟むことでshade数を考慮したlambdaが起動されることでよくなる

サービス利用時の注意点

  • ペイロード長
  • 双方向通信を行いたいかどうか


また、big data活用時は基本的にS3でデータレイクを作成すること

エッジコンピューティング

サーバ上ではなく、ゲートウェイにインストールするプログラム
実体は、ゲートウェイ上のlambdaである。
ローカルでの実行が可能である。

エッジコンピューティングのデザインパターン

設置場所にネットワークが存在しない。
ネットワークコネクションがあるタイミングで一括[bulk]でデータ送信を行う。

データペイロードの一部にセンシティブ情報が含まれている
greenglassがデータを解析して、データをマスクしたり、ハッシュしたり、データ欠落させたりすることが可能である。


[引用]



Next Post Previous Post
No Comment
Add Comment
comment url