동적 콘텐츠 가속(Dynamic Content Acceleration)을 위한 CDN 기술들
김봉석 (Bongseok Kim)
--------------------------------------------------------------------------------------------------------------------
요약문
CDN에 적용되는 가장 일반적 기술은 정적 콘텐츠를 캐시하여 서비스하는 Caching이다. CDN 사업자라면 기본으로 제공하는 Caching 외에 동적 콘텐츠를 가속하는 Dynamic Content Acceleration이야 말로 인터넷 상에서 콘텐츠를 가속하는 핵심 CDN 서비스이다. Dynamic Content Acceleration을 위한 Global Distributed DNS, Connection Pooling and HTTP Keep Alive, Dynamic Routing, TCP Optimization 등 다양한 기술들에 대해 알아본다.
--------------------------------------------------------------------------------------------------------------------
1. 인터넷 사용 환경의 진화
인터넷과 인터넷 비즈니스는 이미 한국뿐만 아니라 전 세계 인류의 삶을 대변하고 있다. 요즘 네이버, 다음, 페이스북으로 대표되는 포털/SNS 사이트와 유튜브로 대표되는 동영상 사이트는 우리의 삶에서는 없어서는 안될 도구로 거듭난 지 오래다. 그리고 이러한 인터넷 비즈니스와 함께 각종 모바일 기기들은 인터넷 생태계를 송두리째 바꿔버렸다. 아이폰이 출시된 이후 한국에도 각종 스마트폰이 론칭되었고 통신 사업자와 단말기 제조업자 간 스마트폰 전쟁뿐만 아니라 우후죽순으로 생겨나고 있는 소셜 네트워킹 서비스 및 어플리케이션들은 한국의 인터넷 생태계를 송두리째 바꿔버렸다. 인터넷을 매개로 연결된 다수 사용자들은 성인-청소년, 남자-여자, 사장-임직원의 관계를 수평으로 허물어버렸고 글로벌-한국, 대기업-중소기업, 엔터프라이즈-닷컴의 시장 경계를 허물어버렸다. 분명 이 중심에는 분명 국경이 없는 인터넷과, 이러한 인터넷을 기반으로 전 세계 인류를 대상으로 서비스하는 인터넷 비즈니스와, 스마트폰이나 태블릿PC 등의 모바일 기기가 있다. 진정한 인터넷 빅뱅이 시작된 것이다.
(그림1. 2016년까지의 트래픽 증가 예상치)
2. 모든 인터넷 사용자가 이미 사용하고 있는 CDN
모든 인터넷 사용자는 이미 CDN을 체험하고 있다. 위에서 열거한 대표적 기업들 외에도 인터넷 사용자라면 언뜻 떠올릴 수 있는 모든 기업들은 이미 CDN을 사용하여 그들의 콘텐츠를 빠르게 사용자에게 전달하고 있다. 당연한 일이겠지만 사용자는 보다 고품질의 콘텐츠를, 보다 빨리, 자신들의 기기에 최적화된 후 전달 받길 원한다. 웹사이트가 느리게 열리거나, 잦은 동영상 버퍼링 현상이 발생하거나, 파일 다운로드가 느리거나, SaaS형 웹 어플리케이션이 자주 트랜잭션이 완결되지 않으면, 사용자는 기업이 제공하는 비즈니스에 더 이상 참여하지 않는다. 따라서, 기업 입장에서는 이러한 사용자들의 욕구를 뒷받침해야만 인터넷 비즈니스에서 성공할 수 있다.
(그림2. 사용자 니즈와 기업 서비스의 선순환 구조)
3. 고도로 발전하고 있는 CDN 기술과 다양한 비즈니스 모델로의 팽창
전통적으로 CDN은 ‘캐싱(Caching)’ 이라는 기술을 기반으로 빠르게 콘텐츠를 전달해왔다. CDN에서 발전 시켜온 기술을 논하기 전에 먼저 CDN의 역사를 거슬러 올라가보자. 한국은 2000년도, 태생적으로 나라가 넓어 상대적으로 CDN이 더 절실했던 미국은 1997년도로 거슬러 올라간다. 최근까지 인터넷 제반 인프라가 고도로 발달한 한국에 비해 미국은 그렇지 못했기 때문에 ISP간의 IX구간 네트워크 라우팅을 최적화하는 방향으로 발전했다. 네트워크 홉(Hop)수 기반으로 최적 경로를 산출하는 것, RTT(Round Trip Time)을 최소화할 수 있는 경로로 라우팅하는 것, 가장 가까운 라우팅 거리라고 해도 병목현상이 발생하는 IX구간을 우회하는 경로로 라우팅하는 것, 이러한 것들이 미국이 먼저 발전시켜왔던 기술이다. 반면, 한국은 ISP간의 IX 구간이 열려있고 ISP의 제반 기술 및 인프라 투자가 높았기 때문에 2000년대 초기 외에는 이러한 고민을 할 필요가 없었다. 그래서 사용자 트래픽을 탄력적으로 대응하는 구성으로 발전해왔다. 그러나 인터넷은 국경이 없는 세상이다. 인터넷은 바로 글로벌이고, 글로벌 IX 구간의 퍼포먼스 저하 현상을 해결하여 국내 인터넷 비즈니스 사업자의 글로벌 진출을 지원하기 위해 한국의 대표적 CDN 사업자 역시 첨단 가속 기술을 속속 개발하여 CDN 플랫폼에 탑재하고 있다.
또한, CDN 비즈니스는 이제 콘텐츠 가속 전송을 원하는 기업을 대상으로 서비스하는 것뿐만 아니라 ISP나 MNO(Mobile Network Operator), 네트워크 장비 제조사까지 그 발을 넓히고 있다. ISP나 MNO가 겪고 있는 가장 큰 고충은 바로 트래픽 폭증으로 인한 제반 네트워크 인프라스트럭처 증설 비용이다. 일관된 사용자 측면의 체감 품질, QoE(Quality of Experience)를 보장하기 위해서 Broadband를 위한 네트워크 인프라뿐만 아니라 3G와 4G 등 Cellular Network을 위한 네트워크 인프라 증설로 인한 비용은
실로 어마어마하다. ISP나 MNO가 겪고 있는 이러한 고충들은 CDN으로 많은 부분을 해결할 수 있기 때문에 네트워크 장비 제조사가 CDN 기술을 탑재한 솔루션, 혹은 네트워크 장비 제조사와 CDN 기업과의 파트너쉽 형태의 솔루션, 혹은 CDN 기업이 직접 자신의 가속 플랫폼을 ISP나 MNO 인프라에 적용하는 솔루션 등 다양한 형식이 시도되고 있다.
구분 글로벌 CDN 한국 CDN 미국/유럽 CDN 일본 CDN 중국 CDN CDN
CDNetworks Akamai Limelight
CDNetworks Akamai GS Neotek Hyosung ITX
CDNetworks Akamai Limelight EdgeCast Cotendo Mirrorimage
CDNetworks Akamai Limelight J Stream Accelia
CDNetworks Chinacache China Netcenter CDN + ADN (service type)
CDNetworks Akamai
CDNetworks Akamai
CDNetworks Akamai Cotendo
CDNetworks Akamai
CDNetworks P2P only P2P service
Nowcom
Bittorrent
Thunder P2P solution
Kamuse Peering Portal
Octoshape Avacast
Telco/ISP + CDN
SK Broadband KT LG U+
AT&T Level 3 TaTa (India) Internap KPN (Holland) Global crossing
NTT KDDI
IDC + CDN
Equinix
Hostway
Rackspace Savvis
Sakura internet Bit-isle
21Vianet China NetCenter Public cloud computing (IaaS, PaaS)
Amazon Google Microsoft
SK Broadband KT
Home CDN
Clunet
(표1. 전 세계 주요 CDN 및 관련 업체 현황) (주1: ADN (Application Delivery Network)은 동적 콘텐츠를 가속하는 서비스를 의미)
전 세계 내노라 하는 주요 CDN 사업자들은 단순히 기존 전통적 CDN 기술인 정적 콘텐츠에 대한
캐싱을 통한 가속 (Static Content Acceleration)뿐만 아니라 동적 콘텐츠를 가속시킬 수 있는 가속 기술을 (Dynamic Content Acceleration) 개발하여 가속 플랫폼에 탑재하여 보다 더 빠르게 기업의 콘텐츠를 전달하고 있다. 또한, 비즈니스 모델 역시 단순 콘텐츠만 가속하여 전달하는 서비스만 하는 것이 아니라 고객 웹 퍼포먼스를 위한 원스탑 서비스 제공을 위해 Global Distributed DNS, Global Traffic Management (Load Balancer), Global Distributed Storage, Transcoding, Just-in-time media file packaging 등 다양한 결합 서비스를 선보이고 있다.
(그림3. 응답시간별 가속 기술)
4. Global Distributed DNS
Global Distributed DNS는 세계 각 지에 구축한 DNS라고 생각하면 된다. 각 지의 DNS는 도메인 존 정보와 기타 설정 정보를 서로 공유하여 서비스하게 된다. 기업의 웹서버 도메인을 Global Distributed DNS에 위임하거나 아예 메인 DNS로서 서비스하는 경우 해외 사용자에게 가장 가까운 DNS가 DNS쿼리에 대해 응답함으로써 DNS Lookup Time을 국내 DNS에서만 서비스하는 경우보다 보통 5배 이상 감소시키게 된다.
또한, 각 지의 모든 DNS는 Authoritative DNS로 운영되어 정확한 도메인과 IP 정보를 제공하게 된다. 이러한 Global Distributed DNS, 즉 전 세계 각 지의 DNS가 마치 하나의 DNS처럼 동작하려면 IP Anycast 기반에서 동작해야 한다. 즉, IP Anycast는 분산되어 있는 DNS가 하나의 IP에서 동작하도록 하는 것이다. 이로 인한 장점 2가지는 바로 위에서 설명한 가장 인접한 DNS가 응답하도록 하여 성능을 개선하는 것과 하나의 DNS에 장애가 발생하더라도 다른 DNS가 응답하도록 하여 서비스 연속성을 보장하는 것이다.
(그림4. IP Anycast 기반, 평상 시 DNS 쿼리와 DNS 위치 전송 흐름)
평상 시에는 DNS 1과 DNS 2가 같은 IP를 가지고 있더라도 사용자는 BGP AS 브로드캐스팅에 의해 가장 가까운 DNS에 접속하게 된다. 따라서 같은 IP를 두 개 이상의 DNS에 셋팅이 되어 있더라도 문제는 발생하지 않고 가장 가까운 DNS가 처리하기 때문에 성능이 향상된다.
(그림4. IP Anycast기반, 장애 시 DNS 쿼리와 DNS 위치 전송 흐름)
만약 하나의 DNS에 장애가 발생하더라도 BGP 광고에 의해 인근의 다른 DNS로 우회하여 서비스된다. DNS IP가 같기 때문에 사용자나 LDNS 등은 DNS의 IP를 변경할 필요가 없다. 즉, 한 국가에 구축된 DNS에 장애가 발생하더라도 인접 국가의 DNS로 우회되어 서비스되기 때문에 전체 서비스 연속성을 24/365 보장할 수 있다.
5. Dynamic Content Acceleration
(그림5. 미투데이 콘텐츠 구성)
상기 그림5를 보면 소셜 네트워킹 사이트의 전형적인 콘텐츠 구성을 볼 수 있다. 소셜 네트워킹 사이트의 이미지나 동영상은 변하지 않는 정적 콘텐츠이기 때문에 CDN 엣지 서버에 캐시한 후 서비스하게 된다. 하지만, 게시판, 일시, 참여 인원 현황, 사용자 로그인 등은 시시 각각으로 변하거나 사용자 요청마다 결과값이 다른 동적 콘텐츠로서 CDN 엣지 서버에 캐시하면 안되는, 캐시할 수 없는 콘텐츠이다. 따라서, 정적 콘텐츠와 동적 콘텐츠를 가속 시키는 방법은 천양지차이다.
정적 콘텐츠를 가속하는 방법(Static Content Acceleration)은 캐시, 압축 등의 기술이 탑재된 캐시 플랫폼에 의해 가속한다. 캐시 플랫폼은 이러한 기술과 캐시 아키텍처 측면에서 CDN 사업자마다 조금씩의 차이가 있지만 대체적으로 대동 소이하다고 볼 수 있다. 다만 웹 퍼포먼스의 차이는 캐시 플랫폼마다 많은 차이가 발생한다.
동적 콘텐츠를 가속하는 방법(Dynamic Content Acceleration)은 캐시 플랫폼에 탑재된 3가지 대표 기술인 Connection Pooling and HTTP Keep Alive, Intelligent IP Routing, TCP Optimization 등의 기술에 의해 가속한다. 이 기술에 대해 설명하기에 앞서 왜 동적 콘텐츠를 가속해야 하는 지부터 알아보자.
(그림6. 글로벌 웹 사이트 응답속도 측정 예)
gif, js, swf 등의 정적 콘텐츠들은 모두 CDN 사업자의 엣지 서버에 캐시되어 서비스되기 때문에 상당히 빠른 응답시간을 보인다는 것을 알 수 있다. 그러나, 위에서 www.xxxx.com/main.htm은 JSP 구문을 포함하고 있다. 따라서 엣지 서버에서 바로 서비스될 수 없고 국내 웹 서버, AP 서버의 처리가 필요하기 때문에 HTTP request와 HTTP response모두 해외 낮은 품질의 인터넷 혼잡 구간을 통과할 수 밖에 없으므로 상당히 긴 응답시간을 보이고 있다. www.xxxx.com/akc.js 역시 마찬가지이다. 특정 검색 요청으로 인해 검색 서버에서의 처리가 필요하기 때문에 역시 해외 낮은 품질의 인터넷 혼잡 구간을 통과하면서 응답시간이 지연되고 있다. 이러한 동적 콘텐츠로 인해 전체 페이지의 응답속도가 느려진다면 사용자가 더 이상 참여하지 않을 것이다. 이렇게 컨트롤이 어려운 해외 Middle Mile 인터넷 구간에 대한 가속을 위해 Connection Pooling and HTTP Keep Alive, Dynamic Routing, TCP Optimization 등의 기술이 존재한다.
6. Connection Pooling and HTTP Keep Alive
(그림7. 동적 콘텐츠 가속 어시스트 기술, Connection Pooling and HTTP Keep Alive)
DNS Lookup 후 알아낸 웹 서버 IP에 사용자가 접속하여 콘텐츠를 전송받기 위해서는 TCP 커넥션을 맺어야 한다. TCP 커넥션을 맺기 위해서는 TCP 3 way handshaking은 필수다. 그러나 매번 콘텐츠를 전송 받기 위해 이 과정이 발생한다면 이는 곧 응답시간 지연으로 직결된다. CDN을 사용하면 이러한 문제가 해결된다. Connection Pooling에 의해 CDN 엣지 서버와 CDN 오리진 서버 사이에 일정 량의 TCP 커넥션을 항상 유지하기 때문에 사용자와 웹서버간 커넥션 연결에 필요한 시간을 줄여준다.
TCP 연결을 일정 시간 동안 지속 시키는 HTTP Keep Alive는 보통의 경우 웹 서버에서 설정을 해제시켜 둔다. 왜냐하면, TCP 연결을 계속 지속 시키면 접속 사용자가 적을 때는 성능이 향상되지만, 사용자가 많을 경우 엄청나게 많은 TCP 연결로 인해 웹 서버 부하가 기하급수적으로 증가하기 때문이다. CDN 사업자는 CDN 엣지 서버와 CDN 오리진 서버 간 HTTP Keep Alive 기술을 적용하기 때문에 TCP 연결을 매번 끊지 않고 사용함으로써 매번 연결할 필요가 없으므로 더욱 응답시간이 줄어들게 된다.
(그림8. Connection Pooling and HTTP Keep Alive 기술이 적용된 예)
그림8은 전체 145개 오브젝트가 있는 페이지에서 단순 웹 서버로만 서비스하는 경우와 Connection Pooling and HTTP Keep Alive가 적용된 CDN 환경 하에서의 전체 RT(Round Trip) 횟수 차이를 보여주고 있다. 거의 1/3 수준으로 패킷이 왕복하는 RT 횟수가 줄어들기 때문에 응답속도가 그만큼 개선된다.
7. Dynamic Routing
RTT(Round Trip Time)은 인터넷 상에서 클라이언트에서 서버까지 패킷이 왕복하는데 걸리는 시간을 의미한다. 보통 사용자에서 웹서버까지 패킷의 왕복 시간을 의미한다. 이 RTT는 웹 페이지 응답시간을 측정하고 개선하기 위한 기본이 되는 단위이다. RTT를 개선하기 위해서는 TCP/IP 프로토콜을 개선해야 한다. OSI 7 레이어에서 네트워크 레이어는 종단과 종단간의 라우팅을 담당하는 레이어이다. 따라서 그림 7을 기준으로 살펴보면, 사용자에서 CDN엣지 서버, CDN 엣지 서버에서 CDN 오리진 서버, CDN 오리진 서버에서 고객 웹 서버까지의 최적의 라우팅이 필요하고 이는 인터넷 프토콜(IP) 상에서 기능 향상이 이루어져야 하는 부분이다. 항상 문제는 CDN 엣지 서버와 CDN 오리진 서버 사이, 글로벌 Middle Mile 구간에서의 최적 라우팅이다.
(그림 9. Dynamic Routing 필요 배경)
(그림 10. Dynamic Routing 개념)
평상 시에 CDN 엣지 서버와 CDN 오리진 서버 사이에서 임의의 패킷을 주고 받으며 RTT를 체크한다. 미리 셋팅한 여러 경로에서 테스트를 하게 되는 데 각 경로의 RTT값을 저장하고 분석해서 어느 경로가 가장 낮은 RTT인지를 분별한다. 즉, 최단 거리의 라우팅이라 하더라도 인터넷 혼잡 구간을 통과하면서 최저 RTT를 보장하지 않을 수 있으므로, 우회하는 경로가 최저 RTT를 보장한다면 그 경로로 커넥션을 맺도록 라우팅을 하는 것이 응답속도 향상에 도움을 줄 수 있다. 흡사 서울에서 부산까지 가장 가깝게 가려면 경부 고속도로를 이용해야 하지만, 막히는 경우 중부내륙 고속도로로 우회하는
것이 빠르게 가는 방법인 것처럼.
8. TCP Optimization
위에서도 설명했지만 글로벌 Middle Mile 구간은 예상치 못한 혼잡(Congestion) 구간이 발생하기 마련이다. 네트워크 관련 연구소나 장비 업체, 서비스 기업들은 오랜 시간 동안 이러한 혼잡 구간을 통과할 때의 응답속도를 개선하기 위한 TCP Congestion Control에 대해 연구해 왔다. 저마다의 결론들이 조금씩 다르나 TCP Congestion Control을 위한 기본 알고리즘은 같은데 Slow Start, Congestion Avoidance, Fast Retransmit and Reordering Control, Fast Recovery로 구성되어 있다. 여기서는 Fast Recovery를 제외한 나머지 2가지 방식에 대해 알아본다.
(그림 11. TCP Optimization 배경 및 원리)
TCP는 전송 성능(Throughput) 보다 신뢰성 있는 전송(Reliability)를 보다 중요하게 설계되어 있는 프로토콜이다. 즉, 양 시스템 간의 오류 복구, 흐름 제어 등 신뢰성 있는 데이터 전송을 보장하도록 설계되어 있다. 그럼에도 전송 성능을 높이는 것이 필요한데, 쉽게 설명하면 그림 10과 같다. KTX로 서울에서 부산까지 왕복한다고 하면, 차량 객실을 1량으로 왕복하는 것과 차량 객실을 15량으로 왕복하는 것은 왕복 시간은 같지만, 전송하는 수송인원은 15배가 된다. 하지만 그렇다고 KTX 모든 노선과 기차에 대해 차량 객실을 많이 늘리는 것은 결국 각 역마다 승하차 혼잡 현상이 발생할 것이고 복잡한 역에서 일부 승객들이 승차를 못하는 현상이 벌어질 것이다. 다시 말하면, 특정 차량 객실 수를 넘어서면 승하차 혼잡과 승객 미탑승으로 인해 오히려 수송 성능은 낮아지는 것이다. 인터넷도 마찬가지이다. 전송 세그먼트가 많을수록 전송 데이터량은 증가하기 때문에 전송 성능(Throughput)은 증가하는데, 이에 반해 특정 세그먼트 수를 넘어서면 IX 구간 장비의 혼잡 현상이 발생하고 잦은 패킷 유실 (Packet loss) 현상이 발생하여 재전송(Retransmit)이 필요하기 때문에 오히려 전송 성능이 낮아진다. 즉, 혼잡 현상이 발생하지 않는 최대 전송 세그먼트 수를 찾는 것과 패킷 유실 시 빠르게 다시 보내는 것이 중요하다.
Slow Start 알고리즘 원리는 다음과 같다. 송신 단말과 수신 단말이 직접 연결되어 있다면 송신
단말은 수신 단말이 수신할 수 있는 세그먼트, 즉 윈도우 크기만큼 송신하면 된다. 그러나 현실에서 패킷은 수많은 네트워크 홉(장비)를 통과하게 되고 다른 송수신 단말 간의 패킷과 뒤엉키게 마련이다. 따라서 패킷을 저장하는 중간 라우터나 스위치의 저장 버퍼 공간 부족으로 혼잡(congestion)이 발생하는 데 Slow Start는 이러한 문제를 해결하기 위해, cwnd(congestion window, 혼잡 윈도우) 라는 TCP 커널값을 ‘지속적으로’ 증가시키는 방식이다. 즉, cwnd를 1로 초기화하여 최대 세그먼트 한 개를 보낸 후 RTO(Retransmission Time Out, 재전송 시간 초과) 가 발생하기 전에 확인 메시지(TCP 패킷 헤더의 ack 메시지)가 오면 cwnd가 2가 되고 2개의 세그먼트를 보낸다. 이것도 마찬가지이면 다음은 cwnd가 4가 되어 (2n 으로 증가) 보내게 된다. 이런 식으로 한번에 보내는 세그먼트의 크기는 리눅스의 경우 rcv_ssthresh 값까지 증가시킬 수 있다. 그러나 이러한 Slow Start 알고리즘이 무조건 좋은 것은 아니다. 예를 들면 글로벌 CDN에 있어서 CDN 엣지 서버와 CDN 오리진 서버 사이의 Middle Mile 구간에서는 disable시키는 것이 좋을 때도 있다. 이런 이유로 해서 Slow Start를 disable 시킬 수 있도록 fast_start_after_idle을 1로 셋팅하게 될 때도 있다.
Congestion Avoidance 알고리즘 원리는 다음과 같다. 사실 Congestion Avoidance는 Slow Start와 별개의 알고리즘 같지만 같이 실행된다. Slow Start로 cwnd를 증가시키다가 혼잡(congestion)이 발생하면 수신 단말의 윈도우 크기의 반으로 rcv_ssthresh 값을 갱신한다. 만약 원인이 RTO가 발생했기 때문이라면 cwnd의 값은 1이 되어 다시 Slow Start가 시작된다. 이러한 과정은 다음과 같다.
(그림 12. Combined Avoidance와 Slow Start의 병행 수행 과정, W.Stevens, “ TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms”, RFC2001, Jan. 1997 인용)
(그림 13. 동적 콘텐츠 (캐시 불가능한 콘텐츠) 가속을 위한 CDN 구성)
상기의 TCP Optimization을 위한 다양한 알고리즘은 이렇게 널리 알려져 있지만 실제 가속 플랫폼에 적용되어 글로벌 인터넷을 가속시키려면 상당한 노하우가 필요하다. 씨디네트웍스 등 몇 안 되는 CDN 사업자들은 오랜 시간 동안 글로벌 인터넷 구간을 보다 가속하기 위해 다양한 TCP Optimization 기술들을 내재화하고 튜닝하여 가속 플랫폼에 탑재, 동적 콘텐츠를 가속해 오고 있다. 그럼으로써 그림 13와 같이 고객의 웹 서버에서 직접 서비스하는 경우 보다, 정적 콘텐츠만 글로벌 각 지에 캐시하여 서비스하는 경우가 더욱 빠르고 균일한 서비스를 할 수 있고, 더욱이 동적 콘텐츠까지 가속하여 글로벌 Middle Mile 구간까지 가속할 수 있다면 가장 빠르게 가속할 수 있는 것이다.