MQTT 25周年

 (andypiper.co.uk)
4 ポイント 投稿者 GN⁺ 2024-10-23 | 1件のコメント | WhatsAppで共有
  • MQTTは、1999年10月に最初の仕様が公開されてから25年の間に、小型デバイスや不安定なネットワーク向けの軽量プロトコルから、産業・家庭・アプリ全般へと広がった
  • 限られた電力と断続的な接続を前提にしたシンプルな publish/subscribe 構造は、ネットワークやエッジデバイス環境が変化した後も強みとして残っている
  • IBM 周辺で使われていた MQTT は、2009〜2011年にコミュニティでの普及が本格化し、Mosquitto と Eclipse Paho を経て、IBM 外部のオープンプロトコル・エコシステムへ広がった
  • 現在では、Node-RED ベースの Raspberry Pi によるメッセージ処理、Dyson 空気清浄機とアプリ、3Dプリンタ制御、ホーム通知、製造現場など、ユーザーが意識しない場所にも組み込まれている
  • 25周年を機に、コミュニティは X の古いプロジェクトアカウントの代わりに Mastodon の @mqtt@fosstodon.org へ移行し、ActivityPub ベースの Fediverse にも最初のメッセージを投稿した

制約のある環境から始まった軽量メッセージング

  • 2024年10月は、MQTT の最初の仕様につながる文書が公開されてから25周年となる時期である
  • MQTT は、1990年代後半の小型で制約の多いデバイス、軽量または不安定なネットワークを前提に設計されたネットワークプロトコルである
  • 遠隔地の環境監視装置のように、接続が断続的で電力も限られる状況で、センサーデータをより大きなシステムへ送ることに重点が置かれた
    • こうしたデバイスでは、電力、帯域幅、ネットワーク可用性を節約して使う必要がある
    • MQTT は、データを小さいながらも有用な形式で発行し、収集・受信する方式に適している
  • ネットワークがより高速で安定したものになり、エッジ、ホームオートメーション、携帯デバイスが増えた後も、プロトコルの単純さは MQTT の中核的な強みであり続けている

IBM 周辺からオープンエコシステムへ拡大

  • 2001年に IBM へ入社した後、IBM MQ、ビジネス統合、メッセージキューイング、アプリケーション接続、ミドルウェア関連の顧客プロジェクトに携わった
  • IBM Hursley Lab は MQ の基盤であり、MQTT の共同開発者である Andy Stanford-Clark の活動拠点でもあり、その周辺で MQTT の実験が始まった
  • 当時 MQTT はプロトコルとして外部に公開されていたが、IBM の外ではあまり知られておらず、広く実装もされていなかった
  • 2009〜2011年頃、MQTT を IBM の小規模な実装範囲の外へ知らせる活動が進んだ
    • 当時のブローカーの選択肢は、企業向けで高価な IBM WebSphere Message Broker、クローズドソースの microbroker、クローズドソースだが無料で提供されていた Really Small Message Broker などだった
    • Roger Light が作ったオープンソースの Mosquitto は、現在も広く使われている無料実装の一つである
    • Roger Light は、2009年の第1回 OggCamp で Andy Stanford-Clark による接続されたスマートホームの発表を聞いた後に Mosquitto を作った。これは仕様の作成日から10年後のことだった

Eclipse Paho と公式標準化

  • 2011年、IBM の MQTT 実装が Eclipse コミュニティへ寄贈され、Eclipse Paho プロジェクトが始まった
  • 2012年に IBM を離れた後も Paho プロジェクトとのつながりは続き、Cloud Foundry 在籍時にも役割を担った
  • 2014年に Twitter へ加わった後は、公式な関与から退いた
  • その時期に MQTT は OASIS と ISO/IEC で公式な標準化プロセスを経た

今日、見えないところにある MQTT

  • MQTT は IBM の枠を超えてオープンプロトコルの成功事例となり、25年後にはユーザーが気づかないさまざまな製品や場所に組み込まれている
  • 代表的な用途は次のとおり
    • 趣味の開発者やメイカーのプロジェクト
    • Dyson 空気清浄機と関連アプリ
    • 3Dプリンタ制御システム
    • ホーム通知システム
    • 産業・製造現場
  • 個人の作業スペースでも MQTT はさまざまな形で使われている
    • Bambu Lab X1C 3Dプリンタが内部通信に MQTT を使用している
    • 壁にある接続デバイスが MQTT 通知に反応してデータを表示したり、照明を点けたりする
    • Raspberry Pi で動作している Node-RED が MQTT メッセージを処理している
  • 現在スマートフォンに入っているアプリのうち少なくとも1つも、スタックのどこかで MQTT を使っている可能性が高い

