ということで、Google MapReduceの実装であるHadoopを使ったMapReduceと、JMSを使ったMapReduceをやってみました。
メッセージキューを使って分散MapReduceを実装する
HadoopでのMapReduceを気軽に試すサンプル
これ何のためにやったかというと、そこらにあるような数十台規模のサーバーを前提としたときに、Hadoopの有効性、ひいてはその元になってるGoogle MapReduceの有効性について疑問に思ったからです。そこで、ちょっと試してみた、と。
ここで、メッセージキューを使った場合に1秒でできてた処理が、Hadoopを使うとスタンドアロンモードでも40秒近くかかりました。擬似分散モードだと4分近くです。
いくらHadoopの実装がひどいとしても、これはあんまりです。
Googleでの実装はもっと効率的なものになっていると思いますが、それでも効率は悪くなっているはずです。
Googleでは、数十万台のサーバーでギガバイト単位のデータを多数処理するMapReduceプロセスがたくさん走っています。
数十台のサーバーでギガバイト単位のデータをひとつ処理するMapReduceプロセスを、せいぜい2つか3つ処理している、あなたとは違うんです。
数十台のサーバーを使うときには、どこか1台がネットワークの管理をおこなっても問題ありません。けれども数十万台のサーバーを使う場合には、1台にアクセスを集中させるわけにはいきません。そこで、なんらかのオーバーレイネットワークを構成しておく必要があります。
そのとき、なるべくサーバー台数が増えてもネットワークアクセスが増えない仕組みにする必要があります。要するにO(n)をO(log n)にする工夫が必要になるわけですが、このときのオーバーヘッドが大きくて、ネットワークが大きくなるまで割にあわないということになります。
処理するデータが数GBあったとしても、それが例えばWebサーバーのログだけならば、自分で分割する処理を書くことも可能です。Webサーバーのログは単体で数GBあるわけではなく、数十台のWebサーバーに数十MBずつ、もともと分かれているということも少なくありません。そうすると、わざわざ分散ファイルシステムを組むまでもないということになります。
Googleが分散ファイルシステムを使うのは、サーバーが多数であること、扱うデータが多種類であること、という条件があるからだと思います。
サーバーが故障したり新たに追加したときにネットワーク構成が変わることをchurnといい、どれだけ頻繁なchurnに耐えれるかというのをchurn耐性といいます。
Googleでは数十万のサーバーがあるため、いつもどこかでサーバーが壊れサーバーが追加されています。そこでchurn耐性は重要な要素ということになります。
けどサーバー数十台ならそんなに頻繁に壊れないし、サーバー追加もガスガス行われるわけではないと思うので、大げさなchurn耐性は必要ではありません。
また、これらの条件を満たしたいとしても、用途を限定すれば効率をあげていくことが可能です。Googleでは多数の処理が行われるので、汎用的に使えるMapReduceシステムを構築しているといえます。そのため、Map/Reduce処理のプログラムをそれぞれのワーカーに配布する処理も必要になります。
いくつか話を聞くところでは、Hadoopを使いたい目的、使っている目的は、Webサーバーのログ解析であることがほとんどです。それであれば、Webサーバーのログ解析に特化したMapReduceシステムを組んだほうが、より効率的に処理を行うことができそうです。用途が固定されているのなら、Map/Reduce処理もあらかじめインストールしておくことができます。
要するにGoogleのシステムは、効率は悪いがスケールする仕組みを使っているわけです。スケールしないなら、その仕組みは必要ありません。
ということで、100台程度で使えるWebログ解析に特化したMapReduceフレームワークを作ると、なかなかいいような気がしてきました。
