애니캐스트

애니캐스트는 아름다운 거짓말이다. 동일한 IP 주소가 도쿄, 런던, 뉴욕에 동시에 존재한다. 그 주소에 접속하면, 가장 "가까운" 서버에 도달하게 된다—그리고 사람마다 가장 가까운 곳은 다르다.

이것은 꼼수나 임시방편이 아니다. 인터넷에서 가장 중요한 인프라가 실제로 작동하는 방식이다. DNS 루트 서버, Google의 8.8.8.8, Cloudflare의 1.1.1.1—이 주소들은 단일 서버를 가리키지 않는다. 전 세계에 흩어진 수백 대의 서버를 가리키며, 모두가 같은 목적지인 척한다.

하나의 주소가 여럿이 되는 방법

일반적으로 IP 주소는 도로 주소와 같다. 하나의 위치, 하나의 건물. 편지를 보내면 그 특정 장소에 도착한다.

애니캐스트는 이것을 깨뜨린다. 어떤 조직이 뉴욕, 런던, 도쿄, 시드니에 서버를 배포하고, 모두에게 동일한 IP 주소를 부여한다. 그런 다음 각 위치는 인접 라우터들에게 알린다. "저는 192.0.2.1이고, 여기를 통해 저에게 올 수 있습니다."

이 알림은 BGP를 통해 전파된다. BGP는 인터넷을 하나로 묶는 라우팅 프로토콜이다. 모든 라우터는 192.0.2.1로 가는 여러 경로를 학습한다. 그리고 BGP에는 단순한 원칙이 있다. 짧은 경로가 낫다.

로스앤젤레스에 있는 당신이 192.0.2.1로 패킷을 보내면, ISP 라우터가 선택지를 확인한다. 뉴욕은 두 홉 거리다. 도쿄는 네 홉. 시드니는 다섯 홉. 뉴욕이 이긴다. 패킷은 뉴욕 서버로 향한다.

한편 싱가포르에 있는 누군가가 정확히 같은 주소로 패킷을 보낸다. 그들의 ISP 라우터는 도쿄가 가장 가깝다고 판단한다. 패킷은 도쿄로 향한다.

같은 주소. 다른 목적지. 인터넷의 라우팅 구조가 모든 패킷에 대해, 보이지 않게, 즉각적으로 결정을 내린다.

자동 분산의 마법

사용자와 서버 사이에 로드 밸런서가 없다. 각 요청을 들여다보는 중간자도 없다. 인터넷 자체가 로드 밸런서다.

이것이 애니캐스트가 마법처럼 느껴지는 이유다. 서버를 배포하고, 각 위치에서 동일한 주소를 알리면, 트래픽이 자동으로 가까운 서버로 흐른다. 유럽 사용자는 유럽 서버에 접속한다. 아시아 사용자는 아시아 서버에 접속한다. 직접 설정하지 않아도 된다. BGP가 한 것이다.

용량을 늘리는 것도 마찬가지로 우아하다. 상파울루에 새 서버를 배포하고 동일한 주소 대역을 알리면, 남미 트래픽이 그쪽으로 흐르기 시작한다. 서버를 제거할 때는 알림을 철회하면 되고, 트래픽은 다음으로 가까운 위치로 자연스럽게 넘어간다. 인터넷이 스스로 적응한다.

애니캐스트가 쓰이는 곳

DNS 루트 서버

DNS 루트 서버 시스템에는 진정으로 기이한 면이 있다. 루트 서버 주소는 13개뿐이지만(a.root-servers.net부터 m.root-servers.net까지), 수백 대의 물리적 서버가 그 질의에 응답한다. 인터넷의 전화번호부에는 항목이 13개뿐인데, 그 각각이 동시에 모든 곳을 가리킨다.

기기가 루트 서버에 질의하면, 자동으로 가까운 서버로 연결된다. 빠른 응답, 내장된 이중화—그리고 "그" 루트 서버를 노리는 공격은 수십 개의 위치로 분산된다.

공개 DNS

Google의 8.8.8.8과 Cloudflare의 1.1.1.1은 애니캐스트 주소다. 이 기억하기 쉬운 IP들은 수백 개의 위치에 존재한다. 어디에 있든 빠른 응답을 받는 것은, "8.8.8.8"이 항상 당신 가까이에 있기 때문이다—당신이 어디에 있든.

콘텐츠 전송 네트워크

CDN은 애니캐스트를 사용해 가까운 엣지 서버로 연결한다. 이미지를 요청하면 바다 건너 서버가 아닌, 몇 밀리초 거리의 서버에서 받는다.

DDoS 방어

공격자가 애니캐스트 주소를 공격하면, 실제로는 수십 대의 서버를 동시에 공격하는 셈이다. 각 위치가 공격의 일부를 나눠 흡수한다. 단일 서버라면 무너졌을 공격이 전 세계에 분산되면 큰 영향을 주지 못한다.

애니캐스트가 잘 작동하는 이유

사용자별 설정 불필요: 지역별 DNS나 지리적 로드 밸런싱을 따로 설정할 필요가 없다. 하나의 IP 주소가 어디서나, 모든 사람을 위해 작동한다.

자동 페일오버: 도쿄가 다운되면, 그쪽으로 향하던 패킷이 자동으로 다음으로 가까운 서버로 넘어간다. 사용자는 잠깐의 지연을 겪을 수 있지만, 서비스 자체는 이어진다.

