IP의 병목 현상 해결: 이름 및 웹 서비스에 대한 민첩한 주소 지정

대규모 운영 환경에서는 IP 주소 지정 문제로 인해 네트워크 및 웹 지향 서비스의 혁신이 저해됩니다. 아키텍처를 변경할 때마다, 그리고 새로운 시스템 설계를 시작할 때마다 우리는 다음과 같은 질문을 가장 먼저 던지게 됩니다.

• 어떤 IP 주소 블록을 사용 또는 사용 가능합니까?

• IPv4 주소는 충분합니까? 그렇지 않다면 이를 어디서, 어떻게 얻을 수 있습니까?

• IPv6 주소를 어떤 식으로 사용할 것이며, 이는 다른 IPv6 사용에 영향을 줍니까?

• 그리고 마이그레이션을 위한 신중한 계획, 확인, 시간 및 인력은 마련되어 있습니까?

무엇보다 IP 주소부터 걱정해야 하는 이러한 상황에 시간, 비용, 리소스가 낭비되고 있습니다. 40여년 전에 혁신적이고 탄력적인 IP의 개념이 처음 등장했을 때와 비교하면 이는 놀라운 일입니다. IP 주소는 원래는 네트워크 환경에서 고려할 우선순위의 마지막에 놓이도록 설계되었습니다. 하지만 인터넷이 남긴 교훈이 있다면, 설계 당시에는 작고 중요하지 않아 보이거나 예견 자체가 불가능한 취약점이었던 것이 충분한 규모로 확장되었을 때는 언제나 그 모습을 드러낸다는 점입니다.

한 가지 분명한 사실은, "더 많은 주소"가 답이 되어서는 안 된다는 것입니다. IPv4의 경우, 그런 사고방식은 오히려 주소의 희소성을 부추기며 시장 가격을 더욱 상승시키고 있습니다. IPv6는 꼭 필요하지만 부분적인 해결책일 뿐입니다. 예를 들어, IPv6의 경우 개인적인 용도로는 /56 정도의 작은 규모로까지 할당할 수 있다고들 합니다. 이는 2⁷² 또는 약 4,722,000,000,000,000,000,000 개의 주소에 해당합니다. 저는 그렇게 큰 숫자는 떠올리기조차 힘듭니다. 여러분은 어떤가요?

이 블로그 게시물에서는 IP 주소 지정이 웹 서비스에서 문제가 되는 상황과 근본 원인을 설명한 다음, Cloudflare가 민첩한 주소 지정(Addressing Agility)이라고 부르는 혁신적인 솔루션과 그 배경이 되었던 교훈을 소개하겠습니다. 무엇보다도 민첩한 주소 지정 덕분에 가능해진 새로운 시스템과 아키텍처의 종류에 주목해보시기 바랍니다. 전체 내용은 Cloudflare가 ACM SIGCOMM 2021에서 공개한 최신 논문에서 확인하실 수 있습니다. Cloudflare가 배운 교훈들을 간단히 언급하자면 다음과 같습니다.

단일 주소에 표시될 수 있는 이름의 수에는 실제로 한계가 없습니다. 특정 이름의 주소는 어디서든 새로운 쿼리가 생성될 때마다 매번 변경이 가능합니다. 또한 주소 변경의 사유는 서비스 프로비저닝, 정책이나 성능 평가 때문일 수도 있고, 또는 우리가 아직 접해보지 못한 어떤 이유일 수도 있습니다...

아래 지면에는 이 모두가 사실인 이유, 그러한 결론에 도달한 방법, 그리고 이러한 교훈이 _모든 규모_의 HTTP 및 TLS 서비스에서 중요한 이유가 설명되어 있습니다. Cloudflare는 다음과 같은 핵심 인사이트, 즉 인터넷 프로토콜(IP)의 설계 자체에서는 글로벌 우편 시스템에서와 마찬가지로 특정 주소가 반드시 특정 이름을 나타내지도 않고, 그래서도 안 되며, 이는 어떤 경우에도 불필요한 일이라는 생각에서 출발했습니다. 단지 우리가 때때로 주소를 그런 식으로 취급하고 있을 뿐이죠. 이 논문은 모든 이름이 모든 해당 주소, 주소들의 집합, 또는 단일 주소를 공유할 수 있어야 한다는 점을 보여줍니다.

