Batch Night

バッチはなるべく作らないようにしている。

10年以上前、月次バッチがこけた。しかも年末にだ。かくして正月早々の稼働となり、最高の1年の幕開けとなった。正確な原因はもう覚えていない。直前のメンテでテーブル構成が変わり、実行計画が狂ってタイムアウト、とかそんな類だったと思う。毎月動いていたのに、ある月だけ壊れる。拾えなかったから正月にリモート稼働だ。顧客説明のおまけ付きで。

バッチは簡単だと思われている。メインのサービスに比べれば小さいし、やることも単純に見える。だから若手に任せがちだ。これが間違いのもとだ。

考慮すべきことを並べてみる。dry runで実行前に結果を確認できるか。途中で落ちたとき、再実行しても二重処理にならないか。べき等性の担保。SIGTERMを受けたときにグレースフルに停止できるか。中断した地点から再開できるか。接続が切れたときのリトライ。ログは何を処理して何をスキップしたか追跡可能か。大量データを扱う塗りつぶし系のバッチなら、対向システムやDBへの負荷を考慮した速度調整が要る。逆にスループットを求めるならマルチスレッドやワーカープール、そしてそれに伴う排他制御が必要になる。

ここまで並べれば、シンプルだから若手に任せようとはならないはずだ。バッチこそシニアが書くべき領域だと思っている。

そしてもうひとつ。バッチが必要になる構成は、対向システムとの連携を除けば、アーキテクチャの問題であることが多い。リアルタイムで処理できるはずのものを、設計の都合でバッチに逃がしている。バッチを書く前に、バッチが不要な設計にできないかをレビューすべきだ。

バッチを減らすのが最良の設計で、バッチを正しく書くのが次善の策で、バッチを若手に投げるのが最悪の判断だ。どのみちトラブルの後始末はシニアの仕事になる。