오늘은 CDN의 핵심 기술인 Request Routing에 대해서 소개해 드리겠습니다.
Request Routing은 사용자의 Content Request(예. 쿵푸펜더2 볼래요~)에 대해 최적의 Cache Server를 선택해 주는 기능으로 이를 위해 CDN 망에는 Request Router가 존재합니다. (이름에 Router가 들어갔다고 IP Routing의 OSPF, BGP와 같은 라우팅 기능을 수행하는 것은 아님)
Request Router는 DNS 기능을 지원하며 사용자의 Content 요청을 Cache Server로 Redirection해 주는 방식에 따라 DNS-based Request Routing과 Service-based Request Routing으로 나눌 수 있습니다.
DNS-based Request Routing
- 사용자 단말이 요청한 orgin.example.com에 대해 example.com DNS 서버는 CNAME으로 csp123.cdn.kt.com을 돌려주고 (5, 6번)
- Local DNS 서버는 Request Router로 DNS Query를 전달하여 Host Name = csp123.cdn.kt.com에 대한 IP 주소를 요청합니다 (7번).
- Request Router는 [1] Local DNS 서버의 IP 주소와 [2] Cache Server의 부하 등을 고려하여 Cache Server의 IP 주소를 바로 알려 줍니다 (8, 9번).
- 사용자 단말은 이 Cache Server로 Content Request(예. HTTP GET)를 보내 Content(예. 비디오 파일)를 다운로드/스트리밍 받습니다 (11, 12번).
이 방식에서 Request Router는 사용자 단말과의 통신이 없고 또 Local DNS 서버가 단말의 IP 주소를 Request Router로 전달하지 않기 때문에 Cache Server를 선택할 때 사용자의 위치 정보는 활용되지 못하며 또한 사용자가 요청한 Content의 서비스 유형(예. RTMP, HLS 등)을 Request Router가 알 수 없으므로 "서비스 기반의 라우팅(Cache Server 선택)이 불가능"하다는 단점을 가집니다.
Service-based Request Routing
- 사용자 단말이 요청한 orgin.example.com에 대해 example.com DNS 서버는 CNAME으로 csp123.cdn.kt.com을 돌려주고 (5, 6번)
- Local DNS 서버는 Request Router로 DNS Query를 전달하여 Host Name = csp123.cdn.kt.com에 대한 IP 주소를 요청합니다 (7번).
- Request Router는 DNS Response로 자신의 IP 주소(1.1.1.1)를 줍니다 (8번).
- 따라서 사용자 단말은 Request Router로 Content Request를 보냅니다 (10번).
- Request Router는 [1] 요청된 서비스 유형, [2] 요청 Content에 대한 Cache Server의 캐싱 여부, [3] 사용자 단말 IP 주소 기반의 위치 정보, [4] Cache Server의 부하 등을 고려하여 적절한 Cache Server를 선택하고, 해당 Cache Server로의 HTTP 302 Redirection 메시지(Location = http://cache1.cdn.kt.net/vod/movie1.mp4)를 사용자 단말로 전달합니다 (11, 12번)
- 사용자 단말은 cache1.cdn.kt.net의 IP 주소를 알기 위해 다시 한번 DNS Query를 보내고 Request Router는 cache1.cdn.kt.net의 IP 주소를 알려 줍니다 (13~16번).
- 이제 사용자 단말은 이 Cache Server(10.100.10.1)로 Content Request를 보내 Content(예. 비디오 파일)를 다운로드/스트리밍 받습니다 (17, 18번)
이와 같이 서비스 요청을 기반으로 Redirection 하는 방법은 위 설명의 예인 HTTP 302 Redirection 외에 HTTP ASX Redirection, RTSP 302 Redirection, RTMP 302 Redirection등이 있습니다.
이 방식은 사용자 단말이 직접 Request Router로 Content Request를 보내게 함으로써,
- Request Router가 사용자 단말의 IP 주소를 알 수 있어 사용자에서 지리적으로 가장 가까운 Cache Server를 선택해 줄 수 있고
- Content Request의 URI 정보를 통해 서비스 요청 타입(RTMP streaming, Microsoft Smooth Streaming, Progressive Download 등)을 알 수 있어 해당 서비스를 지원하는 Cache Server를 선택할 수 있고
- Cache Server 선택 후 Content의 URI를 hash하여 그 hash 값을 Request Router가 관리함으로써 이후 동일 Content 요청이 왔을 때 동일 Cache Server를 선택(redirection)함으로써 Cache Hit 율을 높일 수 있게 해 줍니다.
현재 DNS-based Request Routing은 Akamai, Amazon과 같은 Global CDN 업체에서 사용하고, Service-based Request Routing은 통신 사업자 CDN에서 주로 사용되고 있습니다.
한가지 의문점이 마지막 글귀에서 Service-based Request 가장 필요한(지역기반 Routing) GCDN 업체들이 DNS-based Request Routing주로 사용한다는게 비효율적인 것 같습니다. 예상으로는 Service-based Request 으로 지역 기반 라우팅 후 DNS-based Request Routing등으로 분산을 하는 방식으로 사용하지 않을까 했거든요.
▶ 통신사업자 CDN: Service based Request Routing
- Cache 서버의 위치: 각 시/도 (한 통신사업자내 수개~수십개의 POP 존재)
- 사용자의 IP 주소로 알 수 있는 정보: 사용자의 정확한 위치 (예. 사용자 IP = 118.131.192.217은 서울 강남구 논현동)
- 각 시/도에 분산된 Cache 서버 중에 사용자와 가장 가까운 서버를 선택하기 위해서는 "사용자의 IP 주소"를 알아야 함
▶ Global CDN: DNS based Request Routing
- Cache 서버의 위치: 전세계 통신사업자의 IDC (통상적으로 통신사업자의 IDC는 1~2개 정도임)
- Local DNS 서버 IP 주소로 알 수 있는 정보: 사용자가 위치한 국가/통신사업자 (예. Local DNS IP = 168.126.63.1은 대한민국/KT)
- 각 국가/통신사업자에 분산된 Cache 서버 중에 사용자와 가장 가까운 서버를 선택하기 위해서는 굳이 사용자의 IP 주소를 몰라도 Local DNS 서버 IP 주소로도 파악이 가능함 (예. Local DNS IP = 168.126.63.1을 보고 대한민국 KT에 위치한 Cache 서버(아마도 서울에 위치) 선택)
*참고로 설명하신 내용은 아래 처럼 바뀌어야 겠네요.
▶ 통신사업자 CDN: Service based Request Routing
▶ Global CDN: DNS based Request Routing
수정했습니다. 고맙습니다.
글 마지막에 Service-based Request Routing의 장점 3가지를 적어 주셨는데요. 그렇다면 DNS 기반의 Global CDN 업체는 이 3가지 문제를 어떻게 풀었나요?
-> 위에 답변 내용(10/23/2012)과같이 Global CDN 관점에서 바라보는 가까운 Cache Server는 국가/통신사업자 레벨임
2. Content Request의 URI 정보를 통해 서비스 요청 타입(RTMP streaming, Microsoft Smooth Streaming, Progressive Download 등)을 알 수 있어 해당 서비스를 지원하는 Cache Server를 선택
-> Amazon CDN(Amazon CloudFront)의 경우, 2종류의 Cache Server가 존재합니다. 하나는 "다운로드형", 또하나는 "스트리밍형"이라서, 스트리밍형 Cache Server에만 RTMP 등의 스트리밍 software가 탑재되어 있습니다.
그리고 CDN 서비스를 사용할 고객은 서비스 타입이 "다운로드"인지 "스트리밍"인지를 선택하게 되고, 그 타입에 따라 Amazon CDN은 서로 다른 Domain Name(CNAME)을 생성합니다.
3. Cache Server 선택 후 Content의 URI를 hash하여 그 hash 값을 Request Router가 관리함으로써 이후 동일 Content 요청이 왔을 때 동일 Cache Server를 선택(redirection)함으로써 Cache Hit 율을 높일 수 있음
-> Global CDN은 사용자의 Content Request 메시지(예. HTTP GET)를 수신하지 않으므로 이 부분은 해결 될 수 없을 것 같네요.
한가지 질문이 있는데요. DNS-based Request Routing에서 "Local DNS 서버의 IP 주소를 고려하여 Cache Server의 IP 주소를 알려 준다"고 하셨는데요. 이게 정확히 어떤 뜻인가요?
여기서 "가깝다"라는 뜻은 2가지로 해석될 수 있습니다.
1. 지리적 거리가 가깝다 (멋지게 얘기하면 Geographic Proximity)
: "지리적 거리"란 BGP에서 말하는 AS Path입니다. 그리고 AS는 ISP를 의미합니다. 예를 들어 KT에서 LG U+ Network은 바로 Peering되어 있으므로 AS Path가 1이라면 KT에서 STC(사우디 통신 사업자)까지는 여러 ISP를 거치게 되므로 AS Path가 1보다 훨씬 크겠죠. 따라서 KT Local DNS 서버를 사용하는 이용자에게는 STC가 아닌 LG U+에 Cache Server를 선택해 줍니다. (KT에 Cache Server가 없다는 가정하에)
결과적으로 DNS 기반의 Request Routing에서 Geographic Proximity를 적용하게 되면 Local DNS 서버와 AS Path가 가장 짧은 Cache Server를 선택해 줍니다.
2. 네트웍 관점에서 가깝다 (Network Proximity)
: "네트웍 관점에서 가깝다"는 의미는 RTT(Delay)와 Packet Loss가 작다는 것을 의미합니다. 이를 위해 Cache Server가 위치한 곳(보통 cluster, region이라 부르더군요)에 있는 특정 서버는 Local DNS 서버에 Ping을 때려 RTT와 Loss를 주기적으로 확인합니다. 그리고 그 정보를 Request Router로 보고합니다.
그래서 DNS 기반의 Request Router는 각 Local DNS 서버와 Cluster/Region 사이에 RTT 및 Loss 정보를 기반으로 Cache Server를 선택해 줍니다.
로드밸런싱과 리퀘스트라우팅은 다른것인가요?
기술적 관점에서 GSLB = Request Routing이라 보시면 될 듯 합니다. GSLB 자료는 아래 링크 참조하세요.
https://www.netmanias.com/ko/?m=view&id=blog&no=5620
네 그렇다면 GSLB는 DNS-based 방식인가요?
네, 맞습니다. 아래 넷매니아즈 블로그를 참고하세요.
https://www.netmanias.com/ko/?m=view&id=blog&no=5617
https://www.netmanias.com/ko/?m=view&id=blog&no=5620
https://www.netmanias.com/ko/?m=view&id=blog&no=5622
https://www.netmanias.com/ko/?m=view&id=blog&no=5624
회사에서 CDN 서비스를 새로 받으려면 회사 도메인 예를 들어 www.abc.com의 cname인 eg.abc.com을 local dns에 돌려 줄때 A레코드 정보로 CDN의 리퀘스터 라우터 정보를 주면 되는 건가요?