Güncellendi 1 ay önce
8.8.8.8을 DNS 설정에 입력했을 때, 여러분은 단 하나의 서버에 연결되는 것이 아닙니다. 6개 대륙에 흩어져 있는 수백 개의 서버 중 하나에 도달하는 것이며, 이 서버들은 모두 정확히 동일한 IP 주소를 공유합니다.
어떻게 이것이 가능할까요? 인터넷의 라우팅 시스템이 자동으로 요청을 가장 "가까운" 서버로 전달합니다—지리적으로 가까운 것이 아니라, 네트워크 관점에서 가까운 것으로. 이것이 바로 애니캐스트입니다: 하나의 주소, 여러 목적지, 자동 선택.
애니캐스트는 절대 장애가 나서는 안 되는 인프라를 지탱합니다: 매일 수십억 건의 쿼리에 응답하는 DNS 루트 서버, 웹의 대부분 이미지와 동영상을 제공하는 콘텐츠 전송 네트워크, 테라비트 규모의 공격을 흡수하는 DDoS 완화 시스템.
애니캐스트가 다른 이유
애니캐스트는 우리가 일반적으로 로드 밸런싱을 생각하는 방식을 뒤집습니다.
전통적인 로드 밸런서는 사용자와 서버 사이에 위치하여 명시적인 라우팅 결정을 내립니다. DNS 기반 로드 밸런싱은 서로 다른 사용자에게 서로 다른 IP 주소를 반환합니다. 지리적 라우팅은 애플리케이션 로직을 사용하여 엔드포인트를 선택합니다.
애니캐스트는 이 중 어느 것도 하지 않습니다. 로드 밸런서를 프로그래밍하는 것이 아니라—네트워크에 질문을 던지고 알아서 답을 찾게 합니다. 전 세계 데이터 센터에서 동일한 IP 주소를 알리면, 인터넷의 라우팅 시스템이 자동으로 각 요청을 가장 가까운 곳으로 전달합니다.
라우팅 인프라 자체가 로드 밸런서가 됩니다. 중앙 컨트롤러도 없습니다. 서버를 추가할 때 설정을 업데이트할 필요도 없습니다. 네트워크가 알아서 처리합니다.
트래픽을 라우팅하는 네 가지 방법
인터넷에는 근본적으로 서로 다른 네 가지 라우팅 방법이 있습니다:
유니캐스트는 한 발신자에서 한 수신자로 트래픽을 전송합니다. 대부분의 인터넷 트래픽이 이 방식입니다—HTTP 요청, 이메일, 동영상 스트림. 하나의 출처, 하나의 목적지.
브로드캐스트는 원하든 원하지 않든 로컬 네트워크의 모든 기기에 트래픽을 전송합니다. ARP와 DHCP가 브로드캐스트를 사용합니다. 대부분의 기기가 무시하는 트래픽으로 네트워크를 채웁니다. IPv6에서는 완전히 제거되었습니다.
멀티캐스트는 명시적으로 참여 신청을 한 기기에만 트래픽을 전송합니다. IPTV는 멀티캐스트를 사용하여 수천 건의 중복 스트림 대신 하나의 동영상 스트림을 수천 명의 구독자에게 동시에 전송합니다.
애니캐스트는 그룹 중 가장 가까운 노드에 트래픽을 전송합니다. 여러 서버가 동일한 IP 주소를 알립니다. 라우팅 시스템이 자동으로 가장 가까운 것을 선택합니다.
애니캐스트의 작동 원리
애니캐스트는 전적으로 BGP—인터넷을 하나로 묶어주는 경계 게이트웨이 프로토콜—에 의존합니다.
작동 방식은 이렇습니다: 구글은 버지니아, 캘리포니아, 도쿄, 런던, 상파울루, 그리고 수십 개의 다른 위치에 있는 데이터 센터에서 8.8.8.8을 알립니다. 각 알림은 라우터들이 피어와 정보를 공유하면서 인터넷 전체로 전파됩니다.
8.8.8.8로 요청을 보내면, 경로상의 모든 라우터가 동일한 질문을 합니다: 이 주소로 가는 최선의 경로는 무엇인가? 주요 기준은 AS-path 길이—트래픽이 통과해야 하는 자율 시스템(독립 네트워크)의 수입니다. 경로가 짧을수록 유리합니다.
요청은 가장 짧은 네트워크 경로를 통해 8.8.8.8을 알리는 서버에 도달합니다. 해당 서버가 장애가 나면, BGP가 경로 알림을 철회합니다. 트래픽은 몇 초 안에 자동으로 다음으로 좋은 경로로 전환됩니다.
"가장 가까운"이 생각과 다를 수 있습니다
여기서 직관이 완전히 무너집니다.
뭄바이 사용자가 뭄바이에 있는 서버 대신 싱가포르에 있는 서버에 도달할 수 있습니다—뭄바이가 물리적으로 더 가까운데도 말이죠. 왜일까요? 싱가포르로 가는 네트워크 경로가 더 적은 수의 자율 시스템을 통과하기 때문입니다.
이것은 단순한 특이 현상이 아닙니다. 본질적인 속성입니다. 인터넷의 토폴로지는 지리를 따르지 않습니다.
"가깝다"는 것에 대한 직관은 우리가 볼 수 있는 지도—도로, 도시, 해안선—를 기반으로 합니다. 인터넷의 지도는 오직 라우팅 테이블 안에만 존재하며, 통신사들 간의 사업 계약, 예상치 못한 각도로 대양을 가로지르는 해저 케이블, 그리고 표면에서는 보이지 않는 지름길을 만드는 피어링 계약에 의해 형성됩니다.
토폴로지상 가장 가까운 서버가 항상 이깁니다. 지리는 무관합니다.
애니캐스트가 인터넷을 지탱하는 곳
DNS 루트 서버는 전적으로 애니캐스트로 운영됩니다. 13개의 루트 서버(A부터 M까지)는 전 세계 1,500개 이상의 사이트에 걸쳐 1,950개 이상의 인스턴스가 운영됩니다1. 루트 서버에 쿼리를 보낼 때, 이 분산된 위치 중 하나에 도달하는 것입니다—같은 물리적 서버로 두 번 연속 연결되지는 않습니다.
공개 DNS 리졸버도 애니캐스트에 의존합니다. 구글의 8.8.8.8은 전 세계 데이터 센터에서 운영되며, 모든 DNS 트래픽의 약 30%를 처리합니다2. Cloudflare의 1.1.1.1은 전 세계 330개 도시에서 운영됩니다3.
콘텐츠 전송 네트워크는 애니캐스트를 사용하여 트래픽을 엣지 서버로 라우팅합니다. 하나의 애니캐스트 IP가 수천 개의 엣지 위치를 대표하며, 사용자를 자동으로 가까운 캐시로 안내합니다. Cloudflare, Akamai, Amazon CloudFront, Fastly 모두 이를 기반으로 구축됩니다.
DDoS 완화는 애니캐스트로 인해 본질적인 보호를 얻습니다. 공격자가 단일 IP에 트래픽을 쏟아부을 때, 애니캐스트는 그 트래픽을 하나의 대상을 압도하는 대신 수십 또는 수백 개의 서버에 분산시킵니다.
2015년 11월 DNS 루트 서버에 대한 공격—정상 부하의 100배에 달하는 지속적인 트래픽—에서 애니캐스트가 장애를 방지했습니다. 공격이 자동으로 여러 사이트에 분산되었습니다. 단일 장애 지점도, 단일 과부하 지점도 없었습니다.
애니캐스트가 중요한 이유
지연 시간이 극적으로 줄어듭니다. 사용자는 네트워크 관점에서 가장 가까운 서버에 연결되어, 응답 시간이 수백 밀리초에서 수십 밀리초로 단축됩니다. DNS의 경우 이것이 중요합니다—모든 웹사이트 방문은 DNS 조회로 시작되기 때문입니다.
장애 조치가 눈에 보이지 않게 일어납니다. 서버나 데이터 센터가 장애를 일으키면, BGP가 경로를 철회합니다. 트래픽은 몇 초 안에 다음으로 가까운 위치로 재라우팅됩니다. 로드 밸런서 재설정도 없습니다. DNS TTL 지연도 없습니다. 네트워크가 스스로 치유됩니다.
확장이 간단해집니다. 용량을 추가한다는 것은 동일한 IP를 알리는 서버를 배포한다는 의미입니다. 클라이언트는 업데이트할 것이 전혀 없습니다. 네트워크가 새 노드를 자동으로 통합합니다.
DDoS 공격이 희석됩니다. 공격 트래픽이 하나의 대상에 집중되는 대신 전체 네트워크에 분산됩니다. 수백 개의 엔드포인트가 동시에 흡수하면 테라비트 규모의 공격도 관리 가능해집니다.
한계점
상태 유지 연결이 어렵습니다. 애니캐스트는 UDP 기반 DNS와 같은 무상태 프로토콜에서 탁월합니다. TCP는 더 까다롭습니다—연결 도중 네트워크 토폴로지가 바뀌면, 패킷이 세션에 대해 아무것도 모르는 다른 서버로 라우팅될 수 있습니다. 그 서버는 TCP 리셋을 보내 연결을 끊습니다.
단기 TCP 연결의 경우, 이것은 거의 문제가 되지 않습니다. 연구에 따르면 라우팅 변경으로 인한 세션 중단은 전체 연결의 0.017% 미만에서 발생합니다. 하지만 장기 연결의 경우, 실질적인 제약입니다.
라우트 플래핑이 세션을 끊습니다. 여러 애니캐스트 노드가 등거리에 있을 때, 사소한 라우팅 변경이 트래픽을 반복적으로 노드 사이에서 전환시킬 수 있습니다. 각 전환은 잠재적으로 상태 유지 연결을 끊습니다.
연쇄 장애가 가능합니다. 하나의 노드가 과부하 상태가 되어 BGP 알림을 철회하면, 트래픽이 다음으로 가까운 노드로 이동합니다. 그 노드도 용량이 부족하면 역시 장애가 날 수 있습니다—도미노가 쓰러지듯.
특별한 주소 범위 없음
멀티캐스트(224.0.0.0/4)나 사설 주소(192.168.0.0/16)와 달리, 애니캐스트에는 예약된 IP 범위가 없습니다. 공개 라우팅 가능한 모든 주소가 애니캐스트가 될 수 있습니다.
차이는 순전히 라우팅 설정에 있습니다. 한 위치에서 8.8.8.8을 알리면: 유니캐스트. 50개 위치에서 알리면: 애니캐스트. IP 주소는 변하지 않습니다. 라우팅 동작이 얼마나 많은 곳에서 알리느냐에 따라 달라집니다.
8.8.8.8로 전송된 패킷은 하나의 서버에 도달하든 수백 개 중 하나에 도달하든 동일하게 보입니다. 애니캐스트는 IP 계층에서는 보이지 않습니다—오직 라우팅 인프라 안에만 존재합니다.
설계 철학
애니캐스트는 인터넷이 어떻게 만들어졌는지에 대한 무언가를 드러냅니다.
설계자들은 모든 라우팅 질문에 올바른 답을 아는 시스템을 만들려 하지 않았습니다. 그들은 각각 부분적인 정보를 가진 수백만 개의 라우터가 끊임없는 협상을 통해 집단적으로 적당한 답을 찾아내는 시스템을 만들었습니다.
애니캐스트는 이것을 적극 활용합니다. 네트워크의 분산된 특성과 싸우는 것이 아니라 이를 이용합니다. 하나의 주소, 모든 곳에서 알려지고, 네트워크의 집단 지성이 트래픽을 적절히 라우팅합니다.
절대 장애가 나서는 안 되는 서비스에 있어, 이 트레이드오프는 효과적입니다. DNS 루트 서버는 단일 장애 지점을 감당할 수 없습니다. CDN은 사용자가 가까운 캐시에 도달해야 합니다. DDoS 방어는 공격 트래픽을 전 세계에 분산시켜야 합니다.
애니캐스트는 하나의 메커니즘으로 세 가지를 모두 해결합니다: 네트워크가 알아서 처리하도록 믿는 것.
애니캐스트에 관한 자주 묻는 질문
애니캐스트는 DNS 기반 로드 밸런싱과 어떻게 다른가요?
DNS 기반 로드 밸런싱은 사용자의 위치에 따라 서로 다른 IP 주소를 반환합니다. 애니캐스트는 네트워크 토폴로지에 따라 서로 다른 서버로 라우팅되는 단일 IP 주소를 사용합니다. DNS 로드 밸런싱은 장애 조치를 위해 TTL 만료가 필요합니다(종종 수 분 소요); 애니캐스트는 BGP 경로 철회를 통해 수 초 안에 장애 조치가 이루어집니다.
내 서비스에 애니캐스트를 사용할 수 있나요?
네, 하지만 자체 IP 주소 공간을 보유하고 여러 네트워크와 BGP 피어링 관계를 유지해야 합니다. 이는 일반적으로 ISP이거나 상당한 인프라를 보유하고 있어야 가능합니다. 대부분의 조직은 직접 구현하는 대신 CDN 제공업체를 통해 애니캐스트를 이용합니다.
모든 웹사이트가 애니캐스트를 사용하지 않는 이유는?
애니캐스트는 무상태 또는 단기 연결에 가장 적합합니다. 장바구니, 사용자 세션, 실시간 기능을 가진 웹사이트는 애니캐스트 모델에 맞지 않는 세션 상태가 필요합니다—라우팅 변경이 사용자를 장바구니 내용을 모르는 서버로 보낼 수 있기 때문입니다. CDN은 정적 콘텐츠에 애니캐스트를 사용하면서 동적 요청은 다른 메커니즘으로 처리합니다.
내가 애니캐스트 서비스를 사용하고 있는지 어떻게 알 수 있나요?
일반적으로 클라이언트 측에서는 알 수 없습니다—IP 주소가 유니캐스트와 동일하게 보입니다. 다른 위치에서 traceroute를 실행하면 동일한 IP로 가는 서로 다른 경로를 확인할 수 있습니다. 8.8.8.8이나 1.1.1.1과 같은 서비스는 애니캐스트를 사용한다고 알려져 있지만, 프로토콜 자체는 설계상 최종 사용자에게 보이지 않습니다.
출처
Bu sayfa faydalı oldu mu?