PostRank の創立者で CTO である Ilya Grigorik 氏が 先週，ZeroMQ の紹介記事を書いている。
バークレーソケット(BSD)は，すべてのネットワーク通信のデファクト API です。1980年代始めに起源を持ち， TCP/IP スィートのオリジナル実装でもあった BSD ソケットが，今日すべてのオペレーティングシステムにおいて，最も広くサポートされている重要なコンポーネントであることは間違いないでしょう。BSD ソケットを使った通信として一般的なのはピアツーピア接続ですが，これには明示的なセットアップとティアダウン，トランスポート(TCP, UDP) の選択，エラー処理などが必要になります。問題がすべて解決すると，次に待ち受けるのがアプリケーションプロトコル (HTTPなど) の世界です。そこではさらにフレーム処理やバッファ処理，処理ロジックなどが必要です。要するに高性能なネットワークアプリケーションを書くのは，退屈な作業以外のなにものでもないのです。
さらに，
異なったソケットタイプ，接続処理，フレーミング，さらにはルーティングといった低レベルな詳細事項を，いくらかでも抽象化できたら素晴らしいとは思わないでしょうか？ ZeroMQ (ØMQ/ZMQ) ネットワークライブラリは，まさにそのためのものです。"このライブラリはメッセージ全体をインプロセスや IPC，TCP，マルチキャストなど，さまざまなトランスポートを越えて送信できるソケットを提供します。ファンアウト，PubSub，タスク分散，要求/応答などのパターンによる N 対 N の接続が，ソケットを使って可能になるのです。"
ØMQ はネットワークスタックにおける新たなレイヤ - スケーラビリティレイヤなのです。分散型システムの負荷拡散を行うことによって，非常に大規模なアプリケーションでもサポート可能にします。単純なポイントツーポイント通信に代わり，分散システム全体のトポロジを定義します。ØMQ のアプリケーションはロックのない並列性を持ち，任意の数のスレッド，コア，マシンに柔軟に対応します。
ZeroMQ はコミュニティによって主導されている。
ØMQ (別名 ZeroMQ あるいは 0MQ) をフリーソフトウェアとして開発するために，数多く[の人々] が３年間に及ぶ作業を続けてきました。
Ilya の説明によると，
- ZeroMQ の通信はメッセージ指向であり，アプリケーション毎に繰り返される日常的，定型的な複雑性の多くを隠します。例えばクライアントソケットから 150kb のメッセージを送信したとき，サーバソケットが明示的なバッファリングやフレーミングをしなくても完全に同一のメッセージを受信できるのです。
- ZeroMQ のソケットでは，トランスポートについても認識する必要がありません。すべてのプロトコル上でメッセージを送信ないし受信するための，ひとつに統合された API が存在しているからです。デフォルトではインプロセス，IPC，マルチキャスト，TCP をサポートしています。切り替えには単に，接続文字列のプレフィックスを変更するだけです。
- ZeroMQ ソケットは，ルーティングとネットワークトポロジを認識します。ピアツーピア接続状態を明示的に管理する必要がない - 前述のようにすべてライブラリが抽象化しているので - ため，インバウンドを listen するために２つの異なるポートへバインドしても，あるいは逆に一度の API コールで２つの異なるソケットにデータを送信しても，問題となるものは何もありません。
さらに，
ZeroMQ の通信は，デフォルトではすべて非同期形式で実行されます。この非同期処理モデルが通信の確立と開放，再接続ロジックをすべて抽象化するとともに，メッセージ配信レイテンシ(待ち時間)の最小化を実現します。ブロッキングがないということは，メッセージのディスパッチや配信，キュー処理 (送信側，受信側とも) と，アプリケーションの通常処理が並列的に実行される，ということです。もちろん使用されるメモリの上限や，さらにはソケットごとのスワップサイズを設定して ZeroMQ ソケットのキュー動作をコントロールすることも可能です。これによって，必要ならばブロッキング API をシミュレートすることも可能ですが，デフォルトは非同期 I/O なのです。
Mongrel2 は ZeroMQ を採用した Web サーバである。Ilya の説明によれば，
Mongrel2 は，ZeqoMQ の Web サーバへの適用に関する興味深いケーススタディを提供します。インバウンド要求はすべて Mongrel2 によって，要求を自動的にロードバランスする "Push" ソケット経由で複数の接続済ハンドラへルートされます。ハンドラは (Pull ソケット経由で) 到着した要求を順次処理して，その内容を "Pub" ソケットに発行(Publish)します。Pub ソケットには Mongrel2 サーバ自身が登録(subscribe) されていて，そのプロセスIDに対する要求を (トピックフィルタを通じて) listen しているのです。
ZeroMQ の Web サイトでは，他の通信機構との比較が簡潔に紹介されている。
- TCP のようなバイトストリームではなく，メッセージベースであり，メッセージパターンに基いています。
- XMPP よりもシンプルで高速，かつ低レベルな処理が可能です。Jabber も ØMQ 上で実現できています。
- 同じ処理を AMQP より100 倍高速に実行できる上に，ブローカが不要です (仕様書も 278 ページ少ないのです)。
- IPC のように単一マシン上だけではなく，複数の機器にわたる抽象化を行います。
- CORBA のように，恐ろしいほど複雑なメッセージ形式をユーザに強要しません。
- RPCと違って ØMQ は完全に非同期です。また，機器をいつでも追加・削除できます。
- RFC 1149 よりはるかに高速です！
- 29west LBM とは違ってフリーソフトウェアです！
- IBM Low-latency とは違ってフリーソフトウェアです！
- Tibco とは違って，いまでもフリーソフトウェアです！
Ilya の結論は，
ZeroMQ は野心的なプロジェクトです。この短い文章で紹介したのが，機能全体のごく一部分でしかないことは言うまでもありません。ZeroMQ の目標は，"標準ネットワークスタックの一部となること，さらには Linux カーネルの一部となること" なのです。これが成功するかどうかは未知数ですが，"伝統的な" BSD ソケット上の抽象化レイヤとして非常に有望で，多くの人々に望まれているものであることに疑いはありません。ZeroMQ は高性能ネットワークアプリケーションの開発を，信じられないほどに容易で，楽しいものにするのです。
Antonio Garrote 氏も Ilya に賛同する。
ZeroMQ は非常に強力です。高速で効率がよいだけでなく，どのようなアプリケーションにおいても，ネットワーク層の設計を大いに簡略化してくれるのです。さらに異なる状況においても，同じ通信パターンの再利用を可能にします。それにもかかわらず ZeroMQ は，私の意見では，RabbitMQ などのキューシステムに対する当面の置き換え手段というよりも，それを補完するものとみなすこともできるのです。他のソフトウェアシステムと同じように，アプリケーションの要件を注意して見ることで，解決すべき問題に対してどのような通信機構がより適当であるか明確になります。
ZeroMQ を使用している，あなたの見解はどうだろう？