Anycast / CDN

edge-computingnetworkingcdnanycastbgp

Edge Computing における「近さ」を実現する技術。Anycast は L3 で最寄りの PoP にパケットを自動ルーティングし、CDN はその上にキャッシュ階層を構築する。Edge CDN はさらにコンピュートを追加して「近い場所でコードも実行できる」世界を実現した。

IP ルーティングの4方式

方式送信:受信定義用途
Unicast1:1特定の1つの IP に送信HTTP, SSH
Broadcast1:全ネットワーク全体に送信ARP, DHCP
Multicast1:Nオプトインしたグループに送信IPTV, ストリーミング
Anycast1:最寄り1台同一 IP を複数拠点が共有。最も「近い」1台にルーティングDNS, CDN

Anycast の仕組み

同一 IP を複数拠点でアナウンス

graph TD
    Client["クライアント"] -->|"HTTPS (Anycast IP)"| BGP["BGP ルーティング"]
    BGP -->|"最短パス"| Tokyo["PoP 東京<br/>同一 IP をアナウンス"]
    BGP -.->|"次に近い"| London["PoP ロンドン<br/>同一 IP をアナウンス"]
    BGP -.->|"遠い"| NY["PoP NY<br/>同一 IP をアナウンス"]
  1. 各 PoP が同一の IP プレフィックス (通常 /24) を BGP で上流にアナウンス
  2. インターネット上のルーターが同一プレフィックスへの複数経路を保持
  3. BGP 経路選択アルゴリズムに基づき「最良」の経路を選択
  4. クライアントのパケットがトポロジカルに最も「近い」PoP に到達

「最も近い」≠ 物理距離

Anycast の「近さ」は BGP メトリクス (AS パス長等) で測った最短パスであり、物理的な地理距離とは一致しない。海底ケーブルの容量や ISP のピアリング関係が影響する。

BGP 経路選択の主要ステップ

優先度属性選択基準Anycast での重要度
2LOCAL_PREF最大値最重要。CDN 事業者がトラフィック制御に使用
4AS_PATH 長最短重要。AS Prepending で人為的に延長可能
6MED最小値隣接 AS への入口選好の提案
8IGP メトリック最小値Hot Potato Routing
9ECMP等コスト全経路等コスト経路間の負荷分散

DNS ルーティング vs Anycast ルーティング

比較DNS ベース (GeoDNS)Anycast ベース
動作層L7 (アプリケーション)L3 (ネットワーク)
仕組みDNS リゾルバの IP から位置推定 → 最寄り PoP の IP を応答全 PoP が同一 IP を BGP 広告。IP 層で最寄りに到達
TTL 依存あり。キャッシュ期限まで古い IP を使用なし。即座にルーティング
位置精度DNS リゾルバの位置に依存クライアント自身のネットワーク位置
フェイルオーバーDNS TTL 期限切れまで障害 PoP に向くBGP 経路撤回で秒単位
制御粒度高い (地域・言語別に細かく制御可能)低い (BGP に委ねる)

現代の CDN は Anycast + GeoDNS + L7 Steering の3層ハイブリッド。

CDN の仕組み

キャッシュ階層 (4層モデル)

graph TD
    Client["クライアント"] --> L1["Edge Cache (L1)<br/>各 PoP。RAM + SSD<br/>ヒット率 ~80%"]
    L1 -->|MISS| L2["Regional Cache (L2)<br/>大陸ごとに1つ<br/>累積ヒット率 ~95%"]
    L2 -->|MISS| L3["Origin Shield (L3)<br/>全ミスが集約<br/>1000同時ミスを1リクエストに結合"]
    L3 -->|MISS| Origin["Origin (L4)<br/>全トラフィックの ~1%"]

Origin Shield のリクエスト結合: 1000クライアントが同時にキャッシュミスしても、Origin には1リクエストしか送らない。Cloudflare: Argo Tiered Cache、Fastly: Shielding。

TLS 終端

