2026年6月6日

ヘルスチェック型DNS の切り替え方法｜保守のために主サーバーを手動で外し、安全に切り戻す手順

DNS・名前解決

ヘルスチェック型DNS は障害のときに自動で切り替わりますが、保守や移行の作業では、正常なサーバーを意図して外し、作業後に戻したい場面があります。手動で切り替えるいちばん素直な方法は、ヘルスチェックの判定を「異常」に変えることです。この記事では Amazon Route 53 のフェイルオーバー構成を例に、切り替えの方法の選び方、計画した切り替えの手順、データベースを含む切り戻しの順番、作業でよくある落とし穴を説明します。

切り替えの方法は大きく三つ

主のサーバーを外して副へ向ける方法には、主に次の三つがあります。

確認用 URL を異常にする：ヘルスチェックが見ている URL が 503 を返すようにして、障害時と同じ経路で切り替えます。
ヘルスチェックの判定を反転させる：Route 53 のヘルスチェックの「反転」の設定を使い、正常な応答を異常として扱わせます。
レコードを書き換える：主のレコードのアドレスを副のものに直接変えます。

おすすめは 1 です。本番の障害と同じ仕組みで切り替わるため、普段の保守がそのまま切り替えの試験になります。2 は確認用 URL に手を入れられない場合に便利ですが、反転している間に主が本当に止まると「正常」と判定されるため、作業が終わったらすぐに戻します。3 は権威DNS の応答がすぐに変わる一方、ヘルスチェックによる自動の切り替えが働かない状態になるため、一時的な手段にとどめます。

大規模な構成では、Route 53 Application Recovery Controller のように、切り替えの操作そのものを管理する仕組みもあります。機能の範囲は変わることがあるため、検討する場合は AWS のドキュメントで確認してください（2026年10月現在）。

準備：確認用 URL に「外す」ためのスイッチを付ける

方法1を使うには、確認用 URL に手動で異常を返させる仕組みを入れておきます。データベースを確かめる確認用 URL（mu-plugin）の判定に、次の数行を加えます。

// wp-content/dns-drain というファイルがあれば、正常でも 503 を返す
if ( file_exists( WP_CONTENT_DIR . '/dns-drain' ) ) {
	$ok = false;
}

これで、ファイルを作れば外れ、消せば戻ります。DNS サービスの画面にログインする必要がなく、SSH でサーバーにログインできる担当者なら操作できます。サーバーが複数ある拠点では、ロードバランサー配下のすべてのサーバーにファイルを置くか、共有のストレージに置きます。

方法2を使う場合のコマンドは次のとおりです。

# 判定を反転させる（主を外す）
aws route53 update-health-check --health-check-id your-health-check-id --inverted

# 元に戻す
aws route53 update-health-check --health-check-id your-health-check-id --no-inverted

落とし穴：ヘルスチェックを「無効」にしても外れない

保守のときにヘルスチェックを無効にすれば外れると考えがちですが、Route 53 では、無効にしたヘルスチェックは正常として扱われます。主のレコードは応答に残ったままなので、主のサーバーを止めると利用者はエラー画面を見ることになります。外したいときは、確認用 URL を異常にするか、判定を反転させます。

もう一つの落とし穴は、TTL です。切り替えの操作をしても、公開リゾルバーは TTL の間、古いアドレスを返し続けます。計画した切り替えでは、事前に TTL を短くしておき、元の TTL が切れるまで待ってから作業を始めます。

計画した切り替えの手順（主から副へ）

WordPress を2つの拠点で動かし、副の拠点のデータベースが主の複製になっている構成を想定します。

1. 事前の確認（前日まで）

対象レコードの TTL を短く（例: 60秒）しておく
aws route53 list-resource-record-sets で現在のレコードを書き出して保存する
副の拠点に curl --resolve で接続し、サイトと確認用 URL が正常に応答することを確かめる
関係者に作業の時間と、書き込みを止める時間を知らせる

2. 書き込みを止める

投稿、コメント、注文などの受付を一時的に止めます。止めずに切り替えると、切り替わりの途中で主に書き込まれた内容が副に届かず、失われることがあります。

3. 複製の遅れを確かめる

副のデータベースで複製の状態を見て、遅れが無いことを確かめます。MySQL では SHOW REPLICA STATUS（古い版では SHOW SLAVE STATUS）の結果の遅れの項目を見ます。

4. 副のデータベースを書き込み可能にする

副の拠点で書き込みも受ける場合は、複製を止めて書き込み可能に切り替えます。マネージドデータベースを使っている場合は、その製品の切り替えの手順に従います。

5. 主を外す

主のサーバーで touch /var/www/html/wp-content/dns-drain を実行します（パスは環境に合わせます）。

6. 切り替わりを確かめる

NS=$(dig +short NS example.com | head -n 1)
dig @"$NS" www.example.com A +short +norecurse   # 権威DNS の応答
dig @1.1.1.1 www.example.com A                    # 公開リゾルバーの応答と残り TTL

権威DNS の応答が副のアドレスに変わり、TTL が過ぎて公開リゾルバーも変わったら、副のアクセスログに利用者の要求が来ていることを確かめます。主のアクセスログで要求が減っていくことも見ておきます。

7. 書き込みを再開する

副で管理画面へのログイン、投稿の保存、コメントの投稿を試してから、受付を再開します。

切り戻しの手順（副から主へ）

切り戻しで注意するのは、Route 53 のフェイルオーバーは、主の判定が正常に戻ると自動で主を返すことです。主の dns-drain を先に消してしまうと、データベースの準備ができていないまま利用者が主に戻り、副で受けた書き込みが主に無い状態になります。

そこで、次の順番を守ります。

主の dns-drain は残したまま、副で受けた書き込みを主のデータベースに反映させる（主を副の複製にしてから役割を戻す、など）
主のサイトを curl --resolve で確かめる
書き込みを止める
主のデータベースを書き込み可能に戻し、副を再び複製にする
主の dns-drain を消す
権威DNS と公開リゾルバーの応答が主に戻ったことを確かめ、書き込みを再開する

データベースを切り替えない構成（副は閲覧専用、またはお知らせページ）なら、手順は「副の確認 → 主の dns-drain を消す → 応答の確認」だけで済みます。

他の DNS サービスの場合

Cloudflare の Load Balancing のように、プールやオリジンを画面から無効にして手動で外せるサービスもあります。どの操作で「外れる」のか、無効にしたものが正常扱いになるのか異常扱いになるのかはサービスごとに違うため、本番の前に試験環境で動きを確かめておきます。

まとめ

手動の切り替えは、確認用 URL を異常にする方法が、障害時と同じ経路で動くため扱いやすいです。
Route 53 で無効にしたヘルスチェックは正常扱いなので、外したいときは URL を異常にするか判定を反転させます。
計画した切り替えは「TTL を下げる → 書き込みを止める → 複製の遅れを確かめる → 主を外す → 確認 → 再開」の順で進めます。
切り戻しでは、データの反映が終わるまで主を外したままにし、最後に dns-drain を消します。