インフラ設計

AWS IoT Greengrass で構築するエッジ IoT アプリケーション - ローカル処理とクラウド連携

エッジデバイスで Lambda 関数を実行し、クラウドとの断続的な接続環境でもローカル処理を継続する。ML 推論のエッジ実行とフリート管理を紹介します。

約 1 分で読めます

Greengrass の概要

IoT Greengrass はエッジデバイスで AWS のクラウド機能をローカル実行するランタイムです。Greengrass Core ソフトウェアを 256 MB 以上のメモリを持つ Linux デバイス (Raspberry Pi、産業用ゲートウェイ、EC2) にインストールすると、そのデバイスがエッジコンピューティングのハブとして機能します。Lambda 関数、Docker コンテナ、カスタムコンポーネントをエッジで実行し、センサーデータの前処理、ML 推論、デバイス制御をローカルで完結できます。クラウドへの接続が断続的な工場、農場、船舶、鉱山などの環境で特に有効です。

コンポーネントとローカル処理

Greengrass v2 はコンポーネントベースのアーキテクチャを採用しています。AWS が提供するパブリックコンポーネント (ストリームマネージャー、ローカル MQTT ブローカー、ML 推論) とカスタムコンポーネント (自社のビジネスロジック) を組み合わせてエッジアプリケーションを構築します。ストリームマネージャーはセンサーデータをローカルにバッファリングし、帯域幅の制約に応じてクラウド (IoT Core、Kinesis、S3) に送信します。接続が切断されてもデータはローカルに保持され、接続回復時に自動送信されます。ローカル MQTT ブローカーでエッジデバイス間のメッセージングを実現し、クラウドを経由せずにデバイス間通信が可能です。

ML 推論とフリート管理

ML 推論コンポーネントで SageMaker でトレーニングしたモデルをエッジデバイスにデプロイし、リアルタイムの推論を実行できます。 TensorFlow Lite や DLR (Deep Learning Runtime) をサポートし、リソースが限られたデバイスでも効率的に推論を実行します。製造ラインでの不良品検出、農業での作物の病害検出、セキュリティカメラでの人物検出などに活用されています。フリート管理では、 AWS IoT コンソールからデバイスグループに対してコンポーネントの OTA デプロイを実行します。デプロイの進捗はデバイスごとに追跡でき、失敗時のロールバックも可能です。 Greengrass について体系的に学びたい方は、関連書籍 (Amazon)も参考になります。

Greengrass の料金

Greengrass Core ソフトウェアのインストールと実行は無料です。コストが発生するのは、クラウドとの通信に使用する AWS サービス (IoT Core のメッセージング、S3 へのデータ転送、Lambda の呼び出し) の利用料金です。エッジデバイスのハードウェアコストとネットワーク回線費用は別途必要です。OTA デプロイで使用する S3 ストレージと IoT Jobs の料金も発生しますが、いずれも少額です。エッジで処理を完結させてクラウドへの転送量を削減することが、Greengrass 環境全体のコスト最適化の鍵です。

まとめ

Greengrass を導入する際は、まずコンポーネントカタログから必要な機能 (MQTT ブローカー、Stream Manager、ML 推論) を選定し、エッジデバイスの CPU・メモリに合わせた構成を設計します。ネットワーク断への耐性が求められる環境では、ローカルでの処理完結を優先し、クラウドへのデータ転送は接続回復時にバッチで行う設計が堅牢です。フリート管理で数千台のデバイスへの OTA デプロイを自動化し、運用負荷を最小化します。

関連するサービス

AWS IoT Greengrassエッジデバイスでローカルコンピュート、メッセージング、ML 推論を実行するサービスAWS IoT CoreIoT デバイスをクラウドに安全に接続し、メッセージを処理するマネージドサービスAWS Lambdaサーバー管理不要でコードを実行するサーバーレスコンピュートサービス

関連する記事

