【レポート】AWS Summit Tokyo 2017:AWS Greengrass Deep Dive #AWSSummit

2017.06.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

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

当エントリでは2017年05月31日に行われた『AWS Greengrass Deep Dive』に関する内容をレポートしたいと思います。

セッション概要

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

スピーカー:
 Craig Williams氏 Partner Solutions Architect, IoT Specialist Amazon Web Services, Inc.

セッション概要:
 IoT のシステムを構築する上でエッジコンピューティングに注目が集まっております。
 AWS が提供するエッジコンピューティングサービスとして、re:Invent 2016 にて AWS Greengrass が発表されました。
 本セッションでは、AWS Greengrass の紹介とGreengrassを利用する上での技術情報をお届けします。

 

セッションレポート

  • 多くの機械が発生したデータはクラウドに上がっていない
  • 鉱山のような厳しい環境
  • 遠隔から、例えば火星から集めたデータ
  • 医療機器のデータ
  • これらはエッジで処理する必要がある

Greengrassが生まれた背景

3つの問題

  • 物理的
    • レイテンシ
    • 1ms以下での処理が必要な場合がある
    • コマンド&コントロールに対応
  • 経済的
    • 大量のデータをクラウドに送信するコスト
    • エッジで処理をし、フィルタリングをしてその一部をクラウドに送信する
  • 地域的
    • プライバシーの規制が地元当局で規制されている場合がある
    • 医療の情報は病院の中に留める、といった規則もある
    • 施設の中にとどめて匿名化してからクラウドにあげる

IoTにおける3つのレイヤ

  • Things
    • デバイス
  • Cloud
    • 情報を集める先
  • Intelligence
    • 機械学習のアルゴリズムがデータを処理してクラウドに送り返す

AWS IoT

  • Device Gateway
    • 認証システムは相互証明書。デバイスとクラウドは証明書を持つ必要がある。
    • それぞれのセキュリティポリシーと1対1のマッピングを行う
    • AWS SDKがなくてもAWS IoTにつなぐことは出来る
    • MQTTのようなオープンソースをベースにしているのでロックインの心配もない
  • Rule Engine
    • データがどこに繋がるのかを決める所
  • Device State
    • Device ShadowはDeviceのState(状態)を持っている
    • 8kのデータブロック。非構造のJSON
    • Wi-Fiがあっても接続が切れることはよくある。オンラインになったときにコマンド&コントロールが行われる

AWS Greengrass

  • サービスをエッジに拡張するもの
  • 同じ機能を使ってエッジで運用が出来る
  • Device Gateway、Lambda Actionがエッジまでおりてきている
  • 一元的にLambda関数をデプロイし、管理することが出来る
  • コンテナベースなので提供した仕組みをそのまま使うことができる
  • 証明書が必要なこともAWS IoTと同じ
  • Device Stateもエッジにある
  • Greengrass自体はクラウドと通信出来る

メリット

  • ローカルイベントを早くレスポンスできる
  • オフラインでの運用
    • AWSには5年に一度接続できればいい
    • Lambdaのデプロイ等は自動的にGreengrassが受け取り更新する
  • シンプルなデバイスプログラミング
    • Cronジョブ、ロギングなどのローカルプログラミングにおける課題はGreengrassで一気に解決される
    • 開発者はただコードを書くだけでよい
  • IoTアプリケーションのコストを削減
    • 帯域の使用量が違う
    • 開発期間が短くなる

GGC (Greengrass Core)

  • Greengrassはソフトウェア
    • Lambdaの実行、メッセージ、Device shadow、クラウドとの直接連携に責任をもっている
    • Lambdaはコンテナエンジンによって動く
    • これらは全てGGCによって管理されている

対象ハードウェア

  • 1GHzのcore
  • 128MB RAM
  • x86 and ARM
  • Linux(Ubuntu or Amazon)
  • Raspberry Piでも動く
  • コンテナベースのエンジンがどんなハードウェアでも動くように設計されている

SDK

  • IoT Device SDKを利用するとローカルネットワークを介してGGCと通信する設定ができる
  • 独自の証明書を使う。
  • 初回起動時GGCが証明書、エンドポイントの取得を行う

