可用性設計を進めていくと、意外と見落としがちなのがDNS層の冗長化です。
サーバーやRDSをどれだけ冗長化しても、利用者を最初に案内するDNSが1つの向き先しか返せなければ、その向き先が落ちた瞬間にサービスは応答しなくなります。AWSのRoute 53には、ヘルスチェックと連動して自動で向き先を切り替える「フェイルオーバールーティング」という仕組みがあります。
この記事では、Route 53のヘルスチェックとフェイルオーバールーティングでDNS層を冗長化する設計手順を解説します。
単なる設定手順ではなく、「どこがSPOF（単一障害点）になるのか」「TTLをどう設計するか」という実務の勘所から掘り下げていきます。
この記事のポイント
・Route 53はヘルスチェックで向き先を自動切替できる
・フェイルオーバーはPrimary・Secondaryの2レコードで組む
・切り替え速度はTTLとヘルスチェック間隔で決まる
・マルチリージョン構成でリージョン障害にも備えられる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜDNS層の冗長化が必要なのか？Route 53の役割
システムの可用性を語るとき、EC2やRDSの冗長化には注目が集まりますが、その手前にあるDNSは見落とされがちです。利用者のブラウザやアプリは、まずドメイン名（例：www.example.com）をIPアドレスに変換してから接続します。この名前解決を担うのがDNSであり、AWSではRoute 53がその役割を果たします。
もしDNSが常に同じIPアドレス1つだけを返し続けると、そのIPの先にあるALBやサーバーが停止しても、利用者は落ちた向き先に案内され続けます。これがDNSがSPOFになるという状態です。
DNSの基本的な仕組みについてはLinux DNS 設定の基本もあわせて読むと、名前解決の流れが整理できます。
Route 53が可用性設計で果たす役割
・ヘルスチェック：向き先のエンドポイントが正常かを定期的に監視する
・フェイルオーバールーティング：異常を検知したら別の向き先を返すように切り替える
・マルチリージョン対応：リージョンをまたいだ向き先の切り替えもできる
Route 53はマネージドサービスとして99.99%のSLAを持ち、Route 53自体の冗長化はAWS側が担保します。つまり運用者は「向き先をどう切り替えるか」の設計に集中できます。
Route 53ヘルスチェックの仕組み
フェイルオーバーの前提になるのがヘルスチェックです。Route 53は世界各地の分散したチェッカーからエンドポイントを監視し、その健全性を判定します。1. エンドポイント監視型のヘルスチェック
最も基本的なのが、指定したIPアドレスやドメインに対してHTTP・HTTPS・TCPで疎通確認を行うタイプです。複数のリージョンにあるチェッカーから同時に監視し、規定の割合以上が失敗した場合に「Unhealthy」と判定します。
# AWS CLIでHTTPヘルスチェックを作成する例 aws route53 create-health-check \ --caller-reference hc-primary-$(date +%s) \ --health-check-config \ Type=HTTPS,ResourcePath=/health,FullyQualifiedDomainName=app.example.com,Port=443,RequestInterval=30,FailureThreshold=3 # 出力例（HealthCheckIdが払い出される） { "HealthCheck": { "Id": "abcd1234-5678-90ab-cdef-1234567890ab", "HealthCheckConfig": { "Type": "HTTPS", "ResourcePath": "/health", "FullyQualifiedDomainName": "app.example.com", "Port": 443, "RequestInterval": 30, "FailureThreshold": 3 } } }
・RequestInterval（監視間隔）：30秒または10秒（Fast）。10秒にすると検知は速いが料金が上がる
・FailureThreshold（失敗回数の閾値）：連続で何回失敗したらUnhealthyとするか。デフォルトは3回
30秒間隔・閾値3回であれば、障害発生から最短でも約90秒はUnhealthy判定までにかかる計算になります。この時間が切り替えの初動を左右します。
2. 専用のヘルスチェックエンドポイントを用意する
ヘルスチェックの向き先には、トップページ（/）ではなく専用の `/health` のようなパスを用意するのが定石です。トップページはDB接続や外部API呼び出しを含むことが多く、DBが軽く詰まっただけでヘルスチェックが失敗し、不要なフェイルオーバーを誘発します。
専用エンドポイントは「そのサーバー自身が生きていて、リクエストを返せる」ことだけを軽量に確認する作りにしてください。アプリの深い依存関係まで確認する「ディープヘルスチェック」は、別の監視系（CloudWatch）で扱うのが現場での分離パターンです。
3. 計算ヘルスチェックとCloudWatch連携
Route 53には、複数のヘルスチェック結果を組み合わせて判定する「計算ヘルスチェック（Calculated Health Check）」もあります。「子ヘルスチェックのうち2つ以上がHealthyなら親もHealthy」といった条件を組めるため、単一エンドポイントの一時的な失敗で過剰に反応するのを防げます。
また、CloudWatchアラームの状態をヘルスチェックの判定に使うこともできます。「CPU使用率が閾値を超えたら」「SQSのキュー滞留が増えたら」といった、疎通では測れない指標をトリガーにできるのが利点です。
フェイルオーバールーティングの設計
ヘルスチェックが用意できたら、いよいよフェイルオーバールーティングを設計します。基本はPrimary（主系）とSecondary（副系）の2レコードを同じレコード名に対して作る構成です。1. Primary・Secondaryの基本構成
同じ `www.example.com` に対して、フェイルオーバータイプのレコードを2つ登録します。・Primaryレコード：通常時に返す向き先。ヘルスチェックを紐付ける
・Secondaryレコード：PrimaryがUnhealthyのときだけ返す向き先
Route 53はPrimaryのヘルスチェックがHealthyな間はPrimaryのIPを返し、Unhealthyになった瞬間からSecondaryのIPを返すようになります。
# フェイルオーバーレコード（Primary）を作成するJSON例 { "Comment": "Primary failover record", "Changes": [{ "Action": "CREATE", "ResourceRecordSet": { "Name": "www.example.com", "Type": "A", "SetIdentifier": "primary-tokyo", "Failover": "PRIMARY", "TTL": 60, "ResourceRecords": [{"Value": "203.0.113.10"}], "HealthCheckId": "abcd1234-5678-90ab-cdef-1234567890ab" } }] }
2. Sorryサーバーへのフェイルオーバー
副系として本番同等のシステムをもう一式用意するのはコストがかかります。予算に応じて、まずは「Sorryサーバー」への切り替えから始めるのが現実的です。S3の静的Webサイトホスティングで「ただいまメンテナンス中です」というページを用意し、Primary障害時にそこへフェイルオーバーさせます。全断でエラーを返すよりも、利用者に状況を伝えられるだけで信頼性の体感は大きく変わります。
・フルスタンバイ：副リージョンに本番同等の構成。コスト高だが無停止に近い
・パイロットライト：副系は最小構成で待機し、障害時にスケールアップ
・Sorryサーバー：S3静的サイトで案内のみ。最も安価
どの方式でも、DNS層の切り替えの仕組み自体は同じフェイルオーバールーティングで実現できます。
AWS上でLinuxサーバーを構築する基礎から固めたい方は、AWSでLinuxサーバーを構築する入門講座で、EC2やAmazon Linuxの土台を先に押さえておくと設計が理解しやすくなります。
3. TTLの設計｜切り替え速度を決める最重要パラメータ
フェイルオーバーの「体感速度」を最も左右するのがレコードのTTL（Time To Live）です。TTLは、利用者側のリゾルバがDNSの回答をキャッシュする秒数です。TTLが長いと、Route 53が向き先を切り替えても、キャッシュが切れるまで利用者は古いIPに接続し続けます。
・TTL 300秒（5分）：フェイルオーバー後、最大5分は旧IPに接続され得る
・TTL 60秒：フェイルオーバー用途での一般的な推奨値
・TTL 30秒以下：切り替えは速いがDNSクエリ数が増える
フェイルオーバーを使うレコードはTTLを60秒程度に短く設定するのが定石です。ただしTTLを短くしても、リゾルバによっては最低キャッシュ時間を独自に持つため、実際の切り替えには「ヘルスチェック検知時間＋TTL」がかかると考えて設計してください。
実装と動作確認の手順
設定が終わったら、必ず「本当に切り替わるか」を確認します。設定しただけで満足して、いざ障害時に切り替わらないのが最悪のパターンです。1. ヘルスチェックの状態を確認する
まずヘルスチェック単体が正しく判定できているかを確認します。# ヘルスチェックの現在の状態を確認する aws route53 get-health-check-status \ --health-check-id abcd1234-5678-90ab-cdef-1234567890ab \ --query 'HealthCheckObservations[].StatusReport.Status' # 出力例（各リージョンのチェッカーからの報告） [ "Success: HTTP Status Code 200, OK", "Success: HTTP Status Code 200, OK", "Success: HTTP Status Code 200, OK" ]
2. 名前解決の結果を確認する
正常時にPrimaryのIPが返ることを、dig（またはnslookup）で確認します。# 通常時：Primaryの向き先が返る dig www.example.com +short # 出力例 203.0.113.10 # Primaryを意図的に停止（/healthを503にする等）した後、TTL経過後に再確認 dig www.example.com +short # 出力例（Secondaryの向き先に切り替わっている） 203.0.113.20
3. 切り替え時間を実測する
障害を注入してから、実際にSecondaryへ切り替わるまでの時間を計測しておきます。検知（ヘルスチェック間隔×失敗閾値）＋TTLの合計が、利用者から見た「切り替え完了までの時間」の目安です。監視間隔30秒・閾値3回・TTL60秒なら、おおよそ2分半前後が現実的な切り替え時間になります。
マルチリージョン構成への発展
マルチAZ構成はAZ障害には強いものの、リージョン全体の障害には対応できません。より高い可用性が求められる場合は、Route 53のフェイルオーバーをリージョンをまたいで組みます。Primaryを東京リージョン（ap-northeast-1）のALB、Secondaryを大阪リージョン（ap-northeast-3）のALBに向けることで、東京リージョン全体が障害を起こしてもDNSが大阪へ切り替えます。
・データ同期の設計：DNS切替は速くても、RDSのクロスリージョンレプリケーションには遅延がある。RPO（どこまでデータ損失を許容するか）を決める
・レイテンシールーティングとの併用：平常時は近いリージョンへ、障害時はフェイルオーバー、という組み合わせも可能
・コスト：副リージョンの待機構成をどこまで持つか（フルスタンバイ／パイロットライト）で大きく変わる
マルチリージョンは強力ですが、DNS層の切り替えより「データの整合性」の設計が本質的な難所になります。まずは同一リージョン内のマルチAZフェイルオーバーで仕組みに慣れるのが手堅い進め方です。
設計の落とし穴チェックリスト
フェイルオーバー設計でよくある落とし穴を、障害時の挙動とあわせて整理します。| 落とし穴 | 障害時に起きる問題 | 対策 |
|---|---|---|
| TTLを300秒以上のまま運用 | Route 53が切り替えても利用者が数分間旧IPに接続し続ける | フェイルオーバー対象レコードのTTLは60秒程度に短縮する |
| ヘルスチェック先をトップページ（/）にする | DBの一時的な遅延で誤検知し、不要なフェイルオーバーが起きる | 軽量な専用の /health エンドポイントを用意する |
| Secondaryにヘルスチェックを付けない | 副系も落ちているのに切り替えてしまい全断になる | Secondaryにもヘルスチェックを紐付ける |
| Primary復旧時の切り戻しを検証しない | Primaryが直っても戻らない、または戻った瞬間に不整合が出る | 切り戻し（フェイルバック）まで含めて動作確認する |
| ヘルスチェック元のIPをファイアウォールで許可していない | 正常なのにUnhealthy判定され、常時Secondaryに向く | Route 53チェッカーのIPレンジをセキュリティグループで許可する |
トラブルシュート｜フェイルオーバーでよくある問題
1. 障害を起こしてもフェイルオーバーが発動しない
Primaryを停止したのにSecondaryへ切り替わらない場合、まずヘルスチェックがUnhealthyになっているかを確認します。# ヘルスチェックがUnhealthyを検知できているか確認 aws route53 get-health-check-status \ --health-check-id abcd1234-5678-90ab-cdef-1234567890ab \ --query 'HealthCheckObservations[].StatusReport.Status' # Successのままなら、チェッカーがまだ疎通できている # セキュリティグループでチェッカーIPを許可していないと逆に常時失敗する
2. 切り替わったが、Primary復旧後も戻らない
フェイルオーバー自体は成功したのに、Primary復旧後もSecondaryのままになるケースです。多くは利用者側のDNSキャッシュが原因で、TTLが切れれば自動で戻ります。切り戻しが極端に遅い場合は、TTL設定を見直してください。
# TTLの残り秒数まで含めて確認する（+shortを付けない） dig www.example.com # ANSWER SECTIONの左から2番目の数字がTTLの残り秒数 # www.example.com. 58 IN A 203.0.113.20
3. ヘルスチェックが正常と異常を繰り返す（flapping）
ヘルスチェックがHealthyとUnhealthyを短時間で行き来すると、向き先が不安定に切り替わり、かえって障害のように見えます。原因は監視間隔に対してエンドポイントの応答が不安定なことが多いです。FailureThresholdを上げて判定を鈍らせる、あるいは計算ヘルスチェックで複数エンドポイントの多数決にすることで安定します。
根本的には、ヘルスチェック先の応答時間を安定させることが先決です。アプリ側のレスポンスが監視のタイムアウト付近で揺れている場合は、専用エンドポイントの処理をさらに軽量化してください。
本記事のまとめ
AWS Route 53でDNS層を冗長化する際の要点をまとめます。| 設計要素 | 推奨設定・方針 | 注意点 |
|---|---|---|
| ヘルスチェック | 専用の /health を監視間隔30秒・閾値3回で監視 | チェッカーIPをセキュリティグループで許可する |
| ルーティング | Primary・Secondaryのフェイルオーバーレコードを組む | Secondaryにもヘルスチェックを紐付ける |
| TTL | フェイルオーバー対象は60秒程度に短縮 | 短くしすぎるとDNSクエリ数と料金が増える |
| 副系構成 | Sorryサーバー～フルスタンバイまで予算で選ぶ | 切り戻し（フェイルバック）まで必ず検証する |
| マルチリージョン | Primary・Secondaryを別リージョンのALBに向ける | DNS切替よりデータ同期のRPO設計が難所 |
DNSを冗長化しておくことで、サーバー層・DB層の冗長化が初めて利用者から見て「止まらないシステム」として完成します。
AWSでのマルチAZ・冗長構成の設計を体系的に学びたい方は、AWS冗長構成の設計実践ガイドもあわせてご覧ください。
AWS上でLinuxサーバーを構築する基礎から学びたい方は、AWSでLinuxサーバーを構築する入門講座からどうぞ。
Linux無料マニュアルを受け取る ＞＞
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます