ダウンタイムなしで VPS を新しい事業者へ移行する

移行の失敗談には、どれも同じ中盤があります。誰かが先に DNS を変え、それからコピーを始めたのです。移行中のダウンタイムがコピーの遅さのせいであることは、ほとんどありません。原因は手順の順番を間違えることです。

ここで紹介するのは、うまくいく順番です。別の事業者から移る場合でも、私たちのプラン同士で移る場合でも同じです。

1. 2 日前：TTL を下げる

変更する DNS レコード（たいていは A、AAAA、それらを指す CNAME）を見つけ、TTL を 300 秒に下げます。そのうえで、少なくとも古い TTL の長さだけ待ちます。TTL が 1 日のレコードは、変更後も一部のリゾルバーが 1 日間古いアドレスを返し続けるということで、サーバー側で何をしても早められません。

これは多くの人が飛ばす手順で、5 分で済むはずの切り替えを、ユーザーの半分が古いサーバーを見ている 1 日に変えてしまうのもこの手順です。

2. 古いサーバーの棚卸しをする

このマシンを別の場所で作り直すのですから、実際に何をしているかを書き出しましょう。覚えていることではなく、実際にしていることです。

ss -tlnp                                # what is listening, and which process
crontab -l; ls /etc/cron.d              # scheduled jobs
systemctl list-timers --all             # the scheduled jobs people forget
systemctl list-units --type=service --state=running

リストにはさらに次も加えます。TLS 証明書とその更新方法、秘密情報を含む環境ファイル、ファイアウォールのルール、ユーザーと SSH 鍵、データベースとそのサイズ、そして IP アドレスでサーバーにアクセスしてくるものすべて。最後のグループが曲者です。取引先の許可リスト、決済事業者の Webhook 設定、監視のチェックなどです。

3. 古いサーバーの隣に新しいサーバーを用意する

新しいサーバーを注文し、古いほうはそのままにしておきます。VPS の一覧 から、契約上の容量ではなく実際の使用量と同じかそれ以上のディスクを持つプランを選びます。古いマシンが少しでも受信トラフィック（ウェブサイト、Webhook、API）を受けているなら、新しいマシンには専用の IPv4 が必要です。NAT プランが受信接続を受け付けるのは SSH ポートだけです。なぜそれが重要かは 転送ポート 1 つでできること、できないこと で説明しています。

接続して同じパッケージを入れ、ユーザーとファイアウォールを作り直します。鍵と最初のログインについては 接続ガイド を参照してください。

4. ファイルを 2 回同期する

1 回目の同期は、古いサーバーが動いている間にすべてをコピーします。何時間かかっても構いません。

rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/

--numeric-ids はファイルの所有者を番号のまま保つので、2 つのシステムでユーザーの作成順が違うときに起きる「すべてが別のユーザーの所有になっている」という定番の事故を防げます。SSH 経由の rsync を使ったことがなければ、VPS へのファイル転送 で手順を追って説明しています。

2 回目の同期は切り替えの直前に行い、1 回目以降に変わった分だけをコピーします。たいてい数秒で終わります。

5. データベースは意識して移す

ファイルは簡単です。書き込みを受けるデータベースだけは、「ダウンタイムなし」に小さな妥協か追加の手間が必要になります。

シンプルな方法：テスト用に一度ダンプして復元しておき、切り替え時に 1 分だけ書き込みを止め（アプリを読み取り専用にするか停止する）、新しいダンプを取って新サーバーで復元し、そこでアプリを起動します。小さなプロジェクトの多くでは、事前に告知した 1〜2 分の停止で済みます。

停止なしの方法：古いデータベースから新しいデータベースへのレプリケーションを組み、追いつかせてから、切り替え時に新しいほうをプライマリに昇格させます。準備は増えますが、1 分の書き込み損失さえ許されない場合には価値があります。

6. ほかの人に見られる前に新サーバーをテストする

DNS はまだ古いサーバーを指しているので、新しいサーバーは誰にも見られずにテストできます。本番ドメインへのリクエストを新しいアドレスに送ります。

curl --resolve example.com:443:203.0.113.10 https://example.com/health

証明書がまだなければ同じ方法で HTTP でテストするか、hosts ファイルに一時的な行を足してブラウザでサイトを一通り確認します。ログイン、アップロード、バックグラウンドジョブ、送信メールをチェックしましょう。足りない PHP 拡張を見つけるなら、このときがいちばん安上がりです。

7. 切り替えて、古いサーバーは動かしたままにする

最後のファイル同期とデータベースの手順を済ませたら、DNS レコードを変更します。TTL が 300 秒なら、トラフィックの大半は数分で移ります。古いサーバーのアクセスログを見ていてください。TTL を無視するリゾルバーやクライアントから、まだ少しずつリクエストが来ます。そのままの状態で数日動かしておきましょう。その後、古い IP を指しているものをすべて更新します。取引先の許可リスト、Webhook の URL、メール用には新しいアドレスの逆引き DNS（私たちの専用 IP プランでは自分で設定できます。逆引き DNS を参照）と SPF レコードです。

よく壊れるもの

私たちが目にする頻度のおおよその順に挙げると、誰もリストに入れていなかった systemd タイマー、古い IP が直書きされた設定ファイル、別のユーザーの所有になってしまったファイル、アプリ自身のポートをふさぐファイアウォール、古いサーバーでは更新されるのに新しいサーバーでは更新されない証明書、そして新しいアドレスに逆引き DNS がまだないために迷惑メール扱いされるメールです。

このチェックリストが合わない場面

書き込みが絶えず、停止を一切許せない忙しいデータベースには、ブログのチェックリストではなく、きちんとしたレプリケーションとリハーサルが必要です。Windows サーバーは rsync とは別のツールで移行します。そして、移行の本当の理由がサイズなら、まずこちらを読んでください。ここではプランをその場で拡大できます。同じネットワーク種別の大きいプランへの変更は、再起動 1 回で vCPU、メモリ、ディスクを増やせて、移行はまったく要りません。新しいサーバーが必要なのは縮小するときだけです。マシンが足りているか自信がなくて移ろうとしているなら、本当に 64 GB のメモリが必要なとき を読めば移行の手間が省けるかもしれません。そもそも VPS が合っているか迷っているなら、VPS・共有ホスティング・専用サーバー・クラウドの比較 が役に立ちます。