このページに書いてあること
システム全面刷新などで移行するときに、リリースしたシステムに対してネットワークを切り替えていくと思いますが、その時の方式について備忘メモ。
別に何が優れてるとかいう話はないです。
前提
- Webアプリが3個あるシステム(例として3個なだけで、通常は50とか100とかある)
- 最終的には3個のシステムを入れ替える
- DBは既存のものを使う
- 既存アプリは自前のDNSを使用して名前解決
以下のようなシステムがあって、システムをリプレースしていくようなパターンです。
DNSで名前解決をしていますから、新システムのIPアドレスは関係ありません。DNSへの設定でアクセスできます。
この時、システムを入れ替えていく方式として、ビッグバン方式と拡張方式が考えられます。
ビッグバン方式
全てのシステムを一気に入れ替える方法です。
移行先のアプリを隣に全て稼働させて、リリースタイミングでDNS設定を切り替えて全システムを一気に移行します。
こんな感じで新システムを全部横にリリースした上で、移行のタイミングを待ちます。
全システムをリリースしたら、DNSの設定を変更してIPアドレスを新システムにものに切り替えます。
で、この設定を移行のタイミングで発動するように時間指定してやれば、ビッグバン方式で移行完了です！
メリット
- 基本的に、ユーザーはアクセスするURLはシステム移行前後で変更しなくて済む。
- 既存システム間でURLアクセスしている場合、各システム側の変更は不要。
- DNSの変更だけで移行が完了する。
デメリット
- 移行システムが多い場合、全てのシステムをリリースするまで移行できないため期間がかかる。
拡張方式
リリースの完了したものから順次移行していく方法です。
準備できたものから移行していき、期間をかけて全システムを移行します。
リリースしたシステムから順次移行をします。移行時には旧システムと新システムを同時に稼働させる場合が多いようです。
こんな感じで、順次移行していきます。
メリット
- 個別に移行していくため、重要なものから順次移行していくことで高速に移行ができる。
デメリット
- 移行に際しては新URLを案内して一定の移行期間を設けて並行稼働する必要があるため、運用負荷が高まる。
- ユーザーへの案内が移行回数分発生する。
- 全システムの新URLを用意する必要がある。
※もちろん、旧URLのまま移行してもいい。
各方式こんな感じでしょうか。
ポイントになるのは、移行に際しての期間でしょうか。
移行までの余裕がある場合はビックバン方式、運用の負荷が高くても順次高速に移行していきたければ拡張方式ということでどうでしょう。
