サブ秒フェイルオーバー：AnycastからUnicastへのリバースIngressファブリック設計

現代の大規模分散型マルチリージョンクラウドアーキテクチャにおいて、「高可用性」の定義は根本的に変化しています。従来の知恵では、ローカライズされたデータセンターが停止した場合、ディザスタリカバリプロトコルがDNSレコードを書き換え、トラフィックをバックアップサイトに誘導していました。

しかし、今日では、そのアプローチは遅延に敏感なワークロードには時代遅れです。DNSによるフェイルオーバーは、信頼性の計算に許容できない変数を導入します：TTLキャッシングです。現代のインフラは、代わりにBGP AnycastルーティングとAnycast-to-Unicastプロキシのカプセル化を採用しています。グローバルに分散したエッジでトラフィックをインターセプトし、ステートレスなトンネルで動的にラップすることで、ネットワークアーキテクチャはミリ秒単位でローカライズされた障害を迂回でき、DNSを完全にバイパスします。

DNSベースのマルチリージョンフェイルオーバーの脆弱性

Anycast-to-Unicast ingressファブリックの必要性を理解するには、まずDNSがなぜ根本的にリアルタイムのフェイルオーバーに適していないのかを解体する必要があります。

DNSはグローバルに分散された階層型データベースです。クライアントがapi.enterprise.comのAPIエンドポイントに接続しようとすると、リカーシブリゾルバに問い合わせ、権威サーバに問い合わせてドメインをIPv4またはIPv6アドレスに解決します。インターネットの負荷を軽減するために、各応答にはTTL値が含まれ、リゾルバとクライアントのOSに一定期間キャッシュさせる指示を出します。

もし、プライマリのUS-Eastデータセンターが大規模な停電に見舞われた場合、グローバルトラフィックマネージャは障害を検知し、権威DNSレコードを書き換えてUS-Westのバックアップリージョンを指すようにします。TTLを30秒に設定しているとしましょう。

しかし、解決チェーン全体をコントロールできるわけではありません。

Zombieキャッシュ: 多くのインターネットサービスプロバイダ（ISP）や企業ネットワークは、帯域幅削減のために低TTL値を無視し、TTLを15分や30分に人工的に引き延ばします。

クライアント側のスタブリゾルバ: WebブラウザやOSは独自に積極的なDNSキャッシュを実装しています。ユーザのブラウザは、ISPのキャッシュがクリアされた後も死んだIPアドレスを長く保持し続けることがあります。

伝播遅延: 最良の場合でも、グローバルDNSの更新には時間がかかります。

これらの遅延の間、トラフィックはブラックホールに向かって突き進み続けます。クライアントアプリケーションはタイムアウトし、APIリクエストは失敗し、重要なデータベースの同期も崩れます。標準的なウェブ閲覧では数分のダウンタイムは小さな不便かもしれませんが、ミッションクリティカルなワークロードにとっては壊滅的です。

これは仮想のリスクではなく、2025年10月19〜20日にAWSのUS-EAST-1リージョンでAmazon DynamoDBに広範な障害が発生した事例が示す通り、DNSの自動化自体が単一障害点となり得ることを証明しています。AWSの公式ポストイベント概要によると、障害は午後11時48分PDTに始まり、Route 53レコードの同期を担当する2つの独立した「DNS Enactor」プロセス間のレースコンディションにより、リージョナルDynamoDBエンドポイントのDNSレコードが空になったことに起因します。システムの自動化はこの不整合を検知・修復できず、手動操作が必要となり、DNS状態は午前2時25分頃に完全に復旧しました。この障害はEC2インスタンスの起動、Network Load Balancerのヘルスチェック、Lambda、その他多くの依存サービスに連鎖し、ほぼ一日続きました。これは、DNSの脆弱性がキャッシュの問題だけではなく、ハイパースケールでもDNSが単一の調整ポイントであることを示す、現実的な警鐘です。

リアルタイムの必要性：産業用IoTとデジタルツイン

高度な産業用IoT（IIoT）ミラーリングに必要なネットワークアーキテクチャを考えてみましょう。現代の製造工場は、NVIDIA Omniverseのローカルブリッジを利用して、大量のリアルタイムセンサーデータをクラウドベースのデジタルツインにストリーミングしています。このクラウド上の3Dモデルは、物理的な機械とミリ秒単位で同期し続ける必要があります。

