Anycast の原理：1つのアドレスを世界に配る

Anycast とは何を解く技術か

通常のユニキャストは「1つの IP アドレス＝1台のホスト」という対応です。世界中のユーザーを1台で受ければ、遠い利用者ほど遅延が大きく、その1台が落ちれば全員が巻き添えになります。Anycast はこの前提を崩し、まったく同じ IP アドレス（同じプレフィックス）を、地理的に離れた複数の拠点が同時に名乗る方式です。ユーザーは1つのアドレスへ送るだけで、ネットワークが自動的に最寄りの拠点へ届けてくれます。

ポイントは、Anycast が新しいプロトコルではなく、既存のルーティングの性質をそのまま利用している点にあります。同じ宛先への経路が複数あれば、ルータは1本の最良経路を選びます。各地のルータから見れば「最良経路の先にある拠点」が自然と最寄りになる、というだけのことです。マルチキャストが「1対多の同報」なのに対し、Anycast は「多の中から最寄り1つへ」であり、目的がまったく異なります（同報系との対比はマルチキャストとブロードキャストを参照）。

同一プレフィックスを複数拠点から広告する

仕組みの核心は BGP の広告です。同じプレフィックス、たとえば 192.0.2.0/24 を、東京・ロンドン・サンパウロといった各拠点（POP）がそれぞれ自分の AS から外部へ広告します。

東京POP:      192.0.2.0/24 を AS64500 から広告
ロンドンPOP:  192.0.2.0/24 を AS64500 から広告
サンパウロPOP: 192.0.2.0/24 を AS64500 から広告

インターネット中のルータには、この同一プレフィックスへの経路が複数の方向から届きます。各ルータはそれを受け取り、BGP の経路選択アルゴリズムに従って1本の最良経路だけをルーティングテーブルへ入れます。AS_PATH が短い（通過 AS 数が少ない）経路ほど優先されるため、結果としてそのルータから見てネットワーク的に近い拠点が選ばれやすくなります。あるルータには東京が、別のルータにはロンドンが最良として見える——これが「1つのアドレスを世界に配る」の実体です。

なぜ広告するだけで負荷分散になるのか

各ルータが独立に最良経路を選ぶ結果、世界中のユーザーが自分にとって最寄りの拠点へ自然に振り分けられます。中央のロードバランサも、ユーザーへの設定配布も要りません。アドレスは1つでも、トラフィックは経路の地形に沿って各拠点へ分散します。

この「広告するだけ」という性質が、Anycast の運用上の強みです。拠点を1つ増やしたいなら、その拠点から同じプレフィックスを広告し始めるだけで、近隣のユーザーが新拠点へ吸い寄せられます。逆に拠点を抜きたいなら広告を止めればよく、ユーザー側には一切手を入れません。

DNS・CDN・DDoS 緩和への応用

Anycast が最も威力を発揮するのが、以下の3領域です。

DNS との相性は格別です。問い合わせは原則 UDP 1往復で完結し、サーバー側に接続状態が残りません。どの拠点が応答しても結果は同じなので、経路が途中で別拠点に切り替わっても害がありません。ルートDNSサーバーが13個の名前で世界中に何百ものインスタンスを展開できているのは、各レターが Anycast だからです（名前解決の流れはDNSを参照）。

CDN では、利用者を最寄りエッジへ向かわせる入口として Anycast を使います。CDN は DNS ベースの誘導と Anycast を併用することが多く、Anycast は「経路そのものに最寄り判定を任せられる」分、設定が単純で反応が速いという利点があります。

DDoS 緩和では、Anycast が攻撃トラフィックを地理的に分割します。世界中のボットからの攻撃は、それぞれの発生源にとっての最寄り拠点へ向かうため、1拠点に全量が集中しません。総容量を多数の拠点に分散できれば、各拠点は自分の取り分だけを捌けばよく、ネットワーク全体として大規模攻撃を吸収できます。

フロー切替という根本的な課題

Anycast の弱点は、経路は時間とともに変わりうるという事実から生じます。BGP の経路は固定ではなく、リンク障害や経路フラップ、ポリシー変更で**収束（convergence）が起きるたびに最良経路が入れ替わります。あるルータの最良経路が東京からロンドンへ切り替われば、そのルータを通る既存の通信は、通信の途中で宛先拠点が変わってしまうのです。これをフロー切替（再固定）**の問題と呼びます。

UDP 単発の DNS なら無害ですが、TCP や TLS のようにサーバー側に接続状態を持つ通信では致命的です。切り替わった先の拠点には、その TCP コネクションの状態（シーケンス番号や TLS セッション）が存在しません。新しい拠点は身に覚えのないパケットを受け取り、RST を返すか黙殺し、接続が切れます。

時刻 t0: クライアント ── TCP ──→ 東京POP（接続確立、状態あり）
時刻 t1: 経路収束で最良経路が切替
時刻 t2: クライアント ── 同じTCP ──→ ロンドンPOP（状態なし）→ RST
        結果: コネクション断、再接続が必要

切替問題への対処

状態を持つ通信を Anycast に乗せる場合の定石は、経路に最寄り判定だけをさせ、状態管理は別レイヤで吸収することです。

• 入口だけ Anycast：最初の接続先選定や DNS 応答のみ Anycast にし、その後の長い通信は拠点固有のユニキャスト IP へ誘導して固定する。最寄り選びの速さと、フロー固定の安全を両取りする最も実用的な構成です。
• 拠点間の状態共有：切り替わっても継続できるよう、拠点間でセッション状態を同期する。実装コストが高く、完全な同期は難しいため限定的に使います。
• 経路の安定化：Anycast プレフィックスの経路を意図的に安定させ、不要なフラップを抑える運用で切替頻度そのものを下げます。

なお、同一拠点内でさらに複数サーバーへ分散する局面では、ECMP とフローハッシュが同じ「フローを固定してリオーダリングを防ぐ」考え方で効きます。Anycast が拠点間の粗い振り分け、ECMP が拠点内の細かい振り分けと、層を分けて捉えると全体像が整理できます。

まとめ

Anycast は、同一プレフィックスを複数拠点から BGP で広告するだけで、各ルータの最良経路選択を通じて世界中のユーザーを最寄り拠点へ自動的に振り分ける仕組みです。中央の制御装置なしに低遅延・水平スケール・耐障害・攻撃分散を同時に実現できるのが最大の価値で、DNS・CDN・DDoS 緩和の基盤になっています。一方で、経路が変われば宛先拠点も変わるというフロー切替の課題があり、状態を持つ TCP/TLS では接続断を招きえます。だからこそ Anycast は状態を持たない通信に最も適し、状態が必要な場面では「入口だけ Anycast、本体はユニキャストへ固定」という役割分担で使うのが、原理に沿った正しい設計になります。