サーバー移行のダウンタイムを最小限にする方法とDNS切り替え時の注意点

このページでは、サーバー移行時のダウンタイムをできるだけ減らす方法と、DNS切り替えの考え方を初心者向けに解説します。ここでいう「ダウンタイムを最小限にする」とは、完全にゼロになることを保証するものではなく、事前準備と確認によってサイトが見られない時間や不整合のリスクを小さくすることです。

サイトが見られなくなる原因 ダウンタイムはなぜ起きる

移行時にサイトが見られなくなる原因は、DNSだけではありません。新サーバー側のWebサーバー設定、データベース、HTTPS証明書、外部サービス連携などが十分に準備できていない状態でアクセス先を切り替えると、表示エラーやフォーム送信の失敗が起こります。

DNSを変更した場合は、利用者の端末が問い合わせる再帰DNSサーバーに以前の回答がキャッシュされているため、しばらく旧サーバーへアクセスする人と新サーバーへアクセスする人が混在します。これは「DNSが世界中へ一斉に反映されるまで待つ」というより、主にキャッシュが有効期限を迎えるまで旧情報が使われる仕組みによるものです。

なお、一般に「DNS切り替え」と呼ばれる作業には、既存のDNS管理サービスでAレコード・AAAAレコード・CNAMEレコードなどを更新する作業と、ドメイン管理会社でネームサーバーを変更してDNS事業者そのものを切り替える作業があります。後者はDNSゾーンの委任先を変える別の工程です。Webサーバーだけを移す場合は、DNS事業者を変えずに接続先レコードだけを更新できるなら、その方が確認する項目を減らしやすくなります。

ダウンタイムを最小限にする基本戦略

基本は、DNSを変更する前に、新サーバーを本番同様に動く状態まで準備し、切り替え後も旧サーバーをすぐには止めないことです。DNSの更新は、準備が済んだ環境へ利用者を案内する最後の工程と考えると、作業の順番を間違えにくくなります。

ただし、問い合わせフォーム、会員登録、ECサイトの注文、コメント投稿など、利用者がデータを書き込むサイトでは注意が必要です。新旧サーバーを同時に公開するだけでは、どちらか一方にだけ新しいデータが入るおそれがあります。データベースの最終同期、切り替え中の書き込み停止、または複製構成のいずれで整合性を守るかを、DNS変更の前に決めてください。本番と同期した環境を作り、準備後に切り替える方式は、データベース移行でも用いられます。

方法①：切り替え前に新サーバーで完全に動作確認する

DNSを切り替える前に、新サーバーへサイトのデータ、プログラム、設定ファイル、データベースを配置し、実際の公開URLで確認できる状態にします。自分の端末だけ一時的にhosts設定でドメイン名と新サーバーのIPアドレスを対応付ける方法や、サーバー会社が用意する一時URL・プレビュー機能を使うと、公開DNSを変える前に確認できます。

確認時はトップページだけでなく、主要ページ、画像・CSS・JavaScript、検索、ログイン、フォーム送信、管理画面、定期処理、メール送信、リダイレクトを確認しましょう。CDN、WAF、外部ストレージ、決済、アクセス解析、Webhookなどを使っている場合は、新サーバーのIPアドレスや送信元を許可する設定が必要になることがあります。

HTTPSを使うサイトでは、証明書が対象のドメイン名に対応していること、証明書チェーンに問題がないこと、HTTPからHTTPSへの転送が想定どおりに動くことも新サーバーで確認します。証明書を新規発行する場合、認証局によってはDNSレコードまたはHTTP上のファイルでドメインの管理権限を検証します。切り替え直前に証明書取得を始めるのではなく、余裕を持って準備してください。

方法②：DNSのTTLを事前に短くしておく

TTL（Time To Live）は、DNSレコードの回答を再帰DNSサーバーなどがキャッシュしてよい時間を秒数で表す値です。TTLが長いほどDNS問い合わせを減らせますが、レコード更新後も古い回答が使われる期間が長くなります。

移行前には、Webサイトの接続先に使うAレコード・AAAAレコード・CNAMEレコードのTTLを、DNS管理画面の「DNSレコード」または「レコード管理」で一時的に短くします。300秒はよく使われる例ですが、選べる最小値や「Auto」の扱いはDNS事業者、契約プラン、プロキシの有無で異なります。たとえばCloudflareでは、プロキシ対象レコードのAutoは300秒で編集できず、DNS onlyレコードの下限もプランによって異なります。

TTLを短くした直後に切り替えてはいけない

重要なのは、TTLを短くした直後に切り替えないことです。すでに旧TTLでキャッシュされた回答は、TTLを下げてもすぐには短くなりません。たとえば変更前のTTLが86400秒なら、短縮設定を公開した後、少なくとも変更前のTTL相当の時間は待ってからIPアドレスなどを切り替える必要があります。AWSも、使用中のドメインやサブドメインの設定を変えるときは、まず300秒など短いTTLを設定し、正しい設定を確認してからTTLを上げる方法を案内しています。