수십 년 된 규칙은 여전히 IP 주소를 이름 및 리소스와 인위적으로 연계합니다. 인터넷을 작동시키는 아키텍처와 소프트웨어가 한 대의 컴퓨터에는 하나의 이름과 (대부분) 하나의 네트워크 인터페이스 카드만 있는 환경에서 진화해 왔으므로 이는 어쩔 수 없는 부분입니다. 그렇다면 하나의 IP 주소가 여러 이름 및 소프트웨어 프로세스들과 연계되는 방식으로 인터넷이 발전해가는 것이 자연스러운 방향입니다.

대부분 이름이 필요 없고 접속 대기(listening ) 프로세스와도 무관한 최종 클라이언트와 네트워크 사업자는 이러한 IP 바인딩의 영향을 거의 받지 않습니다. 그러나 모든 콘텐츠 호스팅 및 배포 업무와 콘텐츠 서비스 공급자(CSP)에게는 이름 및 프로세스 규칙이 강력한 제한 사항으로 작용합니다. 주소에 일단 이름, 인터페이스, 소켓이 할당되고 나면 이는 대체로 정적으로 고착되며, 변경이 가능한 경우에서조차 노력, 계획 및 주의가 요구됩니다.

IP의 "병목" 덕분에 인터넷이 탄생하게 되었지만, TCP로 프로토콜을 전송하고 HTTP로 응용 프로그램 프로토콜을 전송하는 경우에서처럼, IP는 혁신을 발목잡는 족쇄가 되었습니다. 이러한 상황을 묘사하고 있는 아래 그림을 보면, 원래는 서로 별개였던 통신 바인딩(이름으로 연계)과 연결 바인딩(인터페이스 및 소켓으로 연계) 사이에서 일종의 연동 관계가 형성된다는 것을 알 수 있습니다.

이러한 연동 구조는 깨기가 어렵습니다. 둘 중 하나를 변경하면 다른 하나에도 영향을 미치기 때문입니다. 또한 서비스 공급자는 특정 이름과는 무관한 정책 및 서비스 수준을 나타내는 용도로 IP 주소를 사용하기도 합니다. 결국에는 IP 바인딩 역시 하나의 고려 요소로 자리잡게 되었지만, 반드시 그럴 필요는 없습니다.

다른 관점에서 이 문제를 바라봅시다. 새로운 디자인이나 아키텍처, 또는 더 나은 리소스 할당을 고려할 때 가장 먼저 던져야 할 질문이 "어떤 IP 주소를 사용합니까?"나 "이를 위한 IP 주소가 있습니까?"가 되어서는 안 됩니다. 이와 같은 질문과 답변을 주고받는 과정에서 개발과 혁신이 지연되기 때문입니다.

Cloudflare는 IP 바인딩이 인위적일 뿐만 아니라, 혁신적이었던 원래의 RFC 및 표준에 비추어 잘못된 것임을 깨달았습니다. 사실, IP 주소가 도달 가능성 이외의 다른 어떤 요소를 대표한다는 개념은 그 설계 사상에 위배됩니다. 원래의 RFC와 관련 초안에서 설계자는 "이름, 주소 및 경로를 구분해야 한다. 이름은 우리가 찾는 것을 나타내고, 주소는 그것이 있는 위치를 나타내며, 경로는 거기로 가는 방법을 나타낸다"라고 분명히 밝히고 있습니다. 상위 계층 프로토콜에서 SNI나 HTTP 호스트 등의 정보를 IP와 연계하는 모든 방식은 계층화 원칙에 명백히 위배됩니다.

물론 Cloudflare의 작업이 여기에서 완전히 자유로운 것은 아닙니다. 그러나 저희는 IP 주소를 기존 사용 방식에서 분리해내려는 오랜 노력의 결실을 맺었습니다. 이는 거인의 어깨 위에서 내다보는 진화의 방향입니다.

지난 20년을 돌이켜보면, 주소 지정의 민첩성을 달성하기 위한 노력이 한동안 진행 중이었고 Cloudflare가 그 중 하나에 깊이 연관되어 있음을 쉽게 알 수 있습니다.

