エニーキャスト（Anycast）
概要
エニーキャスト（Anycast） は、同一の IP アドレスを地理的に分散した複数の拠点に割り当て、ネットワークのルーティングプロトコルによって最も近い拠点にパケットを届ける通信方式です。RFC 4786（2007 年）でエニーキャストの運用手法が文書化されており、IPv6 ではRFC 4291（2006 年）でアドレスタイプの 1 つとして定義されています。
通常のユニキャストでは 1 つの IP アドレスは世界のどこか 1 か所にしか存在しません。エニーキャストでは同じアドレスを複数の拠点が BGP で広告するため、送信元に最もネットワーク的に近い拠点が応答します。「近い」とは物理的な距離ではなく、BGP の経路選択（AS パス長、ローカルプリファレンス等）に基づくネットワーク距離です。
DNS サービスはエニーキャストの代表的な利用例です。Cloudflare の 1.1.1.1 や Google の 8.8.8.8 は世界中の数百か所のデータセンターで同じアドレスを応答しています。ユーザーがどの地域からクエリを送っても最寄りの拠点が応答するため、低レイテンシと高い可用性を実現しています。
仕組み
エニーキャストは BGP の経路広告を活用し、同一 IP プレフィックスを複数拠点から同時にアナウンスすることで最寄り拠点へのルーティングを実現します。
BGP によるルート広告
エニーキャストは BGP（Border Gateway Protocol）の標準的な動作を利用しています。特別なプロトコル拡張は必要ありません。
- 同じ IP プレフィックス（例: 198.51.100.0/24）を東京、ロンドン、ニューヨークの 3 拠点で BGP に広告する
- 各 ISP のルーターは、同じプレフィックスに対して複数の経路を受け取る
- BGP の経路選択アルゴリズムに従い、最も「近い」（AS パス長が短い、ローカルプリファレンスが高い等）拠点への経路を選択する
- ユーザーのパケットは、選択された経路に従って最寄りの拠点に届く
ユーザー A（日本） → ISP → 東京拠点（198.51.100.0/24）
ユーザー B（英国） → ISP → ロンドン拠点（198.51.100.0/24）
ユーザー C（米国） → ISP → ニューヨーク拠点（198.51.100.0/24）全員が同じ宛先アドレスにパケットを送っていますが、到達する拠点は異なります。
ユニキャスト・ブロードキャスト・マルチキャストとの違い
| 方式 | 送信先 | パケットの届く先 |
|---|---|---|
| ユニキャスト | 1 対 1 | 特定の 1 台 |
| ブロードキャスト | 1 対全 | 同一セグメントの全ホスト |
| マルチキャスト | 1 対多 | グループに参加した複数台 |
| エニーキャスト | 1 対最寄 | 同じアドレスを持つ拠点のうち最も近い 1 か所 |
ブロードキャストとマルチキャストは 1 つのパケットが複数の宛先に届きますが、エニーキャストは 1 つのパケットが 1 か所にのみ届きます。どの 1 か所に届くかがネットワーク状況に応じて動的に決まる点が特徴です。
エニーキャストと TCP
エニーキャストは UDP ベースのプロトコル（DNS、NTP 等）と相性が良い設計です。UDP はステートレスで、1 つのリクエストに対して 1 つのレスポンスが返れば完結します。
TCP はステートフルなプロトコルであり、コネクションの確立から終了までパケットが同じ拠点に届く必要があります。BGP の経路変更が発生すると、途中からパケットが別の拠点にルーティングされてコネクションが切断される可能性があります。
この課題に対して、CDN プロバイダーは次の手法で TCP over Anycast を実現しています。
BGP の経路安定化では、頻繁な経路変更を抑制し、同一拠点へのルーティングを維持します。ECMP（Equal-Cost Multi-Path）の制御では、フローベースのハッシュで同一 TCP フローを同一拠点に固定します。QUIC（RFC 9000）は UDP 上に構築されたトランスポートプロトコルで、コネクション ID による接続の識別が可能なため、IP アドレスの変更にも対応できます。
Cloudflare は TCP と QUIC の両方でエニーキャストを運用しており、2024 年時点で 300 以上の都市にエニーキャストの拠点を展開しています。
DDoS 耐性
エニーキャストは DDoS 攻撃への耐性を備えています。攻撃トラフィックが 1 つの IP アドレスに集中しても、そのトラフィックは全拠点に分散されます。特定の拠点にトラフィックが偏った場合でも、その拠点の BGP 広告を停止すれば、トラフィックは自動的に他の拠点に迂回します。
ユニキャストでは 1 か所のサーバーにすべてのトラフィックが集中するため、攻撃の吸収能力が限られます。エニーキャストでは全拠点の処理能力の合計が防御力となります。
具体例
エニーキャストが実際に使われている DNS サービスと CDN の構成パターンを示します。
DNS サーバーのエニーキャスト構成
パブリック DNS サービスのエニーキャスト IP アドレスの例です。
# Cloudflare DNS
1.1.1.1（プライマリー）
1.0.0.1（セカンダリー）
# Google Public DNS
8.8.8.8（プライマリー）
8.8.4.4（セカンダリー）
# Quad9
9.9.9.9これらのアドレスはすべてエニーキャストで運用されています。ユーザーの地域に応じて最寄りのデータセンターが応答するため、世界中どこからでも低レイテンシで DNS クエリを実行できます。
CDN でのエニーキャスト
CDN（Content Delivery Network）はエニーキャストの代表的な利用例です。Web サイトのドメインに対して CDN のエニーキャスト IP を A レコードとして設定すると、ユーザーのリクエストは自動的に最寄りのエッジサーバーに到達します。
example.com. IN A 198.51.100.1この A レコードの 198.51.100.1 が CDN のエニーキャスト IP であれば、日本のユーザーは東京の拠点に、米国のユーザーはサンノゼの拠点に接続します。DNS の地理的なルーティング（GeoDNS）を使わなくても、BGP レベルで最適な拠点が選択されます。
確認方法
自分が接続している DNS リゾルバーのエニーキャスト拠点を調べるには、CHAOS クラスの TXT クエリが使えます。Cloudflare DNS の場合は次のコマンドです。
dig CH TXT id.server @1.1.1.1 +short"NRT"返される空港コード（NRT = 成田）が、応答した拠点の所在地を示します。
Google Public DNS の場合は、DNS クエリのレイテンシで最寄り拠点への到達を確認できます。
dig @8.8.8.8 example.com +stats;; Query time: の値がエニーキャストの効果を反映します。最寄りの拠点が応答していれば、通常 10 ミリ秒以下の応答時間になります。
traceroute で経路を確認することもできます。
traceroute -n 1.1.1.1経路上のホップ数が少なければ、近い拠点に到達していることがわかります。
外部の視点から DNS レコードの解決結果を確認したい場合は、Labee Dev Toolbox の DNS API を使うと、外部の視点から見た結果を取得できます。
curl "https://labee.dev/api/dns?domain=example.com&type=A"{
"success": true,
"data": {
"domain": "example.com",
"records": {
"A": [
{ "address": "93.184.215.14", "ttl": 300 }
]
}
},
"error": null,
"meta": { "responseTime": 12 }
}meta.responseTime が短い値を返す場合、エッジネットワーク（エニーキャスト）を通じて効率的に名前解決されていることを示します。
よくある問題
エニーキャスト環境で発生しやすい運用上のトラブルと対処法を整理します。
BGP 経路変更による TCP セッション断
BGP の経路が変更されると、同一 IP アドレスへのパケットが別の拠点に届くようになり、確立中の TCP コネクションが切断されます。DNS のような UDP ベースの短いトランザクションでは影響がほぼありませんが、長時間の HTTPS 接続やファイルダウンロード中に発生すると再接続が必要になります。QUIC プロトコルはコネクション ID でセッションを識別するため、ルーティング変更の影響を受けにくい設計です。
特定拠点への偏り
エニーキャストのルーティングは BGP の経路選択に依存するため、必ずしも地理的に最も近い拠点に到達するとは限りません。AS パス長やピアリングポリシーによっては、隣国にある拠点ではなく遠方の拠点にルーティングされることがあります。トラフィックの偏りを監視し、BGP のコミュニティ属性や広告の調整で最適化します。
ヘルスチェックの設計
エニーキャスト環境では、拠点のサービスが停止した場合にその拠点の BGP 広告を自動的に停止する仕組みが必要です。BGP の広告が残ったまま拠点が応答不能になると、ユーザーのリクエストがブラックホールに吸い込まれます。ヘルスチェックの監視間隔と BGP の収束時間を合わせて設計し、障害検知から経路切り替えまでの時間を短縮します。