AWS入門ブログリレー2024〜AWS IoT Greengrass V2 編〜

当エントリは弊社AWS事業本部による『AWS 入門ブログリレー 2024』の35日目のエントリです。

このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。

AWS をこれから学ぼう！という方にとっては文字通りの入門記事として、またすでに AWS を活用されている方にとっても AWS サービスの再発見や 2024 年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。

では、さっそくいってみましょう。今回のテーマは『AWS IoT Greengrass V2』です。

AWS IoT Greengrass とは何か

「Greengrass」を直訳すると「緑の芝生」になりますが、AWS IoT Greengrass は、エッジデバイス上で稼働する各種アプリケーションの構築、デプロイ、管理を支援してくれるサービスです。

AWS でエッジというと「CloudFront」のエッジロケーションなどが連想される方も多いかも知れませんが、ここでいう「エッジ」とは「末端」「端の」という意味の通り「ネットワークに接続する際の末端にある装置」という意味合いで使われます。

この意味合いでいう「エッジデバイス」が果たす役割は「ローカルにあるデータをクラウドに連携する」ことになります。このエッジデバイスのアプリケーションを効率的に管理・運用するためのサービスが「AWS IoT Greengrass」になります。

ユースケースから AWS IoT Greengrass を理解する

さて、さきほど「エッジデバイスのアプリケーションを効率的に管理・運用する」と記載しましたが、具体的にピンと来ないことも多いと思います。IoT に普段触れていなければ私も「ナンノコッチャ？？」となると思います。

ここで、IoT のユースケースを考えてみたいと思います。パッと思いつくのは「センサーから温度を取得してクラウドでグラフ化する」などですね。

自宅の環境データを計測するときの課題

例えば、自室の温度を計測する場合、Raspberry Pi のようなデバイスを用意してデバイス上で Python などを使ってセンサーからデータを収集するプログラムを作成して、環境情報を計測します。

後で湿度も収集したくなったら、既存プログラムを改修したり、新規に追加したりすることになります。
このとき、デバイスに SSH や VNC で接続して直接プログラムを改修すればいいですが、そのアプリのバージョン管理や何らかのトラブルでプログラムが異常終了してしまったら、どうしたらいいでしょうか？

さらに、自室以外にリビングや寝室の温度も計測したくなり、デバイスを複数設置して計測したくなった場合、新たに湿度も計測したくなった時、都度すべてのデバイスにログインしてプログラムを更新するのは面倒になります。

AWS IoT Greengrass による課題解決

先程のような課題に対して、既に何らかの運用基盤を持っている場合はそちらを使っていただくのも良いかと思いますが、運用環境も新規作成する必要があるような場合は、AWS IoT Greengrass を使うことで課題を解決できます。

Greengrass ではプログラムの内容とともにバージョンを管理することができる他、アプリケーションが異常終了した場合でも 2 回まで自動でリトライを行い、復旧をサポートしてくれる機能があります。

また、作成したアプリケーション（コンポーネント）はグループを指定してデプロイすることができるので、管理するデバイスが増えても AWS IoT Greengrass サービス経由で複数デバイスに一括でデプロイが可能です。このとき、エラーになったデバイス数の割合などに応じて、デプロイを途中で停止するなど、デプロイをコントロールすることもできます。

一般的に IoT のユースケースを考えると、IoT デバイスは様々な場所で、多くのデバイスが稼働するケースが多くあります。このように遠隔地に多くのデバイスが存在し、稼働するアプリケーションやバージョンがバラバラな場合は運用コストも無視できない問題になることは容易に想像できます。

このような IoT 固有のアプリケーション運用の課題を効率的にサポートしてくれるのが、AWS IoT Greengrass というサービスです。

Greengrass を構成する主要リソース

ざっくりと AWS IoT Greengrass の概要とユースケースをご理解いただけたでしょうか？
サービスを構成する主な要素は次の通りです。

• AWS IoT Greengrass サービス
• AWS IoT Greengrass Core
• Greengrass Components

「AWS IoT Greengrass サービス」は AWS クラウド上で提供されるサービスで、Greengrass 全体を管理します。例えば、エッジデバイス上で動くアプリケーションの管理、デプロイ管理などがあります。

「AWS IoT Greengrass Core」は、エッジデバイスにインストールして利用するソフトウェアです。
クラウド側の Greengrass サービスと連携して利用します。一般的に 「AWS IoT Greengrass Core」がインストールされたデバイスは「Greengrass Core デバイス」と呼ばれます。

Greengrass Components

「Greengrass Components」は、Greengrass V2 から提供されるようになった新しい要素です。

従来の Greengrass では、デバイス上のアプリケーションは AWS Lambda や Docker コンテナとして作成したものをデバイスにデプロイして利用するものでした。