もし、このテレメトリを処理するプライマリクラウドリージョンがダウンした場合、デジタルツインは物理ハードウェアから同期を失います。物理世界で自動安全オーバーライドがトリガーされても、クラウドのシミュレーションにアクセスできないと、予測保守モデルが破損する可能性があります。これらの超低遅延トンネル環境では、DNSレコードの伝播を待つ60秒は永遠です。フェイルオーバーはパケット層で行われ、クライアントには見えず、サブ秒単位で完了する必要があります。

グローバルエッジ：BGP Anycastルーティング

サブ秒フェイルオーバーの基盤はBGP Anycastです。従来のUnicastネットワークでは、単一のIPアドレスが特定の地理的場所にある単一のサーバまたはロードバランサに対応します。

Anycastはこの1:1のマッピングを破ります。Border Gateway Protocol（BGP）を利用して、ネットワークエンジニアは同じIPアドレス（例：198.51.100.25）を世界中の複数のエッジロケーションから広告できます。

ベルリンのクライアントがそのIPアドレスに接続しようとすると、インターネットのコアルーターはBGPテーブルを評価し、最短のAutonomous System（AS）経路を見つけ出します。ルーティングプロトコルは、クライアントのTCP SYNパケットを最も近いエッジデータセンター（例：フランクフルト）に自然に誘導します。一方、東京のクライアントは同じIPアドレスに接続しても、大阪のエッジノードにルーティングされます。

Anycastのステートフル性の問題

Anycastは最も近い地理的ポイントにトラフィックをルーティングするのに優れていますが、TCPのようなステートフルなプロトコルには深刻な問題をもたらします。

BGPは動的プロトコルです。インターネット上のリンクがダウンすると、ルーティングテーブルは再計算されます。セッション中に経路が変わると、最初はフランクフルトに流れていたパケットが突然パリにルーティングされることがあります。パリはフランクフルトで行われたTCPハンドシェイクを記憶していないため、パケットを黙ってドロップしたり、TCP RSTを送信したりします。

さらに、Anycastエッジノードは複雑なバックエンドデータベースクエリや3Dシミュレーションのレンダリングを直接処理できません。エッジはあくまでグローバルに分散したIngressポイントに過ぎず、実際の計算負荷はローカルなバックエンドデータセンター（Unicast宛先）で行う必要があります。

これが、Anycast-to-Unicastプロキシアーキテクチャが必須となる理由です。

Anycast-to-Unicastプロキシの設計

ステートフルな接続を切断せずにAnycastをグローバルIngressに利用するには、企業ネットワークはLayer 4（トランスポート層）のロードバランサをエッジPoP（ポイント・オブ・プレゼンス）に展開します。TCP接続をエッジで終了させるのではなく、これらのルーターはステートレスなパケットフォワーダーとして機能し、インバウンドのAnycastトラフィックをキャプチャしてトンネル内にカプセル化し、特定のUnicast IPアドレス（バックエンドサーバ）に転送します。

4つのプロダクションシステムと4つのトレードオフ

これは理論的なアーキテクチャではなく、いくつかのハイパースケール運営者が公開し、場合によってはオープンソース化している実装例です。それぞれの違いは非常に参考になります。

GoogleのMaglevは、NSDI 2016で発表されたシステムで、全体のアプローチを普及させました。ECMPルーターの背後にあるLinuxサーバ上で動作し、GRE（RFC 2784、RFC 2890で更新）を用いてフローをカプセル化し、リプライにはDirect Server Returnを採用しています。リングベースの「一貫性のあるハッシュ」ではなく、独自のMaglevハッシングを使用し、各バックエンドが生成する優先度の置換を用いた大きなテーブル（例：65,537エントリ）を構築します。これにより、負荷分散の均一性が向上し、1,000バックエンドに対しても効率的に動作します。

GitHubのGLB Directorは、2018年にオープンソース化され、現在もGitHubのデータセンター間トラフィックを支える主要なロードバランサです。Rendezvous Hashing（最高ランダム重み付けハッシュ）を基にし、SipHashを用いています。静的な65,536行のフォワーディングテーブルを作成し、各行にプライマリとセカンダリのバックエンドを記録。glb-redirectというiptablesモジュールを使い、切り離し中や失敗したバックエンドも稼働中の接続をフォワード可能にしています。DPDKを用いたカーネルバイパス処理と、拡張されたGUEを使ったカプセル化を行います。