ネームサーバーを変更する場合は、Web用のA／AAAA／CNAMEだけでなく、MX、TXT、CAAなども新しいDNSゾーンに正確に用意してから委任先を変えます。DNSゾーンには種類の異なるリソースレコードが含まれ、親ゾーンのNSレコードによってどの権威DNSサーバーへ問い合わせるかが決まるためです。

方法③：新旧サーバーを並行運用する

DNSのキャッシュが残る間は、旧サーバーと新サーバーのどちらにアクセスしても、サイトが表示できる状態を保ちます。静的なサイトであれば、新旧環境に同じファイルを配置しておく方法が比較的取りやすいでしょう。

一方で、更新のあるサイトでは「両方を動かす」だけでは不十分です。移行直前に旧サーバーのデータを最終同期し、切り替えの間は投稿・注文・会員登録などの書き込みを短時間停止する、または新旧環境でデータを同期する仕組みを使う必要があります。確認なく旧サーバーと新サーバーの両方へ書き込みを受け付けると、データの欠落や重複につながります。

旧サーバーは、切り替え直後に停止・解約しないでください。少なくとも旧TTLで残り得るアクセスと、サイトのログ、エラー、メール送受信、定期処理を確認できる期間を確保します。新しいサブドメインを追加する場合は、「存在しない」というDNS応答もキャッシュされ得るため、必要なDNSレコードは切り替えより前に作成・確認しておくと安全です。（出典：RFC 2308）

方法④：アクセスの少ない時間帯に切り替える

十分に準備していても、接続先の混在、利用者側のキャッシュ、外部サービスの制約などを完全に予測することはできません。アクセス解析で利用者が少ない時間帯を確認し、その時間に切り替えると、問題が起きた場合の影響を抑えやすくなります。

作業前には、変更するレコードの現在値、新サーバーのIPアドレス、戻し方、連絡先を記録しておきましょう。障害時は慌てて別の変更を重ねるより、あらかじめ決めた手順でDNSレコードを旧サーバーへ戻せるようにしておくことが重要です。

DNS切り替えのコツまとめ

• DNSを変更する前に、新サーバーで表示・機能・HTTPSを確認する
• 通常の接続先変更と、ネームサーバー変更を区別する
• TTLは事前に短くし、短縮前のTTLが過ぎてから切り替える
• 新旧サーバーを併用する間のデータ書き込み方法を決める
• DNS、メール、外部連携、監視、ロールバックを確認してから旧サーバーを停止・解約する

TTLとは？もう少し詳しく

TTLは「各ネットワークが必ずその秒数だけキャッシュする」という保証ではなく、DNSレコードに設定されたキャッシュ時間です。再帰DNSサーバーは、キャッシュが有効な間は権威DNSサーバーへ再問い合わせせず、保存した回答を返すことがあります。そのため、TTLを300秒にしても、すべての利用者が必ず5分以内に新サーバーへ到達するとは限りません。ローカルDNSキャッシュなどにより、実際に変更を体験するまで5分を超える場合があることも案内されています。

また、TTLを常に短くしておく必要はありません。移行や大きな変更の前後だけ短くし、切り替え後に正常動作を確認したら、通常の運用方針に合う値へ戻します。短いTTLは変更への追従を早めますが、DNS事業者への問い合わせが増える要因にもなります。

ダウンタイムをゼロに近づける理想の流れ

• 1. 現状を記録する：現在のDNSレコード、TTL、ネームサーバー、メール設定、証明書、外部連携を控え、バックアップと戻し方を準備します。
• 2. TTLを短縮する：Webの接続先レコードを短くし、変更前のTTL相当の時間を待ちます。ネームサーバー変更が不要なら、ここでは行いません。
• 3. 新サーバーを準備・検証する：データを移し、公開URLを使ったテスト表示、HTTPS、主要機能、メール、外部連携を確認します。
• 4. データの最終同期を行う：更新のあるサイトでは書き込みの扱いを決め、必要に応じて一時停止または最終同期を行います。
• 5. アクセスの少ない時間帯に接続先を変更する：DNSレコードを新サーバーへ更新し、新旧環境へのアクセス、監視、エラーログを確認します。
• 6. 安定を確認してからTTLを戻す：旧TTL分の余裕を見て、メールや定期処理も含めて問題がないことを確認します。その後にTTLを戻し、旧サーバーの停止・解約を判断します。

切り替え後の確認ポイント

• 外部ネットワークから、wwwあり・なし、主要なサブドメインが想定どおりに表示されるか確認する
• HTTPSの警告、リダイレクトのループ、画像やCSSの読み込みエラーがないか確認する
• フォーム送信、ログイン、注文、メール送受信、定期処理など、サイトの目的に直結する機能を確認する
• アクセスログとエラーログを見て、旧サーバーへのアクセスや異常なエラーが続いていないか確認する
• 問題が起きた場合に備え、旧サーバーとバックアップをすぐには削除しない

この順番で進めれば、DNSのキャッシュによる影響と新環境の設定漏れを切り分けながら、移行リスクを小さくできます。サイトの構成や利用中のサービスによって必要な手順は変わるため、不安がある場合は契約中のサーバー会社や制作会社に、切り替え前の確認項目とロールバック方法を相談してから作業してください。