Greengrass Group

  • 全てのGGCとその他のデバイスのコミュニケーションに関する設定セット
  • Shadowをローカルにするかクラウドに同期するかを選択できる
  • Lambda Funcitonのリスト(クラウドからレプリケーションしたいリスト)を設定する

ローカルルールエンジン

  • Rule Engineと同じ
  • データがコアからクラウドに流れて欲しい、という場合にGreengrass Groupがその流れを管理する

Group + Deploymentsのメリット

  • 例えば工場の中にGroupがそれぞれあり、それぞれのデータの流れを独自に制御する
  • ルーティングの構成などをわざわざ現場に行かなくても管理できる

Local Lambda

  • Python2.7をサポート
  • 将来言語を増やしていく予定
  • これまでと同じようにコードを書いてzip化してアップロードしてLambda Functionを作成する

何が出来るか

  • コマンド&コントロール
  • オフライン実行
  • データのフィルタリングと集約。帯域を節約
  • 時間が経つとスマートに(機械学習)

Shadow

  • デバイスとLambdaの状態を示すJSONドキュメント
  • 定義する内容は論理的なもの(車、エンジンなど)
  • クラウドに同期することもローカルに保持することも可能
  • 他のシステム(携帯など)で見たい場合は同期させればよい

Messaging

  • エッジでは全てのトランザクション、データの流れは定義される必要がある
  • メッセージングの流れ
    • Identityを確認
    • ルートテーブルの確認 => ターゲットのマッチ、デフォルト拒否
    • LambdaかSubscriberへデータを流す
  • ルートテーブルに明示的な定義が無ければデータは受信できない
  • メッセージの内容をルートテーブルが見てどのLambdaを立ち上げるかどうか決める

Security

  • 相互認証をベースとする
  • クラウド内のSigV4認証情報に関連付けることが出来る
    • 必要に応じてAWSリソースと紐付けることができる
  • 製造業では自分的でCAの証明書を持ちたい、という要望がある
    • GGCはローカルの証明書を持ちCAにより署名される

CAの作成プロセス

  • CAでGGC証明書に署名
  • CAでGGD証明書に署名する
  • AWSにCAをアップロード
  • サーバ証明書のアクティベート
  • JITRでGGD証明書を処理
  • DeviceはGGCが証明書を確認してローカル、またはAWSに接続する

Connetion Code

  • 従来のSDKでのプログラミングとの違い
    • host, caPathがローカルのものに変わるくらい

詳細仕様

  • Linux 4.4 with OverlayFS enabled
  • glibc libraries 2.14
  • python 2.7
  • SQLite 3+
  • x86_64, armv6 arm64
  • 128MB RAM
  • Core 1GHz-

###FAQ

  • シャドウサイズの制限は
    • クラウドと同期することが出来るため、クラウド同様8kが上限
  • GGCはコア同士で相互通信できるか
    • 普通にはできない。2つのコア間を中継する接続された「デバイス」を使用してプロキシを作成する必要がある
  • ルートテーブルにワイルドカードは使えるか
    • いいえ。明示的なルールが必要
  • クラウドのトピックをSubscribedできるか
    • はい、ソースは「Cloud」か特定のローカルターゲット
  • Local Lambdaの制限は
    • クラウドのように実行時間5分の縛りはない
    • すべての依存関係はパッケージ化
    • テストはクラウドで実行することも可能

まとめ

  • Greengrassの構成要素
    • Local Lambda
    • Local Device Shadows
    • Local Broker
    • Local Security

何故Greengrassが重要なのか

  • 組み込み開発者、クラウド開発者の全てのメリットが活かせる

パートナー

料金

  • アクティブなGGCごとの価格
  • 1年無償/3台のデバイスまで
  • $0.16/month or $1.49/year
  • 既にページが有り、Limited previewがある
  • Snowball Edge

 

まとめ

Limited Previewの段階のため、まだまだ謎の多いGreengrassが少しだけわかったような気がします。AWS IoTがそのままデバイス側に入るような感じでしょうか。エッジコンピューティングはこれからのIoTのキーとなる技術なので勉強していきたいです。