Designing MQTT Topics for AWS IoT Core – ホワイトペーパーについて

皆さん、こんにちは！
さっそくですが、本記事では AWS IoT Core における MQTT のトピック設計について記載されているホワイトペーパーの紹介をさせていただきます。

IoT システムを構築する場合、アーキテクチャやワークロード、デバイス選定、デバイス-クラウド間の通信設計、データ格納、デバイスのプロビジョニングや運用など様々な観点を考慮・検討する必要があると思います。その中の一つであるデバイス-クラウド間の通信設計において、IoT で比較的多く採用されている MQTT プロトコルが選択肢にあがることがあると思います。 MQTT プロトコルを利用した通信では、MQTT トピックという仕組みによりデバイス-クラウド間での情報をやりとりしますが、基本的にトピックの階層構造自体は自由に設計することができるため、デバイス情報や通信種別などに合わせて構造を統一的に設計するのではないでしょうか。それにより、接続するデバイス種別やデバイス-クラウド間を行き来する情報の種類が増加してもトピックの階層構造がシンプルに保たれ、更にトピック毎に通信に対するポリシー設定をすることでセキュリティ権限管理が可能となります。

ホワイトペーパー「Designing MQTT Topics for AWS IoT Core」では、複数の章にわたって AWS IoT における MQTT トピック設計のベストプラクティス、ガイドライン、方針が紹介されており、本ブログでは各章で説明されている内容について簡単ではありますがお伝えできればと思います。MQTT の概念や用語について理解していることが、本ホワイトペーパーを読みすすめる上での前提となっておりますので承知ください。

ホワイトペーパー(英語)はこちらからダウンロードすることができます。
※ 2021/10/06 にホワイトペーパー (日本語) が公開されました。こちらからダウンロードすることができます。

概要 / 序章

本ホワイトペーパーでは、 IoT システムを構築する際に AWS IoT を利用した MQTT トピック設計を行うためのベスト・プラクティスに焦点が当てられています。AWS IoT Core では、通信やデバイス環境制約を考慮する必要がある IoT システム向けに設計された MQTT プロトコルがサポートされており、MQTT を利用する際に最初に検討すべき項目の1つであるトピック設計を実施する上で、MQTT 通信パターンや通信ワークフローを実現するための参考となるデザインパターンを以降の章で具体例を用いて説明しています。

MQTT 通信パターン

IoT システムでは、デバイスからデバイスへ、デバイスからクラウドへ、クラウドからデバイスへ、デバイスからユーザーへ、またはユーザーからデバイスへなどの、複数の通信パターンをサポートする必要があります。IoT システムと MQTT ではカバーするパターンの範囲が異なりますが、MQTT を用いた通信は大きく3パターンに分類されており、Point-to-Point、Broadcast、Fan-in という名称がついています。

Point-to-Point
こちらは MQTT メッセージの送受信方法として基本的な構成要素の一つで、一対一通信に限定されず、一対多の通信でも利用されます。

Point-to-Point での一対多通信では、単一デバイスから複数デバイスへ複数のトピックを使用してメッセージを送信します。

Broadcast
Broadcast は、一対多でのメッセージ送信方法として利用されます。例えば、単一デバイスからクラウドにある複数サービスに対して、単一メッセージを同時配信する場合に選択します。

Fan-in
Fan-in は、Broadcast の逆と考えることができ、多対一での通信パターンで利用されます。一般的な利用目的としては、複数デバイスの同一メトリクスを収集するなどで、IoT システムのテレメトリー集約を容易にするために利用されます。MQTT トピックを正しく設計することで、下図の RULE SELECT に設定されている + （シングルレベルワイルドカード）が利用しやすくなり、シンプルな構成を保つことができます。

通信ワークフロー

前章で IoT システムでは複数の通信パターンをサポートする必要があると記載しましたが、デバイスからデバイスへ、デバイスからクラウドへ、クラウドからデバイスへの、3パターンが一般的な通信ワークフローとして挙げられます。これらの通信ワークフローにおいて MQTT を利用する場合、以下のような設計上の検討項目があります。

デバイスからデバイスへの通信
MQTT トピック名として、メッセージの送受信者のどちらかの識別子を含めます。

