AWS IoT CoreとMQTT 5を使ってアプリケーションを革新する

Pulisher : Cloud Technology Center チュ・ジェビン
Description：AWS IoT Coreの最新機能およびMQTT5に対するAWSのサポート内容を紹介したChalk Talkセッション

はじめに

MQTT(Message Queuing Telemetry Transport)は軽量メッセージングプロトコルで、IoTモノとサーバー間のメッセージ交換に利用されます。MQTT5はMQTT 3.1.1のアップグレードバージョンで、いくつかの新機能を提供していますね。

最近まで、私はプロジェクト事例が豊富な3.1.1に精通していましたが、MQTT5の存在を知っていても、学習と活用までは踏み出せませんでした。 AWS IoT CoreおよびAWS IoT Greengrass V2でMQTT5もサポートしているので、いつか関連要件が発生したときに対応できるようにしたいので、今回のMQTT5入門セッションを受講しようと思います。

セッションの概要紹介

MQTT 5で新しく出てきた機能

・共有サブスクリプション(shared-subscription)：一般的にMQTTトピックを購読したクライアントは同じメッセージを受信します(ファンアウト)。しかし、共有サブスクリプションを使用する場合、グループ化されたクライアントの一つがランダムにメッセージを受信することになります。これはロードバランシング効果をもたらします。

・リクエスト/レスポンスパターン(request/response)：リクエスト/レスポンストピックを使用して、物事がブローカーにリクエストを送信した後、これに対する応答をレスポンストピックで受信することができます。一方的なコミュニケーションを脱却することができますね! requester-responseパターンが気になる方はリンクを参考してください。

・ユーザープロパティ(user-properties)：MQTTメッセージにある種のキー-値メタデータを追加することができます。MQTTパケットが拡張されたヘッダーフィールドにこれらの値が追加されます。デバイスIDやメッセージの優先順位、メッセージの種類などの情報を追加してみましょう。 このような情報はトピックに入れた経験があるかと思いますが、ユーザープロパティを利用すれば、トピックの命名をもっと単純化することができますね。

・セッション有効期限(session-expiry)：ブローカーに再接続したデバイスであれば、先ほど使ったトピックのサブスクリプション情報を失います。MQTT5ではブローカーがセッション状態を維持するため、デバイスが再接続されるとセッション情報を維持することができる機能です。

・メッセージ有効期限(message-expiry)：メッセージがブローカーに残留する時間を設定します。サブスクリプションされていないデータがブローカーのパーシスタンスに残り続けることを防止します。

・クリーンスタート(clean-start)：前述のセッション有効期限によるセッションのリサイクルを好まない場合は、クリーンスタートを要求します。 これにより、以前のセッションで行ったサブスクリプション情報が初期化されます。

・トピックエイリアス(topic-alias)

AWS IoT CoreでMQTT5のユーザープロパティを適用するアーキテクチャー

ユーザのプロパティは追加のキー:値データと言いましたが、この情報はAWS IoT Rulesで参照することができますか？はい、可能です。
・variableで参照する
“${UserPropertyKey}”

・IoT Functionで参照する
get_user_property(key)

・関連質疑応答
Q) Device IDはどうすればいいですか？トピックに入れるべきですか、ユーザープロパティに入れるべきですか?
A) この質問に対して、ある発表者からは「No absolute right, absolute wrong」と言われましたが、別の発表者からは、Device IDをトピック名に入れるのは面倒で、拡張性を損なうという意見がありました。実際、トピックにはIoT Ruleが目的地を判断するのに役立つ情報を追加すればいいのですが、Device IDは単純なメタデータとしてユーザープロパティに入れるのが妥当なのかもしれません。

共有サブスクリプションに関する詳細

共有サブスクリプションは「クライアントグループ」単位で行われます。1つのグループが任意のトピックを購読することも、もちろん複数のグループが1つのグループを購読することも可能です。注意すべき点は、メッセージがグループ内の1つのクライアントに配信されるという事実です。

MQTT5とQoSについて

推奨事項ではありませんが、トピックを異なるQoSで購読することは可能です。上のグループはQoS1、下のグループはQoS0を利用してサブスクリプションを開始し、実際に可能な構造です。ただ、可能な構造であって、模範的な構造とは言えません。 必要でないサブスクリプションをなくさずに新しいサブスクリプションを作成したときに発生可能なケースを例として考えてみることができます。

MQTT5 Topicエイリアスについて

トピック名の形式が複雑なため、顧客が別のトピックを誤ってサブスクライブした後、しばらく知らないという事態が発生することがあります。 そこで、一時的に有効な短縮URLであるTopic Aliasを利用してFail -Safeなサブスクリプションを実装することができます。

セッションを終えて

AWS IoTは現在も270 millionのMQTT接続を同時に提供しています。 そのうちMQTT5の割合がどれくらいなのかはわかりませんが、今回のセッションで紹介した7つの新機能と連動する要件が発生した場合、その内容を思い浮かべてみてはいかがでしょうか。