乗り換えのサインになる4つの症状

共用レンタルサーバーからVPSへ移る理由は、性能不足だけではない。判断材料になる症状は大きく4つある。継続的に起きているものがひとつでもあるなら、検討する価値がある。逆に、どれにも当てはまらないなら移行の必要はない。

リソース制限に繰り返し当たる

共用サーバーには、同時接続数、CPU時間、メモリ、プロセス数の上限が契約ごとに設定されている。上限を超えると、503エラーが返る、管理画面の応答が極端に遅くなる、cron（定時実行）が途中で止まる、といった形で表面化する。多くの事業者は管理画面にリソース使用量のグラフを用意しているので、まずそこを確認してほしい。ピーク時だけ上限に触れているなら、上位プランへの変更で足りる。平常時から上限付近で張り付いているなら、プラン変更をしても早晩同じ状況になる。

使いたいソフトウェアが制約に引っかかる

常駐プロセスを動かせない、Dockerが使えない、Node.jsやGoのアプリを置けない、Redisのようなミドルウェアを追加できない、PHPやデータベースのバージョンを自分で選べない。これらは性能の問題ではないため、上位プランに移っても解決しない。VPSへ移す最も明確な理由がここにある。

デプロイと運用が手作業から抜けられない

更新のたびにFTPでファイルをアップロードしている、GitHubへのpushをきっかけに自動デプロイしたいがSSHが使えない、本番と同じ構成の検証環境を用意できない。こうした状態は、サイトの規模が小さいうちは我慢できるが、更新頻度が上がると事故の温床になる。root権限（システム全体を変更できる管理者権限）があれば、デプロイの自動化も検証環境の複製も自分の裁量で組める。

同居する他の利用者の影響を受ける

共用サーバーは1台を複数の契約者で分け合う仕組みのため、他の契約者の負荷で自分のサイトが遅くなることがある。自分側に原因がないので、調査しても打つ手がない。頻度が低ければ許容できるが、売上や問い合わせに影響する頻度で起きるなら、リソースが独立して割り当てられるVPSに移す根拠になる。

乗り換えないほうがよいケース

VPSは共用サーバーの上位互換ではない。事業者が引き受けていた作業が、そのまま自分の担当に移る取引である。次の状況では、移行しない判断のほうが妥当になりやすい。

第一に、保守に時間を割けない場合。VPSではOSのセキュリティ更新、SSHの鍵認証設定、ファイアウォールの調整、バックアップの取得と復旧確認、TLS証明書の更新監視が自分の作業になる。最低でも月1時間程度、加えて障害時にはその場で対応する必要がある。この時間を確保できないなら、放置されたVPSは共用サーバーより危険な状態になる。

第二に、WordPress中心のサイトで月間数万ページビュー程度に収まっている場合。PHPとMySQLの構成は共用サーバーが最も得意とする領域で、自動バックアップやWAF（不正な通信を遮断する仕組み）が標準で付くことも多い。移行しても得られるものが少ない。

第三に、独自ドメインのメールが業務の中心にある場合。メールサーバーを自前で運用すると、迷惑メール判定を避けるためのSPF・DKIM・DMARCの設定、IPレピュテーションの管理、スパム対策が継続的な負担になる。この場合はWebサイトだけをVPSに移し、メールは共用サーバーの契約かメール専業サービスに残す構成が現実的である。

第四に、大きな改修を控えている場合。移行とアプリケーションの改修を同時に進めると、不具合が出たときに原因がどちらにあるか切り分けられない。どちらかを先に終わらせる。

移行作業の全体像

1. 現状の棚卸し

最初にやるのは調査で、構築ではない。移すべきものを一覧にする。ドメインと現在のDNSレコード、PHPのバージョン、データベースの種類・バージョン・文字コード、cronの登録内容、TLS証明書の取得方法、メールアカウント、外部サービスに登録済みのIPアドレス制限。DNSレコードはdig example.com A +shortやdig example.com MX +shortで確認できる。ここで漏らしたものが、切り替え後の障害になる。

2. VPSの構築

