Edgeデバイス制御のためにMQTTの技術仕様を読んでみよう！

背景

PJでMLモデルをデプロイするEdgeデバイスを制御するためにIoT Coreを利用するので、MQTTについて理解する必要があり技術仕様書を確認する。
つまり今回はAWSとEdgeデバイス間でIoT Coreを利用するケース目線で読んでいきます。

なお、今回はOASISのMQTT Version 5.0をベースにしようと思います
ただし全部読んでると日が暮れるのでメインどころを読んでざっくり理解します。

今回の内容全体像

今回出てくるメインどころをざっくりまとめました。

MQTTの概要

ひとまずイントロダクションに書いてある内容を元にMQTTの全体像を掴む。

イントロダクションには以下のようにある。

Network Connection:
A construct provided by the underlying transport protocol that is being used by MQTT.
· It connects the Client to the Server.
· It provides the means to send an ordered, lossless, stream of bytes in both directions.

つまり

• OSI参照モデルのトランスポート層の上で動作
• クライアントとサーバの識別が存在する

らしい。
待て、クライアントってPubSubのどっちやねん。と思って読み進めると、

登場人物が以下のように定義されている。

• Server = メッセージブローカー
• Client = Publisher/Subscriber

ServerとClientとしか書かれていないので、一瞬メッセージブローカーが消えたのかと思ったんですが、パブリッシャとSubscriberは場合によってどちらにもなる(発行したり受け取ったり)ので、まとめてClientとして記述されています。

、、、が、普通にクソ紛らわしいので可能な限りPublisherとSubscriberに分けて記述します。

Publisher/Subscriberとメッセージブローカーのやりとりを確認

先ほどの通り、ClientにPublisherとSubscriberがまとまっているので、それぞれを分けて見ていきます。

Publisher側のSessionで何が行われるか

Subscriber側のSessionで何が行われるか

ここから以下のことがわかる

• 通信の開始・終了はクライアント側が決定する。

つまり、今回のEdgeデバイス管理を考えると、EdgeデバイスにIP穴あけは不要で、AWSのIoT Core側だけにIP穴あけが必要と言うことがわかる。
ハードウェアが分散すると言う点でEdgeデバイスのセキュリティ施策って難しいから助かるポイント。

Q:メッセージ受信のためにEdgeデバイス側にIP穴あけはいらないのか？
A:不要。
FirewallなどへのIP穴あけはTCPセッションの開始方向を制御するためのものであり、一度TCPセッションが開始されればそのセッションを使って受信できる。
そのためTCPセッションを開始する方には受信のための穴あけは不要。

仕様を見てみるとまあ確かにTCPを利用しているならばそれはそうかと納得してしまった。
双方向通信の理解度が高まった感じする。
引き続き仕様を読んでいきます。

MQTTに関する用語

ここからは下記のServerの説明部分より下の部分の用語を見ていきます。

Server: A program or device th...

Session

Session:
A stateful interaction between a Client and a Server. Some Sessions last only as long as the Network Connection, others can span multiple consecutive Network Connections between a Client and a Server.

Sessionと聞くとJWTやセッションサーバと同じあれ？と思ったが、説明を読んでみると違う。過去に以下の記事で解説したブラウザが作っているSessionとは別の方式を使ってMQTTでもSessionを再現している模様。
ひとまず仕様にもあるとおりセッションストアか何かでステートフルな通信が実現されていると言う理解をしておく。

ちなみにHTTPのセッションはこちらを参照。

PublisherとSubscriberどちらもSessionを利用する。
Publisherはpublishできればいいため、セッションが必要ないということではなく、セッションの中でWill Messageの設定やQoS応答が行われる。

Subscription

A Subscription comprises a Topic Filter and a maximum QoS. A Subscription is associated with a single Session. A Session can contain more than one Subscription. Each Subscription within a Session has a different Topic Filter.

Topic FilterとQoSというもので Subscriptionが成り立っているとのこと。

mermaidの図を見るとSubscriber側からメッセージブローカー側に登録している。
説明にもあるとおり、登録されたサブスクリプションはセッションに紐づけられ、異なるトピックフィルタをもった複数のサブスクリプションの登録が可能とのこと。
つまりQoS違いでトピックフィルタは同じと言うのはできないと言うことなので、QoSはどれか一つに絞る必要があると言うことか。(まあ複数選択する意味もないかと思ったり。)

次にQoSとトピックを見る

QoS

QoSとは、Quality of Serviceのことで三つのレベルがある

Oasisのページの以下に記載がある

4.3 Quality of Service levels and protocol flows

気をつけたいのはQoSレベル1に以下の記述があり、0にはないことからQoSレベル0は失われても良いトピックに利用すべきということ

This Quality of Service level ensures that the message arrives at the receiver at least once.

レベル	名称 (英語)	意味のイメージ
QoS 0	At most once	多くても1回（届かなくてもOK）
QoS 1	At least once	少なくとも1回（届くことが保証されるが重複可能性あり)
QoS 2	Exactly once	ちょうど1回（重複なし）

サブスクリプションの説明にもあったが、一つのトピックフィルタに対して一つのQoSしか選択できない。
今回はEdgeデバイスからのハートビートをAWSに送りたいのでQoS0でいいかなというきもち。
ただ、起動停止とか届かないとまずい、かつ変な挙動をされると困るものはQoS2だろうと思う。
となるとQoS1の使い所が微妙にわからん。

。。。なんてことを思いながらIoTCoreでの紹介のされ方を見てみると、、、
なんとQoS2はサポートされていない。
つまりアプリケーション側で重複して届くメッセージはハンドリングしないといけないと言うこと。