지연 시간 단축: 물리 법칙은 속일 수 없다—빛이 이동하는 데는 시간이 걸린다. 애니캐스트는 그 대신 지리적 한계를 극복한다. 사용자 가까이에 서버를 두는 것이다.

운영 간소화: 공개할 주소 하나, 사용자가 기억할 주소 하나, 문서에 적을 주소 하나. 복잡성은 라우팅 계층 안에 숨는다.

주의할 점

BGP 경로는 물리적 거리와 다르다

BGP는 지리적으로 가장 가까운 서버가 아닌, 네트워크 홉 수가 가장 적은 서버로 라우팅한다. 때로는 "가장 가까운" 서버가 실제로는 더 먼 곳에 있을 수 있다. 네트워크 위상과 물리적 거리는 항상 일치하지 않는다.

상태 유지 연결은 취약하다

애니캐스트는 DNS처럼 무상태 프로토콜에서 진가를 발휘한다. 질문, 답변, 끝. 몇 분 또는 몇 시간 지속되는 TCP 연결은 위험성이 더 크다. 라우팅이 연결 도중에 바뀌면, 패킷이 갑자기 아무것도 모르는 서버에 도달한다. 연결이 끊긴다.

현대적인 구현은 이를 우회한다—애니캐스트 노드를 안정적으로 유지하고, 간헐적인 연결 재설정을 허용하며, 단기 연결을 활용한다. 그러나 근본적인 긴장은 여전히 남아 있다. 애니캐스트는 모든 패킷이 어디로든 갈 수 있다고 가정하지만, TCP는 패킷이 같은 곳으로 간다고 가정한다.

트래픽 분산이 고르지 않을 수 있다

트래픽은 서버 부하가 아닌 라우팅에 따라 흐른다. 한 위치가 과부하 상태인데도 다른 위치는 한가할 수 있다—BGP는 서버가 얼마나 바쁜지 알지도 못하고 신경도 쓰지 않는다.

운영 복잡성

여러 위치에서 경로 알림을 조율하고, 여러 서버가 주소를 공유할 때 라우팅 문제를 디버깅하고, 전 세계적으로 일관된 동작을 보장하는 것—애니캐스트 운영에는 전문 지식이 필요하다.

핵심 통찰

애니캐스트는 주소와 위치 사이의 통상적인 관계를 뒤집는다. "이 주소는 이 장소를 뜻한다" 대신, 애니캐스트는 "이 주소는 당신에게 가장 가까운 곳을 뜻한다"고 말한다.

모두가 믿기로 한 거짓말이다. 그리고 모두가 믿기 때문에 작동한다. 패킷은 가장 가까운 서버를 찾는다. 서버가 응답한다. 다른 선택지가 있었다는 것을, 다른 서버가, 택하지 않은 다른 경로가 있었다는 것을 당신은 알지 못한다.

인터넷에서 가장 신뢰할 수 있는 서비스들이 이 공유된 약속에 기대고 있다. DNS 루트 서버에 질의하거나 1.1.1.1을 쓸 때, 당신은 하나의 주소가 여러 장소를 의미하고, "어디"가 전적으로 묻는 사람에 따라 달라지는 정교한 합의에 참여하고 있다.

자주 묻는 질문

애니캐스트는 로드 밸런싱과 어떻게 다른가요?

기존 로드 밸런서는 사용자와 서버 사이에 위치하며 요청을 능동적으로 분산한다. 애니캐스트는 그 결정을 인터넷의 라우팅 계층으로 넘긴다—중간 관리자가 없다. BGP 라우터가 중앙 컨트롤러 없이 네트워크 위상만 보고 선택한다. 덕분에 애니캐스트는 무한히 확장 가능하지만(무너질 로드 밸런서 자체가 없으니), 트래픽이 정확히 어디로 가는지에 대한 제어는 줄어든다.

제 웹사이트에도 애니캐스트를 쓸 수 있나요?

가능하지만, 여러 위치에서 BGP 연결이 필요하다. 이는 일반적으로 BGP를 지원하는 데이터 센터에서 직접 인프라를 운영하거나, 애니캐스트 서비스를 제공하는 업체를 이용하는 것을 의미한다. 대부분의 웹사이트는 BGP를 직접 관리할 필요 없이 유사한 지리적 분산을 제공하는 CDN을 선택한다.

가장 가까운 애니캐스트 서버가 다운되면 어떻게 되나요?

트래픽은 자동으로 다음으로 가까운 서버로 넘어간다. 특정 위치가 BGP 경로 알림을 중단하면—의도적으로든 장애 때문이든—라우터가 그 경로를 라우팅 테이블에서 제거한다. 몇 초에서 몇 분 이내에 패킷은 새로운 목적지를 찾는다. 잠깐의 지연이 있을 수 있지만, 서비스는 계속된다.

DNS 서비스는 애니캐스트를 쓰는데, 대부분의 웹사이트는 왜 안 쓰나요?

DNS 질의는 애니캐스트에 딱 맞는다. 작고, 무상태이며, 독립적이다. 각 질의는 완결된 트랜잭션—질문이 들어오고 답변이 나가면 끝이다. 웹사이트는 다르다. 지속되는 TCP 연결, 세션 상태, 연속성에 대한 기대가 있다. 웹사이트에 애니캐스트를 적용할 수 있지만(많은 CDN이 이를 증명한다), 웹 트래픽의 상태 유지적 특성을 처리하기 위해 더 정교한 엔지니어링이 필요하다.