デバイス上で Lambda が動く？？ 私も初めて聞いた時はどういうことかイメージ出来ませんでした。
どういうことかというと、何らかの「メッセージ受信」など事前に定義されたトリガーを元に、デバイス上の Lambda 関数がキックされてデータを処理し、事前に定義したルーティング機能により AWS などへデータを転送するという仕組みが提供されていました。

この仕組みでは、都度「AWS Lambda にアプリをデプロイ → デバイスにデプロイする」という段階的な処理が必要となり、やや冗長な仕組みとなっていました。
また、デバイス上のセンサーを利用したい場合、デバイス上の Lambda が該当リソースにアクセスできるようにデバイスファイルの指定なども都度必要で、導入までの敷居が少し高い部分がありました。

アプリケーションをデプロイする際も、複数のアプリケーションが一括で管理されていたため、すべてのアプリケーションが再起動するという仕組みになっていました。

コンポーネント化によるメリット

Greengrass V2 では、引き続き Lambda 形式のプログラムも利用できますが、ローカルリソースを使う場合でも従来の IoT アプリ開発と同じようにプログラムを開発できるようになっています。

また、アプリケーションも「コンポーネント」という単位で管理できるようになったので、一つのコンポーネントをデプロイする際でも、他のコンポーネントには影響しなくなりました。

以前のバージョンでは、機械学習推論やデータストリームの機能など、コネクターの他に様々な機能が独立して提供されていました。これらが V2 のコンポーネントとして提供されることになり、設定や運用を一定のルールに基づいて行えるようになり、その分の学習コストも下がりました。

コンポーネントの種類

Greengrass で利用できるコンポーネントには大きく分けて次の 4 種類が存在します。

• AWS が提供するパブリックコンポーネント
  • Greengrass のソフトウェア自体や、CloudWatch へカスタムメトリクスを発行するコンポーネントなどが提供されています。
  • コレまでのバージョン（Classic, V1）で「コネクタ」として提供されていたものの多くが、パブリックコンポーネントとして提供されています。
  • 公開されているコンポーネントの一覧は下記のドキュメントで確認できます。

• カスタムコンポーネント
  • ユーザーが自由に作成し利用できるコンポーネントです。
  • 作成したプログラム類一式をコンポーネントとして AWS IoT Greengrass に登録して利用できます。
• 3rd パーティー製コンポーネント
  • 3rd パーティー コンポーネント ベンダー によって開発・提供されるコンポーネントです。
  • このコンポーネントは提供ベンダーに直接問い合わせ購入することで利用できます。
  • 詳細は以下のページより確認できます。

• コミュニティコンポーネント
  • Greengrass コミュニティによって開発・公開されているコンポーネント群です。
  • 以下のリポジトリで公開されています。

コンポーネント間通信、AWS IoT Coreとの通信

Greengrass デバイスでは、 一つのコンポーネントですべての処理を行う事もできますが、機能が増えるとコードも肥大化してメンテナンスコストが大きくなったり、データ処理中にエラーが発生した時のエラーハンドリングが難しくなる場合があるので、結果的に複数のコンポーネントを動かすことになるケースが多いと思います。

その際、プロセス間通信（IPC）によりコンポーネント同士で連携してデータ処理することが出来ます。

従来は、デバイス上で動く複数の Lambda 関数同士の通信を行うときや AWS クラウドと通信する時は「サブスクリプション」という機能でターゲット同士のルーティングを定義してデータ連携を設定していました。
そういう観点では、ルーティング内容の確認がやりやすい部分はありましたが、Greengrass V2 になり SDK を利用して簡単にプロセス間通信できるようになったので、開発コストが削減できるようになりました。

具体的な始め方

ここまでの説明で次のことがザックリとご理解いただけたでしょうか？

• Greengrass でデバイス上のアプリ運用が効率的になる
• アプリを作りたいときは、コンポーネントという単位で作る
• パブリックコンポーネントを使えば自前で開発しなくても利用できる機能がある
• コンポーネント同士の連携や、AWS IoT Core とのやり取りはプロセス間通信で行える

Greengrass のインストールからサンプルのコンポーネント作成〜デプロイまでの手順を下記のブログで紹介しています。（手順が長いので本記事では、詳細は下記の記事に譲りたいと思います）

この記事では、デバイス上（Raspberry Pi）で擬似的なセンサーデータを生成して、そのデータをデバイス上のログに出力するコンポーネントを開発 PC で作成して、Greengrass サービスからデプロイするまでの手順を紹介しています。

図中にある「GDK (Greengrass Development Kit)」とは、コンポーネント開発を効率化する公式のツールです。GDK を使わなくても開発できますが、手作業で行う作業コストが高くなるので、ぜひ GDK を利用していただければと思います。

EC2 や Cloud9 でも試せる

