AWS IoT Greengrass

解決する課題

工場や店舗、車両など現場（エッジ）にあるデバイスは、ネットワークが不安定だったり、クラウドへの往復遅延が許容できなかったり、大量の生データをそのまま送ると通信コストがかさんだりします。すべての処理をクラウドで行う前提だと、こうした環境では成り立ちません。AWS IoT Greengrass はクラウドの機能をエッジ側まで広げ、デバイス上でローカル処理を実行できるようにします。

• ネットワークが切断されている間もローカルで処理を継続し、復旧後にクラウドと同期できる
• センサーデータを現場で前処理・集約・フィルタリングしてから送り、通信量とコストを抑えられる
• 機械学習モデルをエッジに配置し、低遅延でローカル推論を実行できる
• 現場のソフトウェアをクラウドから遠隔でデプロイ・更新し、多数のデバイスをまとめて管理できる

クラウドに常時依存せず、現場の近くで判断や処理を完結させたいケースが中心的な価値です。

主要概念と用語

• Greengrass Core デバイス: Greengrass のランタイム（Core ソフトウェア）を導入したエッジ機器。ローカル処理の実行主体になる
• コンポーネント: Core デバイス上で動かす機能の単位。AWS が提供するパブリックコンポーネントと、利用者が作るカスタムコンポーネントがある
• レシピ: コンポーネントの構成（依存関係、起動手順、設定など）を記述した定義ファイル
• デプロイ: どの Core デバイス群にどのコンポーネントを配布するかを指定し、ターゲットへ反映する操作。クラウドから遠隔で行う
• モノ（Thing）/ モノのグループ: AWS IoT Core 上でデバイスを表す登録単位。デプロイ対象をグループ単位で指定できる
• ローカル機械学習推論: 学習済みモデルをエッジへ配置し、Core デバイス上で推論を実行する仕組み
• ローカル MQTT ブローカー: Core デバイス上で動き、近接するデバイス同士の通信や、クラウドへ届ける前のメッセージ中継を担う
• クライアントデバイス: Core デバイス経由でクラウドとやり取りする、周辺の小型デバイス
• ストリームマネージャー: 生成データをローカルにバッファし、クラウド（IoT 系のデータ送信先など）へ確実に転送する仕組み

仕様・制限・クォータ

• Core デバイスには一定の計算資源（CPU・メモリ・ストレージ）と対応 OS・アーキテクチャが必要で、機械学習推論を行う場合はモデルに見合った性能が求められる
• コンポーネントにはバージョンがあり、デプロイ時にバージョンを指定する。更新は新しいバージョンを再デプロイして反映する
• デプロイのターゲットは個別の Core デバイスのほか、モノのグループ単位でまとめて指定できる
• ローカルで動かすコンポーネント数やデバイス数、メッセージのサイズなどにアカウントやデバイス単位の制限・クォータがあり、一部は引き上げ申請が可能
• ランタイムや一部機能はインターネット接続が断続的でも動作するが、デプロイの受信やクラウド同期には接続が必要

具体的な対応 OS・最小スペック・上限値は更新されるため、最新の公式ドキュメントで確認してください。

内部の仕組み

利用者は「どの機能をコンポーネントとして用意するか」「どの Core デバイス群に配るか」を定義し、Greengrass がエッジ側での配布・実行・ライフサイクル管理を担います。

• ランタイム: Core デバイス上の Greengrass Core ソフトウェアが、配布されたコンポーネントの起動・停止・監視を行う
• デプロイ: クラウド側でデプロイを作成すると、対象の Core デバイスがそれを受け取り、指定バージョンのコンポーネントをダウンロードして反映する。複数デバイスへ一括で配布できる
• ローカル実行: 配置されたコンポーネントはデバイス上で動作し、ローカルでのデータ処理・推論・デバイス間通信を行う。クラウドが見えない間もローカル処理は継続する
• クラウド連携: Core デバイスは AWS IoT Core と接続し、必要なメッセージや処理結果をクラウドへ送る。ストリームマネージャーは接続が不安定でもデータをバッファして転送する

