WEBシステムのリプレイスロードマップ

最近PHPのWEBシステムを触っていたり、Railsを触っているのですが、PHPを書く楽しさをわかりつつも、やっぱりRails素晴らしいなーなんて感じている毎日です。
またPHPは古いコードが多く、何か手を入れる度にリファクタリングしたりで無駄な工数がかさんでいるという課題が有ります。
同僚と飯食いながら

「PHP捨ててRailsに乗り換えたいっすねー」

なんていいながらも話が大きすぎたり、枯れたストックビジネスという背景があってなかなか腰が重いです。
ただこのままグダグダやっていても、10年後も平気でこのままという事も起こりえるのでちょっと考えていました。
大きく分けて3ステップあると思っています。

現状

\"現状\"
左の赤い鯖がRails、右の黄色がレガシーPHPなシステムです。
nginxやDBの構成は若干妄想ですが、まあ普通に組んだらこんな感じでしょう。
ここで問題なのは、セッションファイルを各々のサーバで持っているので、極めて移行が難しい状況にあります。

STEP1 セッションファイルの共有

\"STEP1\"
まずはSTEP1として、セッションファイルをDBに持って行き、各々のシステムで_SESSION[\"hoge\"]とかsession[:hoge]とやっている部分を、SESSINSTANCE[\”hoge\”]みたいな感じで一つクラス拵えて、DBにアクセスする手段を作るというのが必要。

STEP2 コンテンツの移行

\"STEP2\"
STEP2はセッション情報がシステム間で共有できるようになるのでcookieベースでセッションを紐付けて、各々のシステムがインターネットから見て透過的にアクセス出来るようにします。
後はコンテンツを移行して、移行が終わったコンテンツはnginxのURLベースで振り分け先を変えていくのが良いと思います。
この構成の利点は切り戻しが非常に簡単にやれるので、何かあれば旧システムへ!という事が可能です。

STEP3 さよなら旧システム

\"STEP3\"
必要なコンテンツの移行が終わったらいよいよ旧システムの切り離し。
このタイミングは実際は移行が全て終わるとURLは全てRails側に向くのでいつの間にかSTEP3というのが理想ですね。

まとめ

この手の話の一番大事なのって何かあった時にすぐ戻せることなので、それを全てLBで一元管理できるは非常に魅力的だなと思っています。
一番問題になりそうなのはSTEP1で、セッションアクセス不可!何度もログインさせられる!お客様お怒り!なんてパターンが一番起こりえるのでここは技術的検証しっかり取りたいですよね。
いやー、ペパボ楽しいわ。
おやすみなさい。

Comments are closed.