OSを入れ、SSHを公開鍵認証に切り替え、ファイアウォールで必要なポートだけ開け、Webサーバーとアプリケーションの実行環境を用意する。原則として、旧サーバーとミドルウェアのバージョンを揃えるところから始める。PHP 7系から8系のようなバージョン差は、移行と同時ではなく、移行が完了して安定してから上げるほうが切り分けが楽になる。

3. データの移送

ファイルはrsyncで転送する。旧サーバーでSSHが使えるならrsync -avz -e ssh ./public_html/ user@vps-host:/var/www/example.com/のように直接送れる。SSHが使えない共用サーバーでは、FTPで一度手元に落としてからVPSへ送る。データベースはmysqldump -u user -p --single-transaction --default-character-set=utf8mb4 dbname > dump.sqlのようにダンプする。管理画面しか使えない場合はphpMyAdminのエクスポート機能で代替できる。文字コードの指定を誤ると日本語が壊れるので、旧環境の設定を確認してから実行する。

4. DNSを切り替える前の動作確認

ここが移行の成否を分ける。手元のPCのhostsファイルにVPSのIPアドレスとドメイン名を書けば、自分だけがVPS側を本番ドメインで開ける。macOSとLinuxでは/etc/hosts、WindowsではSystem32配下の同名ファイルにある。この状態で、トップページだけでなく、ログイン、フォーム送信、画像アップロード、決済のテスト、管理画面の動作まで一通り確認する。

TLS証明書には注意点がある。Let's Encryptの標準的な認証方式（HTTP-01）は、ドメインがまだ旧サーバーを向いている間は使えない。DNSレコードで所有を証明するDNS-01方式を使えば、切り替え前に証明書を取得できる。この準備をしておかないと、DNS切り替え直後に証明書エラーが表示される時間が生まれる。

5. DNSの切り替えと旧サーバーの停止

AレコードをVPSのIPアドレスに変更する。MXレコードやSPFのTXTレコードを一緒に書き換えてしまう事故が多いので、メールを移さないなら触らない。切り替え後は、アクセスログでVPSにリクエストが届いていること、エラーログに異常がないことを確認する。

ダウンタイムを抑える段取り

ダウンタイムの正体は、DNSの伝播待ちではなく、データの二重管理である。DNSが切り替わる途中では、一部の利用者が旧サーバー、残りがVPSにアクセスする時間帯が必ず発生する。この間に旧サーバー側で書き込みが起きると、そのデータは移行先に存在しないまま失われる。

手順としては、まず切り替えの48時間以上前に、対象レコードのTTL（DNSの情報がキャッシュされる秒数）を300秒程度まで短くしておく。TTLの変更自体が、変更前の値の分だけ浸透に時間を要するためである。次に、余裕のある時間帯にファイルとデータベースの初回同期を済ませておく。

切り替え当日は、サイトをメンテナンスモードにして書き込みを止め、その状態で差分だけを再同期する。データベースを取り直し、VPSへ流し込み、hostsファイルで最終確認をしてからDNSを変更する。書き込みを止めている時間だけが実質的なダウンタイムになり、規模にもよるが十数分から30分程度に収まることが多い。更新のない静的サイトなら、書き込みを止める必要がないため、体感上のダウンタイムはほぼゼロにできる。

切り替え後、旧サーバーはすぐに解約しない。最低1週間、できれば2週間は起動したまま残す。キャッシュが残っている利用者や、TTLを無視するリゾルバ経由のアクセスが旧サーバーに届き続けるためで、ここで旧サーバーを止めるとその利用者にはエラーが表示される。旧サーバーを残したまま、アクセスログにリクエストが来なくなったことを確認してから解約する。

移行を決める前に確認すること

ここまでの内容は、移行の判断が済んでいる前提の作業である。判断そのものに迷っているなら、確認すべきことは2つに絞られる。ひとつは、いま起きている問題が上位プランで解決するかどうか。リソース不足だけが理由なら、まずプラン変更を試すほうが安く速い。もうひとつは、月1時間の保守時間を今後も継続して確保できるかどうか。確保できないなら、移行しても運用が破綻する。

両方を確認したうえで結論が出ないなら、時間課金のVPSを1台借りて、本番と同じ構成を組んでみるとよい。DNSを切り替えなければ本番に影響はなく、構築にかかった実時間と、自分が詰まった箇所が、そのまま判断材料になる。数百円で得られる情報としては割がよい。