実際に Greengrass を利用する場合は、何らかの物理デバイスを用いて利用することになると思いますが、Greengrass の学習目的であれば必ずしもデバイスは必要ありません。

実物のデバイスがある方が理解度が高くなると思いますが、Linux や Windows であれば利用できるので、EC2 や Cloud9 に Greengrass Core ソフトウェアをインストールして試すことができます。

下記の Greengrass Workshop では Cloud9 をデバイスに見立てて学習できるように構成されています。

クラウドとデバイスのネットワーク構成

これまでは、Greengrass を利用する場合はインターネットの利用が必須でしたが、昨年のアップデートで閉域環境でも利用できるようになりました。

製造現場の工場などセキュアな通信がセキュリティ要件として必要な場合、インターネットアクセスが導入のハードルになることが多かったのですが、このアップデートにより安心して利用できるようになりました。

（出典元：https://pages.awscloud.com/rs/112-TZM-766/images/reInvent2023-recap-CMP_GENERAL1-4-IoT.pdf)

Greengrass の利用を前提にしたサービス

Greengrass V2 では多くの機能がコンポーネントとして提供されていることを説明しました。
これらのコンポーネントの中には、他の AWS サービスを利用するためのエージェントに相当するコンポーネントも存在します。

例えば、AWS IoT SiteWise では、Greengrass Core デバイスに専用のコンポーネントをインストールすることで、SiteWise ゲートウェイとして利用できるようになり、製造設備からデータを収集して AWS クラウドに連携します。

SiteWise に関連するコンポーネントのドキュメントページは下記になります。

Greengrass が利用可能なデバイス要件

Greengrass はいわゆる PC で利用することが想定されています。そのためサポートされるプラットフォームは下記の通りとなります。
デバイス要件の詳細は公式ドキュメントを参照してください。

Linux の場合

• アーキテクチャ
  • Armv7l
  • Armv8 (AArch64)
  • x86_64
• デバイス要件
  • Greengrass Core ソフトウェアに利用可能な最小 256 MB のディスク容量
  • Greengrass Core ソフトウェアに割り当てられる最小 96 MB RAM
  • Java ランタイム環境 (JRE) バージョン 8 以降
  • GNU C ライブラリ(glibc) バージョン 2.25 以降

Windows の場合

• アーキテクチャ
  • x86_64
• OS バージョン
  • Windows 10
  • Windows 11
  • Windows Server 2019
  • Windows Server 2022
• デバイス要件
  • AWS IoT Greengrass V2 をサポート（V1 はサポートしていません）
  • Greengrass Core ソフトウェアに利用可能な最小 256 MB のディスク容量
  • Greengrass Core ソフトウェアに割り当てられる最小 160 MB RAM
  • Java ランタイム環境 (JRE) バージョン 8 以降

Greengrass コンポーネントの中には、Windows をサポートしていないものがあります。
Windows のサポート有無については、各コンポーネントのドキュメントを確認してください。

利用料金

「アクティブな Greengrass Core デバイス1台につき ＄0.18/月（東京リージョン）」 が発生します。月のうち１度でも認証されると課金対象になりますが、デバイスが クラウドに接続しない場合は料金は発生しません。

IoT Core や IoT Analytics など他の関連サービスや、Kinesis など他の AWS サービスも使う場合は、その利用料金が別途発生します。

Greengrass V1 の利用について

この記事の執筆時点（2024 年 5 月 1 日）では、V1(Version 1、Classic と表記されることもあります)は既に「延長ライフサイクルフェーズ」に入っています。
このフェーズでは、セキュリティパッチやバグ修正などのアップデートはリリースされません。

これから新規に利用される場合は、Greengrass V2 を前提に利用することが推奨されます。
また、弊社のブログを始め技術解説には、Greengrass V1 を前提にしたものも存在するため、自分が参照しているドキュメントがどのバージョンを前提としているものか事前に確認するようにしましょう。

引用元：https://docs.aws.amazon.com/ja_jp/greengrass/v1/developerguide/maintenance-policy.html

最後に

今回は AWS IoT Greenrass V2 についてご紹介しました。
全体的にイメージの掴みづらいサービスだと思うのでサービスの概要を中心にご紹介しました。

Greengrass V2 で重要なポイントは「コンポーネントをいかにうまく使いこなすか」だと思っています。
パブリックコンポーネントも非常に多くの種類が提供されているので「具体的にどんな課題に対して、どのようなコンポーネントで対応できるのか？」コンポーネント一覧を覗いていただくと更に理解が深まるかと思います。

以上、『AWS 入門ブログリレー 2024』の35日目のエントリ『AWS IoT Greengrass V2』編でした。

次回、2024/05/02 は弊社 emi による「Amazon Data Firehose (旧 Amazon Kinesis Data Firehose)」の予定です！