NanoMQ: IoTエッジ向けMosquittoよりマルチスレッドのエッジブローカー
Jaylin
はじめに
現在は情報爆発の時代です。IoTの登場と接続デバイスの増加により、すべてのデータをクラウドで処理することはもはや不可能になっています。エッジコンピューティングのパラダイムが台頭してきています。このパラダイムは、クラウド中心のサーバーからネットワークの境界へ、コンピューティングアプリケーション、データ、サービスのフロンティアを押し広げることを目指しています。
このパラダイムシフトのメリットには以下が含まれます:
- 低遅延、高反応性、高信頼性
- クラウドサービスへのデータ転送コストの削減
- 機密性安全性の向上
エッジコンピューティングのパラダイムシフト
エッジコンピューティング技術はクラウドとエンドノードの双方向に通信します。クラウドコンピューティングと組み込みシステムの中間的存在となります。エッジが真ん中に位置するため、両方向のオーケストレーションが必要です。さらに、組み込みシステムの世界では、コスト(電力、メンテナンス) - サイズ(メモリ、CPU) - パフォーマンス(スループット、レイテンシ)の三つを同時に最適化する「トライアングルジレンマ」が長年存在しています。エッジコンピューティングにはユニークな課題があります。
このパラダイムシフトは、エッジのMQTTメッセージングサービスに大きな影響を与えます。コンピューテーションをクラウドからデータソースに近いエッジに移行することで、エッジでのデータの移動と集約の方法が大きく変わります。現在、MQTTはIoTデータ取り込みのデファクトスタンダードです。したがって、MQTTミドルウェアは課題に直面することになります。特に一般的にエッジで使われてきたMosquittoなどのブローカーには以下の3つの課題があります。
トレンド#1: シングルコアからマルチコアへ
エッジでのデバイス接続数が増加しているため、エッジ・コンピューティングの最大の難問の1つは、消費電力を最小限に抑えながら、（MLやMQTTブローカーのような）計算とI/O集約型アプリケーションで高い性能を同時に達成することである。歴史的に、エンジニアは、より良いパフォーマンスと低消費電力を達成するために、クロック周波数の向上というフリーランチを享受してきた。しかし、もはやそうではない。私たちは、HPCやデータセンター業界でマルチコアのトレンドを見てきました。エッジで起こる同じストーリーは、大いに期待されている。
トレンド#2：コンピューテーション・オフロード
ヘテロジニアス・コンピューティングは、エッジAIアプリケーションに広く採用されている。ローカルのデータ処理能力を強化することで、クラウドサーバーへのデータ転送コストを削減できる。典型的なタイプの計算では、センサーからAIアクセラレーターやDSPにデータを転送する必要がある。このコンセプトは、計算オフロードとしてよく知られている。データと転送先が同一のPCB上にある場合、通常はオンボード・バスI/Oを介して実現される。しかし、これは典型的なケースではありません。データが発生する場所は、通常、計算されるべき場所から遠く離れています。したがって、データのコンテキストを把握し、望ましいコンシューマーにデータを転送することができるメッセージング・サービスが必要となる。これにより、エッジノードが切り離され、ローカルネットワークのトポロジーの複雑さが軽減される。さらに、イベント・ドリブン・アーキテクチャーをサポートするメッセージング・ブローカーがあればなお良い。
トレンド#3：相互運用性
相互運用性とは、MQTTブローカーの特徴であり、そのインターフェイスは、エッジまたはクラウドの他のシステムと、取り込みまたはアクセスのいずれにおいても、何の制限もなく動作することが完全に理解されていることである。エッジコンピューティングの状況下では、以下を指す：
エッジ・クラウド オーケストレーション
IoTデバイスは地理的に分散しており、そのライフサイクルをリモートで管理・監視するのは容易ではない。この問題を解決するために、コンテナベースの技術が登場している。エッジMQTTブローカーは、エッジクラウドオーケストレーションを実現するために、クラウドネイティブなアーキテクチャを統合するRESTful APIを提供する必要がある。
オールインワン・プロトコル対応
エッジでは、IoTエコシステムは断片化されている。ZeroMQとnanomsg/nngはまだブローカーレスシナリオでよく使われている。MQTTはブローカー中心のプロトコルであり、ブローカーレスには適していない。したがって、ブローカーとブローカーレスの両方をサポートでき、ブリッジングネットワークを構築する際にトポロジーが柔軟なエッジメッセージングサービスが早急に必要である。
MosquittoとNanoMQの比較
前章では、直面する課題を明らかにしました。ここで、これらの一般的なエッジMQTTブローカーをチェックします。ここでは、Mosquittoを例にとり、これら3つの課題に関してNanoMQとの比較を行います。
Mosquittoの場合
Mosquittoプロジェクトは、2009年にRoger Lightによって初めて開発され、後にEclipse Foundationに寄付されました。 Mosquittoは最も長い歴史を持つMQTTプロジェクトで、ユーザーから高い評価を得ています。
Mosquittoの設計はシンプルでクリーンです。epollサポート付きのシングルスレッドデーモンプロセスとして動作します。1つのソケットから入ってきたデータを受信し、他のソケットに配信します。
- シングルスレッド: 最新の2.0+バージョンでも、Mosquittoはシングルスレッドアプリケーションとして動作するため、エッジアプリケーションがマルチコアCPUの利点を活用できません。シングルスレッド設計は、特にレイテンシに敏感なアプリケーションの場合、システム上の最大パブリッシャー数を制限します。
- コンピューテーションオフロード: サードパーティのプラグインはあるものの、MosquittoプロジェクトはルールエンジンやMQTTメッセージのフィルタリング、エンリッチメント、変換などの機能をサポートしていません。ネイティブなイベントプロデューサがないため、Mosquitto上にイベント駆動型アーキテクチャを構築するのは困難です。
- 相互運用性: MosquittoはRESTful HTTP APIを提供していません(2.0.1以前)。デバイス管理などの外部システムとの統合が困難です。最新の2.0バージョンは、統合機能の強化よりもセキュリティの改善に注力しています。
明らかに、Mosquittoは従来の組み込みシナリオをターゲットとしており、リソース利用効率が高く、メモリとCPUの使用量が少ないという特徴があります。したがって、Mosquittoは処理能力の低いIoTセンサーやデバイスに理想的です。
NanoMQによる解決
Mosquittoがコスト効率に重点を置いている一方で、NanoMQ )がその空白を埋めています。次の章では、NanoMQがこれらの課題をどのように解決し、エッジコンピューティング時代においてMosquittoに代わる最良の選択肢となる理由を説明します。
エッジ上のアクター: 1からNへ
解決策に入る前に、ハードウェアの側面から見てみよう。歴史的に、エンジニアはムーアの法則に依存し、より良いパフォーマンスと低消費電力を達成するためにクロック周波数を上げてきたが、もはやそうではない。特に組み込み機器やモバイル・システムでは、デバイスの周波数を上げ続けるのは単純に効率が悪いため、この10年間はシングルコアで高周波のアーキテクチャを使う代わりに、マルチコアを選んできた。業界はマルチコアを選択し、周波数を下げた。しかしその結果、プログラミング・モデルに大きな変化が生じた。特にMQTTブローカーのようなI/O集約型のミドルウェアでは、計算を複数のコースに分散させなければならない。
マルチコア化のもう一つの大きな原因は、半導体プロセスが見えない壁にぶつかっていることだ：
グラフからわかるように、シングルスレッド性能は平坦化している。シングルコアの周波数は過去20年間苦戦している。電力効率と発熱の問題から、エッジでは状況はさらに悪化している。しかし、唯一進歩し続けている指標がある。
この考え方は、複数の並列コアを低い周波数で使用することで、高い周波数のシングルコアと同じ計算性能を達成できるというものだ。もちろん、マルチコアアーキテクチャは、同じ性能でより低い消費電力を達成できるという違いがある。しかし、楽観主義のコストは上昇している。
並列化が役たつ
アムダールの法則によれば、マルチコアシステムを活用するためには、コードを並列化し、最適化マージンを得る必要がある。直列化されたコードは、ソフトウェアの足を引っ張っている。
しかし、並列コンピューティングに切り替えるには、次のような問題を解決する必要がある：
- オブジェクトの共有状態
- レースコンディション
- ブロッキング呼び出し
- デッドロック
- メモリコピー
残念ながら、MQTTに関しては、QoS配信やトピックフィルタリングのように、並列化が難しいブロッキングコールをベースにしたトリッキーなロジックがある。さらに悪いことに、ブロードキャストのようなファンアウト・メッセージ・パターンは、しばしばデータの競合を避けるために大規模なメモリ・コピーにつながります。NanoMQはビルトインのActorモデルを実装することで、サイズとパフォーマンスのバランスをとる完璧なスポットを見つけました。
残念ながら、MQTTに関しては、QoS配信やトピックフィルタリングなどのブロッキング呼び出しに基づくいくつかのトリッキーなロジックがあり、これを並列化することは困難です。さらに悪いことに、ブロードキャストなどのファンアウトメッセージパターンは、多くの場合、データ競合を避けるために大量のメモリコピーを引き起こし、これはメモリ制限のあるデバイスには受け入れられません。 NanoMQは、組み込みのアクターモデルを実装することで、サイズとパフォーマンスのバランスの取れた完璧なスポットを見つけました。
Actor・モデルは物理学にヒントを得たソフトウェア設計の強力なコンセプトです。NanoMQの内部Actor・システムは、LinuxとMQTT向けに最適化されたNNGの非同期I/Oフレームワークに基づいています。すべての計算を複数のアクタに抽象化し、効率的な方法でアクタ間で不変メッセージを交換します。
NanoMQは、その繊細な設計によって、上記のようなさまざまな課題にエレガントに取り組んでいる：
- レース条件 - 不変メッセージ
- ブロック呼び出し - 内部は完全に非同期I/O
- デッドロック - スレッドレベルの並列性
- メモリーコピー - ゼロコピー
エッジの革新的なActor・モデルのおかげで、NanoMQはマルチスレッドのステロイドのようです。最新のSMPシステムにおいて、より少ないCPU使用率でマルチコアに対応するために簡単にスケールアウトすることができます。NanoMQがよりスケーラブルであることは間違いありませんが（ベンチマーク結果をご覧ください）、一方でゼロ・コピー機能により、メモリ消費量はMosquittoと同レベルです。
ルールエンジンとWebHookによるオフロード
計算オフロードとは、計算タスクをリモートデバイスやクラウドプラットフォームに転送することを指す。近年、業界ではデータストリームを再利用可能にし、ネットワークの複雑さを軽減するために、統一名前空間（UNS）の概念を導入した。MQTTブローカーはこの場所に完璧にフィットする。
しかし、オフロード戦略の柔軟性を高めるには、メッセージ・シンクを操作するためのコンテキストを把握するルール・エンジンをブローカーが提供する必要がある。MosquittoとNanoMQはどちらも最初の要件を満たすMQTTブローカーだが、NanoMQはMosquittoにはない、組み込みルール・エンジン、オフライン・キャッシング、データ永続化といった素晴らしい機能を提供している。データ永続性とオフライン・キャッシングは、エッジ・アプリケーションがオフライン・モードで実行され、データを安全に保ちたい場合に不可欠です。NanoMQは、ネットワークが復旧した後に送信を再開したり、バックアップ・データベースにフルスケールのデータを永続化することができます。Mosquittoに関しては、ルール・エンジンやプロトコル・プロキシはないが、SQLiteやファイルに対するデータ・キャッシュ機能を提供している。しかし、この機能はシングルスレッド設計のために非常に制限されている。同期ディスク書き込み操作が多すぎると、ブローカはどのメッセージにも応答しなくなる。
さらに、NanoMQには旧来のHTTPベースのアプリケーションと連携しやすいWebhookシステムがあります。既存のサービスをMQTTに変更することなく、エッジ・アーキテクチャを更新する場合に便利です。
NanoMQのルール・エンジンはまだ原始的な段階にあり、一部のSQLしかサポートしていません。それにもかかわらず、NanoMQのルール・エンジンは、まだ違いを生み出すことができます。
相互運用性：ブローカー＋ブローカーレス＋HTTP API
エッジ-クラウド・オーケストレーション
NanoMQはモニタリングやリモート変更を含む豊富なRESTful APIを提供する。Dockerとしてデプロイする際に、環境変数を使ってブローカーを設定することができる。そのため、NanoMQ は Mosquitto と比較してよりクラウドネイティブに優しい。
オールインワン・プロトコル対応
NanoMQはMQTTブローカーであるだけでなく、エッジで有能なメッセージング・バスでもあります。ZeroMQ、DDS、nanomsg/nngもNanoMQの手の内にあります。NanoMQは、ZeroMQ/DDS/SOME-IPメッセージと内部MQTTブローカーをブリッジするスタンドアローンのプロキシ・プラグインを提供します。
相互運用性は、これら2つの人気のあるブローカーが本当に異なる位置づけを示すところである。Mosquittoがクラウドとエッジの両方で軽量MQTTブローカーとして長い歴史を持つプロジェクトであるのに対し、NanoMQは現代のクラウドネイティブ時代に新しく生まれたプロジェクトだ。明らかにNanoMQはオールラウンドな機能を備えたエッジ・コンピューティング分野をターゲットにしているが、MosquittoはシンプルなMQTTブローカーとして迅速にデプロイするための最良の選択肢であることに変わりはない。
新しく登場したアーキテクチャであるUNSに合わせるために、NanoMQは、終わりのないプロトコル変換から解放してくれる、小さいが強力なブローカーを探しているなら、良いスタートとなる。
まとめ
IoTネットワークのデータ取り込みにおいて、MQTTは事実上の標準となっています。そのため、MQTTミドルウェアは、特に以前に広く使用されていたエッジブローカー、Mosquittoなどに対して直接的な挑戦を受けています。しかし、NanoMQは、Mosquittoのマルチスレッド代替品として、これらの問題に対する解決策を提供しています。
NanoMQは、組み込みのActorモデルを実装することで、サイズとパフォーマンスのバランスを見つけました。これにより、競争状態、ブロッキング呼び出し、デッドロック、メモリコピーといった問題を効果的に解決しています。また、NanoMQの革新的なActorモデルにより、マルチスレッドを利用して簡単にスケールアウトでき、メモリ消費量についてはMosquittoと同等のレベルを維持しています。
さらに、NanoMQは、内蔵のルールエンジン、オフラインキャッシュ、データ永続性といった、Mosquittoが持たない強力な機能を提供しています。これらの機能は、エッジコンピューティングのパラダイムシフトに対応するための重要な要素であり、NanoMQはこれらの挑戦を解決するための優れた選択肢となっています。
最後に、NanoMQはまだ開発初期の段階にあり、Mosquittoのような既存のソリューションと比較して、一部の課題が存在します。しかし、その革新的なアプローチと強力な機能により、エッジコンピューティングの新たなパラダイムに対応するための有力な選択肢となっています。