デバイスの登録・接続・メッセージングに AWS IoT Core、機械学習モデルやコンポーネント成果物の保管に S3 を利用するなど、他の AWS サービスと組み合わせて動作します。

設計パターン / ベストプラクティス

• 現場で前処理してから送る: 生データをそのままクラウドへ送らず、エッジで集約・フィルタリングして通信量とコストを下げる
• 機能はコンポーネントに分割する: 役割ごとにコンポーネントを分け、バージョン管理と段階的なデプロイをしやすくする
• グループ単位で段階展開する: まず一部のモノのグループへデプロイして検証し、問題なければ全体へ広げる
• オフライン前提で設計する: 切断中もローカルで動作を続け、復旧後に同期できるよう、ローカル状態とクラウド状態の整合を考慮する

運用・監視

• Core デバイスやコンポーネントの状態・ログは CloudWatch に連携して集約・監視できる
• デプロイの成功・失敗や進捗はクラウド側で確認でき、対象デバイスごとの反映状況を追える
• デバイスやデプロイの状態変化を EventBridge で受け取り、通知や後続処理を自動化できる
• API 操作の監査証跡は CloudTrail に記録される
• 多数のデバイスを扱うため、デプロイのロールアウト範囲を絞り、失敗時に切り戻せる運用手順を用意しておく

コスト

• 課金は基本的に Greengrass で管理するアクティブな Core デバイスの数に対して発生する従量制で、デバイスが増えるほどコストが上がる
• Core デバイスがクラウドとやり取りするメッセージングなどには、連携する AWS IoT Core 側の料金が別途かかる
• 機械学習モデルやコンポーネント成果物の保管に使う S3、ログ集約に使う CloudWatch など、組み合わせる各サービスの費用も加わる
• エッジで前処理してクラウドへ送るデータ量を減らすと、通信や下流サービスのコストを抑えられる

具体的な単価は変動するため、料金は公式の料金ページで確認し、小規模に検証してからデバイス台数に応じた費用を見積もるのが安全です。

セキュリティ

• 各 Core デバイスは X.509 証明書で認証され、AWS IoT のポリシーで許可された操作のみを行える
• クラウドとの通信は TLS で暗号化され、デバイスとクラウド間のメッセージは保護される
• デバイスやデプロイに割り当てるロール・ポリシーは IAM と IoT ポリシーで最小権限に絞り、対象リソースを限定する
• 機械学習モデルやコンポーネント成果物を置く S3 へのアクセスを必要な範囲に制限し、保存データの暗号化（KMS 管理鍵を含む）を行う
• 現場に物理的に存在するデバイスが持つ認証情報の管理に配慮し、漏えい時には証明書を失効できるようにしておく

Well-Architected の観点

• 運用上の優秀性: コンポーネントとデプロイで現場ソフトウェアを標準化・遠隔管理し、CloudWatch や EventBridge で可観測性を確保する
• パフォーマンス効率: ローカル処理と推論で往復遅延をなくし、エッジでの前処理によりクラウド側の負荷とデータ量を減らす
• 信頼性: オフラインでもローカル動作を継続し、復旧後にクラウドと同期できる構成で現場の継続性を保つ
• セキュリティ: 証明書認証・TLS・最小権限ポリシーでデバイスとデータを保護する

試験で問われるポイント

関連サービス・比較

デバイスの接続・認証・メッセージングを担うクラウド側のサービス AWS IoT Core とは役割が異なり、両者は組み合わせて使います。AWS IoT Core と比較します。

ハンズオン / CLI例

# デプロイ対象のモノのグループへ、配布するコンポーネントとバージョンを指定してデプロイを作成
aws greengrassv2 create-deployment \
  --target-arn arn:aws:iot:ap-northeast-1:123456789012:thinggroup/MyEdgeGroup \
  --deployment-name demo-edge-deployment \
  --components '{"com.example.MyApp":{"componentVersion":"1.0.0"}}'

# 作成したデプロイの状態を確認（対象への反映状況を追う）
aws greengrassv2 get-deployment \
  --deployment-id <deployment-id> \
  --query "{Status:deploymentStatus,Target:targetArn}"