設計段階から関わって、足掛け5年程付き合っていたとあるシステムが、リプレースに伴い、先日稼動停止した。
私が自分で各サーバに停止コマンドを入力した。WEBサーバとAPサーバでtomcatの停止スクリプトを走らせて、DBでインスタンスを停止させて、それでおしまい。周囲はリリースの準備でてんやわんやだったので、多分私だけが、システムを停止させて、画面にそっけなく表示された停止ログを見届けたと思う。
全ての接続が落ちていることを確認して、SQLPlusからshutdown immediateを入力して、それでシステムは完全に稼動を停止した。何故だか、妙に感慨深かった。
ちょっと書き残しておきたくなったので、このシステムについての経緯を書いてみようと思う。細部はぼかす。
5年ほど前、先代のシステムが上手いこと動かなかった為に、突貫工事でリプレースをすることになったのがこのシステムのスタート地点だった。会社のエラい人は、3回くらい連続してシステム発注がうまくいかなかったので、システム開発会社不信になりかけていた(勿論これは、発注側にも失敗するだけの原因があった訳だが)。結局、社内でシステムをフルスクラッチで開発することになり、私は以前の開発チームから引き抜かれる形で今の会社に移ってきた。
開発メンバーは、たったの三人しかいなかった。仕方ないので、徹底した分業体制をとることになった。
リーダーが、Tomcatを使ってWebサーバ・APサーバ及びフロント画面の構築。
サブリーダーが、PHPを使って管理・帳票系アプリの構築。
私が、DB設計とビジネスロジックの構築。当時私は、DB以外のことはあまり分からなかった。あれから5年、DBばかり触っていたので、今でもDB以外のことはあまり分からないような気がする。
先代のシステムは、DBはPostgreSQL、APサーバはLinux + Apache/Tomcatという徹底した安価構成だった。ただ、当時まだPostgreSQLはクラスタリングを上手いこと行うことが出来ず、またパフォーマンス的にもシステム全体のボトルネックになっていたので、そこだけはどうにかしようということでOracleを使うことになった。他のサーバは変わらず安価構成である。
何しろリーダーにもサブリーダーにも余裕が全くなかったので、ビジネスロジックの大半はDBのファンクション・プロシージャで構築して、APサーバーの処理はそこに丸投げすることになった。お蔭で私は100個以上のファンクション・プロシージャを書いた。ビジネスロジックをDBに集中させるのは、ボトルネックもDBに集中することになる、という当然の弊害を生むことになる訳だが、当時はとにかく他の選択肢がなかった。SQLをチューニングさえすれば当該箇所のパフォーマンスが分かりやすく向上する、という点ではいい面もあったと思う。
リリースの前後は三日ほど徹夜した。それでもリリース直後は戦場だった。よく切り抜けられたものだと思う。
それから五年ばかり、私の会社生活の大部分は、このシステムの面倒を見ることに終始していた。途中でシステムのコンセプトは大きく変わって、当初は処理する予定のなかった規模のトランザクションを処理しなくてはならなくなったりもした。なんとかシステムをスケールアウトさせようと、数々の無駄な努力、及びごく一部の有用な努力を積んだ。
ファンクション・プロシージャを徹底的にいじくって、これ以上はもう無理、というところで全然別の解決法を思いついたりもした。思いついた時は「俺って天才じゃね」と考えた解決法を、一年後改めて見直した時は思いついた当時の自分を殴りたくなったりもした。自分が悪いのだが、ドキュメントは不足しっぱなしだった。
エラい苦労もさせられたが、どんな苦労も振り返るだけなら一瞬である。何はともあれ、今の会社の在籍生活の内、95%以上をこのシステムと付き合って過ごしたのは確かだ。
リプレースの二、三週間前、システムの周辺状況の関係から、システムが妙に不安定になったことがあった。二、三日会社泊をすることになり、帰ってから奥様にその話をしたら、笑いながら
「なんだか子供が「寝るのやだー」って駄々こねてるみたいだね」
と言われた。システムを擬人化するのも馬鹿らしいと思うが、何故だかそれで、聊か情が移った。
今、システムはまだ、データセンターのラックマウントサーバ数台の中に眠っている。サーバは再利用することになるか、除却することになるか、まだよく分からない。
何はともあれ、5年間お疲れ様でした、と声をかけてやりたい。そんな風に思った。
2011年08月30日
この記事へのトラックバック
物に魂を込める式の表現がありますけど、その伝でいけば、書いた文字にも魂は宿る。などと夢想できます。なにはともあれ｢ありがとうお疲れ様｣位は書いてあげてもよいなあ。と、思いました。