요약

  • NANOG 98 발표는 기존 사이트가 서비스 IP를 계속 광고하는 동안 TCP 포트를 클라우드로 단계적으로 옮긴 사례를 설명했다.
  • 발표자는 6개월 동안 포트 3,000개를 이전했고 애플리케이션 문제로 두 번 롤백했으며 거래 손실은 없었다고 밝혔다. RFC 8955는 발표 자료의 redirect-nh 동작을 표준화하지 않는다.

이전 계획에 ‘단계적’이라고 써도 결제 세션은 다음 패킷이 같은 서비스에 도착하는지만 본다. NANOG 98에서 인프라 아키텍트 Hervé Hildenbrand는 클라이언트 소프트웨어에 IP 주소가 고정되어 있고 일반 TCP를 쓰는 서비스를 소개했다. 바꿀 DNS 레코드도, 애플리케이션이 받아들일 프록시 경로도, 업데이트할 클라이언트 펌웨어도 없었다. /32 전체를 한 번에 옮기면 TCP 포트 3,000개 이상이 함께 이동한다. 두 사이트가 동시에 같은 프리픽스를 광고하면 활성 세션이 갈라질 수도 있다.

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와 포트 범위, 허용된 다음 홉을 검증하며, 라우터 필터가 승인되지 않은 목적지를 거부한다고 설명한다. 잘못된 규칙은 포워딩 속도로 백본 트래픽에 영향을 줄 수 있다. 주입 전 검증과 장비 내부의 하드 필터를 겹쳐, 제한된 이전 규칙이 전역 문제로 커질 가능성을 줄였다.

슬라이드는 TCP 포트 3,000개를 6개월 동안 옮겼고, 수렴은 1초 미만이었으며, 애플리케이션 문제로 두 번 롤백했고, 거래 손실은 0건이었다고 보고한다. 이는 발표자의 사례 수치이지 독립 감사된 서비스 기록은 아니다. 도식의 192.0.2.50은 RFC 5737에서 문서 예시용으로 지정한 TEST-NET-1에 속하고, 10.100.0.254는 RFC 1918의 사설 주소 공간에 속한다. 고객이나 실제 서비스 주소는 공개되지 않았다.

가져갈 교훈은 FlowSpec으로 서비스를 옮길 수 있다는 데 있지 않다. 팀은 공유된 하나의 식별자, IP 주소를 작은 운영 결정으로 나눴다. 각 결정에는 구체적 매칭 조건과 승인된 목적지, 되돌릴 수 있는 변경이 붙었다. 그래서 애플리케이션 문제를 하나씩 해결하면서 매번 전체 네트워크를 전환하지 않아도 됐다. 사례 세부 내용은 NANOG 98에서 Hervé Hildenbrand가 발표한 슬라이드에 따른다.