지난 수십 년간 이어져 온 IP와 네트워크 카드 인터페이스를 일대일로 바인딩하는 관행이 처음으로 깨진 것은 Google의 Maglev가 트래픽을 하나의 '가상' IP 주소에서 다수의 서버들로 분산시키기 위해 ECMP(Equal Cost MultiPath)와 일관된 해싱을 결합하는 방식을 고안했을 때였습니다. 한편, 원래의 인터넷 프로토콜 RFC에 따르면 이러한 방식의 IP 사용은 권장되지 않으며 이는 가상의 방식도 아닙니다.

그 이후로 GitHub와 Facebook 등에서 유사한 시스템들이 많이 제안되었으며, Cloudflare의 Unimog 역시 그 중 하나입니다. Cloudflare는 최근 소켓 및 프로세스에서 IP 주소를 분리하기 위해 bpf_sk_lookup이라는 새로운 프로그래밍 가능 소켓 아키텍처를 설계하기도 했습니다.

그러면 이름은 어떻게 처리할까요? '가상 호스팅'의 가치는 1997년에 HTTP 1.1이 호스트 필드를 필수 항목으로 정의하면서 정착되었습니다. 이것은 단일 IP 주소에 복수의 이름들이 공존할 수 있다는 것을 인정한 최초의 사건이며, 이는 TLS의 서버 이름 표시 필드에서도 고스란히 재현되었습니다. 가능한 이름의 수가 가용한 IP 주소보다 많기 때문에 이는 반드시 필요한 조치였습니다.

"이름이란 게 무슨 소용인가?"라고 물었던 셰익스피어는 현명했습니다. 인터넷이 말을 할 수 있었다면 아마도 "우리가 다른 주소로서 표시하는 이름 역시 똑같은 도달 가능성을 제공합니다"라고 답했을 것입니다.

만약 셰익스피어가 "주소란 게 무슨 소용인가"라고 물어봤다면, 인터넷은 이 경우에도 "우리가 다른 이름으로서 표시하는 주소 역시 똑같은 도달 가능성을 제공합니다"라고 답했을 것입니다.

이러한 답변을 통해 드러나고 있는 함의는 강력합니다. 이름과 주소 간의 매핑은 모두 임의적입니다. 이것이 사실이라면, 특정 주소에서 해당 이름에 도달할 수만 있다면 이름에 도달하는 용도로 어떤 주소를 사용해도 무방합니다.

실제로, 하나의 이름에 다수의 주소를 사용하는 이러한 방식은 DNS 기반의 로드 밸런싱이 도입되었던 1995년부터 이미 소개되어 있었습니다. 그렇다면 모든 이름에 대해 모든 주소를, 또는 모든 이름에 대해 아무 때나 임의의 주소를 사용하지 못할 이유는 무엇일까요? 심지어 모든 이름에 대해 하나의 주소를 사용할 수도 있지 않을까요? 하지만 먼저 주소 지정의 민첩성을 달성할 수 있는 방법에 대해 알아봅시다.

민첩성의 열쇠는 권한 있는 DNS가 쥐고 있습니다. 하지만 특정 형태의 레코드나 조회 테이블에 저장된 고정적인 이름 대 IP 매핑과는 거리가 멉니다. 클라이언트의 관점에서는 바인딩은 오직 '쿼리 시'에만 이루어집니다. 매핑이 실제로 사용되는 모든 환경에서 이름이 주소에 바인딩될 수 있는 쿼리의 응답 순간은 요청이 가진 수명의 최종 단계에 해당합니다.

따라서 이름 매핑이 실제로는 일부 레코드나 영역 파일에서가 아니라 응답이 반환되는 순간에 이루어지는 것으로도 볼 수 있습니다. 이는 미묘하지만 중요한 차이입니다. 오늘날의 DNS 시스템은 이름을 사용하여 주소 집합을 조회한 이후 반환할 구체적 주소를 결정하기 위해 일종의 정책을 활용하기도 합니다. 아래의 그림은 이러한 과정을 설명하고 있습니다. 쿼리가 도착하면 조회를 통해 해당 이름과 연결된 주소가 표시되고, 이러한 주소 중 하나 이상이 반환됩니다. 주소 선택의 폭을 좁히기 위해 서비스 수준이나 지리적 적용 범위와 같은 정책 또는 로직 필터를 추가적으로 활용하는 경우도 많습니다. 여기서 중요한 점은 주소 식별에는 먼저 이름이 사용되고, 정책은 나중에 적용된다는 사실입니다.