CDN の最大の性能貢献の一つ。シドニー→バージニアで直接 TLS ハンドシェイクすると 2 RTT (~700ms)。PoP でローカルに終端することでこのレイテンシを排除。

キャッシュ制御

ディレクティブ説明
max-age=NN秒間キャッシュ有効
s-maxage=NCDN 向け TTL (max-age より優先)
stale-while-revalidate=N期限切れ後 N秒間、古い応答を返しつつバックグラウンドで再検証
stale-if-error=Nオリジンエラー時、N秒間古い応答を提供
immutableコンテンツ不変。再検証しない

推奨戦略:

キャッシュキーの注意

TCP と Anycast の問題

TCP はコネクション指向。通信中に BGP の経路が変更されると:

  1. パケットが別 PoP に到達
  2. 新 PoP に TCP 状態がない
  3. TCP RST (リセット) → コネクション断

対策

対策効果
BGP の安定性確保保守的なポリシーでルート変更を抑制
BFD1秒未満の障害検出 → BGP 収束を高速化
ECMP一貫性ハッシュでフロー固定
QUIC / HTTP/3Connection ID でコネクション識別。IP 変更でも接続維持

QUIC が Anycast の問題を構造的に解決

Anycast の利点

利点詳細
DDoS 耐性攻撃トラフィックが全 PoP に自動分散。ネットワーク全体の容量が攻撃耐力
低レイテンシBGP で最寄り PoP に自動ルーティング。DNS 遅延なし
高可用性PoP 障害時、BGP 経路撤回で秒単位フェイルオーバー。DNS TTL 待ち不要
UDP との親和性DNS (1.1.1.1, 8.8.8.8) 等の短トランザクションに最適

Edge Computing と Anycast

従来 CDN vs Edge CDN

従来 CDNEdge CDN
できること静的コンテンツのキャッシュ・配信キャッシュ + 任意のコード実行
パーソナライズ不可可能 (リクエストごとに動的生成)
オリジン依存動的コンテンツは必ずオリジンに転送Edge で処理完結可能

Anycast + Edge Compute = グローバル分散コンピュータ

  1. Anycast: デプロイ先を意識せず、全リクエストが最寄り PoP に到達
  2. Edge Compute: PoP 上で任意のロジックを実行 (V8 Isolates / WASM)
  3. 分散ストレージ: KV, D1, R2, Durable Objects で Edge に状態を持てる
  4. ゼロコンフィグ: コード push → 330+ PoP に即座にデプロイ

従来の「リージョン選択 → デプロイ → LB 設定」というクラウドの運用モデルとは根本的に異なる。

主要 CDN プレイヤー

CDNPoP 数AnycastEdge Compute
Akamai4,100+DNS 主体 + Anycast DNSEdgeWorkers + Spin (WASM)
CloudFront450+DNS ベース (Route 53 Anycast)Lambda@Edge / CF Functions
Cloudflare335+全面 AnycastWorkers (V8 Isolates)
Google Cloud CDN180+AnycastCloud Functions/Run 連携
Fastly~80AnycastCompute (WASM)

PoP 数の注意: 定義がプロバイダーごとに異なる。Akamai は ISP 内の単一サーバー、Cloudflare はフルスタックデプロイ。330 PoP が 1,500 PoP とメディアンレイテンシで同等以上のケースもある。

「近さ」の実現スタック

graph TB
    L7["L7: GeoDNS + L7 Steering<br/>地域・コンテンツ種別・負荷に基づく制御"]
    L4["L4: QUIC / HTTP/3<br/>コネクションマイグレーションで Anycast + TCP の問題を解決"]
    L3["L3: Anycast + BGP + ECMP<br/>IP レベルで最寄り PoP に自動ルーティング"]
    Phys["物理: PoP 配置 + ISP ピアリング<br/>335-4,100+ 拠点を世界中に物理配置"]
    L7 --> L4 --> L3 --> Phys

押さえどころ（カード化候補）

関連

Graph

Backlinks