# エニキャストルーティング ## 定義 エニキャストルーティング(Anycast Routing)は、同一のIPアドレスを複数の地理的に分散したサーバー(フロントエンド・PoP)で共有し、BGPのベストパス選択によりユーザーのリクエストを「最近接」のサーバーへ自動的に誘導する手法である。CDNでは、エニキャストアドレスを100以上のPoP全体でアナウンスすることで、明示的なDNSリダイレクションなしに低レイテンシルーティングを実現する。 Microsoft の Odin の観察では、エニキャストは60%のリクエストを最適フロントエンドへ送信するが、20%は最適より25ms以上悪いフロントエンドへ送信する([[@2018__NSDI__Odin - Microsoft's Scalable Fault-Tolerant CDN Measurement System]])。 **エニキャスト vs DNSリダイレクション**: - **エニキャスト**: BGPルーティングがFE選択を決定。ユーザーのLDNSとHTTPリクエストが同一FEに向くとは限らない - **DNSリダイレクション**: 権威DNSがLDNS単位でFEを指定。LDNSが広域分散ユーザーを服するとパフォーマンス低下 - Microsoft は2種を複合: ファーストパーティCDNにエニキャスト + ユニキャストパッチ、Azure TrafficManagerにDNSリダイレクション IPv6 の仕様レベルでは、エニキャストアドレスは送信元指定ルーティング(source-directed routing)の一部として導入された。個々のノードではなくトポロジ上の集合(例: あるバックボーンプロバイダの全ルータ)にアドレスを割り当て、ルーティングプロトコルが定める「最も近い」インタフェースへパケットを届けるための汎用的な仕組みであり、CDN でのフロントエンド選択に限定されない(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 4 Advanced Internetworking]] §4.2.4)。 ## 横断的知見 - **プロトコル仕様が「最も近い」を厳密に定義しないまま実運用でBGPのベストパスに委ねている実態が、CDNの計測研究で定量化されている**: 『Computer Networks: A Systems Approach』第4章は IPv6 エニキャストアドレスを「ルーティングプロトコルが定める最も近いインタフェースへ届く」とだけ定義し、「最も近い」がどう決まるか(ホップ数か、BGP のパス属性か、性能か)には踏み込まない。Odin 論文の計測はこの仕様上の空白を実測で埋めており、BGP のベストパス選択がネットワーク性能を考慮しないために、エニキャストで選ばれる「最も近い」フロントエンドが実際には性能面で最適でないことが 20% のリクエストで観測される。仕様が意図的に(あるいは単に)未規定のままにした「最も近い」の実装依存性が、CDN の実運用でどれだけの性能コストを生むかを、教科書とは異なる粒度で示している。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 4 Advanced Internetworking]] §4.2.4, [[@2018__NSDI__Odin - Microsoft's Scalable Fault-Tolerant CDN Measurement System]]) - **エニキャストの性能盲目性**: BGPはネットワーク性能を考慮せずベストパスを選択するため、循環ルーティングや遠隔FEへの誘導が発生する。Odinの計測では20%のリクエストが最適より25ms以上悪いFEへ送信される。DNS転送との複合でこの弱点を補完できる——両者の性能悪化要因は相関しないため(Source: [[@2018__NSDI__Odin - Microsoft's Scalable Fault-Tolerant CDN Measurement System]]) - **ユーザー・LDNS分離問題**: エニキャストとDNSリダイレクションをリージョナルに組み合わせると、ユーザーのLDNSと自身が異なるリージョンのFEに誘導される場合がある(Figure 6の3シナリオ)。グラフ分割でリージョンを設計してもP75で約3%のレイテンシ劣化が生じる(Source: [[@2018__NSDI__Odin - Microsoft's Scalable Fault-Tolerant CDN Measurement System]]) - **EDNS Client Subnet(ECS)の普及不足**: ECSはユーザープレフィックス粒度のDNSリダイレクション決定を可能にするが、大手パブリックリゾルバ以外ではほぼ採用されていない。Odinの計測が示す実態(Source: [[@2018__NSDI__Odin - Microsoft's Scalable Fault-Tolerant CDN Measurement System]]) - **エニキャストリングによる負荷分散**: 複数のエニキャストIPアドレス(リング)を設計し、過負荷時にDNSでより小さいリングへ誘導する方式(FastRoute、Odin/Microsoft)が実用化されている。リングの設計にはFEごとの制御可能性(HTTP・DNS要求の相関)計測が必要(Source: [[@2018__NSDI__Odin - Microsoft's Scalable Fault-Tolerant CDN Measurement System]]) - **エニキャストCDNの性能評価(Odin)は、CDN事業者への依存が生む構造的な集権化リスクを問わない——第6章はその欠落を補う異なる評価軸を提示する**: 本ページはOdin論文にもとづき、エニキャストがFE(フロントエンド)選択の性能(最適FEへの到達率60%、25ms以上悪化する割合20%)を評価してきたが、この評価軸はCloudflare・Fastly・AkamaiのようなCDN事業者そのものへの依存度は問題にしない。[[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 6 集権化と非集権化]]は同じCDN/ホスティングインフラ層について、「少数のサービスへの過度な依存」がインターネットの脆さを生むという別の評価軸を提示し、Mastodonインスタンスのホスティング先AS分布(図6.3: OVHcloud・Cloudflareが最多も各10%程度、小規模ASの合計が11,000インスタンス相当)を実例として示す。エニキャストの性能評価とAS分布の集中度評価は、同じCDN/ホスティング層に対する「速いか」と「偏っていないか」という独立した問いであり、両者を併せて評価する枠組みは本wikiにまだない。(Source: [[@2018__NSDI__Odin - Microsoft's Scalable Fault-Tolerant CDN Measurement System]], [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 6 集権化と非集権化]] ch.6 §6.4) - **RIA第3章は、本ページが「仕様レベルで未規定」と指摘してきたエニキャストの「最も近い」の決定メカニズムを、ブリッジングされたAS間のBGP経路選択として具体的に説明する**: 本ページはSystems Approach第4章の「ルーティングプロトコルが定める最も近いインタフェースへ届く」という抽象的な定義と、Odin論文が示す実測のずれ(20%が最適より25ms以上悪化)を対比してきた。RIA第3章§3.2.2.3は、この「最も近い」の決定メカニズムをブリッジング(bridging)の実例として具体化する——同じ名前Aを持つエニキャストグループの各サーバのアクセスネットワークがAへの経路をBGPで広告し、複数の広告(ビジネス関係上等価なもの)を受け取ったネットワークは、トランジットネットワーク数で測った最短経路を選ぶ。「最も近い」とは物理的な距離ではなく、ビジネス関係で等価な経路群の中でのASホップ数の最小値であることが明示される。これはOdinが観測した性能ギャップ(BGPが性能を考慮しないこと)の形式的な根拠を与える——ASホップ数の最小化は必ずしも遅延の最小化と一致しない。(Source: [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 3 Composing Networks and Services]] §3.2.2.3, [[@2018__NSDI__Odin - Microsoft's Scalable Fault-Tolerant CDN Measurement System]]) - **RIA第3章は、Webの負荷分散という文脈でIPエニキャスト(解法II)の限界を「セッションアフィニティの欠如」と定式化し、本ページが記録するanycast TCPセッション切断問題に形式的な説明を与える**: 本ページの未解決の問いは「BGPルーティング変化でlong-lived TCP接続が切断される問題をどう解決するか」を問うてきた。RIA第3章§3.3.5.5は、この現象を「各パケットが独立に転送されるため、セッション途中でBGP経路がエニキャストグループ名への別メンバーへ変わりうる」と定式化し、これが解法IIの持つ「唯一の欠点」であると位置づける。同時に、解法IV(Level 7ロードバランサ)が持つ「唯一の利点」であるコンテンツシャーディングとの対比によって、エニキャストが構造的に持つトレードオフ(セッションアフィニティを諦める代わりに真に分散したサーバ配置ができる)を明確にする。(Source: [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 3 Composing Networks and Services]] §3.3.5.5) - **SRE Book第19章は、本ページがOdin論文・RIA第3章で記録してきた「コンテンツサーバのIPアドレスとしてのエニキャスト」とは異なる用途——権威DNSネームサーバー自体のアドレスとしてのエニキャスト——を報告し、用途が変わっても同型の限界に行き着くことを示す**: SRE Book第19章は、DNSクエリを権威ネームサーバーのエニキャストアドレスへ送ることで最も近いネームサーバーに到達させ、さらなる改良として「ネットワークとその概略の物理的位置のマップ」を保持することでより精度の高いDNS応答を返す方式を報告する。しかしこの用途でも、本ページが既に指摘してきた限界——DNSクエリの送信元IPが実ユーザーではなく再帰リゾルバのものになるため、エニキャストで到達したネームサーバーが返す応答は「リゾルバから見て最も近い」ものであり「ユーザーから見て最も近い」とは限らない——が残るとSRE Book自身が明記している。Odin論文が報告する「ユーザー・LDNS分離問題」と同じ構造の限界が、エニキャストの適用対象をコンテンツサーバーからDNSネームサーバーへ変えても再現することを示す。(Source: [[@2016__OReilly__SRE Book - Chapter 19 Load Balancing at the Frontend]], [[@2018__NSDI__Odin - Microsoft's Scalable Fault-Tolerant CDN Measurement System]]) ## 未解決の問い - SRE Book第19章が報告する「ネットワークと物理的位置のマッピングによるDNS応答精度向上」は、Odinのエニキャストリング設計(FastRoute)のような負荷ベースの動的な縮退と同じ仕組みで実装されているか、独立した仕組みか。SRE Book第19章は「より複雑なDNSサーバー実装とマッピング更新パイプラインの維持」というコストを述べるのみで、実装の詳細には踏み込んでいない。 - エニキャストCDNの性能最適化(FastRoute等のリング設計)とAS分布の非集権化は両立するか。特定少数のASに性能上有利なPoPが偏在する場合、性能最適化がAS集中を助長する可能性はないか。 - BGPルーティング変化でlong-lived TCP接続が切断される問題(anycast TCP session disruption)をアプリケーション層透過的に解決する手法は? - エニキャストとDNSリダイレクションの複合で、ECS普及後の世界でどう設計が変わるか? - グローバルエニキャストからリージョナルエニキャストへの移行で、高パーセンタイル(P90/P99)のレイテンシ劣化が経時増加する原因と対策は? ## 関連 - [[分散エニーキャストゲートウェイ]]: 同じ「エニーキャスト」の発想を CDN/DNS の経路選択ではなく、EVPN の L3 デフォルトゲートウェイ(全 PE が同一 IP/MAC で応答)へ適用した特殊形。目的が「最近接1ノードへの収束」ではなく「モビリティ透過性」である点が異なる - [[CDN計測システム]]: エニキャスト性能を継続計測・パッチするOdinの仕組み - [[ネットワーク監視]]: データセンター内ネットワーク監視(エニキャストはWAN領域で補完的) - [[集権化と非集権化]] / [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 6 集権化と非集権化]]: CDN/ホスティング層のAS集中度という、性能評価とは独立した集権化リスクの評価軸 - [[階層的ルーティングとアドレス集約]] / [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 4 Advanced Internetworking]]: IPv6 エニキャストアドレスの仕様上の定義(source-directed routing) - [[ブリッジング]] / [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 3 Composing Networks and Services]]: BGPブリッジングによるエニキャストの形式的な決定メカニズム、Webの負荷分散におけるセッションアフィニティの欠如 - [[@2016__OReilly__SRE Book - Chapter 19 Load Balancing at the Frontend]]: 権威DNSネームサーバー自体のアドレスとしてのエニキャストの用途、再帰リゾルバ介在による限界の再現 ## 出典 - [[@2018__NSDI__Odin - Microsoft's Scalable Fault-Tolerant CDN Measurement System]]: エニキャストCDNの性能特性と計測ベースのパッチ適用の一次資料 - Larry Peterson・Bruce Davie 著, 進藤資訓 訳, 『ネットワークシステムについて語るときに我々の語ること』, ラムダノート, 2026, 第 6 章 §6.4. - Larry Peterson and Bruce Davie, *Computer Networks: A Systems Approach*, 6th edition, Chapter 4: Advanced Internetworking, §4.2.4. https://book.systemsapproach.org/scaling.html - Pamela Zave, Jennifer Rexford, *The Real Internet Architecture*, Princeton University Press, 2024, Chapter 3, §3.2.2.3, §3.3.5.5. - Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (eds.), *Site Reliability Engineering: How Google Runs Production Systems*, O'Reilly, 2016, Chapter 19.