1. 序章
受託開発会社に在籍していた時のお話です。
退職するメンバーが保守を担当していたシステムを引き継ぐことになりました。
このシステムは、もともと他社が開発・納品したシステムの拡張版開発案件として受託開発したもので、リリース後の保守・運用も請け負っていました。
技術構成はこんな感じです。
- Java
- Tomcat
- Linux
しかし、このメンバーも前担当者(退職済み)から満足な引き継ぎは受けられなかったようで、
お互い不明点も少なくないまま引継していました。
そんな折、デプロイに関して、不可解な注意点を伝えられます。
「warの入れ替えはできません。修正した部分だけをサーバーに反映してください。」
当初は意味が理解できませんでした。
本来ならwar1個の入れ替えで済むのに、ソースファイルを10個修正したら、
10個反映しなくてはなりません。
サーバ構成自体もCATALINA_BASEのwebapps配下にアプリケーションを展開する一般的な手法でした。
にもかかわらず、なぜわざわざそんな面倒なことをしているのか・・・。
理由を尋ねても「前任者のやり方を踏襲している」とのことで、真意は不明のままでした。
2. 本番環境に触れて
システムを引き継いでしばらく経ち、私にも本番環境に修正物を反映する機会がやってきました。
注意のとおり、warの入れ替えはせず、既に展開されているアプリケーションのディレクトリ(以降、appディレクトリとします)に今回の修正物を反映しました。
その際、アプリケーションディレクトリ配下にサーバー上にしかない(バージョン管理に登録されてない)ディレクトリがあることに気づきました(以降、これをfilesディレクトリと呼ぶことにします)。
サーバはこんな状態でした。
webapps
└app.war
└app
└WEB-INF
└META-INF
└files ←これ
中を見るとXMLやHTML、画像ファイルなどが沢山格納されていました。
しかし、設定ファイルやUIで使用しているファイルはちゃんとバージョン管理に登録されています。
これらのファイルの用途は何なのか、気にはなりましたが、一旦スルーしてました。
3. ディレクトリの正体判明、からの絶望と恐怖
そこからさらに時間がたち、これらのファイルの出元と用途が判明しました。
XMLやHTMLはアプリケーションによってアウトプット、画像ファイルはユーザがシステムからアップロードしたものでした。
つまりこれらのファイルはれっきとしたデータであり、それらをアプリケーションの領域へ保存・展開するような構成になっていたのです。
ここまでくれば、冒頭のデプロイに関する不可解な注意の、その真意に気付いた方もいらっしゃると思います。
私もここではじめてその意味に気づきました。
warを入れ替えようとすると・・・?
warを入れ替える際、新しいwarを格納する前に、古いwarおよびtomcatによって展開されたアプリケーションのディレクトリの両方を消すと思います。
では、このシステムでそれをやる(appディレクトリを消す)とどうなるでしょう
webapps
└app.war
└app
└WEB-INF
└META-INF
└files
はい。古いwarによって展開されたappディレクトリを消すと、その配下のfilesディレクトリは消え、アプリケーションがアウトプットしたファイルやら、ユーザがアップロードしたファイルやらも一緒に消えます。
つまり、一部のデータが吹っ飛びます
そんな事態になりようものなら、賠償問題にだってなりかねません。
ディレクトリは消さず、warだけを入れ替えればいいのかもしれませんが、
それはそれで別のトラブルが発生する危険性もあります。
そして何よりの問題点は、このようなデータを一掃してしまうリスクが後任である私に引き継がれなかったことでしょう。
4. リスク回避のための暗中模索
担当になって以降、どうにかしてこの問題を解決できないか、思案しました。
- 保管場所の移設
- シンボリックリンク
- デプロイの自動化
- etc...
しかし、どれも諸々の事情と問題があり、私にできたことといえば、
デプロイの手順書を整備し、先述したリスクを明記して事態を共有することだけでした
5. どうあるべき?
頻繁に作業が発生しうる、あるいは復旧が容易なアプリケーションの領域と、滅多に作業が発生しない、あるいは復旧も困難なデータ領域は物理的・論理的に分離するようにしましょう。
なんらかの制約により、アプリケーション領域にデータ領域が必要な場合は、シンボリックリンクやバインドマウントの利用も有効だと思います。
6. まとめ
このシステムは他にも問題点が多くお守りは大変でした。
しかし、ディレクトリ設計以外にもこのシステムからの学びが多かったことも事実です。
これを読み「問題点の多いシステムを担当していても今後の糧になる」と
考える方が1人でもいたら幸いです。
ここまでお読みいただき、ありがとうございました。