プロローグ
本記事は、有名な国立台湾大学（NTU）の研究者チームによるブログを紹介しています。このチームは、R2XとV2Xの研究開発プロジェクトでZenohを何度か使用しており、最近当社のブルードラゴンプロトコル、MQTT、Kafka、およびDDSの性能を比較した興味深い比較実験を行いました。Zenohコミュニティを代表してNTUチームに感謝申し上げます。この検証は当社がよく質問されるいくつかの質問について回答してくれています。
– kydos
はじめに
通信モデル
MQTTとKafkaは、各メッセージがブローカーを通らなければならないブローカード通信モデルを採用しています。それとは異なり、DDSは、ミドルマンなしでメッセージが直接パブリッシャーとサブスクライバー間で送受信されるピア・ツー・ピア通信モデルを採用しています。Zenohは、ブローカードとピア・ツー・ピアという両方の通信モデルだけでなく、ルーテッドインフラストラクチャモデルもサポートしています。図１に、メッシュとクリークがピア・ツー・ピアモデルである混合トポロジーのモデルを示します。より詳細な検証については、様々な開発モデルをご覧ください。ZenohはMQTT、Kafka、およびDDSを公正に比較するためにブローカードモデルとピア・ツー・ピアモデルの両方を使用します。
テストされた性能指数
この性能検証では、スループットと遅延性の2つの主要性能指数について注目しました。図2は、スループット測定についての通信図です。Zenoh、MQTT、およびKafkaを比較するために、すべてのデータを「ブローカー」または「Zenoh Router」を介してサブスクライバーに送信しました。ZenohピアモデルとDDSの試験については、データをパブリッシャーからサブスクライバーに直接送信しました。
図3は、遅延性測定のための通信図です。スループット試験と同様に、MQTT、Kafka、Zenohクライアントモードではブローカーによりメッセージを転送し、ZenohピアモードとDDSでは、データはping とpongのノード間で直接送信されます。
試験された設定
実験のために２つのシナリオが用意されました。シングルマシーンと、イーサネットで接続されたマルチマシーンです。マルチマシーンシナリオでは、テストされたプログラムとブローカー（またはZenoh Router）は、別々の装置上で実行されます。表１は、使用された装置それぞれの設定を示しています。
表１ 試験用装置の設定
| 種類 | 仕様 |
|---|---|
| OS | Ubuntu 20.04.3 LTS |
| CPU | AMD Ryzen 7 5800X、固定周波数 4.0 GHzで稼働、8-コアプロセッサ、16スレッド |
| RAM | 32 GiB DDR4 3200MHz |
| ネットワーク | 100Gb イーサネット（マルチマシーンシナリオ） |
試験手順は、Zenoh、DDS、MQTT、およびKafkaすべてに共通しています。それぞれのバージョンと設定は以下の通りです。手順は精密測定のガイドからの提案に基づいて設計されています。すべてのベンチマークプログラムは Zenoh 性能テストプロジェクトに記載しています。
Zenohについては、テストプログラムはバージョン0.7.0-rcを使用し、Zenoh ルータzenohdはガイドに従って構築できます。信頼度は「信頼可能」として設定し、輻輳制御はパブリッシャーサイトで「ブロック」と設定しました。遅延性測定については、その信頼度は「ベストエフォート」に設定して、KafkaとMQTTの動作に合わせました。
MQTTについては、テストプログラムは Eclipse Mosquitto バージョン 2.0.15を使用しました。MQTTクライアントには、Eclipse Paho MQTT C クライアントライブラリー v.1.3.11を実装しました。すべてのMQTTクライアントについては、そのベストパフォーマンスを達成するために通信QoSレベルを0に設定しました。
Kafkaについては、テストプログラムはオフィシャルブローカー3.2.1とrdkafka クライアントライブラリー0.28.0を使用しました。よりよい結果を得るために、オンラインドキュメントと実際の実験からの提案にしたがい以下のパラメーターを選択しました。inger.ms=0、スループットはバッチサイズ=400KB、遅延性は 1; コンプレッションタイプ=なし、acks=0 および fetch.min.bytes=1（遅延性テストのみ）
DDSについては、テストプログラムはEclipse Cyclone DDSをターゲットインプリメンテーションとして使用します。これらはオフィシャルDDSの例に基づいています。信頼性QoSについては、RELIABLEを採用しました。履歴QoSについては、KEEP_LASTを遅延性テストで使用し、KEEP_ALLをスループットテストで選択しました。
スループット比較
スループットテストにおいて、パブリッシャープログラムはメッセージを連続で発行します。同じトピックについてサブスクライブしている消費者プログラムが、複数のメッセージを収集し、メッセージレート（msg/s）を測定します。この手順を各ペイロードサイズで繰り返し、1番目から99番目のパーセンタイルを超える異常値は除いたサンプルから中央値を選択して結果1とします。同じ手順をZenoh、Cyclone DDS（以下、DDSと略す）、MQTTおよび Kafkaについて行います。ビットレート（bit/秒）もメッセージレートとペイロードサイズに基づいて算出します。また、iperf ユーティリティも使用して、２つのピア間のアプリケーション層からのデータレートの理想値も測定しました。8バイトから512MBまで様々なペイロードサイズをテストし、スループットの傾向を調べました。なお、以下のチャートでは、Y軸はメッセージレートとバイトレートの両方の対数スケールです。統計データはこちらで見ることができます。いくつかの数字は、議論目的で以下の段落で報告します。
図4は、シングルマシーンシナリオの結果を示す図です。この数字から、Zenohは、小さいペイロードサイズの場合に4Mメッセージ／秒以上まで達成できることが分かります。Zenohについての2本の線のうちで、ピアモード（ZenohP2Pとして示す）は、クライアントモード（Zenohブローカードとして示す）よりもよい結果を示しました。これは、Zenohルータによりデータ送信を中継する必要が無かったからです。DDSは、速度はより遅いですが、Zenohと相対的に近い値が得られ、こちらも200万 msg/sに達しました。なお、チャートではY軸は対数スケールです。
Kafkaについては、2KBより小さいペイロードサイズでは56Kから63K msg/sの間で安定的なメッセージレートを維持し、その後、ペイロードサイズが最後に測定が成功した512KBまでこの値は減少していきました。一方、MQTTは、ペイロードサイズが32KBの前では33Kから38K msg/sの間のすこし低いスループットを示しました。しかし、Kafkaと比較するとより大きいペイロードサイズをサポートしたものの、この値は急激に減少していき、最も悪い性能値を示しました。しかし、Kafkaは、基本的にはより大きいペイロードサイズをサポートすることができるはずです。観察された制限についての理由は、当社が使用したKafkaバインディングが1MB以上のメッセージサイズを拡張することができなかったためです。
図5は、スループットを秒あたりのビット数で示したものです（ビット / 秒またはbps）。図5によれば、Zenohが4KB以上のペイロードサイズの場合にiperf（76 Gpbs）で測定されたスループットの理想値に向かって飽和していくのが分かります。ピアモードの Zenoh P2Pは67 Gbpsまで達することができます。DDSについては、達成できるスループットの最高値は約26 Gpbsです。Kafkaは、ペイロードサイズが16KBより大きい場合に約4～5Gbpsで飽和しています。MQTTについては、32 KBのペイロードサイズでは約9 Gbpsまで達します。MQTTの性能が減少する現象は、各テストで同じく見られました。理由はまだ分かっていませんが、将来の研究課題となるでしょう。
全体として、シングルマシーンシナリオではスループットの比較についてのビットレート数を取り上げ、Zenoh、DDS、Kafka、そしてMQTTから得られた最高の数値を見ると、8バイトのペイロードサイズではZenohピアモードの性能値がDDSのそれよりも最大2倍、KafkaとMQTTではそれぞれ65倍と130倍高いものでした。Zenohは8KBでピークパフォーマンスを達成し、DDSよりも4倍以上、Kafkaよりも24倍以上、およびMQTTよりも27倍以上高くなりました。最後には32 KBのペイロードでは、Zenohは、DDSの2倍以上、MQTT5倍以上、Kafkaの10倍以上のスループットを達成しました。
100 Gbのイーサネットにおけるマルチマシーンにわたるスループットを図6および図7に示します。ここでは、ビットレートの結果に注目します。
図において、iperfは、ターゲットネットワークのスループットの理想値が44 Gpbsであることを示しています。最大ビットレートはそれぞれZenohブローカードでは約34 Gbpsで、Zenoh P2Pでは約50 Gbpsでした。Cyclone DDSについては、そのスループットランキングは、14 Gbpsではチャートの第三位の地位を保持しました。一方、MQTTのビットレートは、ペイロードサイズが32 KBでは約9 Gbpsまで達することができ、その後シングルマシーンシナリオの場合と同様に減少しました。Kafkaについては、ペイロードサイズが32 KBの場合、最高のビットレート数は 5 Gbpsでした。
比較結果をまとめると、マルチマシーンシナリオで観察された結果は、シングルマシーンシナリオと同様の性能トレンドを維持し、Zenohは、DDSやKafka、MQTTと比較して数倍から数十倍の性能向上を示しました。
遅延性比較
遅延性テストでは、pingプログラムがpingメッセージを発行し、pongプログラムがpingメッセージを受領して同じメッセージを返信します。テストしたペイロードサイズは、（ICMP エコー / リプライに合わせて）64バイトに固定し、テストは、バック・ツー・バックで実施されて、基本のオペレーティングシステムにより生ずるプロセススケジューリングとコンテキストの切り替えの影響を減らしました。遅延性は、pingとpongのオペレーション1をカバーする往復時間の中央値の半分として定義されます。同様に、1番目と9番目のパーセンタイルを超える異常値を除外します。統計データについてはこちらをご覧ください。表2にテスト結果を示します。Linux ping ユーティリティを達成可能な最小遅延性のベースラインとして含めました。
表2 シングルマシーンシナリオとマルチマシーンシナリオの遅延性データ（µs（マイクロ秒））
| ターゲット | シングルマシーン | マルチマシーン |
|---|---|---|
| Kafka | 73 | 81 |
| MQTT | 27 | 45 |
| Cyclone DDS | 8 | 37 |
| Zenoh ブローカード | 21 | 41 |
| Zenoh P2P | 10 | 16 |
| Zenoh-pico | 5 | 13 |
| ping | 1 | 7 |
シングルマシーン環境では、pingから得られた遅延性の理想値は、1 µsです。MQTT とKafkaの遅延性は、それぞれ、73 µs と27 µsです。Zenohについては、クライアントモードのZenoh ブローカードでは、遅延性は 21 µsであり、これは主にミドルマンを介したデータのルーティングによるものです。Zenoh P2Pでは、遅延性は 10 µsと更に低くすることができます。Cyclone DDSについては、遅延性はZenohよりも更に低くなり、8 µsまで下がりました。その理由は、UDP Multicastを使っているからです。Zenohは現在同じデータトランスポートをまだ実装していませんが、Zenohをインプリメンテーションしたマイクロコントローラ –、Zenoh-pico ではそれを実現しています。その遅延性もテストし、Zenoh-picoの結果は5 µsでした。これは、Cyclone DDSの遅延性よりも低く、主に、Zenoh プロトコルとそのインプリメンテーションはOMG DDSI-RTPSプロトコル（すべてのDDS対応インプリメンテーションにおいて実装）よりも軽量で、効率的になれることが理由です。
100 Gbのイーサネットを有するリアルネットワークでのマルチマシーンシナリオでは、Zenoh ブローカードの遅延性は約41 µsであり、ピアモードのZenoh P2Pの遅延性は16 µsで、これは、Kafkaの81 µsや MQTTの45 µs、Cyclone DDSの37 µsよりも低くなっています。Zenoh-picoについては、最高で13 µsに留まり、pingユーティリティによるベースラインの7 µsと最も近い値となりました。
総じて、Zenohの遅延性は低くなっています。そのデフォルトであるピア・ツー・ピアモードのZenohは、MQTTやKafka（そしてマルチマシーンシナリオの場合のDDS）と比較して最も短い遅延性を有しています。UDPマルチキャストトランスポートが Zenohでサポートされている場合、Zenoh-picoの結果のように、Zenohは、すべてのソフトウェアの中で最も低い値を達成できます。
結論
このブログでは、Zenoh、MQTT、KafkaおよびDDSの性能を比較しました。Zenoh は、常にMQTTやKafkaよりも高いパフォーマンスを達成しました。結果によれば、Zenohは、Zenohインプリメンテーションに組み込まれているその低オーバーヘッドデザインとマルチプル最適化技術のおかげで、アプリケーション層からのスループットと遅延性検証について従来のベースラインツールであるiperfやpingによる理想値と比較的近い値を得ることができます。
当社の検証では、Zenohは、シングルマシーンテストについて、最高で67 Gbpsを達成し、デフォルトのピアモードを使用した100 GbE のネットワークでのマルチマシーンテストでは51 Gbpsを達成しました。MQTTや Kafkaよりも1桁、2桁の改善となり、DDSのスループットよりも2倍の改善が可能です。ひとつ顕著なことは、Cyclone DDSが、そのUDPマルチキャストトランスポートメカニズムの使用により、シングルマシーンシナリオの遅延性テストでは最もよい成績を収めたということです。しかし、Zenohのマイクロコントローラインプリメンテーション用であり、UDPマルチキャストトランスポート搭載のZenoh-picoと比較すると、すべての場合において最も低い遅延性を得ることができました。この能力は、今後すべてのZenohインプリメンテーションによりサポートされるでしょう。
Zenohのゴールは、比類のない性能とスケーラビリティを有した次世代通信フレームワークを提供することです。非常に高性能であるだけでなく、Zenohは最もシンプルなAPIと最短の学習カーブを備えた技術でもあります。当社は、クラウドからエッジ、そしてモノまでのコンティニュアムまでシームレスにサポートできるZenohが工業、IoT、ロボティクス、そして自動車の用途においてベストチョイスであると思っています。
この記事を楽しんで頂けたなら幸いです。