昨日の深夜のサーバリプレースを一人でやりきったpapettoTVです。こんにちわ。
結局、昼過ぎまで落ち着かず、リプレースには魔物が棲んでたということで、もう魔物に襲われないようおまじないを唱えておきます。

リプレースって？

サーバAで動いてたwebサービスをサーバBに移すこと。新規でサービスを公開するのとは違って、既にユーザもいるしコンテンツも貯まった状態でのサーバの切り替えなので、いかにユーザに迷惑をかけずに（＝止める時間を短くするか）が勝負です。

止めずに出来るのがもちろん理想ですが、なかなか難しいところ。

リプレース作業

まずリプレースでやることを大まかに

• リプレースによるサービス一時停止の告知
• リプレース先のサーバ環境構築
• メンテナンス画面作成
• ソースの移行（プログラム、htmlやcss等のコンテンツ、生成されたデータを含む）
• DBサーバの移行
• 動作検証
• DNS切り替え（新サーバで公開）

リプレースによるサービス一時停止の告知

ついついリプレース作業そのもののに集中しがちですが、こちらも大事。
慌てて思い出してバタバタしないように、リプレースの話があがったらまず意識する。

リプレース先のサーバ環境構築

新しいサーバBは何のアクセスも無いので、事前に準備する
可能な限りサーバAと同じ環境（特にソフトウェアのversion）にする

バージョンアップさせたい気持ちは、、、分かる、、、分かるけど、、、ぐっ！！とこらえる。軽い気持ちでversionあげたら、はい、それでメンテ時間延びたー

リプレースの要件等でどうしてもバージョン違いをインストールする場合は、事前に同じ動作できるか要検証サイト全体を見直すつもりで要検証

• httpd.confは同じにした？
• GDは入ってる？jpegだけ抜けてない？実はImageMagic入ってた・・・とか無い？
• APCは？
• DBの文字コード、エンジンは同じにした？
• メールサーバの設定はOK？プログラムとの連携とれてる？

メンテナンス画面作成

サーバBにコンテンツを移して動作検証するまで、コンテンツの更新を止めないとデータの移行が出来ません。その間ユーザはサーバAのメンテナンス画面で耐えてもらいます。
メンテナンス終了時刻も書いておきましょう。安心してまた来てもらうために。（作業側としてはプレッシャーですけどね！

ソースの移行を済ませる

rsync が使えるとパーミションもそのままでコマンド一発で移行完了するので非常に楽。

• remote側の指定が「/」無しで終わってるとそのディレクトリ毎同期する
• sshでremoteサーバに接続するので、事前に鍵認証しておくと、パスワード聞かれないので楽
• ユーザは、元サーバと同じIDになるだけなので、同じ（名前の）ユーザになるとは限らないので注意
• 予め環境構築時にこの辺を意識しておくと吉
• 当然移行後はあらたなソースの更新は、リプレースが終わるまでしない。しないようスケジュールしておく。

さ、ここまではメンテナンス入る前に準備できるので、きっちり確実にすること。
ここでの作業の漏れは、メンテ時間の延長にもろに響くので非常に大事。

ただし、ここからはメンテ中にしかできない作業なので、事前に作業をきっちり詳細まで妄想して分単位でスケジュールを立てて置くこと。

DBサーバの移行

メンテタイムに入ったら、さっさとdumpして突っ込む。

動作検証

• アクセスできた？
• DBの参照・更新・削除できた？
• ログは吐かれてる？
• メールとの連携は問題ない？

一通りチェックして問題が無かったら、、、

DNS切り替え（公開）

無事公開！DNSの切り替えが反映次第リプレースしたサーバにアクセスがくるでしょう。

だがっ！・・・・ここで終わらない・・・・！

• 外部サーバとの連携は問題ない？IPが変わったなら、その影響は？
• 解析ツールは動いてる？
• バッチ処理は？
• ・・・

まだまだ出そうですねw

まとめ

とまあ、ここまでざっくりとした流れでした。
チェック項目を挙げればきりがないほどでちゃいます。
ただ、これからリプレースする前には一読して、今回よりはスムーズに取りかかれればと思って書きました。

もう、昼間からきて準備して次の昼間に作業が終わるとかは嫌ですからねっ！