Amazon Web Services ブログ
[AWS Black Belt Online Seminar] AWS Greengrass で実現するエッジコンピューティング 資料及び QA 公開
こんにちは、マーケティングの鬼形です。
先日 (2018/5/8) 開催しました AWS Black Belt Online Seminar「AWS Greengrassで実現するエッジコンピューティング」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。
20180508 AWS Black Belt Online Seminar AWS Greengrassで実現するエッジコンピューティング
Q1. long-live lambda はスケールアウトさせることがそもそもできないという理解でしょうか。
A. はい、1つのコンテナで動作しますので、複数コンテナで動作させることはできません。メモリを増やすスケールアップはできますので、処理速度が足りない場合は Lambda 内でスレッドを増やすなど Lambda 内のロジックを工夫することでご対応ください。
Q2. long-lived Lambda でエラーが発生した場合、自動的に再起動されますか？
A. はい、5回まではリトライを試みます。5回エラーが生じると、そこで再起動を諦める形となります。Greengrass のシステムが出力する runtime.log に再起動の様子が出力されますので、そちらで振る舞いをご確認いただけます。
Q3. 例えば Lambda で分類器による分類を行う場合、分類器への入力をハンドラの引数等で渡すことはできますか。エッジのスペックの制限で入力をファイルにできない、ファイル読み込み速度を低減させるためメモリ渡しにしたい。といったことを考えています。
A. 分類器は ML のモデルだと想定しました。MQTT のメッセージを Lambda のハンドラ関数で受け取ったのち、受け取ったメッセージから必要な値を抽出し、それを入力値として、利用されている ML のフレームワークの推論メソッドを呼び出す形となります。入力値をメモリから渡せるかどうかは ML のフレームワークのメソッドの実装に依存します。
Q4. Local Lambda のメモリ使用量を設定できるとのことですが、デバイス側でヒープメモリを確保できなかった場合はどういう挙動になるのでしょうか。
A. コンテナ起動時にメモリ不足によるエラーが発生し終了します。エラーは Greengrass のシステムが出力する runtime.log に出力されます。
Q5. Lambda で Python3 サポートの予定はありますか。
A. ロードマップに関するご質問についてはご回答できません。大変申し訳ございません。
Q6. Lambda の初期化処理でループを回す例題は拝見しました。MQTT によってハンドラーが呼ばれて処理する例題の URL を教えてください。
A. こちらの Github を参考になさってください。hello-world-counter-python というサンプルが MQTT によってハンドラーが呼ばれて処理する例題となります。こちらは on-demand でも long-lived でも動かすことができるので、それぞれの Lifecycle を確認していただくのに良いかと思います。ひととおり試していただく手順も Developer Guide に用意しております。
Q7. device 側はグローバル IP がない（プロキシ経由など）の場合クラウドとの接続はどういう構成にする必要がありますか。
A. MQTT は device 側からクラウドに接続し、そのセッションを維持する形となりますので、 Device 自体がグローバル IP を持つ必要はありません。そのため NAT 内のデバイスでもクラウドと常時接続していただくことが可能です。(8883 ポートで外部アクセス可能である必要があります) 一方、コーポーレートの http proxy などを通して Greengrass がクラウドと常時接続することは現状できません。
Q8. ここでいうデプロイとはデバイス側のことですか？一斉にデプロイが発生するということですか。
A. Greengrass のデプロイは、Greengrass Group に定義した各種設定と、Lambda のアプリケーションコード、機械学習のモデルを配信することを指します。各種設定には、接続するエンドポイントデバイスや、ローカルリソースアクセス、Subscription、Greengrass group Role、Logging などを含みます。デプロイはこれらすべてを一斉にデプロイしますが、差分更新となりますので、例えば機械学習のモデルを更新した場合、デプロイ済みの Lambda のアプリケーションコードは再ダウンロードされず、更新したモデルのみがデプロイされます。
Q9. プロトコルアダプターを用いて、BLE、EnOcean 接続デバイスとの通信は可能でしょうか。TCP レイヤーでの通信ができることが大前提でしょうか。
A. いいえ、UDP やその他プロトコルにも対応できます。ただしプロトコルによっては、host OS 側のデバイスリソースにアクセスが必要となりますので、ローカルリソースアクセスを用いてホワイトリスト登録を行っていただく必要があります。よって、ローカルリソースアクセスで許可できる範囲で通信が可能なプロトコルであれば、対応できる、となります。
Q10. 産業用プロトコルと同様に自分で拡張する方法についてのドキュメントはありますか。
A. ポーティングガイドのようなものはご用意しておりませんが、コードを参照していただけます。
https://github.com/aws-samples/aws-greengrass-samples 内 greengrass-opcua-adapter-nodejs
プロトコルアダプタは、Lambda で動くプログラムで様々なプロトコルに対応する形ですので、通信したいプロトコルが提供するライブラリを Lambda に組み込んで実装するのが一般的です。
Q11. スケールアウトは、動的でしょうか？事前にスケールアウト用で AWS 上に事前準備が必要な物でしょうか。
A. スケールアウトは動的であり、自動で行われます。特にAWS 上で事前準備は必要ありません。デバイス側に実際の負荷でメッセージを流したときにどれくらいスケールアウトし、それに対しハードウェアのリソースが十分かをご確認ください。
Q12. ggc 起動 → LongLivedLambda 起動 → 5回エラー、となった後はリモートで ggc を再起動できますか。
A. デプロイを行うことで、再度実行し直すことが出来ます。通常は5回エラーが連続して発生している状況なので、コードの修正や設定変更を伴うデプロイになるかと思います。
以上です。
今後の AWS Black Belt Online Seminar のスケジュール
■ソリューションカット
■サービスカット
詳細はこちらからもご確認いただけます。皆様のご参加をお待ちしております。