9/26のJAWS-UG IoT専門支部主催「AWS Greengrass Handson」を受講し終わったばかりの松下です
受講目的
- AWS Greengrass Coreからセンサー制御ってどうするの？
- Lambda関数の更新時の手順は？
この2点が前から気になっていました。運用するのに必須だからさ。
結論
AWS Greengrass についてわかった事 (たぶん)
AWS Greengrass Core (エッジデバイス上で動くコンテナプロセス、以下ggc) は、AWS IoT に対するMQTT Proxyサーバ的役割と、Lambda実行環境を持っている。
そのため
- ggcを起動すると 8883 ポートでMQTT接続を待ち受ける
- オフラインとなったとしても、センサー制御部プログラム側から見ると、AWS IoTに直接接続しているかの如く動作し続けることができる
AWS Greengrass Coreとセンサー制御部の関係
NEW(3/7): re:Invent 2017 で AWS Greengrass のアップデートがされ ローカルLambdaからローカルリソースへのアクセスも可能になりました
ggcやその上で動くLambdaからOSが持っているローカルリソース、例えば /dev/ttyUSB0 をRead/Writeすることはできない。（と推測される）
そのため、「センサーからReadする→AWS Greengrass SDKを使って)ggcにデータを投げる」というプログラムが必要。また、このプログラムが動くようにする環境が必須-
また、上記プログラムの活動制御はggcは行ってくれないので、systemdのUnitを作る※、そのプログラム自体の更新の仕組みを考える、等が必須※ggc上のLambdaを更新する際、ggcのMQTT接続が切れる模様。そうなると、センサー制御部のプログラムは再接続の仕組みを持たせるか、supervisor的なところから再起動してもらう必要がある
Lambda関数の更新時の手順
ggc上で動くLambdaのイメージ
ハンズオンでの構成を再現すると
ThingShadowSensor.py
(publishするように書く)
↓
(8883:sensing/data/Sensor-01)
↑
(subscribeするように設定)
Lambda:cpuUsageChecker-01:VERSION
(publishするように書く)
↓
(8883:$aws/things/Alert-01/shadow/#)
↑
(subscribeするように書く)
ThingAlertSensor.py
わかりづらくてゴメン。何が言いたいかというと、Lambda関数だ～とか言わず、結局のところMQTTのトピックを介してパイプ処理をしている。そして、ggc内はスクリプトじゃなくてLambda関数を実行できるよ、という解釈で大丈夫。（たぶん）
そのため、この行先（＝サブスクリプション）に、たとえば Lambda:cpuUsageChecker-01:NEW-VERSION が含まれるエントリー（トピックの組み合わせ）を作ってあげれば NEW-VERSION な Lambda関数が起動する。
手順は以下の通り;
- AWS Lambda関数を更新、発行する (新しいバージョンができる)
- クラウド側AWS Greengrassの「Lambda」メニューで、新しいバージョンのLambda関数を「追加」する (複数のバージョンが存在することになる)
- クラウド側AWS Greengrassの「サブスクリプション」メニューで、新しいバージョンのLambda関数を「ソース」や「ターゲット」とするエントリーを作成し、古いバージョンのLambda関数を利用しているエントリーを消す
- 消さなくても良い。その代わり、トピックを調整する必要がある
- クラウド側AWS Greengrassの「グループ」メニューから、デプロイする
まだわからないこと
- ggcに対してすっぴんのMQTTクライアント接続が可能なのか？ (AWS Greengrass SDKはデカすぎる。センサー制御プログラムは極力小さくしたいはずだ！)
あとがき
市川さんはじめ、全国のJAWS-UG IoT 専門支部の方々、お疲れ様でしたー！！！