(a) 기존의 권한 있는 DNS

(b) 민첩한 주소 지정

민첩한 주소 지정은 이러한 구조적 관계를 뒤집을 때 가능합니다. Cloudflare의 아키텍처는 이름에 미리 할당된 IP 주소 대신에 이름을 포함할 수 있는(여기서는 포함하지 않는) 정책에 기반합니다. 예를 들어 정책은 위치나 계정 유형 등의 속성으로 표시되는 한편 이름은 무시(Cloudflare 배포에서는 실제로 무시됨)할 수도 있습니다. 속성은 해당 정책과 연결되어 있는 주소들의 풀을 식별해줍니다. 풀 자체는 해당 정책과 별도로 존재하거나 몇몇 요소를 다른 풀 및 정책들과 공유 중일 수 있습니다. 또한 풀에 들어 있는 모든 주소의 가치는 동등합니다. 즉, 어떤 주소든 DNS 쿼리 이름의 검사 없이 반환이 가능하고, 무작위로 선택해도 무방합니다.

여기에 쿼리당 응답과 관련한 두 가지 주목할 만한 사항이 있습니다. 찬찬히 살펴봅시다.

i. IP 주소는 런타임 또는 '쿼리 타임'에 계산 및 할당이 가능하며 실제로도 할당됩니다.

ii. 뒤이은 연결의 수명과 다운스트림 캐시의 TTL 중 더 긴 쪽이 IP 대 이름 매핑의 수명이 됩니다.

이는 바인딩 자체가 원래는 임시적이며 이전의 바인딩, 확인자, 클라이언트, 목적 등과는 상관없이 언제든 변경될 수 있다는 강력한 결론을 시사합니다. 규모 역시 문제가 되지 않습니다. Cloudflare는 이미 엣지에 이를 배포했습니다.

배포에 대해 이야기하기 전에 먼저 IPv6에 대해 짚고 넘어가겠습니다. 무엇보다 IPv4와 관련하여 여기에서 논의된 _모든 사항_이 IPv6에서도 동일하게 적용된다는 점을 기억해 주시기 바랍니다. 세계의 우편 시스템이 그러한 것처럼, 주소는 캐나다, 캄보디아, 카메룬, 칠레 또는 중국에서도 여전히 주소일 뿐이며, 비교적 고정적이고 융통성이 없는 특성 역시 그대로 유지됩니다.

이러한 유사성에도 불구하고 의문은 계속 남습니다. 그저 IPv6로 변경만 해도 민첩한 주소 지정을 추구하려는 모든 이유가 충족되는 것은 아닐까요? 대답이 직관적이지 않을 수 있지만, 결론은 확실하고 절대적인 '아니오'입니다! 현 시점의 모든 사람들이 앞으로 살아갈 동안에는 IPv6로 주소 고갈을 완화할 수 있겠지만, IPv6 접두사와 주소는 너무나 방대하므로 이를 이름 및 리소스에 바인딩하는 것과 관련한 추론이 어려워집니다.

방대한 IPv6 주소는 운영자가 비트 길이와 큰 접두사 크기를 활용하여 IP 주소에 의미를 심으려 할 수도 있기 때문에 비효율성의 위험도 남아있습니다. IPv6에 이렇게 강력한 기능이 있지만, 이는 접두사에 포함된 수많은 주소들이 사용되지 않고 지나감을 의미하기도 합니다.

그동안 Cloudflare는 IPv6의 가장 큰 지지자 중 하나였으며, 특히 방대한 주소 덕분에 지속성이 보장된다는 점 때문에라도 충분히 그럴 만했습니다. 그럼에도 불구하고 IPv6은 주소가 이름 및 리소스에 연결되는 방식은 거의 변화시키지 못합니다. 반면, 주소의 민첩성은 수명이 유지되는 내내 유연성과 응답성을 보장합니다.

