MQTTが産業用アーキテクチャにどのように組み込まれるか

Podcast「Augmented Ops」の最新エピソードでは、HiveMQの共同創業者兼CTOであるドミニク・オーバーマイヤー氏をゲストに迎え、産業用IoTアーキテクチャの現状と、その中でMQTTが果たす役割について掘り下げました。 「MQTTを活用した産業用アーキテクチャの構築」と題されたこの対談では、オーバーマイヤー氏と共に、MQTTの役割、Unified Namespace（UNS）のような新しいアーキテクチャをMQTTがどのようにサポートしているか、そして多くの製造業者がこれらの新しい技術やアプローチを活用するためにデジタルインフラの再構築を進めている理由について掘り下げました。

大学を卒業してすぐにHiveMQを設立したことから、10年以上にわたりMQTT技術委員会に参画し、規格の策定に貢献してきたオバーマイヤー氏は、この技術と製造業におけるその活用について、多角的な視点から解説している。特に同氏は、製造業者に対し、企業規模の産業インフラを構築するためにMQTTを採用するよう呼びかけている。

オーバーマイヤー氏はMQTTの歴史について詳しく説明し、1999年にIBMが石油・ガス分野での活用を目的に開発を開始し、2010年にオープンソース化されたことで、誰もがロイヤリティを支払うことなくこの仕様を実装できるようになったと述べた。 この変化がMQTTの普及に向けた最初の弾みとなり、当初はホームオートメーションの分野で利用され始め、その後、コネクテッドカーから産業・製造分野に至るまで、あらゆる用途で好まれる通信プロトコルとなった。しかし、HTTPやOPC UAといった数多くの現代のプロトコルと比べ、MQTTの真の差別化要因は何なのだろうか？

まず第一に、MQTTはパブリッシュ／サブスクライブ（しばしばPub/Subと略される）という通信パターンに従っています。つまり、MQTTインフラストラクチャ内のどのノードも、中央のブローカーにある特定のアドレス（トピックと呼ばれる）にデータをパブリッシュできるほか、他のノードからブローカーにパブリッシュされるデータをサブスクライブすることもできます。 その結果、メッセージがパブリッシュされると、すべてのサブスクライバーに自動的に受信されます。これは、更新されたデータを要求するために一定間隔でクライアントを継続的にポーリングするプロトコルとは対照的です。オーバーマイヤー氏が説明するように、「これは、データの生産者と消費者の結合を解除することを意味します」。また、MQTTクライアントは通常、「例外発生時のみ報告」するように設計されており、データ値が実際に変更された場合にのみ、ブローカーにメッセージをパブリッシュします。

これは、MQTTのもう一つの特徴である「軽量な設計」とも関連しています。この設計により、MQTTは産業現場でよく見られるような、ネットワークリソースが限られた環境に特に適しています。膨大なパケットオーバーヘッドを必要とする冗長なプロトコルとは異なり、MQTTはクライアントとブローカー間の通信にバイナリ形式を採用しており、ヘッダーは固定の2バイトに加え、最大12バイトの可変ヘッダーで構成されています。 これに加え、「例外時のみ報告」という仕組みにより、ネットワークトラフィックが大幅に削減されるため、MQTTは高いスループットを必要とする大規模アプリケーションに最適です。

MQTTが広く普及した要因は、そのシンプルさにあります。オバーマイヤー氏によると、この仕様は「クライアント側での実装を極めて容易にする」ことを意図して設計されたとのことです。 MQTTの標準化団体であるOASISによって仕様が公開されているおかげで、誰でも好みのプログラミング言語を使って、ゼロからこの仕様を実装することができます。さらに、さまざまな言語で多数のオープンソースのMQTTライブラリが存在しており、開発者が自身のプロジェクトでMQTTを利用することをさらに容易にしています。

MQTT仕様のシンプルさと柔軟性は、他のプロトコルに比べて多くの利点をもたらす一方で、いくつかの課題も生じさせています。例えば、オーバーマイヤー氏は、このプロトコルは送信されるデータの構造を「一切問わない」と説明しています。データはテキストから画像、さらにはバイナリに変換可能なあらゆるデータまで、最大で256メガバイトという膨大な容量のものまで含まれます。 ペイロードや実装の細部における柔軟性により、この仕様は非常に汎用性が高い一方で、それぞれ異なる方法でMQTTを実装している可能性のある様々なシステムとの相互運用性を確保することが、より複雑にもなっています。

単にMQTTを希望のデータプロトコルとして指定するだけでは、2つのシステム間のシームレスな相互運用性を保証するには不十分です。なぜなら、データのエンコード方法やペイロードの具体的な内容については規定されていないからです。これにより、データ生成側にとっては仕様の実装が容易になりますが、そのデータを実際に活用する側にとっては、より大きな負担がかかってしまいます。 オーバーマイヤー氏は、Sparkplug Bのようなフレームワークが人気を集め始めている理由として、MQTTの多くの側面を標準化し、相互運用性を大幅に容易にしている点を挙げています。

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

MQTTが実装に特に適しているアーキテクチャの一つが、近年業界全体で注目を集めている「統一ネームスペース（UNS）」という概念です。オーバーマイヤー氏は、従来の技術が「ポイント・ツー・ポイントのプロトコル、あるいは組織全体にわたるエンドツーエンドのデータ転送を本来の目的として設計されていないバスプロトコル」を採用している点を指摘し、その結果「多くのデータサイロ」が生じていると述べています。 しかし、UNSを導入すれば、「OT担当者やIT担当者、そしてアプリケーションがアクセスできる中央ハブ」が実現すると彼は述べています。これにより、ノード間のポイント・ツー・ポイント接続が不要になり、誰でもネームスペース内のデータにアクセスしてクエリを実行できるようになります。

しかし、なぜMQTTを使うのでしょうか？UNSに求められる最低限の技術要件は、エッジ駆動型であること（つまり、エッジ側のノードが中央ハブに報告を行うこと）、例外報告方式であること、軽量であること、そしてオープンアーキテクチャに基づいて構築されていることです。 MQTTは、パブリッシュ／サブスクライブ型の通信パターンを採用していること、例外発生時のみ報告する機能を備えていること、帯域幅の使用量が少ないこと、そして仕様がオープンであり、誰でも無料で実装できるという事実により、これらすべての要件を満たしています。 MQTTとUNSの間には強い相乗効果がありますが、オーバーマイヤー氏は「Unified Namespaceは、はっきり言っておくと、概念であり、技術ではない」と強調しています。また、「SparkplugやMQTTは技術ですが、UNSは概念」であり、さまざまなメッセージング技術を用いて実装できるものです。