DNSフェイルオーバーは、DNSサービスがサーバーの死活を定期的に監視し、メインのサーバーが応答しなくなったときに予備サーバーのIPアドレスを返すよう切り替える仕組みです。ロードバランサーを置かずに冗長化できる反面、切り替わるまでにDNSキャッシュ分の時間がかかります。この記事では、仕組みと限界、ヘルスチェックの作り方、予備サーバー側の準備、切り替えの試験方法までを、WordPressサイトを例に説明します。
DNSフェイルオーバーの仕組みと、ラウンドロビンとの違い
通常のDNSは、登録されたレコードをそのまま返すだけで、サーバーが止まっていても気づきません。DNSフェイルオーバーでは、権威DNSサービス側に「ヘルスチェック」が加わります。
- DNSサービスが一定間隔でメインサーバーにHTTP(S)などで接続し、正常な応答が返るかを確認する
- 決められた回数続けて失敗すると、メインを「異常」と判定する
- 以降の問い合わせには、予備サーバーのIPアドレスを返す
- メインが復旧すると、設定に応じて元の応答に戻す
複数のAレコードを並べて振り分ける「DNSラウンドロビン」は負荷分散が目的で、死活監視はしません。止まったサーバーのIPも返し続けるため、冗長化の手段としては不十分です。フェイルオーバーは「正常なサーバーだけを返す」ことが目的で、メイン1台＋予備1台のアクティブ／スタンバイ構成がもっとも一般的です。
切り替えにかかる時間を見積もる
DNSフェイルオーバーで最初に理解しておきたいのは、切り替えが一瞬では終わらないことです。利用者から見たダウンタイムは、おおむね次の合計になります。
- 検知時間：チェック間隔 × 失敗と判定するまでの回数（例: 30秒間隔で3回なら約90秒）
- キャッシュの残り時間：リゾルバーが古い応答を保持している時間（最大でTTL）
- クライアント側の保持：ブラウザやアプリが名前解決の結果を使い回す時間、既存の接続を使い続ける時間
TTLを短くするほど切り替えは早くなりますが、問い合わせ回数が増えます。フェイルオーバー対象のレコードは60〜300秒程度にするのが一般的です。ただし、一部のリゾルバーやアプリケーション（独自のDNSキャッシュを持つランタイムなど）はTTLを守らず長く保持することがあり、TTLを60秒にしても全員が60秒で切り替わるわけではありません。「数分程度のダウンタイムは許容する」という前提で選ぶ方式です。秒単位の切り替えが必要なら、ロードバランサーやクラウドの冗長構成を検討してください。
DNSフェイルオーバーに対応した主なサービス
ヘルスチェックとフェイルオーバーは、権威DNSサービスの機能として提供されています。代表的なものは次のとおりです（2026年10月現在）。機能の範囲や名称、課金体系は各社が変更することがあるため、公式ドキュメントで確認してください。
- Amazon Route 53：ヘルスチェックを作成し、レコードのルーティングポリシーで「フェイルオーバー」を選んでプライマリとセカンダリを指定します。
- Cloudflare：DNS自体には死活監視がなく、有料の Load Balancing 機能でオリジンのプール、監視（モニター）、フェイルオーバーの順序を設定します。
- Azure Traffic Manager / Google Cloud DNS のルーティングポリシー / NS1 など：優先度やヘルスチェックに基づく応答の切り替えが可能です。
レジストラ付属の無料DNSやBINDを素のまま運用している場合は、この機能がありません。自前で監視スクリプトを書いてAPIでレコードを書き換える方法もありますが、監視スクリプト自体が止まると機能しないため、まずはマネージドサービスを使うほうが安全です。
手順1：ヘルスチェック用のURLを用意する
トップページをそのまま監視すると、ページキャッシュが効いていてデータベースが落ちていても「正常」と判定されることがあります。WordPressでは、データベースまで疎通できるかを見る軽いURLを用意すると判定の精度が上がります。
<?php
// health-check.php（WordPressのルート、wp-load.php と同じ階層に置く例）
// SHORTINIT で最小限だけ読み込み、DB に問い合わせて結果を返す
define( 'SHORTINIT', true );
require __DIR__ . '/wp-load.php';
global $wpdb;
$ok = ( '1' === (string) $wpdb->get_var( 'SELECT 1' ) );
header( 'Cache-Control: no-store' );
header( 'Content-Type: text/plain; charset=utf-8' );
http_response_code( $ok ? 200 : 503 );
echo $ok ? 'OK' : 'NG';SHORTINIT を定義すると、プラグインやテーマを読み込まずにデータベース接続までで処理が止まるため、監視の負荷を抑えられます。データベースに接続できない場合は WordPress がエラーを返すので、監視側は異常と判定します。
置いたあとに確認したい点は次のとおりです。
- ページキャッシュ（キャッシュ系プラグインやCDN、サーバーのキャッシュ）の対象から外す。キャッシュされた200が返り続けると監視の意味がなくなります
- エラーの詳細やバージョン情報を出力しない
- 監視が HTTPS で行われる場合、証明書の検証やリダイレクトで失敗しないかを確かめる
監視側では、このURLが200を返し、本文に「OK」を含むことを条件にすると誤判定を減らせます（文字列一致の条件を設定できるかはサービスによります）。
手順2：予備サーバーを用意する
フェイルオーバーで一番難しいのは、DNSの設定よりも予備サーバーの中身です。WordPressでは、次のどちらかの方針を先に決めます。
方針A：お詫び・メンテナンスページを出す予備側は静的なページだけを返すサーバーやオブジェクトストレージ＋CDNにします。データの同期が不要で、構成も単純です。「止まったときに真っ白にならない」ことが目的ならこれで十分です。
方針B：同じサイトを予備でも表示するデータベースの複製（レプリケーション）、wp-content/uploads の同期、テーマ・プラグインのファイルの一致が必要です。注意したいのは書き込みです。予備側でもコメントや注文、管理画面での更新を受け付けると、切り戻したときにメイン側とデータが食い違います。予備側は読み取り専用にする、書き込み処理を止める、切り戻し時のデータ統合手順を決めておく、のいずれかを事前に用意してください。
どちらの方針でも、予備サーバーには同じドメインのSSL証明書が要ります。通常時は予備サーバーにアクセスが来ないため、Let's Encrypt の HTTP-01 認証では更新に失敗しがちです。DNS-01 認証で発行する、メイン側で取得した証明書を安全な方法で配布する、などの方法で予備側の証明書を有効に保ちます。
手順3：DNSレコードとヘルスチェックを設定する
Route 53 を例にすると、流れは次のようになります（画面の表記はコンソールの改修で変わることがあります）。
- メインサーバーのヘルスチェックを作成する（プロトコル、ホスト名、パス
/health-check.php、チェック間隔、失敗と判定する回数を指定） - 同じ名前（例:
www.example.com）のAレコードを2つ作り、ルーティングポリシーをフェイルオーバーにする - 1つ目をプライマリとしてメインのIPと手順1のヘルスチェックを関連付け、2つ目をセカンダリとして予備のIPを指定する
- TTLは60〜300秒程度にする
Cloudflare の Load Balancing を使う場合は、メインと予備をそれぞれ「プール」として登録し、監視の設定を付け、プールの優先順位でフェイルオーバーさせる、という考え方になります。
既存のレコードをフェイルオーバー用に作り替えるときは、作業の前日までに既存レコードのTTLを短くし、作業前に現在のDNS設定をエクスポートしてバックアップしておくと、問題が起きたときに戻しやすくなります。
手順4：切り替えと切り戻しを試験する
設定しただけで本番の障害を待つのは危険です。利用者の少ない時間帯に、意図的にメインを異常にして動作を確かめます。
# 1. 平常時の応答を確認（メインのIPが返る）
dig +short www.example.com A
# 2. メイン側でヘルスチェックURLだけを503にする、Webサーバーを止める等で障害を再現
# 3. 権威DNSに直接問い合わせ、予備のIPに変わったか確認
dig +short www.example.com A @ns-xxx.awsdns-xx.com
# 4. 公開リゾルバー経由でも確認（キャッシュが切れるまで旧IPのことがある）
dig www.example.com A @8.8.8.8権威DNSの応答が変わるまでの時間が検知時間、公開リゾルバーで変わるまでの差がキャッシュの影響です。実測した時間を記録しておくと、障害時に「あと何分で切り替わるか」の判断材料になります。
切り戻し（メイン復旧後に元へ戻す動作）も確認します。メインが不安定なまま自動で戻ると、切り替えと切り戻しを繰り返す「フラッピング」が起きます。方針Bで予備側に書き込みがあった場合は、自動で戻さず、データを確認してから手動で戻す運用のほうが安全です。
ネームサーバー自体の冗長化も確認する
Webサーバーを冗長化しても、ドメインの権威DNSが止まれば名前解決ができません。ネームサーバーは複数台が登録されているか、異なるネットワークに分散しているかを確認します。
dig +short example.com NSマネージドDNSは通常、複数の拠点に分散した複数のネームサーバーを割り当てます。自前のDNSサーバーを使っている場合は、最低2台を別のネットワークに置くか、セカンダリDNSサービスの利用を検討してください。
まとめ
- DNSフェイルオーバーは、ヘルスチェックで異常を検知したら予備サーバーのIPを返す仕組みで、ラウンドロビンとは目的が異なります。
- 切り替え時間は「検知時間＋DNSキャッシュ＋クライアントの保持」の合計で、数分単位になる前提で使います。
- WordPressではDBまで確認するヘルスチェックURLを作り、キャッシュの対象から外します。
- 予備サーバーは「お詫びページ」か「同じサイト」かを先に決め、同じサイトなら書き込みと切り戻しの扱い、SSL証明書の更新方法まで用意します。
- 設定後は意図的に障害を起こして、切り替えと切り戻しの時間を実測しておきます。