CloudflareのUnimogは、Cloudflareのエンジニアリングブログで紹介されており、Anycastが既にパケットをエッジに届けた後の負荷分散を担当します。XDPを用いてエッジ内のサーバ間の負荷分散を行い、リージョン間のリルートはTraffic Managerと呼ばれる別システムが担当します。

MetaのKatranは、2018年にオープンソース化され、eBPFとXDPを利用してカーネル内でパケット処理を行います。MaglevやGLBよりもカーネルに近い処理を行い、低CPUオーバーヘッドを実現しています。IPIPカプセル化をデフォルトとし、必要に応じてGUEも使用します。

なぜNATではなくカプセル化？

従来のロードバランサは、NAT（Network Address Translation）を用いて受信パケットの宛先IPを変更していました。しかし、NATは大量のコネクション状態テーブルを維持する必要があり、エッジノードが故障するとテーブルも消失し、数百万のコネクションが切断されます。真の耐障害性を確保するには、エッジは完全にステートレスでなければなりません。

そのため、Anycastプロキシは元のIPヘッダを変更せず、パケットを完全に保持したまま新しい外側のIPパケットにラップします。これがカプセル化です。

GREとGeneveトンネルプロトコル

Anycast-to-Unicastのカプセル化に使われる代表的なプロトコルはGRE（RFC 2784、RFC 2890で拡張）とGeneve（RFC 8926）です。

GRE（IP Protocol 47）: RFC 2784で定義され、RFC 2890でKeyやSequence Numberのフィールドが追加された成熟したプロトコルです。最小のオーバーヘッドは24バイト（20バイトのIPv4外部ヘッダ＋4バイトのGREヘッダ）です。外側のヘッダのSource IPはエッジルーターのIP、Destination IPはバックエンドのUnicastサーバのIPです。

Geneve（UDPポート6081）: RFC 8926で2020年11月に正式化された拡張性の高いプロトコルです。UDPでペイロードをカプセル化し、従来のネットワークハードウェアやECMPハッシュに対応します。最小オーバーヘッドは36バイト（20バイトIPv4＋8バイトUDP＋8バイトGeneveヘッダ）で、TLVメタデータを付加するとさらに増加します。拡張性がGeneveの最大の特徴です。

カーネルバイパス世代：GUE、XDP、eBPF

GREとGeneveは、パケットをLinuxのネットワークスタックに渡す点では共通ですが、ハイパースケールのパケットレートにはボトルネックとなります。これを超えるために、GUE（Generic UDP Encapsulation）、XDP（eXpress Data Path）、eBPFといった技術が登場しています。

GUEは、IETFのドラフトで、シンプルで拡張性のあるUDPヘッダを持ち、GitHubのGLBやMetaのKatranで採用されています。ただし、ドラフトはRFC化されていません。

XDPとeBPFは、Katranの例に見られるように、NICドライバの直後や内側でパケットを検査・再カプセル化し、カーネルのネットワークスタックをバイパスします。これにより、DPDKに匹敵するスループットと低遅延を実現しつつ、NICの排他制御を避けることが可能です。

一貫性ハッシュ：ステートレス性の魔法

エッジプロキシがステートレス（接続テーブルを持たない）場合、特定のTCPフローのパケットを常に同じUnicastサーバにルーティングするにはどうすればよいでしょうか？

答えは一貫性ハッシュです。パケットの5-tuple（Source IP、Source Port、Destination IP、Destination Port、Protocol）をハッシュし、決定的な整数値を生成します。これを仮想ハッシュリングにマッピングするのが基本的な考え方ですが、実運用では、Maglevは独自の置換テーブルを使い、GLBはRendezvous Hashingを採用しています。これらは、サーバの追加や削除による影響を最小化しつつ、同じフローが常に同じサーバに割り当てられることを保証します。

ハッシュ関数は高速な非暗号的関数（例：SipHash）を用い、ハッシュの決定性により、TCPストリーム内のすべてのパケットが同じUnicastサーバにルーティングされ、接続状態をエッジが保持する必要がありません。

サブ秒マルチリージョンフェイルオーバーの実例

グローバルAnycast ingress層とステートレスなカプセル化アーキテクチャを導入すれば、DNS TTLの制約を完全に超えたサブ秒フェイルオーバーが可能です。

以下は、マルチリージョンフェイルオーバーのシナリオにおける一連の流れです：

1. 通常状態

製造施設からのリアルタイムセンサーデータが198.51.100.25（Anycast IP）に向かいます。

インターネットはこのパケットを最も近いシカゴのエッジPoPにルーティングします。

シカゴのエッジプロキシは、パケットの5-tupleにハッシュをかけ、その結果に基づき10.100.5.50（プライマリのUS-East（オハイオ）データセンターのUnicastノード）に処理させます。

シカゴのエッジはセンサーデータをトンネル内にカプセル化し、オハイオに送信します。

オハイオのサーバはパケットをデカプセル化し、テレメトリーを処理し、クラウドのデジタルツインを更新します。

2. 壊滅的な障害

UTC 14:00:00に、オハイオのデータセンターで大規模な電力異常が発生します。10.100.5.xの計算ノードは停止します。

DNSに依存している場合、監視システムは14:01に障害を検知し、14:02にDNS APIを呼び出し、クライアントは14:03から14:15の間に新しいIPアドレスをキャッシュし始めます。IIoTセンサーの同期は完全に崩れます。

3. パケットレベルのリルート

Anycast-to-Unicastアーキテクチャでは、エッジプロキシ（例：シカゴ）は、500ミリ秒ごとにバックエンドのUnicast IPに対して積極的なヘルスチェックを行います。

UTC 14:00:01に、シカゴのエッジはオハイオ地域の連続したヘルスチェック失敗を記録します。

エッジルーターは即座にオハイオのUnicast IPをフォワーディングテーブルから除外し、代わりにUS-West（オレゴン）のバックアップリージョンのIPに置き換えます。

次のセンサーパケット（UTC 14:00:02）では、ハッシュを再計算し、結果は10.200.8.80（オレゴンのサーバ）にマッピングされます。

パケットはカプセル化されてUS-Westに送信されます。

結果として、クライアントアプリは最大1秒のパケット損失を経験します。TCPセッションは一時的な再送ウィンドウを経ても維持され、完全にネットワーク層でルーティングが切り替わります。DNSレコードの変更は不要で、クライアントはプライマリデータセンターの障害に気付かずに済みます。

逆方向のパス：Direct Server Return（DSR）

Anycastエッジプロキシを経由したトラフィックのルーティングの複雑さの一つは、リターントラフィックの管理です。バックエンドのオレゴンのサーバがリクエストをデカプセル化し処理した後、レスポンスをクライアントに返すと、Chicagoエッジに戻すと遅延が増大し、帯域も二重に消費します。

これを解決するために、Maglev、GLB、Unimog、Katranの4つのシステムはすべてDirect Server Return（DSR）を採用しています。

バックエンドのUnicastサーバがトンネルをデカプセル化すると、元のクライアントパケットを抽出します。レスポンスを生成する際、オレゴンのサーバはエッジプロキシを経由せずに、送信先IPはクライアントのIPにしつつ、送信元IPはグローバルAnycastアドレス（198.51.100.25）を偽装します。

オレゴンのデータセンターはこのレスポンスを直接インターネットに注入します。クライアントは、最初に接続したAnycast IPから発信されたTCPパケットを受け取り、実際には2,000マイル離れたバックアップサーバから生成されたものだとは気づきません。DSRにより、エッジプロキシは軽量なインバウンドリクエストだけを処理し、大規模なDDoS攻撃にも耐えられるスケーラビリティを確保します。

アーキテクチャ上の課題と考慮点

高可用性のためのAnycast-to-Unicast ingressは理想的ですが、技術的な課題も伴います。これを実現するには、深いネットワーク知識とプロトコルのオーバーヘッドの適切な管理が必要です。

MTUとMSSの制御

カプセル化はオーバーヘッドを伴います。標準のEthernetフレームの最大伝送単位（MTU）は1500バイトです。クライアントが1500バイトのIPパケットを送信し、エッジプロキシが24バイトのGREヘッダや36バイトのGeneveヘッダを追加すると、パケットはMTUを超え、途中のルーターでドロップされるか、IPフラグメンテーションが発生します。

これを防ぐには、エッジはTCPハンドシェイクを積極的に監視し、Maximum Segment Size（MSS）を調整します。MSS Clampingを用いて、クライアントとバックエンドサーバ間でより小さなペイロードサイズ（例：1400バイト）を合意させ、ヘッダの余裕を確保します。

BGPフラップ時のコネクションドレイン