AWS Snow ファミリーによるオフラインデータ転送とエッジコンピューティングSnowcone・Snowball Edge・Snowmobile のデバイス選定基準を整理し、エッジでの EC2・Lambda 実行と大規模データ移行の計画手法を紹介します。AWS IoT Core で実現する IoT デバイス接続 - MQTT 通信とデバイスシャドウMQTT プロトコルで IoT デバイスを接続し、デバイスシャドウで状態を同期する。ルールエンジンによるデータルーティングとデバイス認証の設計を紹介します。AWS Panorama でエッジコンピュータビジョンを実現 - 既存カメラへの ML モデルデプロイエッジデバイスでコンピュータビジョンモデルを実行し、カメラ映像をリアルタイムに分析する。Panorama Appliance のデプロイとモデル管理を紹介します。

同じテーマの記事

Auto Scaling はなぜスケールアウトは速く、スケールインは慎重なのか - 非対称な判断ロジックの設計意図EC2 Auto Scaling がスケールアウトを即座に実行する一方でスケールインに冷却期間を設ける非対称な設計の理由、フラッピング防止の仕組み、ターゲット追跡スケーリングの内部ロジックを解説します。AWS Auto Scaling で実現する需要追従型インフラ - スケーリングポリシーの設計と最適化ターゲット追跡・予測・スケジュールドの 3 種類のポリシーを使い分け、混合インスタンスポリシーでスポットを活用したコスト最適化を実現する手法を紹介します。AWS の障害ドメイン設計 - AZ・リージョン・パーティションの 3 層構造が守る可用性の仕組みAWS のインフラが AZ (障害隔離)、リージョン (地理的分離)、パーティション (政治的分離) の 3 層で設計されている理由と、各層の障害がどこまで波及するかを具体的な事例とともに解説します。AWS 障害から学ぶ分散システムの原則 - 過去の大規模障害が変えたアーキテクチャS3 障害 (2017)、Kinesis 障害 (2020)、us-east-1 の特殊性など、AWS が公開した障害レポートを題材に、Shuffle Sharding、Static Stability、Cell-based Architecture といった設計原則を解説します。AWS はなぜそこにリージョンを建てるのか - データセンター立地選定の知られざる判断基準AWS がリージョンの立地を決定する際に考慮する電力供給、地政学リスク、データ主権法制、ネットワーク接続性、自然災害リスクなどの判断基準を、具体的なリージョンの事例とともに解説します。AWS の Availability Zone ID はなぜアカウントごとに異なるのか - AZ マッピングの設計意図us-east-1a がアカウントごとに異なる物理 AZ を指す仕組み、AZ ID (use1-az1) が導入された背景、キャパシティの均等分散という設計意図、クロスアカウントでの AZ 指定の注意点を解説します。バッチコンピューティング基盤 - AWS Batch で実現する大規模並列処理AWS Batch を活用した大規模バッチ処理の構築方法を解説します。ジョブキュー、コンピューティング環境の自動スケーリング、Spot インスタンスによるコスト最適化など、科学計算や大規模データ処理に最適なバッチ基盤の設計を紹介します。AWS Batch でバッチコンピューティングを自動化 - ジョブキューとコンピューティング環境の設計AWS Batch によるジョブのスケジューリング、Fargate/EC2 コンピューティング環境の使い分け、スポットインスタンスの活用を解説します。

内容が近い記事・サービス

AWS IoT Greengrassエッジデバイス上で Lambda 関数や ML 推論を実行し、クラウドとの断続的な接続環境でもローカル処理を継続できるエッジコンピューティングランタイムAWS IoT Greengrassエッジデバイス上でローカル処理・機械学習推論・メッセージングを実行し、クラウドとシームレスに連携する IoT ランタイムIoT デバイス管理 - AWS IoT Core と Lambda で実現するスケーラブルな IoT プラットフォームAWS IoT Core と Lambda を活用した IoT デバイス管理プラットフォームの構築方法を解説します。AWS IoT Core で実現する IoT デバイス接続 - MQTT 通信とデバイスシャドウMQTT プロトコルで IoT デバイスを接続し、デバイスシャドウで状態を同期する。ルールエンジンによるデータルーティングとデバイス認証の設計を紹介します。