【レポート】AWS Summit Tokyo 2017：最新 IoT デザインパターン 〜AWS IoT と AWS Greengrass を用いた構築パターン〜 #AWSSummit

2017年05月30日(火)〜2017年06月02日(金)の計4日間に渡り、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで行われている『AWS Summit Tokyo 2017』。

当エントリでは2017年05月31日に行われた『最新 IoT デザインパターン 〜AWS IoT と AWS Greengrass を用いた構築パターン〜』に関する内容をレポートしたいと思います。

• AWS Summit Tokyo 2017（2017年5月30日～6月2日）｜AWS

セッション概要

当セッションの登壇者及び概要は以下の通り。

セッションレポート

• IoTのサービスを出してから問い合わせの幅が広がった
• 農業、製造業などの生産ラインに関わる方からの問い合わせが増えている
• 勘と経験でやっていたものをデータを元にしたアクションに変換
• 職人的な技を数値化する、というのもIoTの領域
• やりたい事は大体同じ
  • モニタリング; 状態の監視、位置情報の管理
  • 予防予知保全: 壊れる前に気づく
  • データ連携/モバイル
  • 遠隔制御: コントロールする側の要件
• 大量のデータを収集、保存。そのデータを分析。デバイスをリモート制御することがAWSの得意分野
• 今日はこの中からAWS IoTとGreengrassについて紹介する

AWS IoT

• HTTPS/MQTTS/WebSocketのマルチプロトコル
• デバイスシャドウを使ってオフラインの端末にも同じような方法で制御できる
• ルールエンジン
  • SQLライクで柔軟なフレームワークができる
• 活用例
  • センサーの位置によって格納場所を変えたい
  • 温度が25度を超えたら通知したい
  • ゲートウェイにデータを集めて、そこからJSON型式でAWS IoTに飛ばす
  • JSONの値によって適用されるルールエンジンが変わる
  • ワイルドカードも使える

IoTにおけるクラウドデザインパターン

• データ収集、活用のユースケース
• ルールエンジンからS3へファイルを送信しているがファイル、バイト単位で使いにくい
  • バッチデータストアパターン
  • 間にkinesisをfirehoseを挟む
  • メッセージを時間またはサイズ指定で1ファイルに複数データをかけるために今後データ活用がやりやすくなる
  • センサーデータのバックアップなど
• backendシステムでシステム異常を検知したい
  • QoS2 エミュレートパターン
  • データの到達通知、デバイス側で送信したデータに識別子を付与し、識別子のデータ処理が正しく処理されたかを別トピックのサブスクライブで受け取る
• ニアリアルタイムの処理/スライディングウインドを作成したい
  • リアルタイム異常検知パターン
  • kinesis analyticsを使ってRANDOM_CUT_FOREST関数による異常検知を実行

shadow活用のユースケース

• 遠隔地にあるデバイス管理にはコストがかかる
  • ファームアップパターン
  • Device Registryにファームバージョンを管理
  • Shadowをつかってコマンドの実行
  • HTTPSでファームをダウンロード
• 大量のデバイスの状態を管理したい
  • インテリジェントシャドウパターン
  • ShadowだけではなくDynamoDBを挟んでAPI GatewayからDynamoDB StreamをつかってLambdaを動かしIoTのShadowを動かす

その他

• payloadが128kbに制限されている。それ以上のデータを贈りたい。
  • テンポラリトークン取得パターン
  • トークン取得リクエストをpublishする
  • lambdaからSTSを叩いてトークンを取得、トークンを受信用topicにpuslishしてデバイスはsubscribe。トークンを使って一時的に権利を獲得してS3にアップロードする。

アンチパターン

• IoTからLambdaをとおしてEC2やRDSに書き込む
  • IoTやLambdaはスケールするが、EC2やRDSはコネクション数の制御がある
  • 間にKinesisを挟むとlambdaの発火パターンが変わる => shard数が起動数になる
• kinesis利用上の注意
  • shardを分けられるのでパーティションを増やす
  • パーティションを増やすことで並列に処理ができる
• 使い分け
  • 双方向のメッセージを使う時はAWS IoT
  • 128kbという制限がある
  • 128kbを超える場合はkinesisを使う
  • 数MBの場合は直接S3に送る
• S3を中心としたデータレイクを構成するとEMRやAthenaを使って処理の幅が広がる

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

• AWS Greengrass
  • ゲートウェイの中にインストールする
  • クラウドではデバイスの管理を行う
  • クラウドで使っていたものをデバイスの中に持ち込める
  • Kernel4.4以上というのが厳しいという声をもらう
• クラウドで開発したモジュールを配布・管理可能かつ、ローカルで実行する
  • レイテンシの向上
  • ネットワークに常時接続する必要がなくなる
  • センシティブ情報をエッジで処理し、問題のないもののみクラウドに送る

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

• 設置場所にネットワークがない、SIMの電波も届かない
  • データアグリゲーションパターン
  • greengrassでローカル上で処理
  • N分間のデータを纏めてダイレクトにS3へ送る
• センシティブ情報が含まれているのでクラウドを使いにくい
  • センシティブ情報マスキングパターン
  • greengrassでデータを解析
  • ID部分をhash化
  • ユーザID管理DBをローカル上に建てる

まとめ

まだGAにはなってないGreengrassのお話は大変興味深いものがありました。一方デザインパターンはIoT案件を取り扱っている側から見てもユーザからの要望がリアルで、かなり実用性の高いものだと思います。是非こちらを実践していきたいと思います。GreengrassのGAはよ！