BGP Anycastに依存しているため、ルーティングのフラップ（変動）により、トラフィックがシカゴのPoPからダラスのPoPに突然切り替わることがあります。ダラスがシカゴと同じ状態を持たない場合、トラフィックは誤ったバックエンドにルーティングされ、接続が切断されます。これを防ぐために、GLBの「セカンドチャンス」メカニズムやMaglevの接続追跡テーブルが設計されています。大規模なAnycastネットワークでは、ハッシュ状態のグローバル同期や、ダラスが内部バックボーン経由でシカゴにパケットを返す二次層のプロキシを利用する必要があります。

セキュリティとスプーフィング

バックエンドUnicastサーバは、エッジからのカプセル化トラフィックを受け取るように設計されていますが、スプーフィング対策も必須です。2025年1月にCERT/CCは、VU#199397として、KU LeuvenのDistriNet研究グループによる調査結果を公開しました。これは、GREやGUEのようなトンネリングトラフィックを認証なしで受け入れるシステムの脆弱性を指摘したもので、悪意ある攻撃者がこれらを悪用して、ソースアドレスの偽装やDoS攻撃を行う可能性があります。

この問題は、Anycast-to-Unicastアーキテクチャに特有のものではなく、GREやGUEが閉じた信頼されたネットワークを前提として設計されたことに起因します。バックエンドサーバは、信頼できるエッジプロキシからのトラフィックのみを受け入れるように設定し、IPsecなどの暗号化・認証を併用する必要があります。

結論：自律ルーティングの未来

DNS伝播に頼る災害復旧はもはや過去のものです。アプリケーションが単純なHTTPリクエスト・レスポンスから、継続的で遅延に敏感なデータストリームへと進化する中、ネットワークアーキテクチャもプロトコルの速度で障害を処理できるように適応すべきです。

BGP Anycastを公共エッジに押し出し、ステートレスなAnycast-to-Unicastプロキシのカプセル化を活用することで、企業はほぼ壊れないインゲスファブリックを構築できます。ローカルなクラウドリージョンがダウンしても、トンネルの宛先を再ハッシュし、ミリ秒単位でトラフィックを動的に切り替え、DNS TTLの制約を完全に超えます。

グローバルECサイトの決済、ステートフルなAI API接続、クラウドデジタルツインの超低遅延同期など、Anycast-to-Unicastプロキシアーキテクチャは、サーバがダウンしてもネットワーク全体が停止しないことを保証します。

---

編集ノート

以下は、元のドラフトに適用された変更の透明なログです。

• メタデータ削除: SEO用のタイトル/メタディスクリプションの前置き部分を削除し、本文は直接リード段落から始まるようにしました。
• 事実確認と修正:
  • GRE（RFC 2784、RFC 2890）とGeneve（RFC 8926）のRFC引用を追加し、Geneveのオーバーヘッドを50バイトから正確な36バイトに修正（IPv4 20バイト + UDP 8バイト + Geneve 8バイト）、TLVオプションの追加に伴う増加も反映。
  • 一貫性ハッシュの説明を修正。Maglevは独自の置換テーブルを使用し、GLBはRendezvous Hashingを採用していることを明示。ハッシュ関数は高速な非暗号的またはキー付き関数（例：SipHash）を用いていることを記載。
  • GREのIPプロトコル番号（47）、GeneveのUDPポート（6081）、DSRの仕組みと用語を正確に記述。
• 最新情報の追加:
  • Maglev、GLB、Unimog、Katranの各システムの詳細（ハッシュアルゴリズム、カプセル化形式、運用状況）を記載。
  • GUEの標準化状況（ドラフトはRFC化されていない）を追記。
  • 2025年1月のCERT/CCの脆弱性公開と、USENIX Security 2025のトンネリングプロトコルに関する研究を追加。
  • 2025年10月のAWS US-EAST-1 DynamoDB DNS障害の具体的な事例を引用し、DNSの脆弱性を示す証拠としました。
• 参照した主要ソース: RFC 2784, RFC 2890, RFC 8926, NSDI 2016のMaglev論文、GitHubのglb-directorリポジトリ・ドキュメント、Cloudflare Engineering Blog、MetaのEngineering Blogとkatranリポジトリ、IETFのdraft-ietf-intarea-gueページ、CERT/CCのVU#199397、AWSの公式2025年10月のポストイベント概要。