要約

  • NANOG 98の発表は、旧拠点がサービスIPを広告し続ける間に、TCPポートを選択してクラウドへ移した事例を示した。
  • 発表者は半年で3,000ポートを移行し、アプリ起因のロールバックが2回、取引損失はゼロだったと報告。RFC 8955は資料にあるredirect-nh動作を標準化していない。

移行計画に「段階的」と書いても、決済セッションの次のパケットが届かなければ意味はない。NANOG 98でインフラアーキテクトのHervé Hildenbrand氏は、クライアントがIPアドレスをソフトウェアに固定し、生のTCPで接続するサービスを紹介した。DNSの付け替えも、アプリケーションが許容するプロキシの追加も、クライアントのファームウェア変更もできなかった。/32全体を一度に動かせば3,000を超えるTCPポートがまとめて移る。二つの拠点から同時に広告すれば、進行中のセッションを分断するおそれがあった。

NANOGの発表によると、チームは通常の通信を旧拠点に残し、宛先・プロトコル・ポートの組み合わせを選んで転送した。資料には、BGP FlowSpecのルールで次ホップを新しいクラウド内のAnycastアンカーに変え、拠点間をMPLSで運ぶ構成が描かれている。準備ができたポートから移し、残りはそのままにする。最後に新拠点から/32を広告し、旧拠点から撤回してからFlowSpecのリダイレクトを削除する。

トラフィックフィルターとして知られる仕組みを、段階的な移行に使った点は鮮やかだ。ただし「FlowSpec」は照合条件とBGPによる配布を指す言葉で、万能の転送コマンドではない。RFC 8955は宛先プレフィックス、プロトコル、ポートによる照合を定義する一方、FlowSpec NLRIの次ホップアドレスは無視すると定める。標準のリダイレクト動作は、route targetに基づいて該当トラフィックをVRFへ送るものだ。Hildenbrand氏の資料では、Anycastアドレスに向けたredirect-nhが示されている。RFCは追加アクションを別の標準で定めることも実装固有にすることも認めているが、FlowSpecを使えばこの次ホップ書き換えが自動的に相互運用できるわけではない。資料には実装名やアクションのワイヤ形式がない。

安全策もこの事例の一部だ。資料によると、ルールはGit/Terraformで宣言し、CI/CDが宛先IP、ポート範囲、許可された次ホップを検証する。ルーター側のハードフィルターも未承認の宛先を拒む。誤ったルールはバックボーン上のパケット転送に即座に影響する。注入前の検証と装置側の拒否を重ね、限定された移行ルールが全体障害に化けるのを防いだ。

発表資料は、半年で3,000のTCPポートを移し、収束は1秒未満、アプリケーションの問題で2回ロールバックし、取引損失はゼロだったと報告している。これは登壇者の事例報告であり、独立監査されたサービス記録ではない。図の192.0.2.50はRFC 5737が文書例用に確保したTEST-NET-1、10.100.0.254はRFC 1918のプライベートアドレス空間に属する。顧客名や実際のサービスアドレスは開示されていない。

持ち帰るべき点は「FlowSpecでサービスを移せる」ではない。チームは共有された一つの識別子、IPアドレスを小さな運用判断に分け、それぞれに照合条件、許可された行き先、取り消せる変更を用意した。そのため、アプリ側の問題を一件ずつ直しながら、ネットワーク全体の一括切り替えを避けられた。

出典：NANOG 98の講演ページ、Hildenbrand氏の発表資料、RFC 8955、RFC 5737、RFC 1918。