ページ

2011年2月2日

RabbitMQのクライアントのfailover対応はどうなっているのか?

今年はうさぎ年なので、RabbitMQで遊んでいる今日この頃です。RabbitMQ自体は、クラスタリングに対応していて、クラスタ内でメッセージをルーティングして配信してくれます。ただ、AMQPのプロトコル自体にはクラスタについていの規定はありません。AMQPを利用しているサーバなりクライアントなりが独自に実装すべきもののようです。クライアントの実装としてJavaとPythonでは若干状況は異なる(開発元が違う)のですが、そのメモ。

まず、Pythonです。Pythonはamqlibを使っています。AMQPを利用しているサーバに対して使えます。でも、接続先は一つだけです。接続先が落ちている場合はつながりません。その場合、接続先を自分で列挙して順番にトライするようです。最初の接続先はそれで十分だと思いますが、実行途中でサーバがダウンした場合は、自動で他のサーバを見つけてくれたりはしません。サンプルコードのようにしか見えませんが、その辺を透過的に扱おうとしているのが、このコードです。つまり、failoverのことはクライアントでがんばれ、と。

Javaの場合は、rabbitmq.comからJavaのクライアントが提供されています。最初の接続については、複数のAddressを渡して順番に接続を試みることができるので、Pythonよりはよくできています。でも、一旦接続が確立すると、それだけを使い続けます。途中でサーバがダウンしたら、また最初からやり直しです。残念ながrこのあたりはPythonと大差ありません。AMQPのクライアントライブラリじゃなくってRabbitMQのクライアントライブラリなので期待しましたが、残念ですね。

ざっとメーリングリスト(あと、これ?)を読んだ限りでは、このあたりの事情は2008年頃からあまり変化がないようです。MSラブなのにWindowsのことは僕はよく分かりませんが、LinuxではVirtual IPを使えばいいんじゃない、と書いてあったりもします。それもソリューションの一つかもしれませんが、ちょっと敷居が高いです。
たとえばAPサーバが6台あれば、6台すべてにRabbitMQを入れてクラスタ化して、各APはlocalhostのMQを見るとかっていうのは現実的なんだろうか?これだと、failしても影響を局所化できそうですが、それ以外のコストが上がりそうです。

サーバの実装に比べてクライアントの実装がちょっと薄すぎるような気がします。まあ、failoverできれば何でもいいんですが。

0 件のコメント: