AWS IoT Core の Black Belt を読んだのでまとめてみる
歴史シミュレーションゲーム好きのくろすけです！
今回は AWS IoT Core に入門するために確認した Black Belt についてまとめようと思います。
資料概要
今回確認したのは下記の資料です。
AWS IoT Core 概要
AWS IoT Core は、IoT デバイスをクラウドアプリケーションやその他のデバイスに簡単かつ安全に接続できるマネージド型のクラウドサービスです。
本記事では、Black Belt で学んだ IoT Core の主要な機能や特徴についてまとめます。
主要機能
AWS IoT Core を構成する主要な機能は下記の6つです。
- デバイスゲートウェイ
- 認証サービス
- レジストリ
- メッセージブローカー
- ルールエンジン
- デバイスシャドウ
1. デバイスゲートウェイ
IoT ワークロードに最適化されたフルマネージドな接続管理
- MQTT、WebSocket、HTTP のプロトコルをサポート
- TLS 1.2 を使⽤した安全な通信（最新では TLS 1.3 も対応）
- 制約のあるデバイスへの最適化
全ての通信はTLS暗号化が行われるようです。
そのため、厳密には MQTTS、MQTT over WebSocket Secure、HTTPS 通信となるようです。
また、HTTP (HTTPS) はパブリッシュのみ対応しているようです。
詳細は下記をご確認ください。
2. 認証サービス
デバイス認証を管理し、ユニークなアイデンティティを大規模に提供
- AWS IoT Core が発⾏した証明書か、お客様独⾃の CA が発⾏した証明書を使⽤可能
- ジャストインタイム登録を使⽤した⾃動デバイス・プロビジョニング
- x.509 デバイス証明書による TLS 相互認証、SigV4、およびカスタム認証をサポート
- IoT ポリシーによる柔軟できめ細かいアクセス制御
利用可能な認証方法
- x.509クライアント証明書
- TLS相互認証
- 登録数に上限がなく、証明書の持ち込みも可能
- 基本的には IoTデバイス に使用
- Amazon Cognito
- スマートフォンなど、入力装置があるデバイスで利用可能
- 人による認証情報の入力ができない場合はマッチしない
- 大量デバイスには向いていない
- 基本的には モバイルアプリケーション に使用
- AWS IAM
- SigV4 セキュリティトークンでの認証
- 作成数に上限があるため、大量のデバイスの運用には適さない
- 基本的には ウェブ、デスクトップアプリケーション に使用
- カスタム認証
- AWS Lambda で独自の認証方法の実装
- HTTP ヘッダー、MQTT connect 時の ID/Password など
- その他の認証メカニズムが必要な場合に使用
基本的な使い分けは下記に記載があります。
IoT ポリシー
各デバイスに許可するアクションの設定です。IAMポリシーみたいなものですね。
IoT ポリシーはデバイスの証明書もしくはグループ（Thing Group）にアタッチできます。
3. レジストリ
AWS サービスで簡単に使えるようにデバイスを定義してカタログ化する
静的なデバイス属性はレジストリに保存する
（動的なデバイスの状態はデバイスシャドウに保存）
- デバイスにカスタム属性を定義できます
- 属性値でデバイスを検索できます
- (例: 2010年に製造されたデバイス)
- Thing Type の定義により、デバイス間で属性とポリシーの標準化を可能にします
- Thing Group の定義により、デバイスの⼀括管理を可能にします
- （ジョブの実⾏、ポリシーの設定など）
Thing Type
オブジェクト指向言語でいうところのクラスのイメージです。
下記の制約があります。
- 1つのデバイスに指定できる Thing Type は 1つ
- Thing Type に付けた名前は変更できない
- デバイスに設定できるカスタム属性数の制限
- Thing Type が指定されたデバイス：最大 50 個
- Thing Type 未指定のデバイス：最大 3 個
特に最後の制約により、Thing Type はほぼ必須との補足がありました。
Thing Group
デバイスをグループ化して管理する。
階層設計も可能で、それぞれの階層（グループ）に IoT ポリシーをアタッチできます。
下記の制約があります。
- Thing Group に付けた名前は変更できない
- û、é、ñ などの国際⽂字を含めることはできない
- 1デバイスに指定できるグループは最⼤10個
- Thing Group は最⼤1つの直接の親を持ち、⼀度設定した親は変更できない
- 階層は 7 階層まで
- ⼦グループの数は最⼤100個
- グループ階層は⼊念に計画し、それに含む⼦グループを作成する前に親グループを作成する
- デバイスは同じ階層構造の中で1つの Thing Group にのみ所属できる
- グループにアタッチできる IoT ポリシーは最⼤２つ
4. メッセージブローカー
IoT デバイス間で信頼性の高い高速通信
Pub / Sub モデルにおける、Topic の管理をしている
- デバイスとアプリケーション間の双⽅向メッセージ・ストリーミング
- オフラインデバイス向けメッセージキュー
- デバイスとアプリケーションを疎結合にするためのパブリッシュ＆サブスクライブ
- QoS0 および QoS1 メッセージングのサポート
- ワイルドカード・トピックフィルタをサポートするカスタマイズ可能なトピック空間
Topic
メッセージ（データ）を送る先を示す文字列
最低一つの Topic Level（階層）を持つ
"/" で複数（最大8階層）の Topic Level を連結（先頭に"/"は不要）
以下が主な仕様です。
- "$"で始まる Topic は予約されているので使用しない
- 大文字と小文字は区別される
- 可能な限り小文字、数字、"-"だけ使用する
- Topic の長さは UTF-8 で 256bytes まで
- ワイルドカードが使用できる
- "+"：1階層にマッチ（間の階層もOK）
- "#"：末尾の複数階層にマッチ
メッセージ
128KBまでの任意のデータを送信可能
特に制約がなければJSON形式を推奨
- メリット
- ルールエンジン(後述)で JSON 内の属性を参照できる
- 他の AWS サービスとの連携もしやすい
- デメリット
- メッセージサイズは⼤きくなる
- デバイスが JSON を Parse / Serialize できるリソースを必要とする
QoS (Quality of Service)
MQTTプロトコルでのメッセージ配信の信頼性レベルです。
IoT Core では レベル0とレベル1 をサポートしています。
5. ルールエンジン
⼤量のデータを SQL ライクな⽂法で取り込み、分析や視覚化などのために10以上のサービスを利⽤可能
- 変換: 数値演算、⽂字列操作、⽇付などの組み込み関数
- フィルター: WHERE 句を使⽤して必要なデータのみを取得
- エンリッチ: Device Shadow と Amazon Machine Learning (現 SageMaker AI か？) またはインライン AWS Lambda 実⾏を介した外部ソースからのコンテキスト取り込み
- ルーティング: 10以上の AWS サービスやSalesforce, HERE などのサードパーティサービスにデータを送信
その他のデータ収集
動画などのデータ種別やデータサイズの関係で IoT Core でのデータ収集が難しい場合は、下記サービスの検討も
- Amazon Kinesis Data Stream
- Amazon Kinesis Video Stream
- Amazon S3
この際の認証機能は IoT Core で実現できるようです。
6. デバイスシャドウ
いつでもあなたのデバイスの状態を把握し、管理する
主に遠隔制御に使用する機能です。
アプリケーションからデバイスへコマンドを送信することができます。
- デバイスの最後の既知の状態を報告します。
- 例えば「現在把握している電球の最後の⾊は⾚です」など
- デバイスの状態を変更します。
- 例えば「電球の⾊を⻘に変える」など
- MQTT を使⽤した状態変更のリアルタイム通知
- オフラインデバイスとの⾮同期通信
- デバイスへの簡単な実装のためのAWS IoT Device SDK への統合
- アプリケーションがデバイスと通信するためのREST API
あとがき
AWS IoT Core の Black Belt は、IoT Core の初歩的な知識が体系的にまとめられており、非常に参考になりました。
今後は実際に IoT Core を使った検証を行ってみたいと思います。
以上、くろすけでした！
