エンジニアの河崎です。
AWS GreengrassはLambda等のAWSで利用可能なサービスの一部をローカルデバイス上で実行できるようにする事で、エッジ側でのアプリケーション実行を簡単にできるサービスです。 ABEJAではエッジコンピューティングを行っていますので、さっそく調査をしてみました。
以降の検証は Raspberry Pi 3 Model B で行っています。
※2017年6月9日時点の情報です。また、できるだけ正確な情報を書くようにしましたが、間違っている可能性もありますのでご留意ください。
調べてみた
AWS Greengrassとは？
公式ドキュメント
What Is AWS Greengrass? - AWS Greengrass
Developers.IOのブログエントリ
【新サービス】AWS GreengrassがGA(一般利用開始)になりました！ ｜ Developers.IO
どうやって動かすの？
GreengrassCoreのインストールされたデバイス上で常時起動型のLambda functionを実行するサンプル
Deploying a simple Lambda function to AWS Greengrass - AWS Greengrass
GreengrassCoreのインストールされたデバイスをハブにして、IoTデバイス間の通信をするサンプル
AWS Greengrass Example Scenario - AWS Greengrass
Developers.IOのブログエントリ
AWS Greengrass CoreをEC2でセットアップする ｜ Developers.IO
Greengrass Coreの動作要件は？
AWS Greengrass FAQs - Amazon Web Servicesに記載があります。
- Operating Systems: Ubuntu 14.04 LTS, Jessie Kernel 4.¼.4, and other Linux distributions with Kernel 4.4 or greater
- CPU Architectures: x86_64, Armv7, Aarch64 (ArmV8)
また、以下のカーネルコンフィグの項目が有効化されている必要があります。世の中にはcgroupsやoverlayfsが有効化されていないカーネルが乗ったデバイスが有るので気をつけたいですね。
自分のカーネルでカーネルコンフィグの項目が有効化されているかはdockerのチェックスクリプトを使うと良いかもしれません。
2.Kernel configuration ·Mqueue: CONFIG_POSIX_MQUEUE ·Overlay: CONFIG_OF_OVERLAY ·Overlay FS: CONFIG_OVERLAY_FS ·Seccomp Arch Filter: CONFIG_HAVE_ARCH_SECCOMP_FILTER ·Seccomp Filter: CONFIG_SECCOMP_FILTER ·Seccomp: CONFIG_SECCOMP ·Devpts: CONFIG_DEVPTS_MULTIPLE_INSTANCES 3.Kernel configuration for Namespace - Kernels must be built with these configurations enabled: ·IPC isolation: CONFIG_IPC_NS ·Network isolation: CONFIG_NET_NS ·UTS isolation: CONFIG_UTS_NS ·User isolation: CONFIG_USER_NS ·PID isolation: CONFIG_PID_NS 4.Kernel configuration for Cgroup - Kernels must be built with these configurations enabled: ·Enable cgroups: CONFIG_CGROUPS ·Enable Memory cgroup: CONFIG_MEMCG ·Enable freezer cgroup: CONFIG_CGROUP_FREEZER ·Enable devices cgroup: CONFIG_CGROUP_DEVICE ·Enable pids cgroup: CONFIG_CGROUP_PIDS
デバイス上でLambdaが動くってどういうこと？
GreengrassCoreがインストールされたデバイス上でpythonのスクリプトを実行する事ができます。Lambda functionの実行はMQTTでメッセージを受けた時に実行、定期的に実行、常時起動などができるようです。 ちなみに、GreengrassCoreで実行されるLambda functionには実行時間の制限はありません。
Lambda functionの実行ログは？GreengrassCoreのログは？
以下の2種類のログを取得可能。それぞれ、CloudWatchとLocalファイルシステムに保存する事ができます。Localファイルシステムの場合はどれくらいのサイズまで保存するかを指定できます。
- User lambda logs
- Greengrass system logs
検証してみた
GreengrassからAWSの他のサービスへアクセスする権限はどうやって指定するの？
IAM Roleを使う
GrenngrassからCloudWatch Logsへログを送る場合は、Greengrass GroupにIAM Roleを付与します。また、LambdaからCloudWatch Logsや他のサービスにアクセスする時も同様にLambda functionにIAM Roleを付与します。
Greengrassからどういう感じでAWSサービス扱うのかな？
基本的にはMQTTでクラウドに送った後にRules Engineを使うのがよさそうです。Lambda functionに適切なIAM Roleを付与すればSDKからKinesisやDynamoDBにアクセスする事は可能だと思うので、ユーザ側の要件によりそう。
CloudWatch Eventsからデバイス側のLambdaを呼び出せる？
今のところできなさそう？
Greengrassコアがオフラインの状態でもLambda functionの実行はできる？
多分できる。未検証
このサンプルを動かしてる状態で、ネットワークの状態をいじると検証できます。
Lambda functionからpythonライブラリや設定ファイル等にアクセスできる？
可能
クラウドでの実行時と同様にDeployment Packageを作る事ができます。この際、AWS Greengrass Core SDKをダウンロードしてパッケージに含める必要があります。また、設定ファイルもパッケージにいれれば読み込みできそうです。 しかし、デプロイパッケージの容量制限は50MBなので、特定用途では使えない事がありそうです。 また、パッケージする時にコンパイルが走るライブラリは、GreengrassCore上のランタイムでは動かないと思われるので一工夫必要です。多くの場合、パッケージしたいマシンはx86でGreengrassCoreが動くデバイスはARMですよね。また、コンテナ内には必要依存ライブラリも存在しません。
こういうプロジェクトを参考にがんばるとよさそうですね。 GitHub - vitolimandibhrata/aws-lambda-numpy: NumPy Python Library for AWS Lambda
Lambda functionからデバイス側のファイルシステムにアクセスできる？
読み込みのみ可能
Lambda function起動時に、デバイスのファイルシステムを起点として、コンテナのファイルシステムをoverlayfsで構築しているようです。Lambda functionで書き込んだファイルは、デバイス側のファイルシステムに反映されませんし、Lambda functionを再起動した時はLambdaから見えているファイルシステムはリセットされています。
/tmpはコンテナ起動時にリセットされるので、デバイス側の/tmpとコンテナ側の/tmpは完全に独立しています。
以上の特性を利用すれば、Lambdaからデバイス側のファイルを参照だけする事ができますが、推奨されない気がします。
Lambda functionからデバイス側のカメラやGPIO等にアクセスできる？
今のところできない
Lamda functionの中から/devを見てみましたが、カメラデバイスやgpioデバイスは見えていませんでした。
ローカルネットワークでのデバイス間通信ってどんな感じでやるの？
APIを使う事でGreengrass Coreのローカルネットワーク内でのIPをIoTデバイス側から取得できます。 AWS IoT device SDKを使う事で簡単に、IoTデバイスから同一ネットワーク内のGreengrass Coreに接続する事ができます。Greengrass CoreにはMQTT brokerと同一GreengrassCore内のDeviceShadowを保持するDBが有るので、IoTデバイスとGreengrass CoreがAWSに繋がらない状態でも、デバイス同士のメッセージの交換や、DeviceShadowを使った状態の同期が可能です。このサンプルを動かしてみると良いと思います。
Local Rules Engineって何？
Subscriptionsの事だと思います。メッセージのソース、ターゲット、メッセージを流すトピックフィルターを指定できます。ソースとターゲットは、IoT Cloud(クラウド側のMQTT broker)、Local Device Shadow、同一Grenngrass Group内のデバイス、Lambda functionを指定できます。このサンプルをいじれば色々検証できそうです。
おわりに
現時点ではGreengrassCore上でのLambda functionは、センサー等を使ったヘビーな処理を実行するというよりは、ゲートウェイとして必要になるメッセージの処理と、デバイスの操作を簡易的に行うために使う事が想定されているのかなという感想を持ちました。 まだドキュメントが少ないので、増えていくと検証もすすみそうですね。当面は、APIドキュメントを読んでいこうと思います。
AWSを使う事でクラウドだけでなく、エッジ側でもシステムを簡単に構築・運用できるようになっていってほしいですね。
宣伝
ABEJAではエッジ・クラウドを問わずディープラーニングを実行できるプラットフォームを提供しています。 テクノロジーの最先端に挑戦したいイケてるしヤバイエンジニアの方のご参画をお待ちしております！
ABEJAが発信する最新テクノロジーに興味がある方は、是非ともブログの読者に！
ABEJAという会社に興味が湧いてきた方はWantedlyで会社、事業、人の情報を発信しているので、是非ともフォローを！！ www.wantedly.com
ABEJAの中の人と話ししたい！オフィス見学してみたいも随時受け付けておりますので、気軽にポチッとどうぞ↓↓
学生向けの勉強会もしています！ガンガン応募してください！