관련 아키텍처 및 전송 가능성에 대해 한 마디 덧붙이자면, 민첩한 주소 지정은 권한 있는 DNS를 운영하는 모든 서비스에 적용이 가능하며, 이는 심지어 권장됩니다. 다른 콘텐츠 지향 서비스 공급자와는 당연히 경쟁 관계겠지만, 이는 소규모 운영자도 마찬가지입니다. 대학, 기업 및 정부 기관 등, 권한 있는 서비스를 자체적으로 운영할 수 있는 조직은 얼마든지 존재합니다. 결과적으로는 운영자가 반환된 IP 주소에 대한 연결을 수락할 권한을 가진 모든 경우가 민첩한 주소 지정의 잠재적인 수혜자가 됩니다.

Cloudflare는 2020년 6월부터 프로덕션 트래픽을 대상으로 엣지에서 민첩한 주소 지정을 가동해 왔습니다. 그 내용은 다음과 같습니다.

• 2천만 개 이상의 호스트 이름 및 서비스

• 캐나다의 모든 데이터 센터(충분한 인구와 여러 시간대를 제공)

• IPv4에서 /20 (4096개 주소) 및 IPv6에서 /44

• 2021년 1월부터 2021년 6월까지 IPv4에서 /24 (256개 주소)

• 모든 쿼리에 대해 접두사 내에서 임의의 호스트 부분을 생성

민첩성에 대한 진정한 테스트가 이루어지는 가장 극단적인 조건은 Cloudflare 서버에 도달하는 모든 쿼리에 대해 임의의 주소가 생성될 때일 것입니다. 그래서 이 아이디어를 실제로 테스트하기로 결정했습니다. 2021년 6월, Cloudflare의 몬트리올 데이터 센터에 이어 토론토에서도 2천만 개 이상의 전체 영역이 단 하나의 주소로 매핑되었습니다.

그 이후 1년에 걸쳐 해당 정책에 의해 캡처된 모든 도메인에 대한 쿼리에 무작위로 선택된 주소가 부여되었으며, 처음에는 4096개 주소에서, 그 다음에는 256개에서 선택되었고, 마지막에는 1개만 남았습니다. Cloudflare 내부에서는 1개 주소의 집합을 Ao1이라고 불렀는데, 이 점에 대해서는 나중에 설명하겠습니다.

여러분은 어쩌면 다음과 같은 질문들을 속으로 던지고 있을지도 모릅니다.

• 이로써 인터넷의 어디가 바뀌게 되었나?

• Cloudflare 시스템에는 어떤 영향을 미쳤을까?

• 작동 모습을 볼 수 있다면 무엇을 보게 될까?

위 질문 각각에 대한 짧은 대답은 _'아무것도 없음'_입니다. 여기서 중요한 점은 주소 무작위화가 인터넷에 의존하는 시스템의 설계와 관련한 약점을 드러낸다는 것입니다. 그러한 모든 약점은 언제나 설계자가 IP 주소에 도달 가능성 이상의 의미를 부여하기 때문에 발생합니다. (희망 사항을 덧붙이자면, 이러한 모든 약점은 하나의 주소 또는 'Ao1'을 사용함으로써 피할 수 있습니다.)

"없음"이 의미하는 바를 더 잘 이해하기 위해 위의 질문 중 맨 아래 항목부터 살펴보도록 합시다.

그 대답은 아래 그림의 예에 나와 있습니다. Cloudflare 배포 외부의 "나머지 인터넷"에 속하는 모든 데이터 센터에서는 특정 영역에 대한 쿼리가 동일한 주소로 반환됩니다(예: Cloudflare의 전역 애니캐스트 시스템). 그와는 대조적으로, 배포 데이터 센터에 도착하는 모든 쿼리는 임의의 주소를 부여받습니다. 아래에서 볼 수 있듯, 이는 두 개의 서로 다른 데이터 센터로 보내지는 연속적인 dig 명령에 해당합니다.

후속 요청 트래픽에 대해 궁금하신 분들을 위해 답변드리자면, 이는 서버가 주소 풀의 모든 주소에 있는 2천만 개 이상의 도메인 가운데 어떠한 것에 대한 연결 요청이라도 수락하도록 구성되었음을 의미합니다.

아니오. 이는 권한 있는 DNS용 데이터 파이프라인에 대해 드롭인 방식으로 투명하게 이루어진 변경입니다. BGP, DDoS, 로드 밸런서, 분산형 캐시 등에 대한 라우팅 접두사 광고 각각에는 변경이 필요하지 않았습니다.

