AWS IoT 再入門ブログリレー – AWS IoT Core 編

本企画は、弊社チームIoTメンバーが初心に返ってIoTサービスについて学びなおし、解説してみようというものです。AWSのIoTサービスをこれから学ぼうという方、既に利用している方、等様々な方の参考になればと思います。

本エントリーでは、IoTデバイスをAWSクラウドに接続する際に入り口となる『AWS IoT Core』について紹介します。「AWS IoT Coreについて知りたいけど、範囲が広すぎてどこから手をつけていいかわからん！」「今北産業で！」という方向けに、３行とまではいかないですが、とりあえずこれだけ覚えて帰ってください！というポイントをできるだけ絞ってまとめてみたいと思います。

また、AWS IoT Coreについての以前の入門記事もとてもわかりやすいので、そちらも是非参考にしてみてください。内容がかなり被っている部分もありますが、今回は再入門編ということでポイントを絞った内容にしました。

AWS IoT Core概要

AWS IoT アーキテクチャーは様々なサービスで構成されており、AWS IoT Coreはその中において、IoTデバイスを各種AWSサービスに接続するためのゲートウェイの役割となるマネージドサービスです。

※画像出典:公式ドキュメント

※画像出典:公式ドキュメント

AWS IoT Coreは、例えるとAWS API GatewayのIoT版と考えるとイメージしやすいかと思います。

しかしAWS IoT Coreはサポートする範囲が広く、なかなか理解できるように整理するが難しい部分でもあります。

この記事では、以下の図のようにAWS IoT Coreがサポートする機能中でさらにコアとなる４つのポイントに絞って説明してみたいと思います。

• デバイスゲートウェイ

デバイスからの入り口にあたる部分です。デバイスがAWS IoT Coreと通信を行う際のプロトコルと、セキュアに通信するための相互認証について説明します。

• メッセージブローカー

デバイスとの大量の送受信メッセージを捌く部分です。Topicと呼ばれるアクセスポイントにより、WebAPIでいうURIのように構造的にメッセージを振り分けることができます。

• ルールエンジン

SQLライクなフィルタリングを行うことができ、これによって他のAWSサービスに適切にルーティングしたりすることができます。

• デバイスシャドウ

デバイスのステータスをスナップショット的にクラウド上に保持することで、デバイスがオフラインの時でもアプリケーションや他のサービスからデバイスのステータスを更新し、デバイスが再接続されたタイミングで同期することができます。

それでは、これらの主要な機能について説明していきます。

デバイスゲートウェイ

AWS IoT Coreの入り口にあたる部分がデバイスゲートウェイです。ここではデバイスやクライアントの認証情報方法と、また通信に使用するプロトコルも定義されています。

認証

IoTデバイスがAWSと接続するにあたり、通信データのセキュリティ要件を考慮することは重要です。AWS IoT ではクライアントとサーバーでそれぞれにTLSを介した相互認証を行うことでセキュアな通信が可能となります。

• サーバー認証

  IoTデバイスがAWS IoT Coreに接続すると、HTTPSへのブラウザアクセスと同じようにAWS IoT CoreサーバーはTLSによる証明書をデバイスに送信します。

  この証明書は、AWS IoT Coreにより発行するほか、独自の認証機関の証明書を使用することもできます。

• クライアント認証

  AWS IoT Coreでは、IoTデバイス（またはクライアント）の認証に３つの認証方法をサポートしています。

  • X.509クライアント証明書・・・主にIoTデバイスで使用
  • IAMユーザー、グループ、ロール・・・Webアプリ、デスクトップアプリ、AWS CLIなど
  • Amazon Cognito・・・モバイルアプリケーションで使用
• カスタム認証

  AWS IoT Coreがネイティブでサポートしている認証認可の仕組みではなく、独自の認証認可の仕組みを利用する場合は、カスタム認証を使用します。

  カスタム認証では、認証用のLambda関数に認証情報を含むリクエストをコールすることで認証を決定します。

承認

上記の認証プロセスで認証されたIDを使用することでAWS IoT Coreへのアクセスを行うことができますが、AWS IoT Core側でもそのIDを承認するプロセスが必要となります。AWS IoT Coreでは、AWS IoT CoreポリシーとIAMポリシーにより承認を行います。

AWS IoT Coreポリシーがデバイスやクライアントのアクセス許可を行い、IAMが各種AWSリソースへの連携を許可します。

詳細については公式ドキュメントのAuthorizationとAWS IoT の ID とアクセス管理を参照してください。

デバイス通信プロトコル

AWS IoT Coreは、IoTデバイスおよびクライアントとの通信プロトコルとして、MQTT、MQTT over WebSocket Secure(WSS)、HTTPSプロトコルを使用可能です。

• MQTT

  MQTTはTCP/IP上で動作する軽量なPub/Sub型のデータ配信のためのOASIS標準プロトコルで、AWS IoTではバージョン3.1.1をベースにしています。ただし、サポートするサービス品質レベル(QoS)が違うなど、一部仕様の違いがあるので注意が必要です。

  AWS IoTでサポートするQoSについてはこちらの記事が詳しいので参考にしてください。

  各種プログラム言語に対応したAWS IoT デバイス SDKsを使用してIoTデバイスとの双方向通信が可能です。

• MQTT over WSS

  MQTT over WSSは、その名の通りMQTTをWebSocket上で通信することができるプロトコルです。これによりWebページ上からMQTTプロトコルを用いてAWS IoT上とデータ通信が可能となります。

  アクセスするエンドポイントやポートなどの詳細については公式ドキュメントを参照してください。

  また、実際にやってみたこちらのブログも参考になると思います。

