T

バッチ処理の集中管理

携帯端末向けサイトの管理者Aは悩んでいた。とある携帯キャリアの課金体系ときたらひどい仕様で、入会日から一か月後に入会状態の継続が確定するのだが、他のキャリアのように月初に〆日があるのと違って、特に月末になるといったいいつ継続確定すればいいのかまったくもって判断がつかない。2月28日の翌月って3月28日なのか?翌々月は?1月31日の翌月は?直感で解決できない仕様は悪い仕様である。開発者の悩みは尽きない。

しかし、管理者Aの悩んでいるのは、そんなことではなかった。仕様書を読めばわかる問題なら、散文には慣れている文学部出身のAにはたやすいことだ。過ちを恐れるあまり舌が凍りついたような文面に、ご丁寧にもコピープロテクトまでかかった小癪な仕様書も、彼の読解能力の前には交通安全の標語とさして違いはない。数日の内に、バッチ処理は仕様通りに動作するよう完璧に設計され、実装され、凄まじいテストにも完璧に耐え、crontabの美学に完璧にのっとってスケジューリングされた。開発チームは祝杯をあげ、バッチ処理はもう半年間ずっと問題なく動いている。

だが、問題は起こった。ある朝、彼の携帯電話がけたたましい音を鳴らして気だるい春の空気を切り裂いた。サーバから直接送信されるアラートだ。件名を見ただけで、彼の眠気は吹き飛んだ。完璧な上にも完璧な例のバッチ処理が動作していないのだ。ユーザ情報の集計処理は来るはずのデータを待ちながら悲鳴を上げている。そんな馬鹿な!完璧なことピンポン玉のごときあのバッチ処理が失敗するなんて!

会社のサーバに繋がる秘密の端末からキーを叩く彼は驚愕した。完璧なバッチは完璧なまでに詳細な実行ログを残すことになっている。しかし、ログは一切残っていない!どういうことだ!crontabは変更されていない。プログラムに手を加えられた形跡もない。

ふと、管理者Aは/var/log/cronを覗いてみたい誘惑に駆られた。そして、恐る恐るコマンドを叩き、犬にしか聞こえない周波数帯で悲鳴を上げた。

$ sudo grep "perfectBatch.sh" /var/log/cron | grep $USER \
awk '{print $1 " " $2 " " $3 " " substr($8, 2)}'
password:
.............
Mar 22 04:00:00 /usr/local/bin/perfectBatch.sh
Mar 23 04:00:00 /usr/local/bin/perfectBatch.sh
Mar 24 04:00:00 /usr/local/bin/perfectBatch.sh
Mar 26 04:00:00 /usr/local/bin/perfectBatch.sh
............

ない!ない!25日がない!

完璧なバッチは、完璧に作られ、完璧に設定されている。しかし、まさかcronに無視されるとは誰も思っていなかった。死すべき定めの人間の現実は、そんな思いを平気で踏みにじるのか。管理者Aは、ふと故郷の景色を思い出した。

と。

まあ、そんなわけで、割と負荷の高いサーバを運用した経験のある人なら、cronが実行されなかったのであわてたことがある人も結構いると思う。かくいう筆者も同じで、原因を調査してもこれといって手がかりもなく困り果てていた。1台や2台のサーバならなんとか確認して運用することもできるが、100台にもなるとそうはいかない。

そこで、cronはそもそもちゃんと動かないという前提で、確認の手間を省くことでなんとかならないかと考えることにした。思いついた方法は2つで、

(1) サーバ内に問題検知エージェントが稼働している
(2) 全てのバッチ処理は完了通知をリモートサーバに投げる

1の場合、エージェントの稼働を監視する方法がないので、結局同じことになる。2の場合、どこかに集中管理用サーバを用意して、いつどのサーバからどんな通知がこないといけないかをデータとして保持したアプリケーションが通知を受け付け、問題を検知する。この場合、集中管理サーバだけ確認しておけばいいので運用は簡単だ。バッチ処理の側に終了通知を投げる機能の追加が必要だが、これから作るものに適用していって、うまくいくようなら全部のマシンのバッチ処理に適用すればいい。

そんなわけで、バッチ処理の集中管理システムというものを作ってみたくなったのだが、そもそもこの手の問題にはみんなどうやって対応しているのだろうか。もっといい知恵があれば知りたいし、そんなのとっくにあるよという方がいれば教えてほしい。キモは、cronが無視するタスクの検知だ。

Posted by on 3月 24, 2009 in Linux, Work

コメントを残す