그러나 한 가지 흥미로운 부작용이 있었습니다. 무작위화와 IP 주소 간의 관계는 좋은 해시 함수와 해시 테이블 사이에서의 그것과 같으며, 이는 임의의 크기인 입력을 고정된 수의 출력에 균등하게 매핑합니다. 이러한 효과는 한 데이터 센터에 7일간 도착한 요청의 1% 샘플에서 가져온 데이터를 사용하여 아래 그래프에서와 같은 무작위화 전후의 IP당 로드 측정값을 확인해 보면 잘 드러납니다.

민첩한 주소 지정 이전

/20에 대한 무작위화

/24에 대한 무작위화

무작위화 이전에는 Cloudflare IP 공간의 작은 부분에 한정하여 (a) IP당 최대 요청과 최소 요청 간의 차이(y1축의 왼쪽)가 세 자릿수였고, 마찬가지로 IP당 바이트(y2축의 오른쪽)는 거의 여섯 자릿수였습니다. 무작위화 이후에는, (b) 이전에는 복수의 /20을 점유했던 단일 /20 상의 모든 도메인에서 각각 두 자릿수 및 세 자릿수만큼 감소하게 됩니다. /24까지 한 발 더 나아가 보면, (c) 256개 주소에 대한 2천만여 개 영역의 쿼리당 무작위화는 부하의 차이를 작은 상수 인자로 낮춥니다.

IP 주소를 기준으로 리소스를 프로비저닝하는 것을 고려 중인 모든 콘텐츠 서비스 공급자에게는 이러한 내용이 중요할 수 있습니다. 고객이 생성한 부하에 대한 선험적 예측은 까다로울 수 있습니다. 위의 그래프는 _모든 주소를 모든 이름에 부여_하는 것이 최선의 방향임을 입증하여 보여줍니다.

여기서도 대답은 '아니오'입니다. 더 정확하게 말하자면, "무작위화로 달라지는 것은 없습니다... 하지만 시스템과 관련 설계상의 약점을 드러낼 수는 있습니다."

주소 무작위화에 영향 받을 _여지_가 있는 모든 시스템은 도달 가능성 이상의 모종의 의미를 IP 주소에 부여했다는 조건을 공통적으로 갖추고 있었습니다. 민첩한 주소 지정은 IP 주소의 의미 체계와 핵심 인터넷 아키텍처를 유지할 뿐만 아니라 복원하기까지 하지만, 그 의미에 대해 자의적으로 해석하는 소프트웨어 시스템에는 악영향이 있습니다.

먼저 몇 가지 예를 살펴보고, 이것이 중요하지 않은 이유를 알아본 다음, (단일 IP 주소를 사용하여) 약점을 우회하도록 민첩한 주소 지정에 이루어진 약간의 변경 사항을 소개하겠습니다.

• HTTP 연결 병합을 통해 클라이언트는 기존 연결을 재사용하여 다른 출처의 리소스를 요청할 수 있습니다. URI 권한이 해당 연결과 일치할 때 병합을 허용하는 Firefox와 같은 클라이언트는 영향을 받지 않습니다. 그러나 주어진 연결과 동일한 IP 주소로 확인하기 위해서는 URI 호스트가 필요한 클라이언트의 경우, 문제가 발생합니다.

• 비 TLS 또는 HTTP 기반 서비스가 영향을 받을 수 있습니다. 한 가지 예로 ssh의 경우, 호스트 이름 대 IP 매핑을 known_hosts에서 유지 관리합니다. 이러한 연계 방식은 나름 합리적이지만, 현재 많은 DNS 레코드가 둘 이상의 IP 주소를 반환하고 있다는 점을 감안할 때 구식이며 수명이 다했습니다.

• 비 SNI TLS 인증서에는 전용 IP 주소가 필요합니다. 각 주소는 SNI가 없는 단일 인증서만 지원이 가능하기 때문에 공급자는 프리미엄을 부과할 수밖에 없습니다. IP와는 상관없이 더 큰 문제는 SNI 없이 TLS를 사용하는 것입니다. Cloudflare는 이 바람직하지 못한 관행을 끝내기 위해 비 SNI 사용에 대해 연구하기 시작했습니다.

