AWS IoT 再入門ブログリレー AWS IoT Greengrass（V1）編
この記事の趣旨
本企画は、弊社チームIoTメンバーが初心に返ってIoTサービスについて学びなおし、解説してみようというものです。本エントリーでは、「AWSのエッジコンピューティングサービス」である「AWS IoT Greengrass」について紹介します。
Greengrass V2について
Greengrass は 昨年の「re:Invent 2020」で V2 が発表されていますが、V1と仕様が異なるため今回は V1 を前提にご紹介したいと思います。
今回のエントリで、Greengrass にどんな機能があって何ができるのかを把握いただければ幸いです。
Greengrassのユースケース
Greengrass は単なるエッジコンピューティングのサービスではなく、AWSクラウドの機能をエッジデバイスへ拡張できるエキサイティングなサービスですが、そもそもエッジコンピューティングとは、簡単に言うと 「現場にあるローカルデバイスやその近くにあるデバイス・サーバでデータ処理を行うこと」 と言えます。
では、エッジでデータ処理を行いたい理由は何があるのでしょう。次のようなユースケースを考えてみました。
例えば、回線帯域が細くて大きなデータが送れない場合、エッジデバイス上で不要なデータを削ってサイズを小さくして送りたいと思うでしょう。
データにセンシティブな情報があれば、その部分だけ削除したりマスキングしてデータを送りたいというケースもあると思います。
さらに、異常発生の検知などレイテンシの問題でクラウドにデータを送らずにローカルデバイス同士でデータのやり取りを行いたいケースも考えられます。
しかし、これらを実現する場合、Greengrass を使わなくても 既存のデバイスで実現することは可能です。次からは Greengrass を使う理由について見ていきたいと思います。
Greengrass のメリット
Greengrass にはエッジコンピューティングの実現を加速させるような様々な機能が提供されています。
先程の例にあったようなデバイス上でデータを加工する場合、その処理を実現するプログラムの開発はどうするのが効率的でしょうか？ また、開発だけでなくデバイスへのデプロイ方法も考えなければいけません。考えたデプロイ方法も対象のデバイスが多くなった場合の事を考えておく必要があります。
こういった課題を一つずつ検討して実装していくのは時間もコストもかかることが容易に想像できます。この他にもいくつか比較してみたものが下記の表になります。
| 比較項目 | Greengrass | no Greengrass |
|---|---|---|
| デバイス上のアプリ開発 | ・Lambdaの場合、従来のLambda 開発手法がそのまま使える。 ・Greengrass API によるアプリのデプロイ |
自前で開発手法を整備、デプロイ基盤を用意する必要がある |
| エッジデバイス間の通信 | Greengrass Core を MQTT ブローカーとして利用可能 | 自前で仕組みを用意する必要がある |
| AWS サービスのアクセス性 | コネクター機能により独自実装せずに多くのサービスを利用可能 | 自前で実装する必要がある |
| 産業プロトコルの利用 | コネクター機能などにより独自実装せずに利用可能な場合がある | 自前で実装する必要がある |
Greengrass はこの他にも様々な機能を持っているため、デバイス要件を満たせば Greengrass によりエッジコンピューティングの導入がとても容易になるケースが多くあると考えられます。 とはいえ、自前で実装しなければならない場合や学習コストなどの考慮点もあり銀の弾丸ではないので、要件に応じて検討する必要があります。
Greengrass Group と Greengrass Core
Greengrass の構成要素には、大きく分けて次の2つがあります。
- Greengrass サービス
- Greengrass 全体を管理するサービス
- エッジデバイスがクラウドと連携できるための各種機能の提供と管理を行う
- 例１：Greengrass Core デバイスやデバイス上の Lambda 関数の管理
- 例２：データのルーティング設定（デバイス to AWS, デバイス to デバイスなど）
- Greengrass Core
- エッジデバイスにインストールして利用するソフトウェア
- Greengrass サービスと連携して機能を提供
- インストールされたデバイスは「Greengrass Coreデバイス」と呼ばれる
全体の構成としては、下記のBlackbeltにある図がイメージしやすいと思います。
図の下側にある「Greengrass Group」は、物理的には「Greengrass Core デバイス」と「Greengrass Core デバイスと通信するデバイス」をグルーピングして管理します。なお、Greengrass Core デバイスはグループに一つだけ存在する形になります。
この図の「Greengrass Connected Device」は、Greengrass Core に接続できる別のデバイスです。
Greengrass Core は ローカルで MQTT ブローカーの機能を提供しているので、同じグループ内の他のデバイスと MQTT でデータのやり取りを行うことが可能です。
また、このデバイスから Greengrass Core 経由でAWS クラウドへデータ送信することも可能です。
このグループを管理の基本単位として、次のようなリソースや設定を管理します。
- Greengrass Core 上の Lambda
- Greengrass Core と通信する周辺デバイス
- 拡張機能
- ログなどの各種設定
- など
MQTT ブローカー
既に書いてしまいましたが、Greengrass Core デバイスは ローカルの MQTT ブローカーとしての機能を提供します。
そのため、下記のようにインターネットにつながっていなくても、ローカルのデバイス同士でメッセージのやりとりを行うことが可能です。
Greengrass Core デバイスに接続するための IPアドレスやポート番号は、Discovery API により取得可能です。
そのため、インターネットに接続できないローカルのデバイス間で MQTT メッセージをやり取りしたい場合は、事前にGreengrass Core コアデバイスの IP アドレスやポート番号を保持しておくか、ローカルで参照できる仕組みを用意しておく必要があります。
あるいは、初期セットアップ時だけインターネット接続できる場所で行い、その際に Greengrass Core への接続情報を取得、ローカルに保存するなどの仕組みを用意しても良いかもしれません。
サブスクリプション
デバイスデータの送信先は、用途に応じてクラウドや他のローカルデバイスなど様々なケースがあります。
この送り先を決めるルーティングを「サブスクリプション」という設定で行います。
上の図でdevice2から出ている赤色の矢印「デバイス to AWS」の場合、サブスクリプションが下記のように設定されています。
| 設定項目 | 設定内容 |
|---|---|
| source | device2 |
| destination | IoT Cloud |
| topic | data/cloud |
この設定の意味は次のようになります。
- source : データの送り元である
device2から - topic : Greengrass Core デバイスに対してトピック
device/cloudを指定して - destination : データを publish すると AWS クラウドに転送される
このサブスクリプション設定により「デバイス to デバイス」「デバイス to クラウド」「クラウド to デバイス」というように、あらゆる方向でデータのやり取りが簡単に行えるようになります。
ローカルアクション（Lambda）
「エッジコンピューティング」としてエッジ上でデータ処理する為に、Greengrass Core デバイス上で Lambda Function を実行することが可能です。
このLambda Function は、AWS クラウドで開発したものをデバイスにデプロイして利用します。そのため、既に Lambda を利用した開発実績や環境があれば、開発スタイルを変えること無く、そのままエッジ上の処理も開発することが可能になります。
デプロイした Lambda Function は MQTT メッセージを受け取ると処理を実行します。
上記の場合では、「IoT デバイス」が「Lambda1」にデータを送るサブスクリプションが設定されているので、「IoT デバイス」からトピックdata/lambdaにデータを Publish すると Lambda が実行されます。
また、Greengrass の Lambda で利用できる言語は下記の通りなので、通常の Lambda のような選択ができない点に注意が必要です。（バージョンなどは最新のドキュメントを参照してください）
デバイスシャドウ
Greengrassでは、ローカルの Greengrass Core デバイス上で 「デバイスシャドウ」 を利用することができます。これは、クラウドのデバイスシャドウと同期もできるし、ローカルだけで利用することも可能です。
デバイスシャドウについては、下記の記事も参考にしていただければと思います。
ちなみに Greengrass のローカルシャドウは、デバイス上の SQLite3 で管理されています。
セキュリティ
通常のデバイスと同様に、Greengrass Core デバイスもデバイス証明書、秘密鍵、IoT CoreのCA証明書を使って AWS と接続します。
また、Greengrass Core に接続する他のデバイスが MQTT で通信するためには、 IoT CoreのCA証明書ではなく、所属するグループ固有の 「グループ CA 証明書」 を利用します。
IoT Core の CA 証明書は AWS コンソールなどから誰でもダウンロードできますが、「グループ CA 証明書」はグループ固有なので、グループ ID などを元に Discover APIで取得します。（Discover APIは先に書いたとおり、Greengrass Core デバイスの 情報を取得できる API です。）
ローカルリソースアクセス
Greengrass Core デバイスはローカル上のデバイスなので、Greengrass Core の Lambda からローカル上のカメラやセンサーなどにアクセスしたい場合があります。
Greengrass Core の Lambda はデフォルトでは Linux コンテナで実行されるので、デバイスへのアクセスを制限することができますが、ローカル上のデバイスにアクセスしたい場合は、この「ローカルリソースアクセス」を設定します。
デフォルトでは、ホワイトリスト形式でアクセスしたいリソースを指定します。
例えば、ラズベリーパイ で Python の RPi.GPIO を使って GPIO を操作したい場合は、/dev/gpionumを許可対象に指定します。
これは、RPi.GPIOが/dev/gpionumに対して読み書きを行うためです。操作するデバイスや操作方法によってリソースタイプを指定します。
なお、デフォルトではなく「ノンコンテナLambda」の場合は、ホスト上で実行されるモードになるので、制限なくデバイス上のリソースにアクセスすることができるようになります。
そのため基本的にはホワイトリスト形式を使うデフォルトモードが推奨されていますが、Docker コンテナとして Greengrass を利用する場合は「ノンコンテナLambda」で動かす必要があるので注意が必要です。
拡張機能
Greengrass では基本的な機能の他に、拡張機能として AWS の各種サービスへのアクセスを容易にしてくれたり、ストリームデータを効果的に利用できるような機能がいくつか提供されています。
ここでは全てを紹介しきれないので、「機械学習」と「コネクター」について簡単に紹介させていただきます。
機械学習
Greengrass では機械学習による推論を Greengrass Core デバイス上で実行することができます。
上の図のように、SageMakerや独自環境で作成した既存のモデルを Greengrass Core デバイスにダウンロードしてエッジ上で推論することが可能です。
これにより、学習などの潤沢なマシンリソースが必要な処理はクラウドで行い、エッジデバイスは推論できるだけのリソースがあればいい、ということになります。
また推論結果をクラウドに送り再学習させることで、継続的にモデルをアップデートさせることも可能になります。
コネクター
AWSの各種サービスと連携する場合や、製造現場でよく利用される産業プロトコルで他の機器にアクセスするような場合に、汎用的に利用できるアプリケーションが AWS から提供されています。
例えば、Greengrass Core デバイスから「Kinesis Data Stream」にデータを送りたい場合は「Kinesis Data Stream 用のコネクター」を使って簡単にデータを送ることができます。
また、ローカルの産業機器と Modbus-RTU などの産業プロトコルで通信したい場合も、該当する処理をコネクターにオフロードすることができます。
実際にコネクタをデプロイすると、Greengrass Core デバイス上に該当のアプリケーションがデプロイされて稼働していることを確認することができます。下記は 「Sitewise コネクター」をデプロイした際のプロセスです。この場合は、コネクターに該当する2つの Java プロセスが起動していることを確認できました。
コネクターとして提供されていない場合は、Greengrass Lambda で自前で実装するといった対応が必要になりますが、コネクターが使えるならその開発工数を削減することができます。
また、コネクターとして提供されていない場合でも、下記のようにリファレンス実装などの形でコネクターに相当するアプリケーションが公開されている場合があります。
上記は、三菱電機 の シーケンサである MELSEC からSLMP プロトコルを使って Greengrass Core デバイスでデータ収集するようなケースが想定されています。
マネージドなコネクターを使わない場合は、基本的にはユーザー自身でアプリケーションの保守などを行う必要があると思いますが、これらを参考に処理をカスタマイズすることも可能になると思います。
自前で実装する前に該当するコネクターの有無や、公開されているサンプルの有無などを一度確認されるのもオススメです。
注意点としては、Greengrass Core 上の Lambda が動作するモード（コンテナ Lambdaかどうか）によってコネクタの利用可否が変わります。対応表が下記ドキュメントで公開されているので、こちらも合わせてご確認ください。
Greengrass Core のシステム要件
Greengrass Core を利用できるデバイスには、ある程度リッチな環境が要求されます。
基本的には Linux が想定されますが、Greengrass Core の Docker イメージもあるので他のOSでも動かすことが可能です。
製造業の現場ではWindows マシンも多く利用されていると思いますが、Docker の実行環境が用意できるのであれば、Windows マシン上でも Greengrass を利用することが可能です。
ただし、この場合は Lambda のコンテナモードは利用できない点に注意が必要です。
Greengrass の始め方
Greengrass の環境構築の方法には、大まかに分けると2パターンあります。
- クイックスタート
- コンソールやCLIから順次作業を行って環境構築する
クイックスタートは非常に簡単に Greengrass の環境をセットアップしてくれるスクリプトです。
インタラクティブにパラメータをセットして実行したり、オプションでパラメータを指定して一気に構築することも可能です。
クイックスタートを使わない場合は、マネジメントコンソールや AWS CLI を使って次のような工程を一つずつ手作業で実施します。
- Greengrass Core ソフトをダウンロードしてインストール
- デバイス証明書、秘密鍵、CA 証明書をダウンロードしてデバイスに保存
- 必要に応じてデバイス側のOS 設定を変更
- Greengrass プロセスを起動
Greengrass Core ソフトのインストールは、apt コマンドなどOS 標準のパッケージ管理システムで行うことも可能です。
なお、Greengrass Core は OTA エージェントを利用することで自身をアップデートすることができますが、apt などでインストールした場合は、パッケージ管理システムでアップデートすることになります。
モニタリング
Greengrass Core では、Greengrass Core 自身のログと Lambda のログを取得することが可能です。ログの取得有無やログレベルも設定することができます。
取得したログは CloudWatch Logs に送ることもできるので、遠隔地にあるデバイスでもリモートからデバイスのログを参照することができます。
下記はマネジメントコンソールのログ設定の画面です。
Greengrass の利用料金
「アクティブな Greengrass Core デバイス1台につき ＄0.18/月（東京リージョン）」 が発生します。月のうち１度でも認証されると課金対象になります。
また、従来の Lambdaでは実行時間の課金を考慮する必要がありましたが、Greengrass Core の Lambda はデバイス上で実行されるので Lambda の実行時間による課金は発生しません。
その他に、IoT Core や IoT Analytics など他の関連サービスを使う場合や、Kinesis など他の AWS サービスも使えばその利用料金も別途発生します。
最後に
Greengrass 自体とても多機能なので、基本的な機能を中心にピックアップしてご紹介してみました。Greengrass を理解する一助になれば幸いです。
V2 についてはまだ未確認な部分があるので、今後ブログでどんどんご紹介していきたいと思います！
