Anycast DNS とDNSラウンドロビンを組み合わせると、ネームサーバーは世界の複数拠点で応答させつつ、Webサーバーへのアクセスは複数のIPアドレスで大まかに分けられます。ただし、ラウンドロビンの並び順は権威DNSだけでは決まらず、止まったサーバーを自動では外せません。この記事では、並び順がどこで決まるかを整理したうえで、素のラウンドロビン、ヘルスチェック付きの複数値応答、重み付けの3つの構成例と確認方法を説明します。
2つの仕組みの役割分担
この組み合わせでは、担当する層がはっきり分かれます。
- Anycast DNS：ネームサーバーの層です。同じIPアドレスを複数の拠点からBGPで広告し、利用者のリゾルバーに近い拠点が問い合わせに答えます。拠点が止まっても名前解決が続きます。
- DNSラウンドロビン：Webサーバーの層です。同じホスト名に複数のAレコード（IPv6ならAAAAレコード）を登録し、利用者ごとに接続先を散らします。
混同しやすいのが「Webサーバー自体をAnycastにする」構成です。CDNやAnycast対応のロードバランサーの背後にWebサーバーを置く場合、利用者に見えるIPはCDN側のものになり、DNSでのラウンドロビンは使いません。この記事で扱うのは、ネームサーバーがAnycast、Webサーバーは個別のIPを持つ構成です。
並び順はどこで決まるのか
ラウンドロビンの効果を見積もるには、利用者が最初に接続するアドレスが、次の3か所の影響を受けることを知っておく必要があります。
1. 権威DNSの各拠点Anycastのネームサーバーは拠点ごとに独立して応答するため、全拠点で共有された「次はこの順番」という状態はありません。各拠点が自分で並び順を入れ替えるか、ランダムに並べます。マネージドDNSの多くは、複数の値を持つレコードをランダムな順で返すと説明しています。
2. リゾルバーのキャッシュプロバイダーや公開DNSのリゾルバーは、受け取った応答をTTLの間キャッシュし、多数の利用者に使い回します。キャッシュから返すときに並び順を入れ替える実装もあれば、そのまま返す実装もあります。大手の公開リゾルバーはそれ自体がAnycastで多数のキャッシュを持つため、利用者ごとに異なる順番が届きやすく、結果としてある程度は散らばります。
3. 利用者のOSとブラウザーOSは受け取った複数のアドレスを、独自の規則（RFC 6724 のアドレス選択規則など）で並べ替えることがあります。IPv4とIPv6の両方がある場合は、Happy Eyeballs（RFC 8305）によって両方へ並行して接続を試みる動きも加わります。
このため、DNSラウンドロビンの分散は「おおよそ」で、台数で均等に割れることは期待できません。偏りを許容できる用途で使う方式です。
構成例1：Anycast DNS＋複数のAレコード
もっとも単純な構成で、マネージドDNSに同じ名前のAレコードを複数登録するだけです。
www.example.com. 300 IN A 203.0.113.11
www.example.com. 300 IN A 203.0.113.12
www.example.com. 300 IN A 203.0.113.13Route 53 ならシンプルルーティングのレコード1件に複数の値を入れ、Cloudflare なら同じ名前のAレコードを複数作り、プロキシを無効（DNSのみ）にします。Cloudflare でプロキシを有効にすると利用者に見えるのはCloudflareのIPになり、ここで説明するラウンドロビンとは別の動きになります。
この構成の限界は、ヘルスチェックがないことです。1台が止まってもそのIPは返り続けます。ブラウザーの多くは接続に失敗すると次のアドレスを試しますが、それが効くのは「接続できない」場合だけです。サーバーには接続できるものの500エラーを返している、という状態では次のアドレスへは移りません。止まったサーバーを外す作業は人が行うことになり、外したあともTTLの間は古い応答が残ります。
構成例2：ヘルスチェック付きの複数値応答
止まったサーバーを自動で外したい場合は、ヘルスチェックと連動して「正常なアドレスだけを複数返す」機能を使います。
Route 53 では「複数値回答」ルーティングがこれに当たります。IPアドレスごとに別のレコードを作り、それぞれにヘルスチェックを関連付けると、正常と判定されたレコードから最大8件を返すと説明されています。1台分のレコード定義は、たとえば次のような形です。
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "www.example.com",
"Type": "A",
"SetIdentifier": "web-11",
"MultiValueAnswer": true,
"TTL": 60,
"ResourceRecords": [{ "Value": "203.0.113.11" }],
"HealthCheckId": "your-health-check-id"
}
}これを台数分（SetIdentifier とIP、ヘルスチェックを変えて）並べ、aws route53 change-resource-record-sets で登録します。同じ名前で通常のシンプルなレコードが残っていると登録できないため、既存のレコードを削除する変更と同じ変更バッチにまとめると、応答が空になる時間を作らずに切り替えられます。作業前には現在のレコードを書き出してバックアップしてください。
自前で PowerDNS を運用している場合は、LUA レコードの ifurlup で、正常なアドレスだけを返す設定ができます。返すアドレスの選び方（1件だけか、正常なもの全部か）はオプションで指定する仕組みなので、使っているバージョンのドキュメントで指定方法を確認してください。
いずれの方式でも、すべてのサーバーが異常と判定されたときの応答がどうなるかは、サービスごとの仕様で決まっています。監視元からのアクセスをファイアウォールで止めて全台が異常扱いになる事故もあるため、監視元のIP範囲を許可しているか、事前に確かめておきます。
構成例3：重み付けで段階的に振り分ける
サーバーの性能差がある場合や、新しいサーバーへ少しずつアクセスを移したい場合は、重み付けのルーティングが向いています。Route 53 の加重ルーティングでは、レコードごとに重み（0〜255）を指定し、その比率でどのレコードを返すかが決まります。重みを0にしたレコードは、通常は返されなくなります。
新サーバー Weight 10 → おおよそ 10 / (10 + 90) の割合で返る
旧サーバー Weight 90ラウンドロビンが「全部のアドレスを並べて返す」のに対し、加重ルーティングは「問い合わせごとに1つのレコードを選んで返す」点が違います。こちらもヘルスチェックを関連付ければ、異常なレコードを候補から外せます。移行が終わったら旧サーバーの重みを0にし、TTL以上待ってアクセスがなくなったことを確認してから停止します。
どの構成でも、Webサーバーは「どれに当たっても同じ結果を返す」ことが前提です。WordPressなら、データベースの共有、アップロードファイルの共有、wp-config.php の認証キーとソルトの統一などを先にそろえてください。
構成の確認方法
まず、Anycastの各ネームサーバーが同じ値の集合を返しているかを見ます。並び順は違ってかまいませんが、含まれるIPがそろっている必要があります。
# ネームサーバーごとに、返るIPを並べ替えて比べる
for ns in $(dig +short example.com NS); do
printf '%s -> %s\n' "$ns" "$(dig +short www.example.com A @"$ns" | sort | tr '\n' ' ')"
done
# 公開リゾルバーごとの並び順（先頭のIP）を見る
for r in 8.8.8.8 1.1.1.1 9.9.9.9; do
printf '%s -> %s\n' "$r" "$(dig +short www.example.com A @"$r" | head -1)"
doneDNSの応答だけでは、実際にどのサーバーへどれだけ接続されたかは分かりません。分散の効果は、各Webサーバーのアクセスログで一定期間のリクエスト数を比べて判断します。構成例2では、1台のヘルスチェックURLを意図的に503にして、そのIPが応答から消えるまでの時間と、各サーバーのリクエスト数の変化をあわせて記録しておくと、障害時の見通しが立てやすくなります。
ここで説明した各サービスの機能名や上限値は、公式ドキュメントの説明に基づくものです（2026年10月現在）。変更されることがあるため、設定前に最新の情報を確認してください。
まとめ
- Anycast DNS がネームサーバーの層を、ラウンドロビンがWebサーバーの層を受け持つ構成です。
- 並び順は、権威DNSの各拠点、リゾルバーのキャッシュ、利用者のOSの3か所で変わるため、分散はおおよそになります。
- 素のラウンドロビンは止まったサーバーを外せず、ブラウザーの再試行も接続失敗のときしか働きません。
- 自動で外したいならヘルスチェック付きの複数値応答、段階的に移すなら重み付けを使います。
- 確認はネームサーバーごとの応答の比較と、各Webサーバーのアクセスログで行います。