• HTTPS

  HTTP1.0または1.1プロトコルを使用したREST APIによるリクエストでAWS IoTにメッセージを送ることができます。この場合実行できるのはパブリッシュのみとなります。

  HTTPSはMQTTと比較すると限定的な機能提供となっていますが、オフィシャルサイトにそれぞれの機能面での比較表（デバイス通信用のプロトコル選択）があるので、こちらを参考にユースケースに合わせた適切なプロトコルを選択しましょう。

メッセージブローカー

IoTデバイスやクライアントからパブリッシュされたデータをAWS IoT Coreが受け取り、次のデータ処理に向けて受け流すサーバーの役割をする仕組みがメッセージブローカーです。

メッセージブローカーは、MQTTトピックを使用してメッセージの振り分けを行います。

MQTTトピック

MQTTトピックは、IoTデバイスやクライアントからパブリッシュされたデータを振り分けるための識別子で、"/"(スラッシュ)で複数のTopic Levelを階層として表すURIのような形式となっています。

Topic Levelは抽象度の高い情報から低い情報へと流れるように設計することが一般的なベストプラクティスとなっています。

例)
building1/floor2/room3/sensor4

トピックの空間設計の詳細については、ホワイトペーパー「Designing MQTT Topics for AWS IoT Core」が参考になります。

トピックフィルター

メッセージブローカーがサブスクライブする際のトピック指定には、ワイルドカードを使用可能です。これにより、トピックにパブリッシュされたデータから特定のトピックを指定してサブスクライブ側に受け渡すことが可能です。

• 単一階層の全て : "+"
  • building1/floor2/+/sensor4
  • building1/+/+/sensor4
• 複数階層(配下)の全て："#"
  • building1/#
  • building1/floor2/#

ルールエンジン

AWS IoT ルールを使用することで、受け取ったデータを加工・フィルタリングした上で、各種AWSサービスに適した形で受け渡すことができます。

ルールには、大きく３つの役割があります。

• SQLステートメントによるフィルタリングで、各AWSリソースに割り振るデータを適切な形に整形する
• ルールに対してアクションを設定する
• ルールの定義の一部としてIAMロールを設定することにより、各AWSリソースに対するアクセス権限の付与を行う

SQLステートメントによるフィルタリング

シンプルなSQL構文クエリにより対象データをフィルタリングできるので、直感的に絞り込むことができます。対象のトピックはトピックフィルタと同様にワイルドカードを使用可能です。

使用可能なSQLバージョンは2015-03-23および2016-03-23となっており、2021/05/10現在のデフォルトバージョンは2016-03-23です。

例)
SELECT temperature as temp FROM building1/floor2/room3/# WHERE temperature > 30

SELECT句やWHERE句では組み込み関数を使用することもできるので、ある程度の変換ロジックをルールの定義として組み込むことも可能です。

詳細については公式ドキュメントの「AWS IoT SQLリファレンス」を確認してください。

アクションの設定

SQLクエリによりフィルタリングしたデータを、AWS IoTルールのアクションにより各種サービスに受け渡します。アクションの公式ドキュメントはこちらです。

受け渡し先は各種AWSサービスだけでなく、Salesforceに連携したり、HTTPSにより別のWebアプリケーションを指定したり、またrepublishアクションにより、別のMQTTトピックにメッセージを再送信することもできます。

現在のAWS IoTコンソール上では以下のようなアクションが指定可能となっています。

IAMロールによるアクセス権限設定

アクションとして各種AWSサービスに連携する際に、そのAWSサービスへのアクセス権限を設定する必要があります。これにより、各ルールからアクセスできる AWS リソースを制御します。

AWSリソースへのアクセスを許可するロールとポリシーを作成しておき、ルールに適用します。

デバイスシャドウ

AWS IoT Device Shadowは、IoTデバイスの状態をAWS IoTクラウド上で保管し、IoTデバイスがAWS IoTに接続されているかどうかに関わらず確認や更新を行えるサービスです。

デバイスは設置状況によりオフラインになることがあります。IoTデバイスの状態の射影としての情報をクラウド上に持つことで、アプリケーション側からは常にデバイス状態を把握することができ、また再接続時に状態の差異を検知することでデバイスの状態を更新することも可能です。

これを実現するためのデバイスシャドウのプロパティとして３つの状態が存在します。

• reported・・・デバイスの状態
• desired・・・アプリケーションからの更新依頼
• delta・・・reportedとdesiredに違いが存在する場合に生成される差分データ（デバイスの更新が完了したら削除される）

デバイスから現在のステータスをアップデート

アプリケーションから電源ONを依頼

デバイスにdeltaを通知してデバイスのステータスを更新

デバイスの最新のステータスでAWS IoTシャドウをアップデート

これらのステータスの状態遷移についてはこちらのブログ記事がわかりやすいので参考にしてみてください。

まとめ

以上、AWS IoT Coreの主要な役割として、「デバイスゲートウェイ」「メッセージブローカー」「ルールエンジン」「デバイスシャドウ」の４つに絞って概要をまとめてみました。

サービス範囲が広く、なかなか取っ掛かりがつかみにくいと感じるかもしれませんが、まずはチュートリアルやオンラインのハンズオンセミナーなどで試してみてると、理解がしやすいと思います。

AWS IoT Coreはこれ以外にも、デバイスの一連の処理を実行するAWS IoT ジョブや、デバイスプロビジョニング、デバイスを検証するためのDevice Advisor、リモートサイトのデバイストラブルシューティングのためのセキュアトンネリングなど、様々な機能がサポートされています。

そちらについてはまた別の機会にブログ化できたらと思います。

この記事がこれからAWS IoTを始める方のヒントになると幸いです。