デバイスからクラウドへの通信
MQTT トピック名ではなく、メッセージにアプリケーションに関する情報を含めます。

クラウドからデバイスへの通信
メッセージに、クリティカルメッセージの確認応答を追跡するためのセッション情報を含めます。

MQTT トピック設計に関するベスト・プラクティス

一般的なベスト・プラクティス

この章では、一般的な MQTT トピックを設計する上での、ベスト・プラクティスについて説明しています。以下は概要一覧ですので、各項目の詳細についてはホワイトペーパーをご覧ください。

• MQTT トピック名には、小文字、数字、およびダッシュのみを使用するようにします。
• MQTT トピック構造が抽象的な項目から具体的な項目に沿っていることを確認します。建物内にある温湿度や CO2 センサーを配置した IoT システムの MQTT トピックを設計する場合、 building1/floor2/room3/sensor4 のようなトピック構造が考えられます。
• 関連するルーティング情報を MQTT トピックに含めます。
• データトピックとコマンドトピックを区別するために、MQTT トピックにプレフィックスを付けます。
• 運用実践の一環として MQTT トピックの構造を文書化します。
• デバイスが MQTT を介してクラウドへ接続する際の MQTT クライアント ID に AWS IoT のモノの名前を使用します。
• パブリッシュやサブスクライブに使用する MQTT トピックには、デバイスのモノの名前を含めます。
• AWS IoT Core のデフォルトのサービス制限を確認します。
• MQTT メッセージのペイロードに、特定のメッセージに関する追加のコンテキスト情報を含めます。
• 単一デバイスへの大規模な Fan-in シナリオを引き起こす MQTT 通信パターンを避けます。
• デバイスでは # （マルチレベルワイルドカード） を使用してすべてのトピックをサブスクライブすることは絶対に許可せず、 IoT Rule でのみ利用するようにします。

テレメトリーのベスト・プラクティス

テレメトリーとは、デバイスから送信されクラウドへ集約した読み取り専用のデータのことを指しており、集約するためにデバイスからクラウドへの通信ワークフローとして Fan-in パターンを利用することができます。AWS IoT では複数サービスを組み合わせることができ、AWS IoT Basic Ingest と標準の MQTT トピックを組み合わせて、テレメトリーのユースケースを実現することが推奨されています。
その他、AWS IoT Basic Ingest の利用によるコスト効率化や、その他のベストプラクティスが説明されています。

コマンドのベスト・プラクティス

コマンド・トピックは、リモートからデバイスを制御する命令(コマンド)を送信し、送信した命令の実行結果を確認するために利用するトピックです。全ての通信ワークフローで利用することができますが、テレメトリーとトピックを共有するのではなく分離して設計します。また、AWS上に命令制御を実装するために、AWS IoT Device Shadow や AWS IoT Job というサービスが用意されています。

コマンド実行効率の最大化やフリートの全体管理のために、AWS IoT Device Shadow や AWS IoT Job を活用する上でのベストプラクティスを参考にしていただけるかと思います。

AWS IoT Device Shadow や AWS IoT Job などは抽象化されており、シナリオによってはテレメトリー及びコマンド処理を行うために標準の MQTT トピックを活用したほうがいいケースもあると思います。期待する動作を実現するために、柔軟性のある MQTT トピックを選択する場合、テレメトリー及びコマンドのベストプラクティスに説明されている MQTT トピック構文と MQTT ペイロード構文が参考になると思います。

AWS 上でのアプリケーション

本章では AWS IoT を用いたベストプラクティスを実現するためのいくつかのユースケースが紹介されています。

AWS IoT Device Shadow のサンプルでは、デバイス管理者がデバイス（サンプルでは風車）に対して、デバイスの周辺環境変化に対応するために物理的な状態（風車の羽の角度）の制御でのユースケースが提示されています。

1) デバイス管理者が AWS IoT Device Shadow へ期待する状態をメッセージとして送信します。

2) AWS IoT Device Shadow に記録された状態とデバイス管理者から送信された期待する状態に差分が発生すると、デバイスへメッセージが送信されます。デバイスは事前に AWS IoT Device Shadow のトピックを Subscribe しておく必要があります。