詳細は触れないが、QoSはレベルによりPublisherとBrokerがやりとりする通信の回数が異なる。(必要に応じて別途記事にするかも。)

Topic Filter

Topic Filter:
An expression contained in a Subscription to indicate an interest in one or more topics. A Topic Filter can include wildcard characters.

Oasisの紹介とは順序が変わるが先にSubscriptionの構成要素であるTopicFilterについて紹介。

前提として、TopicはPub/Subモデルの概念。Publisher側がApplication Messageに付与する、何の情報か？を示したラベル。Subscriber(今回でいうEdgeデバイス)に送るべきメッセージをこのトピックで判断する。

Topic Filterはメッセージブローカーに登録されているApplication Messageをフィルタリングし、取得したいメッセージだけ取り出すためのフィルタ条件。

Topic Name

Topic Name:
The label attached to an Application Message which is matched against the Subscriptions known to the Server.

サブスクリプションで照合されるApplication Messageの名前
まんまですな。
Application MessageにTopic Nameと言う名前がついており、その名前をTopic Filterでパターンマッチすると言うこと。

Shared Subscription

Shared Subscription:
A Shared Subscription comprises a Topic Filter and a maximum QoS. A Shared Subscription can be associated with more than one Session to allow a wider range of message exchange patterns. An Application Message that matches a Shared Subscription is only sent to the Client associated with one of these Sessions. A Session can subscribe to more than one Shared Subscription and can contain both Shared Subscriptions and Subscriptions which are not shared.

上記の説明のうち、注目したい記述が二つある。

1　maximumの記述

A Shared Subscription comprises a Topic Filter and a maximum QoS.

maximamってど言う意味だ？と思い、これを調べてみると、Subscriptionで指定するQoSは「最大このQoSで受け取りたい」と言う意味らしい。
これはQoS1や2で必要となる通信のコストが遅延に弱い回線では負担になるためとのこと。

PublisherとSubscriberが異なるQoSでメッセージをPublish/Subscribeすると、低い方のQoSが採用される。

意識しておかないと本来期待していたQoSで処理されないことになりかねないので気をつけたい。

2 : 紐付けられた一つのクライアントに送信されると言う記述

Shared Subscription is only sent to the Client associated with one of these Sessions

つまりShared Subscriptionとしてサブスクライブすることで、Lambdaのようなワーカーが水平スケールした場合に負荷分散して処理できるということらしい。

確認したところ、AWSにも記載がある。

Wildcard Subscription

Wildcard Subscription:
A Wildcard Subscription is a Subscription with a Topic Filter containing one or more wildcard characters. This allows the subscription to match more than one Topic Name. Refer to section 4.7 for a description of wildcard characters in a Topic Filter.

サブスクライブするときに処理したいトピックが複数パターンになるときにワイルドカードを指定できる。

• # 0階層以上のワイルドカード
• + 1階層以上のワイルドカード

例えば、devices/+/control/#と指定すると、devices/deviceA/control/startとdevices/deviceA/control/stop/glacefulを両方サブスクライブすることができる。

MQTT Control Packet

A packet of information that is sent across the Network Connection. The MQTT specification defines fifteen different types of MQTT Control Packet, for example the PUBLISH packet is used to convey Application Messages.

MQTTで通信されるデータの“パケット形式”のこと。
MQTTには 15種類 の制御パケットがある

Will Message

An Application Message which is published by the Server after the Network Connection is closed in cases where the Network Connection is not closed normally. Refer to section 3.1.2.5 for information about Will Messages.

異常切断が発生したとき、Broker が代わりに Publish するメッセージ。

例えばTCPの異常切断とかBrokerのセッションタイムアウト、KeepAliveで指定した秒数何も送ってこないなど。
この辺りの詳しい内容は別途まとめたいと思う。

今回はEdgeデバイスの死活監視をやるので使いたい。

Will Message 配信フロー

1. ClientがCONNECT時にWillを登録する

   • Topic Name、payload、QoS、retainフラグなどをBrokerへ渡しておく。

2. Network Connectionが異常終了する

   • Keep Aliveタイムアウトやネットワーク断など、正常なDISCONNECTが行われないケース。

3. BrokerがWill情報を参照してPUBLISHを生成する

   • 登録済みのTopic NameとQoSを使い、通常のPUBLISH Control PacketとしてWill Messageを作成。

4. Topic NameとSubscriptionの照合

   • Brokerが保持する各SessionのTopic Filterと照らし合わせ、マッチするSubscriptionを特定。

5. Subscriberへ配信

   • 該当Sessionに属するClientへPUBLISHを転送。Clientは他のメッセージと同様に受信・処理する。

つまりWill Messageは異常切断時の「Brokerによる代理Publish」であり、通常のTopic/Subscriptionマッチング規則に従って配信される。

---

ここからはエラー系をまとめる。

Disallowed Unicode code point

The set of Unicode Control Codes and Unicode Noncharacters which should not be included in a UTF-8 Encoded String. Refer to section 1.5.4 for more information about the Disallowed Unicode code points.

MQTT の文字列（Topic 名、ClientID、User Property など）は
UTF-8エンコードの文字列だが、
使用してはいけない Unicode 文字が存在する。

禁止されている主なもの

• Unicode 制御文字（C0, C1）
  例：0x00（NULL）, 0x1F（Unit Separator）など

Malformed Packet

A control packet that cannot be parsed according to this specification. Refer to section 4.13 for information about error handling.

単純に仕様に従ってパース（解析）できないパケット。

Protocol Error

An error that is detected after the packet has been parsed and found to contain data that is not allowed by the protocol or is inconsistent with the state of the Client or Server. Refer to section 4.13 for information about error handling.

これも単純にQoS3など、パースできるがプロトコル上エラーな内容。