たっくさんのリプレース案件をこなしてきたので気づきをまとめておきたい。もちろん、インフラエンジニア目線である。
システム構成は変えていなくても消費メモリーは増える傾向にある
OSやミドルウェアのバージョンアップが主目的であり、上に載せるアプリケーションは変わりません。こんなときは消費CPUや消費メモリーも変わらないよね、と感覚的に思う人が多いだろう。実際動かしてみたら、あれ、メモリーが足りないみたいな現象は起こり得る。これは、OS自体がデフォルトで消費するメモリーの量が増えるからだ。昔のパソコンはメモリー4GBで十分足りていたのに今は16GBないと不安なように、何かとOSが要求する最低メモリーは増える傾向にある。
気持ち、増やしておいた方がいい。
新旧構成が似通うので、とにかく見た目に差をつける
リプレースする前と後で、究極的には全くイコールを作っているわけなので、双子構成になりやすい。ホスト名も同じにしてしまうと本当に危ない。
Linuxならコンソールの色を変える。Windowsなら壁紙の色を変える。いろんな工夫はあるがまずは見た目が大事。
新旧でデータ通信を行うときには方向に注意
データ移行をやるときも、古い方から新しい方へコピーするのが原則だ。方向を誤ってはならない。
新しい方に入って、古い方から新しい方にデータを「プル（引っ張ってくる）」という方法。
古い方に入って、古い方からデータを新しい方にデータを「プッシュ（押し出す）」と言う方法。
頭を整理してクリアな気持ちでやらないと危険なので気を付けよう。
旧環境の停止は、ゆっくりと、確実に
リプレース環境のリリースが完了しました、と。
で、旧環境はもう使わないよね、すぐ廃棄・・はちょっと危険。
まずは電源を停止するタイミングはリリース後少し待った方がいい。
新環境でリリース後に何か問題があり、「あ、移し忘れてた」みたいな時に、すぐに旧環境を廃棄するとどうしようもない。
また、廃棄するとしても、いったん電源を落として様子を見よう。何らかの処理が旧環境で動いているから新環境が安定していたというオチもある。
とうことで、
・リリース後はしばらく旧環境も動かしておく。
・旧環境はしばらくしたらシャットダウンだけする。
・シャットダウン後問題なければ削除する。
こんな段階を踏む必要がある。ゆっくりと、確実に。
実はアプリケーション側が結構変わっていることもあり得る
私はインフラ側担当なので、アプリケーション側がどうなっているかを把握していない。で、何も知らされていないのでアプリケーションも新旧そのままだとばかり思いこむ。ふたを開けてみると結構新機能が中に入っていたりして、そのためにリリース後にいろいろと発生することがあるが、結構焦る。
リリース直後は気が休まらない。
リプレースは簡単じゃない
企業活動って長年続くものだから、最近のプロジェクトってリプレース物は多いんじゃないかな。ここ最近のDX的な案件はそうだな、ここから3年後くらいにまたポツポツでてくるんだろう。最近はアプリケーション構築の生産性が上がったから、システムの数も増殖していると思う。ということは、リプレースのプロジェクトも3年後はもっと多くなりそうだ。
そういえば、ここ最近久しぶりの新規案件をやってるけど、移行しなくていいから気も楽。新規ものだからこそのリスク（新技術や未経験のもの）もあるけど、リプレースの持つリスクは見逃されがちだな。
簡単じゃないから、費用も下げない方がいいよという感想。外から見たら簡単そうにみえるけれど。