• 초반에는 대상 IP에 의존하는 DDoS 보호에 지장이 있을 수 있습니다. Cloudflare의 주장에 따르면 민첩한 주소 지정에는 두 가지 이점이 존재합니다. 첫째, IP 무작위화는 사용 중인 모든 주소에 걸쳐 공격 로드를 분산함으로써 레이어 3 로드 밸런서의 역할을 효과적으로 수행합니다. 둘째, DoS 완화를 위해 때로는 IP 주소를 변경하기도 하는데, 이는 민첩한 주소 지정에 기본 탑재된 기능입니다.

Cloudflare는 먼저 수만 개의 주소에 걸쳐 바인딩된 2천만여 개의 영역에서 /20의 4096개 주소를 통해 성공적으로 서비스한 데 이어, /24의 256개 주소를 통해 서비스를 제공하기 시작했습니다. 이러한 추세에는 다음과 같은 질문이 따라올 수밖에 없습니다.

무작위화가 _n개_의 주소에서 잘 작동한다면, 1개 주소에 대해 무작위화하지 못할 이유가 있을까요?

그럴 이유는 없습니다. 위에서 IP에 대한 무작위화를 해시 테이블 상의 완벽한 해시 함수에 비유했던 부분을 떠올려 보십시오. 잘 설계된 해시 기반 구조의 장점은 주어진 구조의 모든 크기에서, 심지어 그 크기가 1인 경우에도 자신의 속성을 유지한다는 것입니다. 이러한 감축이야말로 민첩한 주소 지정의 기본 전제를 실제로 테스트해볼 기회입니다.

그래서 Cloudflare는 테스트를 했습니다. /20 주소 세트에서 /24 세트로, 이어서 2021년 6월부터는 하나의 /32 주소 세트 및 그와 동등한 /128(Ao1) 세트로 진행했는데, 그저 작동하는 수준이 아니라 정말로 훌륭하게 작동했습니다. 무작위화로 인해 노출될 수 있는 문제들은 Ao1 단계에서 해결되었습니다. 예를 들어, 비 TLS 또는 비 HTTP 서비스에도 안정적인(또는 최소한 이름에 대한 정책 변경이 있을 때까지는 임의적이지 않은) IP 주소가 부여되었습니다. 또한 HTTP 연결 병합이 마치 무료인 것처럼 제공되었고, Ao1이 사용되는 곳에서는 병합 수준이 증가하는 것도 확인되었습니다.

단일 IPv6 주소에 대한 바인딩과 관련하여 실제로는 주소가 고갈될 가능성이 낮기 때문에 이는 불필요하다는 주장도 있습니다. 이는 CIDR 이전의 입장이며, 너무 낙관적이거나 나쁘게 보면 무책임한 주장입니다. 위에서 언급했듯이 IPv6 주소의 수는 이에 대한 추론을 어렵게 만듭니다. 단일 IPv6 주소를 사용하는 이유를 묻는 대신에 "왜 안 되는가?"라고 물어보는 편이 낫습니다.

Ao1은 IP 무작위화와 관련하여 완전히 다른 의미들을 드러내주며, 이는 겉보기에 사소한 행동이 가질 수 있는 효과를 증폭함으로써 인터넷 라우팅 및 도달 가능성의 미래를 엿보게 해준다고도 볼 수 있습니다.

왜일까요? 현실 세계에서 가능한 가변 길이 이름의 수는 언제나 고정 길이 주소의 수를 넘어서기 때문입니다. 즉, 비둘기집 원리(Pigeonhole Principle)에 따라 단일 IP 주소를 여러 이름으로 공유해야만 하며, 관련 없는 당사자와 상이한 콘텐츠를 공유해야만 합니다.

Ao1에 의해 증폭된 잠재적 업스트림 효과는 거론할 가치가 있으며, 아래에 설명되어 있습니다. 그러나 저희의 평가에서 지금까지는 그러한 효과를 접하지 못했으며, 업스트림 네트워크와의 통신에서 나타나지도 않았습니다.

