DNSラウンドロビンは、それだけでは可用性を高めてくれません。止まったサーバーのIPも返し続けるからです。ただし、クライアントの再試行の仕組みを生かし、止まったサーバーを早く応答から外せるように設定すれば、1台の障害を「一部の利用者が少し待たされる」程度に抑えられます。この記事では、障害時に何が起きるかを確認したうえで、可用性を高めるための6つの設定と、メンテナンス時の手順を説明します。
1台が止まったとき、利用者には何が起きるか
www.example.com に3台分のAレコードを登録していて、そのうち1台が止まったとします。止まったサーバーのIPを最初に受け取った利用者の動きは、止まり方とクライアントによって変わります。
- サーバーが接続を拒否する場合：OSは起動しているがWebサーバーが落ちている、といった状態では、接続はすぐに拒否されます。ブラウザーの多くはすぐ次のアドレスを試すため、利用者はほとんど気づきません。
- 応答がまったく返らない場合：サーバーの電源断やネットワーク断では、接続が拒否されず、タイムアウトまで待たされます。次のアドレスへ移るまでに数秒から数十秒かかることがあります。
- 接続はできるがエラーを返す場合：Webサーバーは動いているがPHPやデータベースが壊れていて500エラーを返す状態では、ブラウザーは次のアドレスを試しません。利用者にはそのままエラー画面が表示されます。
また、ブラウザー以外のクライアント（APIクライアント、外部サービスからのWebhook、監視ツールなど）が次のアドレスを試すかどうかは実装によって異なります。ラウンドロビンで可用性を高めるには、「次のアドレスへ速く移れる止まり方にする」ことと、「異常なサーバーを応答から早く外す」ことの2つが要点になります。
工夫1：サーバーを別々の場所に置く
同じデータセンターや同じネットワークに全台を置くと、その場所の障害で全台が同時に止まり、ラウンドロビンは役に立ちません。可用性が目的なら、クラウドなら別のアベイラビリティゾーンやリージョン、VPSなら別の事業者やデータセンターに分けて配置します。データベースを1台にまとめている場合は、そのデータベースが残る単一障害点になる点も意識しておいてください。
工夫2：1台抜けても耐えられる余力を持たせる
3台のうち1台が止まると、残りの2台に1.5倍のアクセスが集まります。普段から各サーバーの負荷が高いと、1台の障害をきっかけに残りの台も過負荷で応答できなくなります。ピーク時の負荷を「台数−1」で処理できるかを、負荷試験やピーク時のリソース使用率で確かめておきます。
工夫3：TTLを用途に合わせて短めにする
止まったサーバーをDNSから外しても、リゾルバーにキャッシュが残っている間は古い応答が届きます。可用性を重視するなら、ラウンドロビンのレコードのTTLは60〜300秒程度が目安です。短くするほど権威DNSへの問い合わせは増えますが、マネージドDNSならほとんどの場合問題になりません。なお、リゾルバーやアプリケーションがTTLより長く結果を保持することもあるため、TTLを短くしても切り替え時間の上限が保証されるわけではありません。
工夫4：止めるときは「拒否」で止める
メンテナンスなどで1台を意図的に外すときは、パケットを捨てる設定ではなく、接続を拒否する設定にすると、クライアントがすぐ次のアドレスへ移れます。ファイアウォールで一時的にWebのポートを閉じる場合は、DROPではなくREJECTを使います。
# nftables の例：メンテナンス中、443番への新しい接続をTCPリセットで拒否する
# （既存のテーブル・チェーン名は環境に合わせる。作業前に現在のルールを書き出しておく）
sudo nft list ruleset > ~/nft-backup-$(date +%Y%m%d).conf
sudo nft insert rule inet filter input tcp dport 443 ct state new reject with tcp reset
# 作業後：ハンドル番号を確認して、追加したルールだけを削除する
sudo nft -a list chain inet filter input
sudo nft delete rule inet filter input handle 番号作業が終わったら、上のように追加したルールを削除します。サーバーごと止める場合はこの工夫は使えないため、次の工夫5と6の手順で先にDNSから外してください。
工夫5：異常なサーバーを自動で外せる仕組みにする
手作業で外す運用では、夜間の障害に間に合いません。ヘルスチェックと連動して正常なアドレスだけを返す機能を持つDNSを使うと、ラウンドロビンの手軽さを残したまま、止まったサーバーを自動で外せます。
- Amazon Route 53：IPごとにレコードを分け、「複数値回答」ルーティングにして、それぞれにヘルスチェックを関連付けます。
- PowerDNS（自前運用）：LUA レコードの
ifurlupなどで、ヘルスチェックに通ったアドレスだけを返せます。 - Cloudflare：DNSのみのレコードには死活監視がなく、ヘルスチェックによる振り分けは有料の Load Balancing 機能の領域です。
各サービスの機能名や対応プランは変わることがあります（2026年10月現在）。ヘルスチェックを使う場合は、監視するURLをトップページではなく、データベースまで動いているかを返す軽いURLにしてください。そうしないと、「接続はできるがエラーを返す」状態のサーバーを外せません。
工夫6：IPごとに監視して、どの台が悪いかを見分ける
ホスト名だけで外形監視をしていると、DNSが毎回別のIPを返すため、1台だけが壊れている状態を見逃したり、たまにしか失敗しない監視結果に惑わされたりします。IPごとに直接つないで監視すると、どの台が悪いかがすぐに分かります。
#!/usr/bin/env bash
# 各サーバーのIPに直接つないで、ヘルスチェックURLの状態を一覧にする
NAME="www.example.com"
IPS="203.0.113.11 203.0.113.12 203.0.113.13"
for ip in $IPS; do
code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 5 \
--resolve "${NAME}:443:${ip}" "https://${NAME}/healthz")
printf '%s %s\n' "$ip" "$code"
done--resolve を使うと、DNSの応答とは関係なく指定したIPに接続しながら、証明書の検証やホスト名による振り分けは本来のホスト名で行われます。接続できない場合、%{http_code} は 000 になります。この結果を監視ツールに渡して、200以外のIPがあれば通知するようにしておくと、自動で外す仕組みがない環境でも素早く手作業で外せます。
メンテナンスで1台を外す手順
計画的に1台を外すときは、次の順番で作業すると、利用者への影響を最小限にできます。
- 対象のIPをDNSから外す（作業前に現在のレコードを書き出しておく）
- TTLの時間以上待つ。アクセスログで新しいリクエストが減っていくことを確認する
- それでも残る接続のために、工夫4の「拒否」の設定を入れる
- サーバーを停止して作業する
- 作業後、IPごとの監視で正常を確認してから、DNSに戻す
- アクセスログでリクエストが戻ってきたことを確認する
順番を逆にして先にサーバーを止めると、キャッシュに古い応答を持つ利用者が、止まったサーバーに接続しにいくことになります。
まとめ
- DNSラウンドロビンは死活監視をしないため、設定を工夫しないと可用性はほとんど上がりません。
- 接続を拒否される止まり方ならブラウザーはすぐ次のアドレスへ移りますが、タイムアウトや500エラーには弱い仕組みです。
- サーバーを別々の場所に置き、1台抜けても耐えられる余力を持たせ、TTLを短めにします。
- ヘルスチェック連動の複数値応答で異常なサーバーを自動で外し、IPごとの監視でどの台が悪いかを見分けます。
- 計画停止は「DNSから外す→TTL以上待つ→止める」の順で行います。