第２回 新世代エッジエンジニアのための技術講座 コラム

この連載コラムでは、AWS IoT Greengrassについて、数回に分けてお伝えします。
第２回目は、第１回で示した機能構成の各部の解説からスタートします。

本連載は、次のような想定・目的で記述しています。

想定する読者	AWSのGreengrassについて多少は興味がある人 独力で調べようとはしたけれど、公式HPを見ても専門用語満載で、その気が失せた人、記述内容が理解できなかった人
想定する読者の 知識レベル	AWS やエッジコンピューティングといった言葉は聞いたことのある人 少しくらいはプログラムを書いたことがある人/読める人
本連載を読んだ後に得られる期待値	以下の問いに答えられるようになる Greengrassって何ができるの？ Greengrassに関連して登場する用語の意味は？ 公式HPの記述を読むための下地ができる 書いてあることがある程度は理解でき、読み進めることはできる チュートリアルをやってみるとき、各手順の目的や意味がわかる

 

---

1. AWS Greengrass の機能解説 (前半)

ここでは、前回に示した機能構成の各部について解説します。

1の「IoT デバイスおよび AWS IoT との接続」については、接続とセキュリティに分けて説明します。また、8番目の項目として、IoT Device SDKについても説明します。

連載2回目の今回は、1～2を取り上げます。

---

IoTデバイスおよびAWS IoTとの接続 (1)

まず、Greengrass CoreがIoTデバイスやクラウドとどう接続するか、という、図の赤枠の部分です。

主なポイントは以下のとおりです。

IoT デバイス⇔エッジデバイスの接続

• エッジデバイスのアクセスポイントの情報はクラウド(AWS IoT)で管理される
• IoTデバイスは”実行時”にクラウドにその情報を問い合わせて接続できる
• その仕組みにより、IPアドレスなどが変化しても影響を受けなくなる
  ※ 事前に取得しておいた情報を使うことも可能

エッジデバイス⇔AWS IoT の接続

• クラウド(AWS IoT)のアクセスポイントは GGC 毎に固定される
• GGC のインストール&セットアップ時に上記情報は組み込まれる
• GGC はそれを用いてクラウドに自動的に接続する(明示的な接続処理は必要ない)

これについて以下で詳しく説明します。

---

IoTデバイスからエッジデバイスへの接続

IoTデバイスがエッジデバイスに接続しようとすると、そのエッジデバイスのエンドポイントの情報(IPアドレスやポート番号など)が必要になります。この情報の取得方法は、図に示す動的な方法と静的な方法があります。

A) 動的に検出する方法

Greengrassでは、実行時に動的に行う検出の仕組みが提供されています。IoTデバイスの起動時に、AWS IoT側で管理されているエッジデバイスのエンドポイントの情報をクラウドに問い合わせます。その後、その情報を使ってエッジデバイスに接続します。

B) 静的に検出する方法

エッジがオフラインの場合、つまり、IoTデバイスとエッジデバイスがクラウドと切り離されているという状況も考えられます。そのため、あらかじめエッジデバイスの固定のIPを設定しておいて、そのIPを使って接続するという機能も提供されています。

ただし、クラウドとの接続が可能な環境にある場合は、静的なやり方でなくて動的なやり方の方が推奨されます。普通に運用しているとエッジデバイスのIPアドレスが変わっていく可能性があるため、動的な構成を取る方がゆらぎに強いということで推奨されているのでしょう。

---

エッジデバイスの接続先情報の管理

IoTデバイスがクラウドに取得しにいく「エッジデバイスのエンドポイントの情報」は、AWS IoT側で管理されます。

クラウド(AWS IoT)は、エッジデバイスの接続先情報を予め把握しておく必要があります。Discovery APIからの問い合わせに応答できなければならないこと、デプロイの際にクラウドからエッジデバイスに接続できなければならないことがその理由です。

エッジデバイスの接続先情報をクラウドが把握する方法には、自動検出と手動設定の2つがあり、管理コンソールで選択することができます。

• 自動検出
  IPDetectorというプログラムが適宜接続先の情報を登録し、GGCに自動的にIPアドレスを通知する
• 手動設定
  開発者がエッジデバイスのIPアドレスを手入力で設定し、その情報を使用する

---

エッジデバイスからAWS IoTへの接続

次はエッジ デバイスとAWS IoTの間の接続です。エッジデバイスがクラウドに接続するときには、クラウド側のアクセスポイントに関する情報が必要になります。

クラウド側には固定の「カスタムエンドポイント」がというものがAWSアカウントごとに1つ用意されており、それを使ってAWS IoTに接続することができます。このカスタムエンドポイントは管理コンソールから確認できます。

カスタムエンドポイントの情報は、GGCのインストールおよびセットアップする過程で自動的に組み込まれているため、エッジデバイス上のGGCがクラウドに接続するときには、その情報が自動的に使用されます。そのため、明示的に接続しに行く処理は必要ありません。

ただし、IoTデバイスでは、Discovery APIの使用時などにカスタムエンドポイントの情報を明示的に指定する必要があります。その場合には、管理コンソールで確認した情報を使用します。

ここまでが、冒頭の図の1にあたる接続の話でした。次はこの接続のセキュリティを取り上げます。

---

---

セキュリティ (1)

セキュリティは、図の赤枠部分の通信に関係します。

セキュリティに関して重要なのは、認証、暗号化、認可の3つです。

• 認証とは、接続に先立って、お互いが信頼できる相手なのかどうかを確認して、なりすましを防ぐためのものです。通信経路を確立する際に、各々の間で証明書のやり取りとチェックを行うことで、互いの身元が確認されます。
  
  
• 身元が確認できたら、次に通信路を確立します。その際、IoTデバイス、エッジデバイス、クラウドの間の通信経路は、通信傍受や盗み見を防ぐために、暗号化されます。この認証と暗号化によって、セキュアな通信が確保されます。
  
  

通信路が確立されてやり取りが始まり、IoTデバイスやエッジデバイスがGreengrassの機能を利用したりAWSのサービスを利用したりするには、適切な権限を持つ者だけがAWS上のサービスを使えるようにする仕組みが必要になります。それが認可といわれるものです。アクセス権限の付与には、AWS がアクセス権限を管理するために導入している概念(ポリシーなど)や仕組みが用いられます。

---

認証と暗号化

クラウドとエッジデバイスとIoT デバイスの間の通信経路は、TLS (Transport Security Layer。SSLの次世代規格)によって保護(暗号化)されます。

また、通信経路を確立する際には、X.509 証明書を用いた双方向認証によって、お互いの身元が確認されます。

その様子を表したのが次の図です。

GGCのセットアップ時に、「ルートCA証明書」や「コアデバイス証明書」、そして「秘密鍵」(赤い鍵マーク)を、管理コンソールで生成して配置する必要があります。

---

認可

AWSが提供するサービスを利用するには、利用者はその利用許可、つまりアクセス権限をもらわないとサービスなどにアクセスできません。そのアクセス権を付与するための仕組み、つまりAWSの基本的なアクセス管理の仕組みは、次のようなものです。

• 各種リソース(サービスなど)へのアクセス権限を「ポリシー」と呼ばれるもので定義します。 ポリシーとは、「どのリソースに対して、どういうアクションを許可するか」を書いたリストです。たとえば、AWSのリポジトリサービスS3に対して読み書きする権限を許可します、のように定義します。
  
  
• そのポリシーを、ユーザーやグループやロールなどの「アイデンティティ」にアタッチします。
  
  
• そうすると、アタッチされたアイデンティティは、そこに書かれているリソースに対してアクセスする権限を獲得することになります。

Greengrassも、そのAWSの仕組みを借りて、次の図のようにアクセス権限を管理しています。

IoT デバイスに権限を許すポリシーや、エッジデバイスに許すポリシー、エッジデバイスで動くアプリケーションロジックに対して権限を許すポリシーを、それぞれに定義します。また、クラウド側の管理コンソールもさまざまなAWSのサービスを使用するため、管理コンソールがそれらのリソースにアクセスする権限を定義するためのポリシーも用意されます。つまり、アクセス権のコントロールは、それぞれに紐づけられるポリシーの内容を変更するという形で実現されます(IAM ロールの作成や設定変更などは、AWS IAMサービス上で実施します)。

以上がセキュリティの話です。次は、2の「データの収集と配信」です。

---

データの収集と配信 (2)

GreengrassがIoTデバイスやクラウドと通信してメッセージデータを交換するときに、そのデータ伝送をどう行うのかという話に移ります。次の図の赤枠部分のデータ伝送です。

データの送受信(メッセージ交換)の方法を簡単にまとめると、次のようになります。

• GGCはIoTデバイス、アプリケーションロジック、AWS IoTの間のデータ のやり取りを仲介する
• データの配信元がGGCにデータを送信すれば、そのデータに興味を持つ 配信先に自動的に転送される
• データ配信は、開発者が予め定義した「Xというデータは、誰から、誰に送られる」というルールに基づいて実行される
• クラウドとつながらないときには、クラウドへのメッセージはキャッシュされる

---

メッセージ交換

GGC でメッセージ送信データの送受信を行う主体には、次のものがあります(そのほかにコネクタやデバイスシャドウもメッセージの交換主体になれますが、これについては次回ご説明します)。

• IoTデバイス
• アプリケーションロジック(Lambda)
• クラウド(AWS IoT)

GGCは、この3者の間の通信を仲介する役割を果たします。

メッセージ交換は「Pub/Sub型のトピック通信モデル」で行われます。ご存知の方は多いかと思いますが、Pub/Sub型の通信は基本的に、データを送る人(Publisher)がトピックと呼ばれるメッセージの内容を送ると、そのトピックに興味を持っている人、トピックを購読したい人(Subscriber)にデータが配信されるという仕組みです。

この図の例でいくと、たとえば「IoT デバイス」(Publisher)がトピック「A」に関するデータを送信すると、そのトピック「A」について興味を持っている「ロジック」(Subscriber)に転送されます。

また、Pub/Sub型通信には、1つのトピックに興味を持つ人にブロードキャストできるという利点もあります(図のトピック「B」の配信)。

Pub/Sub型通信のプロトコルはいくつか存在しますが、Greengrassでは「MQTT」という通信プロトコルが使われます。Pub/Sub型の通信モデルは非同期通信であり、「IoTデバイス」、「ロジック」、「AWS IoT」のいずれもSubscriberにもPublisherにもなれるため、双方向通信が可能です。ブロードキャスト、つまり1対多での通信も可能です。そしてプロトコル自体が軽量なので、IoTシステムでよく利用されます。

---

ルーティング

Greengrassでは、各交換主体の間のPub/Sub通信が可能ですが、不特定の相手とデータのやり取りができるわけではなく、あらかじめ決められた相手との間でしか通信できないという方式になっています。そのため、やりとりが許されるメッセージのルーティングを定義しておくために、「Subscription」と呼ばれるものが用意されています。

Subscriptionとはつまり、「誰が誰にこのトピックを送る」という内容を定義したリストで、そのリストにないやり取りは許可されません。普通のPub/Sub通信では自由にサブスクライブが可能ですが、Greengrassでは身元の確かな人たちの間でしかやり取りできないように制限を設けているわけです。

---

オフラインキャッシュ

GGCのデータ転送にはキャッシュ機能があります。

データを送ろうとした時にクラウドとの間の接続が切れてオフラインになっていると、クラウドへのメッセージはキャッシュされます。接続が切れている間はキャッシュされていて、接続が復旧したらその間のメッセージがクラウドにアップロードされます。この機能のおかげで、接続が不安定な状態の時のデータ損失を最小限に抑えることができます。

以上が接続とデータ転送に関する話でした。

---

これからのエッジエンジニアに求められる技術を知るには

新世代エッジエンジニアのための技術を実際に学んでみたいという方に、まずは無料でお試しいただけるオンライン学習プラットフォームを準備しています。

業務が多忙なエンジニアでも、スキマ時間で効率的に実践的な学習が出来るEureka Boxは、エンジニアの現場の声から生まれたツールです。

ソフトウェア開発を改善するための開発技術を“知り・学び”“実践する”
超実践的オンライン学習プラットフォーム
Eureka Box（ユーリカボックス）

---

今回は、Greengrassに関する主要な機能についてご紹介しました。次回第３回は、アプリケーションロジックの実行について説明します。

Greengrassを正しく理解した上で適用し、最大限の効果を得られるようスキルアップしたい方にもEureka Boxでの学習はお勧めで、無料会員登録だけでも以下の特典が受けられます。

---

AWSのGreengrassの技術を習得されたい方、ご質問事項は、エクスモーションへお気軽にお問い合わせください。