web2.0 時代のジョブキューサーバー Gearman と TheSchwartz の関係について

■web2.0 時代のジョブ キュー サーバー Gearman と TheSchwartz の関係について

gearman いいよ、と方々で言われている昨今ですが、しかしながら gearman がなんなのかよくわからなかったり、どういう動作をするのかわからなかったり、gearman と TheSchwartz の違いがわからなかったりする方が多いようです。

そのあたりを 6A 以外で brad products を日本一使いこんでると思われる弊社が軽く解説してみようかと。

なぜ JobQueue が必要なのか

１つのプロセスで複数のジョブをやらせようとすると、読み込むライブラリが多くなってしまってプロセスがおおきくなるという問題があります。mod_perl に Imager を読ませると、各プロセスが重くてしかたありません。なので、Imager をロードした画像処理専用サーバーをたちあげたくなります。その役目は Imager 専用 gearman プロセスにやらせればいいでしょう。

cron でプログラムを起動させたいのだが、ライブラリをいっぱいよむので起動に時間がかかるという場合。ライブラリを一通り読ませて常駐させている TheSchwartz の worker に対してジョブを enqueue するだけのプログラムを cron で kick するようにすれば、プロセス起動時間が短縮できて便利。

daemon プロセスを IO 多重化により書いている場合、時間のかかる処理を普通にやると daemon の反応が鈍くなってしまってよくない。そこで gearman の登場だ。gearman 用の socket をつくって job を投げて、そこを監視対象にくわえて様子をみつつ、

socket が readable になったらレスを読み込むという手法により、daemon process が刺さるのを防ぐことができる。

gearman

Gearman は、

Gearman::Client(your application)
gearmand(server. written in perl)
Gearman::Worker(do job)

という３つのパーツから成り立っています。

gearmand はジョブを queue するためのサーバープロセスです。

gearman の Worker は基本的に job を queue されたらすぐに処理してなんらかのレスポンスを返すことが前提になっています。

gearmand がもし万が一落ちたりすると、job がロストする可能性もあるので、job がロストしたら困るような処理には向きません。

gearman を使うパターンのうち重要なユースケースのうちのひとつが Danga::Socket との連携です。Gearman::Client::Async を使うことにより、Danga::Socket の監視対象として gearman の socket を加えつつ、

TheSchwartz

TheSchwartz は RDBMS を job queue サーバーがわりにつかうジョブキューシステムです。

TheSchwartz は

クライアント（your app.)で RDBMS に INSERT する(ジョブの enqueue)
１０秒に一回ぐらい worker プロセスがテーブルをみにきて、ジョブがあればこなす

という仕組みで動いています。

RDBMS に書き込まれるので、データが消えることはほとんどないでしょう。

TheSchwartz のキモは「MySQL は信用できる」というところに尽きます。数年動かしっぱなしにしても動き続ける信頼性を mysql は持っています。そして、web engineer は mysql を熟知しています。そこで、自分で job queue daemon 書くより楽じゃね？という発想が TheSchwartz の根源にあります。（gearmand はときどき落ちるといううわさがありますからね。。。）

仕組み自体が単純なので、気軽に使えるのもメリットです。

欠点は、RDBMS に書き込むというのは非常に遅いということ。そして、worker が随時テーブルをみるという構造上、リアルタイムで結果がほしい場合には使えません。