AWS IoT Greengrass
エッジデバイス上で Lambda 関数や ML 推論を実行し、クラウドとの断続的な接続環境でもローカル処理を継続できるエッジコンピューティングランタイム
概要
AWS IoT Greengrass は、エッジデバイス上でクラウドの機能をローカル実行するためのオープンソースのエッジランタイムです。Lambda 関数のローカル実行、機械学習モデルの推論、デバイス間のローカルメッセージング、OTA (Over-The-Air) によるコンポーネントのリモートデプロイをサポートします。Greengrass V2 ではコンポーネントモデルが導入され、機能を独立したモジュールとして開発・配布・更新できるようになりました。
なぜエッジで処理するのか - レイテンシ・帯域・可用性の三重課題
IoT システムでは、すべてのデータをクラウドに送信して処理する集中型アーキテクチャが必ずしも最適とは限りません。製造ラインの異常検知では数ミリ秒の判断遅延が不良品の流出につながり、監視カメラの映像をすべてクラウドに転送すれば帯域コストが膨大になり、ネットワーク障害時にはデバイスが完全に機能停止します。Greengrass はこの三重課題を解決するために、クラウドの処理能力をエッジに持ち込む設計思想で作られています。Greengrass Core デバイス (ゲートウェイ) 上で Lambda 関数やカスタムコンポーネントを実行し、ローカルで判断が完結する処理はエッジで即座に実行します。集約・要約されたデータだけをクラウドに送信することで帯域を節約し、クラウドとの接続が切れてもローカル処理は継続します。SageMaker で学習した ML モデルを Greengrass にデプロイすれば、カメラ映像の物体検出や振動データの異常検知をエッジでリアルタイムに実行でき、推論結果だけをクラウドに報告する効率的なアーキテクチャが実現します。
V2 のコンポーネントモデルとデプロイの仕組み
Greengrass V2 で導入されたコンポーネントモデルは、エッジアプリケーションの開発と運用を根本的に変えました。V1 では Lambda 関数とコネクタが密結合でデプロイされていましたが、V2 ではすべての機能が独立したコンポーネントとして定義されます。各コンポーネントはレシピ (YAML/JSON) でライフサイクル、依存関係、設定パラメータを宣言し、アーティファクト (実行バイナリ、スクリプト、ML モデルなど) と組み合わせてデプロイされます。AWS 提供のパブリックコンポーネント (ログマネージャー、ストリームマネージャー、ML 推論コンポーネントなど) と、自作のカスタムコンポーネントを自由に組み合わせられます。デプロイはクラウドから OTA で実行され、デバイスグループ (Thing Group) 単位でロールアウトできます。ロールバック設定を定義しておけば、デプロイ失敗時に自動で前のバージョンに戻すことも可能です。Azure の同等サービスである Azure IoT Edge もモジュール型のコンテナベースアーキテクチャを採用していますが、Greengrass V2 はコンテナに依存しない軽量なプロセスベースの実行モデルも選択でき、リソースが限られた小型デバイスへの対応力で優位性があります。
ローカルメッセージングと IPC で構築するエッジ内データフロー
Greengrass Core デバイスに接続された複数のクライアントデバイス間で、クラウドを経由せずにメッセージをやり取りできるローカルメッセージング機能は、エッジシステムの応答性を大幅に向上させます。ローカル MQTT ブローカーコンポーネントをデプロイすると、Greengrass Core が MQTT ブローカーとして機能し、クライアントデバイスはクラウドの IoT Core と同じ MQTT プロトコルでローカル通信できます。コンポーネント間の通信には IPC (Inter-Process Communication) メカニズムが用意されており、パブリッシュ/サブスクライブ方式でイベントを交換します。たとえば温度センサーコンポーネントが測定値をローカルトピックにパブリッシュし、異常検知コンポーネントがそれをサブスクライブして閾値判定を行い、結果をアクチュエータ制御コンポーネントに伝達する、といったエッジ内のデータフローを構築できます。ストリームマネージャーコンポーネントを使えば、ローカルで生成されたデータを S3 や Kinesis に自動的にエクスポートでき、ネットワーク断時はローカルにバッファリングして復旧後に再送します。エッジコンピューティングの関連書籍 (Amazon) では、こうしたエッジ内データフローの設計パターンが詳しく紹介されています。