• 업스트림 라우팅 오류는 즉각적이고 총체적입니다. 만약 모든 트래픽이 단일 주소(또는 접두사)에 도착한다면 업스트림 라우팅 오류는 모든 콘텐츠에 동일하게 영향을 줍니다. (Cloudflare가 인접하지 않은 주소 범위에서 두 개의 주소를 반환하는 이유가 이것입니다.) 그런데 이는 위협 차단의 경우에서도 똑같이 적용됩니다.

• 업스트림 DoS 보호가 트리거될 수 있습니다. 단일 주소에 요청과 트래픽이 집중되었을 때 업스트림에서는 이를 DoS 공격으로 인식하여 준비되어 있던 업스트림 보호를 트리거할 수도 있습니다.

두 경우 모두 민첩한 주소 지정을 통해 주소를 대량으로 빠르게 변경함으로써 완화가 가능합니다. 예방도 물론 가능하지만, 열린 소통과 토론이 선행되어야 합니다.

마지막으로 다음과 같은 업스트림 효과도 있습니다.

• IPv4 NAT의 포트 고갈이 가속화될 수 있으며, IPv6가 이를 해결해줍니다! 클라이언트 측에서, 하나의 주소에 허용되는 동시 연결 수의 상한선은 전송 프로토콜의 포트 필드 크기에 의해 결정됩니다(예: TCP의 경우 약 65,000개).

예를 들어 이는 Linux 상의 TCP에서 최근까지도 골칫거리였습니다. (ip(7) 매뉴얼 페이지에서 이 커밋과 SO_BIND_ADDRESS_NO_PORT를 참조하십시오.) UDP에서도 문제는 그대로입니다. QUIC에서는 연결 식별자로 포트 고갈을 방지할 수 있지만, 먼저 사용되어야 합니다. 그러나 지금까지는 이것이 문제라는 증거가 확인되지 않았습니다.

그럼에도 불구하고, 다행스럽게도 저희가 아는 한 이것이 단일 주소 사용에 따라오는 유일한 위험이며, 이는 IPv6으로 마이그레이션하면 즉시 해결됩니다. (그러니 ISP와 네트워크 관리자는 IPv6을 구현을 서둘러주시기 바랍니다!)

서두에서의 질문으로 마무리하겠습니다. 만약 단일 IP 주소에 연계 가능한 이름 수에 제한이 없으며, 어떤 사유로든 쿼리당 주소를 변경할 수 있는 기능이 주어진다면, _여러분_은 어떤 것을 구축하시겠습니까?

이제 겨우 시작일 뿐입니다! 민첩한 주소 지정으로 가능해진 유연성과 미래 경쟁력은 새로운 시스템과 아키텍처를 구상, 설계 및 구축할 수 있도록 모두를 지원합니다. Cloudflare는 Anycast 시스템에 대한 BGP 경로 누출 감지 및 완화와 측정 플랫폼 등을 계획하고 있습니다.

위의 모든 내용에 대한 자세한 기술 정보와 이 모든 것을 가능하게 해준 많은 분들께 대한 감사 인사를 이 논문과 간단한 토크에서 확인하실 수 있습니다. 이러한 새로운 가능성에도 불구하고 과제는 남아 있습니다. 다음과 같은 미해결 질문들이 있지만, 이는 일부분에 불과합니다.

• 합리적으로 표현하거나 구현할 수 있는 정책은 어떤 종류입니까?

• 그것들을 표현할 수 있는 추상 구문이나 문법이 존재합니까?

• 정책에 오류가 있거나 상충하는 경우를 방지하기 위해 공식적인 방법과 검증을 사용할 수 있습니까?

민첩한 주소 지정은 모두를 위한 것이며, 이러한 아이디어를 성공적으로 전파하는 데도 모두의 힘이 필요합니다. 의견 및 아이디어는 언제든 [email protected]으로 보내주시기 바랍니다.

귀하가 PhD 또는 그에 준하는 연구 프로그램에 등록된 학생이고 2022년에 미국 또는 캐나다와 EU 또는 영국에서 인턴십에 참여하고 싶은 경우.

이러한 프로젝트에 기여하거나 Cloudflare가 트래픽 및 주소 관리 시스템을 개발하는 데 도움을 주고 싶다면, Cloudflare의 주소 지정 엔지니어링 팀의 채용 기회에 도전해보세요!