技術めも

どうも「バッチサーバ」というのが好きでない。

 

WEB系をやっていると、WEBサーバ（APサーバも含む）とは別に、

バッチサーバなるものを用意するケースがあるが、

これって実はあんまりいらないと思っている。

（というか、外したいと思っている）

 

確かに、WEBサーバ側の負荷と切り離して考えられるメリットもある。

しかし、自分にとってはリソースを有効活用できていない感がある。。

 

最近では、

スクリプト言語でも、WEBサーバ内にバッチ処理用のソースコードを持つことが多々ある。

これは、どのサーバでも代替実行が出来るようにするという狙いからのものであるが、

実際はWEBサーバは複数あるケースが多く、

夜間などのアクセスが少ない時間帯で、

複数サーバで、一気にバッチを実行してしまうほうが処理が速く終わってよいと思う。

 

javaなんかでは、APサーバ内の1スレッドとして、

バッチ処理を動かすケースなんかもあるだろう。

 

ということで、こんな風にできたらいいなと思うバッチ処理をまとめてみる。

• WEBサーバ（APサーバも含む）の1スレッドとしてバッチが実行できる
• 手動でも実行できる
• 同一のバッチが複数サーバで動いて欲しくないケースは排他制御をかける
• 空いているリソースを見つけて分散できる
• さらに、実行結果を1か所で確認できる

という感じ。

 

zookeeperなどの組み合わせることで、

上記を実現できるが、

インフラがやや複雑になり、プログラマーの管理ではなかなか厳しい。。

 

javaではcron4jなどがあったり、

nodeではcronのモジュールがあったりするので、

上手いことスレッドとして、組み込みつつ、

外側からも実行可能で、分散的に、必要あらば排他的に、

そして、出来るだけ簡素に。

そんなバッチが組めるような仕組みを考えてみたい。