産業用アーキテクチャにおけるMQTTの位置づけ

Augmented Opsポッドキャストの最近のエピソードでは、HiveMQの共同創設者兼CTOであるDominik Obermaier氏と共に、産業用IoTアーキテクチャの展望とMQTTが果たす役割について探りました。MQTTによる産業用アーキテクチャの構築」と題されたObermaier氏とのディスカッションでは、MQTTの役割、Unified Namespace（UNS）のような新しいアーキテクチャのサポート方法、そして多くの製造業者がこれらの新しい技術やアプローチを活用するためにデジタル・インフラストラクチャを再構築している理由について検証しています。

大学卒業後すぐにHiveMQを設立し、10年以上にわたってMQTT技術委員会の委員を務め、標準規格の開発に貢献したオーベルマイヤーは、このテクノロジーと製造業への応用について微妙な視点を提供しています。特に、企業規模の産業インフラを構築するためにMQTTを採用するよう製造業者に呼びかけています。

Obermaier氏は、MQTTの歴史について詳しく説明し、1999年にIBMが石油とガスのユースケースのために最初に開発した後、2010年にオープンソース化され、誰もがロイヤリティを支払うことなく仕様を実装できるようになったことを説明しました。この変更は、MQTTが普及するための最初の勢いを与え、最初はホームオートメーションのセットアップで使用され、その後、コネクテッドカーから産業用および製造用のユースケースまで、あらゆるものに好まれる通信プロトコルになりました。しかし、MQTTはHTTPやOPC UAのような他の無数の現代的なプロトコルと何が違うのでしょうか？

何よりもまず、MQTTはパブリッシュ/サブスクライブ（しばしばPub/Subと短縮されます）通信パターンに従います。つまり、MQTT インフラストラクチャ内のどのノードでも、中央ブローカの特定のアドレス（トピックとして知られている）にデータをパブリッシュすることができ、他のノードからブローカにパブリッシュされるデータをサブスクライブすることもできます。その結果、メッセージがパブリッシュされると、すべてのサブスクライバが自動的にそれを受信します。Obermaier氏が説明するように、"これは、データの生産者とデータの消費者を切り離すことを意味します"。MQTTクライアントはまた、通常「例外報告（report-by-exception）」するように設計されており、データ値が実際に変更された場合にのみブローカーにメッセージを発行します。

これは、MQTTのもう1つの特徴である軽量設計と結びついており、産業環境でよく見られる制約のあるネットワーク環境に特に適しています。かなりのパケットオーバーヘッドを必要とする冗長なプロトコルとは異なり、MQTT はクライアントとブローカー間の通信にバイナリフォーマットを使用し、固定ヘッダはわずか 2 バイト、可変ヘッダは最大 12 バイトです。例外報告（report-by-exception）と組み合わせることで、ネットワーク・トラフィックが大幅に削減されるため、MQTTは高いスループットを必要とする大規模アプリケーションに最適です。

MQTT普及の鍵は、そのシンプルさにあります。MQTTの仕様は、「クライアントが非常に簡単に実装できる」ように意図的に設計されています。MQTTの標準化団体であるOASISによってオープンにされているおかげで、誰でも好きなプログラミング言語を使ってゼロから仕様を実装することができます。その上、様々な言語のオープンソースMQTTライブラリが数多く存在し、開発者がプロジェクトでMQTTを使用するのをさらに簡単にしています。

MQTT仕様のシンプルさと柔軟性は、他のプロトコルに比べて多くの利点がある一方で、多くの課題もあります。例えば、Obermaier氏は、送信されるデータの構造について「プロトコルは気にしない」と説明しています。ペイロードや実装の多くの詳細に関しては柔軟性があるため、この仕様は非常に汎用性が高い一方で、それぞれが異なる方法でMQTTを実装している可能性のあるさまざまなシステムとの相互運用性を確保するのがより複雑になります。

データがどのようにエンコードされるか、またはペイロードに実際に何が含まれるかが指定されていないためです。なぜなら、データがどのようにエンコードされ、実際にどのようなペイロードが含まれているのかが規定されていないからです。このため、データの生産者にとっては実装しやすい仕様となっていますが、データを消費するシステムにとっては、そのデータを実際に利用するための負担が大きくなります。Obermaier氏は、SparkplugBのようなフレームワークが人気を集め始めた理由として、この点を指摘しています。

Sparkplug Bはオープンソースのフレームワークで、MQTTトピック構造、ペイロード、状態管理などの一貫したパターンを定義することで、さまざまなソースからのデータを双方向かつ相互運用可能な方法でシームレスに統合することができます。Obermaier氏は、「ペイロードがどのように見えるべきか、MQTTトピック構造がどのように見えるべきかなどの標準を設定することで、Sparkplugのようなフレームワークは、MQTT仕様が異なるシステムでどのように実装されているかの詳細を気にすることなく、相互運用性を簡単に実現できるようになりました」と説明しています。

MQTTが特に実装に適しているアーキテクチャの1つが、近年業界全体で注目を集めているUNS（Unified Namespace）コンセプトです。Obermaier氏は、従来の技術が「ポイント・ツー・ポイントのプロトコルや、時にはバス・プロトコルで動作し、組織全体のエンド・ツー・エンドのデータ移動のために設計されていない」ことを強調し、その結果「多くのデータがサイロ化」していることを指摘しています。しかし、UNSを使えば、「OT関係者、IT関係者、アプリケーションからアクセス可能な中央ハブ」が存在します。これにより、ノード間のポイント・ツー・ポイント接続が不要になり、誰でもネームスペース内のデータにアクセスし、クエリできるようになります。

しかし、なぜMQTTを使うのでしょうか？UNSに最低限必要な技術要件は、エッジドリブンであること（エッジにあるノードがセントラルハブにレポートすることを意味します）、Report-by-exceptionであること、軽量であること、オープンアーキテクチャ上に構築されていることです。MQTTは、パブリッシュ/サブスクライブ通信パターンの使用、例外報告機能、低帯域幅使用、仕様がオープンで誰でも無料で実装できるという事実のおかげで、これらすべての条件に当てはまります。MQTTとUNSの間には強い相乗効果がありますが、Obermaier氏は「Unified Namespaceは、はっきり言ってコンセプトであり、技術ではありません」と強調します。SparkplugとMQTTはテクノロジーですが、UNSはコンセプトです。