25周年とコミュニティの移行

  • MQTT コミュニティアカウントは、従来の X プロジェクトアカウントの代わりに Mastodon へ移行した
  • 新しいアカウントは @mqtt@fosstodon.org でフォローできる
  • 25周年を記念して、MQTT は ActivityPub を通じて Fediverse に最初のメッセージを投稿し、open social web に加わった
  • Andy Stanford-Clark は HiveMQ と fireside chat を行い、HiveMQ のポッドキャスト The Unstructured Message も MQTT 関連の内容をさらに見られる場所として紹介された

関連記事

1件のコメント

 
GN⁺ 2024-10-23
Hacker Newsのコメント

  • いまでも稼働中で毎日使われている最初のプロジェクトは、大規模スキーリゾートの造雪・消防用の配管／ポンプ／バルブ系統のSVGマップを取り込み、状態表示用のウェブサイトにしたものだった
    各ポンプ、バルブ、配管区間ごとにMQTTトピックを作り、水の流れる方向、ポンプ／バルブのオンオフ、圧力などの状態を紐づけ、mqtt.jsとjQueryでSVGの色と塗りを更新していた
    コンテナで立ち上げたMQTTブローカーを静的ホスティング上でほぼ10年間手を入れずに動かしており、mqtt.jsはWebSocket上で動作するので、状態が変わると全員に自動で反映される

    • Dockerがもう11年もの技術だというのは驚きだ

  • 最近のプロジェクトでMQTTを使ってみたが、あまり気に入らなかった
    プロトコルにオプションが多く、それぞれが何をするのか、なぜ重要なのか、どの組み合わせで使えば意図どおりに動くのかがすぐには分かりにくく、ドキュメントもその説明をうまくしてくれない
    一部は使っていたEclipse Mosquitto Pythonクライアントのせいかもしれないが、遅いシステムで競合状態が発生し、トピック購読が黙って無視されコールバックが壊れることを突き止めるのに数日かかった
    ドキュメントには100%従っていたのにそうなったし、そこまで古くないプロトコルとしては最もひどい経験のひとつだった

    • ここでは単にクライアントの出来がよくなかっただけのように思える
      Eclipseのクライアント、たとえばPahoをPythonとC++で使った経験も似たようなもので、過度に複雑で低レベルすぎるように感じられ、構造のせいでバグもいくつかあった
      おそらくほぼ1人で保守しているような状態なので、時間とともにこうなったのだろう。C++クライアントもここ6か月の貢献者は1人だけで、直近3か月は誰も貢献していなかった
      明らかなバグを直すだけの単純なPRや、単語を1つ変える程度のものでも、レビューとマージまで2年かかった。非難というより、ライブラリとバグと仕事が多すぎて、少人数の疲弊した人たちがさばいている状態に見えるということだ
      別のクライアントに移ると、Python、Rust、C#、C++での体験はずっと良くなり、たいていは高レベルAPIと低レベルAPIの組み合わせが優れていて、トピックにメッセージを送るだけなら確認応答や再試行などを気にしなくて済む
      逆に制御が必要なら制御もできる。今の状態でpahoなどを存続させておくこと自体が、むしろ害になっているのではないかと心配している。公式に死んだ扱いなら、少なくとも問題は強制的に可視化されたはずだが、今はユーザーがこうした体験をしてMQTTを諦めたり、自分が間違っているのだと思い込んだりしてしまう
    • paho Python MQTTライブラリでMQTTを使ってきてかなり多くのものを作ったが、全体としてはひどい経験だった
      API設計、貧弱なドキュメント、Pythonの慣習に従っていないようなやり方まで、すべてが気に障った
      最初は簡単そうに見えるが、プロトコルと実装の広がりが次第に足を引っ張る。ある時期には、サーバーへの接続に成功したかを確認する信頼できる方法が、同じトピックを2回購読して on_connect メッセージの特定のエラーコードを捕まえることだった。当時そのコードはドキュメント上では成功コードになっていた
      ばかげて聞こえるのは分かるが、もっと良い方法があったとしても簡単には見つからなかった。それでも文句を言うのは簡単で、このライブラリを作った多くの人たちには感謝している。彼らがいなければ今作れたものも作れなかったし、こういう巨大なプロジェクトを引き受ける人たちを尊敬している
    • Python、C、C++でPaho APIを使ってみたが、結局どれも使わなくなった
      可能なら mosquitto_sub と mosquitto_pub でプロトコルを処理し、標準入出力を読み書きするだけにする方を選ぶ
      バグのせいだけではなく、ブローカー接続の管理を、すでに書かれてテスト済みのプログラムに任せる方が簡単だった
      ただし遺言メッセージではこのやり方を効果的には使えなかったし、Linuxのようなものを動かさないマイクロコントローラにも向いていない
    • MQTTと直接競合するものではないが、https://pipe.pico.sh はSSHで通信する優れたpublish/subscribeツールだ
      実質的には認証付きのネットワーク *nix パイプシステムを作るもので、イベントを送受信する最も単純な方法を目指している
    • どこかで「単にTCPを使えばいいのでは」というのを見たが、自分のIoTプロジェクトには普通のTCPで十分だった
      自分のユースケースでは無限キューが重要だったが、MQTTはそれを提供していなかったし、MQTTが独自のメッセージIDを追跡してブローカーに送るために自分でもまたメッセージIDを管理しなければならないなら、わざわざ使う理由がなかった
      すでにMQTT前提のプロジェクトと連携するのでなければ、どこが最適な使いどころなのかよく分からない

  • ここ数年で、MQTT は工場内で機械間のデータを共有する用途でずっと多く使われるようになっている。
    歴史的には、Oil & Gas 分野で遠隔油井サイトのデータを取得する SCADA 用途で使われていた。
    10年以上前に Kepware（OPC サーバー）へ MQTT を追加してタグ値を「クラウド」へストリーミングしたことがあり、発表後に MQTT の創始者の一人である Arlen Nipper が来て「よくできている」と言ってくれて身が引き締まった。
    今は HighByte という新しい会社で、エッジで工場データをモデリングし、MQTT、SparkplugB（MQTT 上のプロトコル）、S3、Azure Blob などへ送っている。
    要するに MQTT は Industry 4.0 の大きな原動力であり、長い時間が経った今もこれほど使われているのがすばらしい。

    • 現在は Kepware IoT プラグインで毎秒約 80万タグ を MQTT にストリーミングし、最終的に VictoriaMetrics DB に入れている。
      少し無骨で、望んでいるより処理段階が多い。Kepware が IoT プラグインに毎年の更新ライセンス費用を課しているため、今はそのソリューションから離れ、telegraf が Kepware から OPC-UA データを直接読む構成へ移行中。
      Kepware で働いていた、あるいは今も働いているのか気になる。
    • 同じ業界で働いているが、OPC Foundation 標準 の技術的な見劣り、スコープの拡張、NIH 症候群にはかなり困惑している。
      単に Sparkplug B を使って、その上にセマンティクス用の仕様を実装すればよいのにと思う。
      しかも今やっている非同期まわりの作業も過剰設計でひどい。一時期会議に参加していたが、MQTT の仕様は 50 ページもなく読みやすいのに、読んだことすらなく、ヘッダーが何のためにあるのかも理解していない状態だった。たとえば本来はペイロードに入れるべきものをヘッダーに入れようとしていた。
      Microsoft 側のある人物は、MQTT で競合他社が何をしているか先に見ようという提案にさえ不快感を示した。真似るより新しく作りたかったからだ。
      私の提案で、うちの会社は OPC UA を最もエッジ側でのみ扱い、我々の技術とはできる限り分離する予定だ。
    • 私も MQTT を最初に見たのは 化学製造 の分野で、航空や鉄道の制御システムでもよく見かけた。
      ただ最近は、Kafka や RabbitMQ が MQTT の市場領域へさらに食い込んでくるのも見えている。
    • 昔なら Modbus を使っていたような場所で MQTT が使われているのだろうかと気になる。

  • 約15年前、ツイートする IoT 機器が一般的ではなかったころ、Andy Stanford Clark の家がニュースになったことがあった。
    https://www.bbc.co.uk/blogs/technology/2009/06/things_that_t...
    中核プロトコルは、衛星リンクで 1 バイト送るのに 1 ドルかかっていた時代に考案されたため、信じがたいほど 効率的 で、実装も単純だ。

  • 以前、あるクライアントのファイアウォールで使えるポートが MQTT 1883 しかなかったことがある。
    センサーデータをそうやって受け取っていたためで、どれだけ頼んでも他のポートを開けてくれなかったので、MQTT 上にリアルタイム TCP ラッパーを作って回避した。
    ローカルのマルチスレッド TCP デーモンが特定ポートへの送信リクエストを待ち受け、それを MQTT で包んで固有のトピックへ publish し、サーバーデーモンはそのトピックを検知して展開したうえでサーバープロセスへ渡していた。
    クライアントマシンから見ると、こちらのサーバーにリアルタイム TCP 接続を張っているように見えたが、その途中に見えない奇妙な MQTT ラッパーが入っていた。
    動き出してからはスマートだったが、デバッグは本当に苦痛で、何度も行き止まりにぶつかりながら、全体をきちんと組み上げるまで数か月かかった。

    • こういう ファイアウォール規則の回避 をすると解雇されかねない場所でも働いたことがある。
      今では、何もできず手持ち無沙汰でいるしかない状況を「プロセスを動かしたままにしておく」と呼んでいる。
    • 実質的には MQTT-Sockets プロトコル を実装したようなもので、それで反対側の WebSockets サーバーにも接続できたはずだ。

  • 面白いことに、最も有名な C++ ライブラリである Boost が、同時期に async-mqtt5 実装（https://github.com/mireo/async-mqtt5）を Boost.MQTT として取り込むかレビュー中である: https://lists.boost.org/Archives/boost/2024/10/index.php

    • 最近の新規プロジェクトでも、人々がまだ Boost を選んでいるのか気になる。
      体感的には、導入の大半は 2000 年代とごく初期の 2010 年代、つまり誰もが C++0x/C++11 を強制する前で、最近はまれにしか見ない。
      boost.org は昔への旅のようだ。2008 年ごろの記憶そのままで、非常停止ボタン風の「Get Boost」までそのままだ。

  • MQTT は本当に優れた小さなプロトコルで、趣味プロジェクトに使えるほど「十分に小さい」だけでなく、Facebook Messenger のようなものにも使われるほどスケールしている。
    [1]: https://engineering.fb.com/2011/08/12/android/building-faceb...

  • MQTTが軽量で効率的だという宣伝は、あまり納得できない。
    結局は TCP/IP を使っているだけで、当時の基準では相対的に特別だったのかもしれないが、そうした主張を裏づける実際の証拠は、繰り返される自慢話以外では見たことがない。
    標準であるため、対応している既製の機器に接続できる点は良い。それでも、発行/購読やメッセージキューにはもっと良い選択肢があると思うし、特にコンシューマ側のフェイルオーバーが必要ならなおさらそう思う

    • 何がより良い選択肢なのか気になる。
      MQTTの優れている点であり、私が見てきたほぼすべての他の発行/購読実装がうまくできていない点は、MQTTの中核となるデータ構造がキューやトピックではなく、購読クライアントだということだ。
      そのため、望むだけ大きなアドレス空間をトピックツリーにマッピングできる。トピックツリーは数兆個のエンドポイントを持てるし、望むなら組み込みサーバー上でもすべてのIPv6アドレスごとに1つのエンドポイントを置ける。
      トピックツリーが豊富なので、購読を必要なだけ選択的に作成でき、サーバーは小さなリソース使用量でも高速に動作できる
    • 本当に、発行/購読やメッセージキューにおけるより良い 代替手段 が何なのか気になる

  • 数年間IoTの授業でMQTTを使ってきたが、非常に 汎用性の高いツール であることが証明されている。
    WebSocketでもサポートされている点も便利だ

  • 最近、組み込みシステムのプロジェクトでMQTTを プロセス間メッセージングシステム として使っていて、かなり面白かった。
    ブローカーとクライアントは同じマシン上で動いていた。
    何かをスニッフィングしたりデバッグしたりする必要があるときは、デバイスをネットワークにつなぎ、MQTT Explorerでメッセージを記録または注入すればよいので簡単だった。
    LANの外にポートを開けて、リモート勤務中の同僚がシステムを扱えるようにもできた

    • こういう使い方はあまり見たことがないが、望ましい特性があるように見える。
      システムコンポーネントとして使う際に最も心配なのは 耐久性保証 で、ブローカー実装がデータを失わないと信頼する気にはあまりなれない
    • 私たちはこの用途に ZeroMQ を使っている。ブローカーは不要だ
    • ここでは ZeroMQ が代替になり得るのではないか？