3) デバイスが受け取ったメッセージをもとに適切な処理を実行し、実行結果を AWS IoT Device Shadow へ送信することで、デバイス管理者が処理結果を確認することができます。

また、風車のサンプル以外にもMQTT コマンド・トピック及び MQTT テレメトリー・トピックのサンプルについても具体例を用いて説明しているので、こちらについてはホワイトペーパーをご覧ください。

MQTT トピックを用いた AWS IoT Rule Engine のベスト・プラクティス

IoT システムではテレメトリー・データの収集やコマンドの送受信を行いますが、AWS IoT Rule Engine を利用することで各メッセージを他の AWS サービスへインテリジェントに連携することなどができます。運用上のメトリクスの収集、データへの情報付与、分析目的のための遠隔測定データ集計、エラーのトラブルシューティングなどのユースケースをサポートしています。

AWS IoT Rule Engine とテレメトリー・トピックを統合することで、送信されたメッセージに対してデータ付与や特定データのフォーマット変換などを行うことができ、他の AWS サービスとの連携においてより有益な情報を提供することが可能となります。また、コマンド・トピックに関しては、コマンドの実行状態を把握するために AWS IoT Rule Engine と Amazon DynamoDB を用いた実行状態の記録・維持方法の一例についてが説明されています。

AWS IoT Rule Engine に関連する推奨事項を確認し、ルール定義のメッセージ拡張やフィルタリングを検討する際の参考にしていただければと思います。以下は概要一覧ですので、各項目の詳細についてはホワイトペーパーをご覧ください。

• topic(Decimal) ルール関数を使用して、MQTT メッセージを MQTT トピックに含まれるコンテキスト情報を補完します
• timestamp() ルール関数を使用して、MQTT メッセージが AWS IoT Core へ到達した時間を補完します
• コマンド・メッセージが JSON の場合、AWS IoT ルールの SELECT 句と WHERE 句でメッセージのコンテキスト情報を参照できます。ルールがトリガーされるべきかどうか、いつトリガーするかの判断に利用できます
• AWS IoT Rule Engine でトリガーされるアクションの一部に Substitution templates を使用します。Substitution templates を使用することで、スケールを容易にしアクションへの動的なルーティングが可能になります
• コマンドのリクエスト状態を追跡するために、 AWS IoT Rule Engine を使用して、状態を DynamoDB などの AWS サービスへ保存できます。ハイスループットで送信されたコマンドを処理する場合は、 Amazon Kinesis を活用して、 DynamoDB へ保存する前にバッファリングすることができます
• AWS IoT ルールの WHERE 句は、 AWS IoT アクションに適用されないようメッセージをフィルタリングするために利用できます
• AWS IoT Core がメッセージを受信したら Amazon Kinesis や Amazon SQS などの AWS サービスを活用して、 MQTT メッセージのペイロードをバッファリングし、 AWS Lambda や Amazon EC2 上で独自ロジックを実行することが可能になります

結論

MQTT は、シンプルでセキュア、柔軟性があり且つ堅牢なプロトコルです。これにより、デバイスとクラウド間の通信ワークフローを定義することができ、増え続けるユースケースに合わせてカスタマイズが可能となります。本ホワイトペーパーでは、AWS IoT 上で MQTT をうまく活用するにあたり最初のステップへのサポートとして、いくつかのユースケースを用いて MQTT トピック設計などの検討に関するベストプラクティス、ガイドラインについてを説明しています。AWS IoT では、AWS IoT Jobs 、 AWS IoT Device Shadow 、 AWS IoT Rule Engine といったマネージドサービスを提供しています。 AWS IoT を利用したシステムを構築する際には、本ホワイトペーパーで概説してるテレメトリとコマンドを定義するためのベスト・プラクティスを活用いただき、全体的な MQTT 設計と矛盾していないかをご確認いただければと思います。

さいごに

この記事では、ホワイトペーパー「Designing MQTT Topics for AWS IoT Core」の内容についてご紹介させていただきました。MQTT を用いた IoT ソリューションの構築を考えている皆様にとって有用な記事とあれば幸いです。

著者
ソリューション アーキテクト 久次米 孝俊