Download pptx - CDN technology overview

Transcript
Page 1: CDN technology overview

CDN Technology overview2016.03 | Product Management team | 김유현 차장

Page 2: CDN technology overview

목 차1. Internet Technology Basics2. CDN Overview3. Caching technology4. Acceleration technology

Page 3: CDN technology overview

1. Internet Technology Basics

Page 4: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 4 -

Internet Basics

• 인터넷은 컴퓨터 ( 혹은 스마트기기 ) 로 연결하여 TCP/IP (Transmission Control Protocol/In-ternet Protocol) 라는 통신 프로토콜을 이용해 사용해 전 세계 수십억 명의 사용자들에게 제공되는 지구 전체의 컴퓨터 네트워크 시스템을 의미함 .

• 대중적인 월드 와이드 웹 (WWW) 은 HTTP (Hyper Text Transfer Protocol) 와 함께 사용되고 , HTTP 로 되어 있는 웹 페이지를 보기 위한 웹 브라우저로는 Microsoft 의 Internet Explorer, Mozilla의 Firefox, Google 의 Chrome 등을 이용함 .

• 하이퍼텍스트 (Hypertext) 는 참조 ( 하이퍼링크) 를 통해 독자가 한 문서에서 다른 문서로 즉시 접근할 수 있도록 한 텍스트를 의미함 .

• 인터넷은 개인 , 학교 , 기업 , 정부 네트워크 등을 한정적 지역에서 전체 영역으로 유선 , 무선 , 광케이블 기술 등을 통해 연결하여 구성한 네트워크들의 네트워크임 .

• 인터넷 구축에 사용된 하드웨어와 프로토콜은 전화 , 음악 스트리밍 , 영화 스트리밍 , 게임 , 홈 서버 등의 서비스를 그대로 구현함 .

• 신문이나 도서 등의 출판물들도 웹사이트 기술에 맞춰 새롭게 구현되었는데 , 블로그나 RSS 등과 같은 형태로 독자들에게 서비스 중임 .

• 인터넷에 의해 사람들의 소통방식도 인스턴스 메시지 (IM), 인터넷 포럼 , SNS 등으로 진화하고 있음 .출처 | 위키피디아 , 인터넷

Page 5: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 5 -

Web Browsing

Internet

Hey, 213.236.208.98, show me your

home page.

HTTP 200 – OKHere you go:

<HTML>...

• 접속하고자 하는 웹 페이지의 Domain name 을 브라우저 상에 입력하여 접속하나 , 실제로는 해당 웹 페이지의 IP 주소로 접속함 .

• IP 주소는 일종의 전화번호 개념이고 , 흔히 Contact name 과 전화번호를 mapping 한 전화번호부를 사용하듯이 , 웹 페이지의 Domain name ( 예 . www.google.com) 과 IP 주소를 mapping 한 DNS (Domain Name System) 를 사용하여 웹 페이지에 접속함 .

• TCP 는 인터넷에 연결된 컴퓨터에서 실행되는 프로그램 간에 정보를 안정적으로 , 순서대로 , 에러 없이 교환할 수 있게 하며 , 웹 브라우저가 월드 와이드 웹에서 서버에 연결할 때 혹은 이메일 전송이나 파일 전송에도 사용함 .

Page 6: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 6 -

DNS Basic Operation

• 인터넷에서 통신을 하기 위해서 모든 단말은 DNS 서버의 IP 주소가 설정되어 있어야 함 . 사람이 이해하기 쉬운 Domain name 을 IP 주소로 변환해 주는 것이 DNS 임 .

• DNS 동작 원리 ( 다음 Page 그림 참조 )1. 브라우저에서 www.test.com을 입력하면 , PC 는 미리 설정되어 있는 DNS ( 이 DNS 를 Local

DNS 라고 부름 ) 에게 www.test.com이라는 hostname” 에 대한 IP 주소를 물어봄 . Local DNS에는 www.test.com에 대한 IP 주소"가 있을 수도 없을 수도 있으며 , Local DNS 가 이미 가지고 있는 경우 ( 캐시 되어 있는 경우 ) 바로 IP 주소를 주고 동작을 끝내게 됨 .

2. 하지만 Local DNS 가 해당 IP 주소를 가지고 있지 않은 경우 Local DNS 는 “ www.test.com에 대한 IP 주소“를 찾아내기 위해 다른 DNS 서버들과 통신을 시작함 . 먼저 Root DNS 서버에게 “www.test.com에 대한 IP 주소"를 가지고 있는 지 물어봄 . 이를 위해 각 Local DNS 서버에는 Root DNS 서버의 정보 (IP 주소 ) 가 미리 설정되어 있어야 함 . (Root DNS 서버는 전 세계에 13대가 구축되어 있으며 우리 나라의 경우 Root DNS Mirror 서버를 3 대 운용하고 있음 .)

3. Root DNS 서버는 “ www.test.com의 IP 주소”에 대한 정보가 없어 Local DNS 에게 “ .com 도메인을 관리하는 DNS 서버”에게 물어보라는 응답을 하게 됨 .

4. Local DNS 는 .com DNS 서버에게 “ www.test.com에 대한 IP 주소“를 문의하고 , 5. 역시 “ .com DNS 서버”에도 해당 정보가 없어 , “.com DNS 서버”는 “ test.com 을 관리하는

DNS 서버”에게 물어보라는 응답을 하게 됨 .6. Local DNS 는 “ test.com DNS 서버”에게 “ www.test.com에 대한 IP 주소“를 문의하고 , 7. “test.com DNS 서버”에는 “ www.test.com hostname 에 대한 IP 주소가 있어 ,

173.194.33.17 을 응답함 .8. 이를 수신한 LDNS 는 “ www.test.com에 대한 IP 주소를 캐시하고 해당 IP 주소를 브라우저에

전달함 .출처 | 넷매니아즈 블로그 , DNS 기본 동작 설명

Page 7: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 7 -

DNS Basic Operation

• 이와 같이 Local DNS 서버가 여러 DNS 서버를 차례대로 (Root DNS 서버 - .com DNS 서버 – test.com DNS 서버 ) 질의하여 답을 찾는 과정을 “ Recursive Query” 라고 부름

• Terminology1. URL: http://www.test.com/index.html 2. Hostname: www.test.com 3. Top level domain name: .com4. Second level domain name: test.com

출처 | 넷매니아즈 블로그 , DNS 기본 동작 설명

Page 8: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 8 -

Cache

• 캐시란 (Cache) “ 앞서 사용된 데이터를 저장하고 있다가 재 요청이 있을 경우 원래의 장치에 요청하지 않고 , 좀 더 빠르게 응답해 주는 것”을 의미함 .

• 캐시 메모리 (Cache memory): 컴퓨터 시스템의 성능을 향상시키기 위해 주로 CPU 칩 안에 포함된 빠르고 작고 비싼 메모리를 말함 .

• ARP (Address Resolution Protocol) 캐시 : TCP/IP 에서 실제 데이터들은 Destination IP 주소가 아닌 Destination MAC (Media Access Control) 주소에 ( 하드웨어 물리적 주소 ) 의해서 매체간 이동이 이루어지며 Destination MAC 주소를 찾기 위해 ARP 를 사용 . 대부분의 네트워크장비 (PC, 서버 , 스위치 , 라우터 등 ) 들은 이 정보를 재사용하기 위해 IP 주소와 MAC 주소를 메모리에 일정시간 기억하게 되고 이것을 ARP 캐시라 함 .

• DNS 캐시 : 도메인 이름을 IP 로 응답해 주는 DNS 역시 캐시를 가지고 있으며 , 네트워크 장비들이 ARP 캐시를 사용하는 이유는 IP 가 자주 바뀌지 않기 때문이고 , DNS 도 도메인 이름에 할당된 IP 가 바뀔 가능성이 적기 때문임 . DNS 요청에 대한 DNS 서버 부하를 줄이기 위해 얻어진 결과 값에 대해 일정기간 캐시를 하고 클라이언트의 요청이 있을 경우 캐시의 정보로 응답함 .

• 웹 브라우저 캐시 : 브라우저는 속도를 높이기 위해 사용자가 한 번 본 페이지를 저장하고 있다가 같은 페이지를 재 요청하면 캐시 데이터를 확인하여 응답하는 방식을 사용하는데 이를 웹 브라우저 캐시라고 함 .

출처 | NRC 와 함께하는 LIVE 네트워크 , 한빛미디어 , 2002

Page 9: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 9 -

Web Cache

• 웹 캐시란 (Web Cache) 하나의 사용자를 위한 브라우저 캐시와는 달리 대다수 사용자를 대상으로 함 . 사용자가 많은 만큼 같은 사이트를 방문할 가능성이 높으므로 재 사용될 가능성도 브라우저 캐시에 비해서 상당히 높음 . 일반적으로 사용자가 많으면 많을수록 웹 캐시는 더 많은 효과를 볼 수 있게 됨 . 가장 큰 특징은 특정 웹 페이지를 요청할 경우 두 번째 클라이언트부터는 멀리 있는 서버 (Origin server)까지 가지 않고 직접 응답한다는 것임 .

• 웹 캐시는 인터넷의 통로인 게이트웨이에 존재하기도 하지만 대규모 웹 사이트를 운영하는 곳은 아래 그림과 같이 웹 서버 앞에 위치하여 웹 서버보다 먼저 클라이언트에게 응답을 해 주어 서버의 부하를 줄여주는 가속기 (Accelerator) 형태로 많이 사용됨 .

출처 | NRC 와 함께하는 LIVE 네트워크 , 한빛미디어 , 2002

인터넷

웹 클라이언트

웹 클라이언트

웹 클라이언트

게이트웨이 가속기

웹 서버

서버를 위한 캐시

클라이언트를 위한 캐시

Page 10: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 10 -

Forward Cache System

• 포워드 캐시 (Forward Cache): 일반적인 사용자들이 생각하는 보편적인 형태로서 사용자의 인터넷 앞에 위치하여 속도를 높여줌 . 포워드 캐시의 가장 큰 목적은 인터넷 구간의 “회선비용절감”임 . 캐시를 사용하면 속도가 빨라지는데 , 이는 클라이언트가 요청한 콘텐츠를 회선 대역폭이 작은 인터넷 바깥 영역을 통하지 않고 속도가 빠른 로컬에서 응답을 하기 때문임 .

• 포워드 캐시 시스템은 라우터 바로 아래 설치가 되어 많은 사용자가 캐시를 통과하도록 구성함 . 포워드 캐시는 네트워크 내의 많은 사용자는 물론 인터넷 밖의 수많은 서버들과 통신을 함 . (1 대의 캐시 (edge server) – 여러 대 ( 고객 ) 의 웹 서버와 (Origin Server) 통신 )

출처 | NRC 와 함께하는 LIVE 네트워크 , 한빛미디어 , 2002

인터넷

웹 클라이언트

웹 클라이언트

웹 클라이언트

웹 캐시

www.cdnetworks.com

www.daum.net

www.naver.com

.

.

.

Page 11: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 11 -

Reverse Cache System

• 리버스 캐시 (Reverse Cache): 포워드 캐시와는 달리 사용자의 인터넷 앞이 아니라 인터넷을 지나서 웹 서버의 앞에 설치가 된 형태를 말함 . 이 경우 캐시는 회선절감과는 무관하게 서버 대신 일을 함으로써 서버의 부하를 줄여주는 역할을 함 .

• 리버스 캐시가 웹 서버의 IP 를 가지고 있으므로 외부에서는 무조건 캐시로 요청할 수 밖에 없음 . (외부에서는 고객의 Origin 서버 IP 를 알 수 없음 .) 만약 캐시가 클라이언트의 요청 콘텐츠를 가지고 있지 않다면 캐시는 설정된 서버와 통신을 하고 jsp와 같은 동적 콘텐츠는 항상 캐시가 아닌 웹 서버 (Origin 서버 ) 에서 처리됨 .

• 리버스 캐시는 다른 용어로 웹 서버의 성능을 높여주는 웹 가속기 (Web Accelerator) 라고도 함 .

출처 | NRC 와 함께하는 LIVE 네트워크 , 한빛미디어 , 2002

인터넷

웹 클라이언트

웹 클라이언트

웹 클라이언트

웹 캐시

웹 서버

Reverse cache = 192.168.10.1

W1=192.168.10.2

W1=192.168.10.3

W1=192.168.10.4

Page 12: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 12 -

Transparent Cache System

• 트랜스페어런트 캐시 (Transparent Cache): Transparent (투명한 ) 이란 말 그대로 사용자 입장에서는 캐시가 있는지 없는지 모르는 상태로 캐시 서버를 위치시키는 형태를 말함 . 트랜스페어런트 캐시는 포워드나 리버스 형태 모두 사용될 수 있지만 일반적으로 별도의 장비 (로드밸런서나 라우터 ) 의 도움을 받아서 구성함 .

• 트랜스페어런트 구성의 가장 큰 장점은 캐시에 장애가 발생하더라도 로드밸런서와 같은 장비에서 이를 감지하여 실제 웹 서버로 트래픽을 보내므로 캐시의 장애로 인한 전체 웹 사이트가 다운되는 문제가 발생하지 않음 . 또한 인터넷 구간의 회선 비용을 절감할 수 있음 .

출처 | NRC 와 함께하는 LIVE 네트워크 , 한빛미디어 , 2002

인터넷

웹 클라이언트

웹 클라이언트

웹 클라이언트

웹 캐시 웹 캐시

웹 서버

라우터 /스위치

라우터 / 스위치웹 트래픽

Page 13: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 13 -

Proxy, Cache Miss / Cache Hit

• 프록시 (Proxy): 보통 캐시를 프록시라고 부르는데 명확히 하면 캐시는 프록시 서버의 일종임 . 프록시란 클라이언트의 요청에 대해 클라이언트를 대신해서 서버로 요청을 하고 그 결과를 다시 클라이언트에게 되돌려주는 아주 간단한 일을 하는 것을 가리킴 .

• Cache Miss / Cache Hit: 클라이언트가 캐시에게 “ http://www.cdnetworks.com/Media Accel-eration.jpg” 이라는 그림을 요청했다고 가정하면 , 캐시는 이 요청에 대한 응답을 했는지를 먼저 확인하고 , 1) 이전에 응답한 적이 없었다면 이것은 “ Cache Miss” 가 되며 , 캐시는 www.cdnetworks.com 서버에 Media Acceleration.jpg 를 요청하게 됨 .

• 만약 2) 이전에 응답한 적이 있다면 이것은 “ Cache Hit” 가 되고 , 클라이언트가 요청한 콘텐츠가 캐시 서버에 존재하여 직접 클라이언트에 응답을 주게 됨 . 캐시를 운영하는 입장에서는 Hits 가 많을수록 좋음 . Hit Ratio 는 캐시의 효과를 나타내는 척도로 사용됨 .

출처 | NRC 와 함께하는 LIVE 네트워크 , 한빛미디어 , 2002

인터넷웹 클라이언트

웹 클라이언트

웹 캐시

www.cdnetworks.com

www.daum.net

www.naver.com

Cache HitCache Miss

Page 14: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 14 -

Freshness / Validation check

• Freshness check: Freshness 란 클라이언트가 요청한 콘텐츠를 캐시에서 직접 주어도 되는지 판단하는 것을 말함 . 캐시는 응답했던 콘텐츠가 가지고 있는 유효기간 (Expiration time) 을 제일 먼저 확인하며 이 정보는 HTTP 응답 헤더의 max-age 나 Expires 를 참조하면 됨 . 예를 들어 max age=86,400 (24 시간 ) 이지만 캐시가 응답한지 아직 24 시간이 지나지 않았으면 이 콘텐츠는 Fresh하다고 판단할 수 있음 . (Cache Hit)

• 유효성 (Validation) check: Hit 된 콘텐츠가 캐시에서 Fresh 하지 않은 콘텐츠로 판단되면 웹 서버로 콘텐츠 재사용 여부를 묻게 됨 . 웹 서버는 자신이 가지고 있는 콘텐츠와 비교하여 1) 아직 사용 가능할 경우 “ 304 Not Modified” 메시지만을 보내 재사용하게 하고 , 2) 사용 불가능할 경우 새 콘텐츠를 내려 보내게 됨 .

출처 | NRC 와 함께하는 LIVE 네트워크 , 한빛미디어 , 2002

인터넷

웹 클라이언트

웹 클라이언트

웹 캐시

www.cdnetworks.com

www.daum.net

www.naver.com

5. Update4. Response

3. Validation check

2. Freshness check

1. Cache Hit

Page 15: CDN technology overview

2. CDN Overview

Page 16: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 16 -

Content Delivery Network

• 콘텐츠 전송 네트워크 (CDN – Content Delivery Network): 콘텐츠를 효율적으로 전달하기 위해 여러 노드 ( 웹 캐시 ) 를 가진 네트워크에 데이터를 저장하여 제공하는 시스템 . 인터넷 서비스 제공자 (ISP – Internet Service Provider) 에 직접 연결되어 데이터를 전송하므로 , 콘텐츠 병목을 피할 수 있는 장점이 있음 .

• CDN 의 목적은 높은 사용성과 효율로 사용자에게 콘텐츠를 전달함에 있음 . CDN 은 오늘날 인터넷에 존재하는 콘텐츠의 상당수를 서비스하고 있는데 , 여기에는 웹 요소 ( 텍스트 , 그래픽 , 스크립트 ), 다운로드 가능한 요소 ( 미디어 파일 , 소프트웨어 , 문서 ), 애플리케이션 ( 전자상거래 , 포털 ), 실시간 미디어 , 주문형 스트리밍 등이 포함됨 .

• 미디어 회사나 전자상거래 업체와 같은 콘텐츠 제공자는 (CP – Content Provider) 그들의 콘텐츠를 사용자들에게 전달하기 위해서 CDN 사업자에 사용료를 지불하고 , 반대로 , CDN 사업자는 ISP 그리고 네트워크 사업자들에게 데이터 센터에서의 서버 호스팅 비용을 지불함 . 더 나은 퍼포먼스와 (Performance) 사용성 (Service Availability) 이외에도 CDN 은 콘텐츠 제공자의 서버의 (Origin server) 트래픽을 덜어주어 콘텐츠 제공자의 비용을 줄여줌 .

• CDN 은 대규모 분산 서버 장비로 공격 트래픽을 완화할 수 있으므로 콘텐츠 제공자에게 DoS 공격에 대해서도 어느 정도 보호해 줄 수 있음 . 초기 대부분의 CDN 사업자는 각 Vendor 가 소유하고 동작하는 서버를 사용하는 콘텐츠만 서비스하였으나 최신 트렌드는 P2P 기술을 이용하는 하이브리드 모델을 사용하는 것임 . 하이브리드 모델에서 콘텐츠는 지정된 서버 그리고 주변 컴퓨터 (peer-user-owned) 를 모두 사용함 .

출처 | 위키피디아 , 콘텐츠 전송 네트워크

Page 17: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 17 -

First mile, Middle mile and Last mile

• 퍼스트 마일 – 데이터센터로부터 (IDC – Internet Data Center) 인터넷서비스제공자 (ISP)까지 콘텐츠가 전송되는 구간

• 미들 마일 – 퍼스트 마일에서 라스트 마일 사이에 있는 구간으로 콘텐츠 제공 사업자와 사용자 사이에 있는 ISP 들간에 연결된 구간

• 라스트 마일 – 지역 ISP 로부터 일반 사용자에게 콘텐츠가 전달되는 구간

OriginWeb server

(IDC)

ISP

Local ISP

Internet Middle Mile

End user

Last Mile Middle Mile First Mile

End user

End userEnd user

Page 18: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 18 -

Middle mile problem

“Origin Server” Cus-tomer web site

“End User”Last Mile Middle Mile First Mile

• Same ISP/Location• Low latency• Low Bandwidth

• Same Data Center/ISP• Low latency• Low Bandwidth

Bad RoutingNetwork Failure

Long distance

Page 19: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 19 -

Middle Mile problem without CDN

• CDN 이 없는 기존 모델에서는1. 콘텐츠 제공자 (CP) 입장 : 서버 이중화를 고려하지 않은 환경에서 콘텐츠 웹 서버와 연결된

네트워크에 장애가 발생하면 , 극단적인 경우 콘텐츠를 사용자에게 제공할 수 없는 상황에 직면할 수 있음 . 또한 일시적으로 수많은 사용자들이 동시에 콘텐츠 웹 서버에 접속을 시도하게 되면 콘텐츠 서버와 연결된 네트워크 구간에서 병목 현상이 발생하여 사용자에게 원활한 서비스 제공이 어려워짐 . 결국 대용량의 콘텐츠를 원활하게 제공하기 위해서는 콘텐츠 증가에 비례하여 고사양의 콘텐츠 서버 및 서버의 네트워크 회선 용량 증설이 필요하며 이로 인한 비용 발생이 늘어나게 됨 .

2. 인터넷 서비스 제공자 (ISP) 입장 : ISP 의 가입자가 외국에 위치한 서버의 콘텐츠 서비스를 이용하는 경우 , 연결 과정에서 트래픽은 수 많은 ISP 혹은 IXP (Internet eXchange Provider) 를 거치는데 , 이 경우 해당 ISP 는 다른 ISP 혹은 IXP 에 트래픽 양에 비례하여 회선 비용을 지불해야 함 . 따라서 대용량 멀티미디어 트래픽이 빈번하게 전송되는 경우 해당 ISP 가 지불해야 하는 회선 비용은 지속적으로 증가할 수 밖에 없음 .

3. 콘텐츠 사용자 (End user) 입장 : 물리적으로 멀리 떨어진 콘텐츠 웹 서버에 접속하여 콘텐츠를 받아오는 경우 , 사용자는 회선 거리에 따라 End-to-End delay 값 (RTT – Round Trip Time) 의 증가로 인해 보다 빠른 시간 안에 원하는 콘텐츠를 제공 받기 어렵게 됨 . 예를 들어 , 미국에 있는 YouTube 서버에 저장된 콘텐츠를 한국에서 제공받고자 할 때 , 서버에서 클라이언트까지 라우팅 홉 수가 상당히 많기 때문에 느린 속도로 콘텐츠를 제공받을 수 밖에 없음 .

• 이러한 문제들을 해결하기 위해서는 네트워크 용량 증설 , 서버 용량 증설 , 서버 이중화 등과 같이 끊임 없는 네트워크 및 시스템 확장이라는 요구사항이 동반됨 .

출처 | 넷매니아즈 블로그 , CDN 이라는 참 좋은 기술

Page 20: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 20 -

Solution for Middle mile problem (CDN)

• CDN 서비스는 기존 네트워크 인프라를 교체하거나 대대적인 확장 없이 다양한 콘텐츠를 유연하고 효율적으로 전송하기 위한 서비스임 .1. 콘텐츠 제공자 (CP) 입장 : 콘텐츠 서버와 연결된 네트워크에 장애가 발생하더라도 , 콘텐츠는

다른 여러 지역에 위치한 캐시 서버에 저장되어 있으므로 콘텐츠 제공자는 정상적으로 사용자에게 콘텐츠를 제공할 수 있으며 ( 지역적 이중화 (Geographical Redundancy) 보장 ), 또한 다수의 사용자가 하나의 콘텐츠를 동시에 요청하더라도 그 모든 요청들이 하나의 콘텐츠 서버로 집중되지 않고 각 사용자의 접속 위치에 따라 여러 곳에 배치되어 있는 캐시 서버로 분산되기 때문에 , 콘텐츠 제공자는 접속 폭주에 따른 서비스 불가 문제 해결 및 성능 향상 등과 같은 효과를 기대할 수 있음 .

2. 인터넷 서비스 제공자 (ISP) 입장 : 여러 지역에 분산된 CDN 사업자의 캐시 서버에 콘텐츠를 미리 가져다 놓음으로써 외부 ISP 혹은 IXP 를 통해 전송되는 구간 즉 , 미들 마일 (Middle-Mile)을 지나는 트래픽의 양이 현저히 감소하게 되고 , 이에 따라 ISP 는 기존 클라이언트 - 서버 환경에서 콘텐츠 전송을 위해 소요되던 막대한 회선 비용을 줄일 수 있음 . 이러한 이유로 ISP 가 자사의 데이터센터에 CDN 사업자의 캐시 서버를 “무상”으로 호스팅 해 주는 경우도 있음 . ( 예 . LGU+ 의 YouTube 무상 호스팅 )

3. 콘텐츠 사용자 (End user) 입장 : 사용자의 콘텐츠 요청을 해당 웹 서버가 아닌 , 사용자에게 근접한 위치의 캐시 서버가 처리함으로써 End-to-End delay 가 현저히 줄어들게 됨에 따라 , 사용자는 기존 네트워크 환경에서의 응답속도에 비해 훨씬 빠른 시간 안에 원하는 콘텐츠를 제공받을 수 있는 효과를 볼 수 있음 . 또한 기존 클라이언트 - 서버 환경에 비해 콘텐츠를 제공하는 서버에서 클라이언트까지 라우팅 홉 수가 상대적으로 적기 때문에 네트워크에서 Congestion 이 발생할 확률 또한 낮아지는 효과를 기대할 수 있음 .

출처 | 넷매니아즈 블로그 , CDN 이라는 참 좋은 기술

Page 21: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 21 -

Without CDN vs With CDN

웹 클라이언트

웹 클라이언트

웹 클라이언트

웹 클라이언트 웹 클라이언트

웹 클라이언트

웹 서버(Origin server)

웹 클라이언트

웹 클라이언트

웹 클라이언트

웹 클라이언트 웹 클라이언트

웹 클라이언트

웹 서버(Origin server)

One Central web server Many Cache servers

캐시

캐시

캐시

캐시

캐시

Page 22: CDN technology overview

3. Caching technology

Page 23: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 23 -

Static and Dynamic Caching

• 다시 한 번 이야기하면 , CDN 서비스는 사용자와 지리적으로 멀리 떨어져 있는 Origin Server (고객의 웹 서버 ) 로부터 콘텐츠 ( 예 . Web object, 음악 , 이미지 , 문서 등 ) 을 다운로드 받으면 시간이 오래 걸리므로 사용자와 가까운 곳에 위치한 캐시 서버에 해당 콘텐츠를 저장 (Caching) 하고 콘텐츠 요청 시에 캐시 서버가 응답을 주는 기술임 . 따라서 사용자는 가까운 곳에 있는 캐시 서버로부터 콘텐츠를 수신하므로 빠르게 다운로드 할 수 있게 됨 .

• Static Caching1. 사용자의 요청이 없어도 Origin Server 에 있는 콘텐츠를 운영자가 미리 캐시 서버에 복사함 .2. 사용자가 캐시 서버에 접속하여 콘텐츠를 요청하면 무조건 그 콘텐츠는 캐시 서버에 있음 . (100%

Cache hit)

• Dynamic Caching1. 최초 캐시 서버에는 콘텐츠가 없음 . (Cache Miss)2. 사용자가 콘텐츠를 요청하면 해당 콘텐츠가 있는지 확인하고 , 없으면 Origin Server 로부터

다운로드 받아 사용자에게 전달해 줌 .3. 이후 동일 콘텐츠를 요청 받으면 저장 (Caching) 된 콘텐츠를 사용자에게 전달함 . (Cache Hit)4. 각 콘텐츠는 일정 시간 (TTL - Time To Live) 이 지나면 캐시 서버에서 삭제될 수 있고 , 혹은 Ori-

gin Server 를 통해 콘텐츠 Freshness 확인 후에 계속 가지고 있을 수 있음 .

출처 | 넷매니아즈 블로그 , CDN 과 ADN

Page 24: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 24 -

Request Routing

• Request Routing 은 사용자의 콘텐츠 Request 에 ( 예 . 게임파일 다운로드 ) 대해 최적의 캐시 서버를 선택해 주는 기능으로 이를 위해 CDN 네트워크에는 Request Router 가 존재함 . Request Router 는 DNS 기능을 지원하며 사용자의 콘텐츠 요청을 글로벌 네트워크 상의 적절한 캐시 서버로 Redirection 해 줌 .

1. 사용자가 요청한 origin.exam-ple.com 에 대해 example.com DNS 서버는 CNAME 으로 csp123.cdn.kt.com 을 돌려주고 (5 번 , 6 번 )

2. Local DNS 서버는 Request Router 로 DNS Query 를 전달하여 Host Name = csp123.cdn.kt.com 에 대한 IP 주소를 요청 (7 번 )

3. Request Router 는 1) Local DNS 서버의 IP 주소와 2) 캐시 서버의 부하 등을 고려하여 , 글로벌 네트워크 상의 적절한 캐시 서버 IP 주소를 return (8 번 , 9번 )

4. 사용자는 이 캐시 서버로 콘텐츠 Request 를 보내 콘텐츠 다운로드/ 스트리밍 (11 번 , 12 번 )

출처 | 넷매니아즈 블로그 , CDN 의 Request Routing 기술

Page 25: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 25 -

Global Server Load Balancing

• GSLB (Global Server Load Balancing) 서비스1. GSLB 서비스는 동일한 기능을 수행할 수 있는 여러 대의 클라우드 서버 ( 예 . 캐시 서버 ) 중 최적

상태의 서버와 연결함으로써 고객 시스템의 안정성을 향상시키며 , 부하를 분산시켜 일부 서버에 트래픽이 집중되는 것을 막기 때문에 서버의 가용성 (Availability) 을 높일 수 있음 . GSLB 서비스는 서버의 상태 확인 후 정상적인 서버에만 연결하므로 보다 신속한 트래픽 처리 및 장애 대응이 가능함 .

2. GSLB 는 SLB (Server Load Balancing) 에서 발전된 개념으로 , SLB 가 한 사이트 내에서 L4 스위칭 기능을 통해 서버의 상태 체크 및 부하 분산 기능을 제공하였다면 , GSLB 는 이 개념을 지리적으로 확장시켜 복수개의 사이트에 대해 동일한 기능을 수행하도록 함 .

출처 | 넷매니아즈 블로그 , Enterprise 를 위한 GSLB

Page 26: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 26 -

GSLB Basic Operation

• GSLB 의 서비스 로직1. 사용자가 www.example.com에 접속하기 위해 Local DNS 로 Query 를 보내고 , Root

DNS, .com DNS 서버를 거쳐2. GSLB 로 www.example.com에 대한 DNS Query 를 보냄 .3. GSLB 는 DNS Proxy 로 동작하며 , 따라서 이 DNS Query 를 그대로 example.com DNS

서버로 전달함 .4. example.com DNS 서버는 www.example.com에 대한 IP 주소 (SLB 의 virtual IP) 1.1.1.1

과 2.2.2.2 가 미리 등록되어 있어 그 값을 GSLB 로 전달함 . (TTL=300초로 가정 )5. GSLB 는 서버 / 사이트 정책 (GSLB Policy) 를 통해 1.1.1.1 과 2.2.2.2 중에 사용자를 위한 최적의 사이트를 결정함 .

6. GSLB 정책을 통해 결정된 웹 서버 IP 1.1.1.1 이 Local DNS 로 전달되고 ,7. Local DNS 는 사용자 ( 단말 ) 에게 IP 주소를 전달하게 됨 .8. 사용자는 www.example.com의 IP 주소 1.1.1.1 을 destination 으로 하여 한국 사이트 SLB1

으로 HTTP GET 을 보내고 , SLB1 은 다시 정책 ( 서버 Health/Load 등 고려 ) 을 적용하여 최종 서버인 10.1.1.10 으로 HTTP GET 메시지를 전달하게 됨 .

출처 | 넷매니아즈 블로그 , Enterprise 를 위한 GSLB

Page 27: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 27 -

GSLB Policy

• GSLB 의 서버 선택 기준 (GSLB Policy)1. Server Health check: 살아 있는 서버 / 사이트 선택2. SLB Session & Network capacity threshold: 과부하 상태가 아닌 사이트 선택3. Network Proximity: 응답 속도가 빠른 (Low Latency) 사이트 선택4. Geographic Proximity: 지리적으로 가까운 사이트 선택5. SLB Connection Load: 새로운 연결 요청이 적은 사이트 선택6. Site Preference: 운영자의 정책에 의해 특정 사이트 선택7. Least Selected: 선택이 덜 된 사이트 선택8. Static Load Balancing: 균등하게 사이트 선택 (Round Robin or Weighted Round Robin)

출처 | 넷매니아즈 블로그 , Enterprise 를 위한 GSLB

• 사이트 / 서버 선택 과정은 1 번 단계를 시작으로 8 번 단계까지 순차적으로 진행되며 , 만약 1 번 단계에서 사이트 /서버가 선택이 되면 2 번 단계로 넘어가지 않고 종료되며 1 번에서 결정이 나지 않으면 2 번으로 넘어가는 방식임 . 또한 운영자는 설정을 통해 각 단계를 enable/disable 할 수 있으며 1~8 번 순서 변경도 가능함 .

Page 28: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 28 -

GSLB Policy

• GSLB 의 서버 선택 기준 (GSLB Policy)1. Server Health Check: SLB 가 서버들로 ICMP(Internet Control Message Protocol), UDP,

TCP, HTTP health check 메시지를 보내고 그 응답 여부를 통해 서버 혹은 서버의 Application이 살아 있음을 주기적으로 모니터링 하여 서비스가 가능한 서버를 선택하게 함 .

2. Session & Network usage threshold: Server Health Check 결과 한국과 미국 서버가 모두 살아 있는 경우 1) 서버의 현재 session 수와 2) Network usage 값을 참조하여 과부하 (Over-loaded) 상태가 아닌 서버를 선택하게 함 . 여기서 Session 수란 서버에서 유지하고 있는 TCP 혹은 UDP 연결 수를 의미하고 , Network usage 란 현재 SLB 를 통해 송수신되는 트래픽 대역폭 (bps) 을 의미함 .

3. Network Proximity: 한국과 미국 서버의 Session/Network usage 가 임계치를 넘지 않은 경우 , Network proximity 를 기반으로 서버를 선택하게 됨 . 여기서 Network Proximity 란 네트워크 관점에서 ( 지리적 관점 아님 ) 사용자와 가까운 서버를 선택해 주는 것으로 여기서 “가까움"의 의미는 Low latency 를 의미함 .

4. Geographic Proximity: Network Proximity 선택에서 Local DNS 가 ICMP 에 응답을 하지 않거나 , 두 사이트의 RTT 결과가 유사한 경우 , 지리적으로 사용자와 가까운 사이트를 선택하게 함 .

5. SLB Connection Load: Geographic Proximity 선택에서 사이트를 선택하지 못한 경우 , SLB의 Connection Load 가 적은 사이트를 선택하게 함 . 여기서 SLB Connection Load 란 “일정 시간 동안 SLB 에 생성되는 새로운 TCP or UDP 연결 수"를 의미함 .

6. Site Preference: 두 사이트의 SLB 모두 Connection Load 임계치를 넘지 않는 경우 , 운영자가 설정한 Site Preference 값 ( 사이트 선호도 ) 에 의해 사이트를 선택하게 함 . 운영자는 GSLB 에 각 사이트 별 (SLB)별로 Preference 값을 설정하고 , GSLB 는 항상 그 값이 큰 사이트를 선택함 .

출처 | 넷매니아즈 블로그 , Enterprise 를 위한 GSLB

Page 29: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 29 -

GSLB Policy

• GSLB 의 서버 선택 기준 (GSLB Policy)7. Least Selected: 두 사이트 모두 동일한 Preference 로 설정되어 있다면 , 사이트 부하를 균등하게 하기 위한 방법으로 선택이 덜 된 사이트 (Least Selected site) 를 선택하게 함 .

8. Static Load Balancing: Round Robin 혹은 Weighted Round Robin 방식으로 사이트를 선택하게 함 . Round Robin 의 경우 한국 – 미국 – 한국 – 미국 ... 순으로 번갈아 가며 사이트를 선택하고 , Weighted Round Robin 방식의 경우 한국 : 미국의 weight 가 2:1 로 되어 있다면 한국 – 한국 – 미국 – 한국 – 한국 – 미국 ... 순으로 한국 사이트를 2배 더 선택하도록 하는 방식임 . ( 예 . 한국 사이트에 서버가 더 많음 .)

• GSLB + SLB 방식의 경우 8 가지 Policy 모두 지원하지만 , GSLB only 방식의 경우와 DNS 방식의 경우 지원 정책이 아래 표와 같음 .

출처 | 넷매니아즈 블로그 , Enterprise 를 위한 GSLB

Page 30: CDN technology overview

4. Acceleration technology

Page 31: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 31 -

Static Content / Dynamic Content

콘텐츠 유형별 가속 기술

동적 콘텐츠(Dynamic con-

tent)

정적 콘텐츠(Static Content)

캐시 가능 콘텐츠

캐시 불가능 콘텐츠엣지 서버에 캐시 할 수 있고

사용자 요청에 상관없이결과값이 동일한 콘텐츠

( 예 : 이미지 , 텍스트 , 동영상 )

엣지 서버에 캐시 하면 안되고 사용자 요청에 상관없이결과값이 동일한 콘텐츠

( 예 : 건설 / 자동차 설계 도면 )

엣지 서버에 캐시 할 수 없고 사용자 요청에 따라

결과값이 달라지는 콘텐츠

( 예 : 영화 /항공 좌석 예매 )

엣지 서버에 캐시 할 수 있으나 사용자 요청에 따라

결과값이 달라지는 콘텐츠

( 예 : 포털 지도 )

Static Content Cache

TCP & Route optimization

Page 32: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 32 -

Application Delivery Network

출처 | 넷매니아즈 블로그 , CDN 과 ADN

• ADN (Application Delivery Network): 캐시와 마찬가지로 사용자와 Origin Server 간에 지리적인 거리로 인해 발생하는 ‘느린 응답속도 / 다운로드 타임'을 해결하지만 , 콘텐츠를 캐시 하지 않고 인터넷 미들 마일에 위치한 서버들간에 콘텐츠 트래픽을 빨리 전달할 수 있도록 하는 기술임 . ADN 은 콘텐츠 캐시가 불가능한 Dynamic 콘텐츠 ( 예 . 영화 /항공기 좌석 예매와 같이 개인별로 다른 콘텐츠가 전달되는 경우 ) 에 적용하여 응답 속도를 향상시킴 .

• ADN 핵심 기술1. Route Optimization: 사용자와 Origin Server 사이의 Routing 경로를 최적화

2.TCP optimization: TCP 프로토콜 최적화 ( 예 . Fast Start, Advanced Congestion Avoidance, Large Window Size)

3. Packet Redundancy (FEC: Forward Error Correction): 동일 패킷을 서로 다른 경로를 통해 중복 전달하여 패킷 손실 시 재전송 없이 데이터를 복구

4. Application Optimization: Application Layer ( 예 . HTTP) 프로토콜 최적화 ( 예 . Web Object Prefetching, Pipelining 등 )

5. Data Compression: 데이터 압축을 통해 전송량 최소화6. Data De-duplication: 동일 byte-stream 에 대해서는 중복 전송을 하지 않아 전송량 최소화

Page 33: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 33 -

Route Optimization – BGP based rout-ing

• BGP based Routing1. 각 나라에는 하나 이상의 ISP 가 존재하고 각 ISP 간에는 BGP (Border Gateway Protocol) 을

통해 라우팅 정보를 교환하여 전 세계가 연결되는 internet 이 만들어짐 . BGP 를 통해 ISP 간에 라우팅 정보를 교환할 때 , ISP 를 식별할 수 있게 AS (Autonomous System) number 가 함께 전달되어 Destination 으로 패킷을 전달하기 위해 몇 개의 ISP (AS) 를 거쳐야 하는지 알 수 있게 됨 .

2. 아래 그림에서 보듯이 좌측 Origin Server 에서 우측 User 에게 전달되는 패킷은 BGP 에 의해 생성된 경로를 따르게 되는데 , 이 때 BGP 경로 선택기준은 일반적으로 AS 가 짧은 경로 (ISP 를 가장 적게 거치는 경로 ) 를 따르게 됨 . (AS1759 – AS12068 – AS3559 – AS6984 – AS7018)

출처 | 넷매니아즈 블로그 , Akamai SureRoute 소개

Page 34: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 34 -

Route Optimization – BGP Routing problem

• BGP based Routing 의 문제점1. AS 기반 패킷 라우팅의 문제점은 경로 선택 기준이 단순히 “최단경로”이기 때문에 네트워크 부하

상태에 따른 트래픽 품질 (Loss, Delay, Jitter) 를 반영하지 못함 . 예를 들어 앞 페이지 그림에서 AS3559 ( 아시아 ) 와 AS6984 (북미 ) 간 링크에 트래픽이 증가하여 ( 네트워크 congestion 발생 ) Latency 가 증가한다면 AS 경로가 길더라도 AS5743 ( 호주 ) 를 거쳐 패킷을 전달하면 효율적이지만 , BGP 기반에서는 불가능함 .

2. 즉 , BGP 기반 라우팅은 실시간으로 변화하는 네트워크 상황에 대처하여 Optimal Routing Path를 제공할 수 없음 .

출처 | 넷매니아즈 블로그 , Akamai SureRoute 소개

Page 35: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 35 -

Route Optimization – Akamai SureRoute

• BGP based Routing 의 한계 극복 – Akamai SureRoute 사례1. AKAM SureRoute 는 BGP 경로 외에 “ Edge Server 를 경유하는 경로 2 개"를 선정하게 되는

데 , 이때의 경로 선정 기준은 “빠른 응답 속도”임 . 즉 , Origin Server 와 User 사이에 Edge 서버를 경유하는 여러 경로들에 대한 Latency 를 측정하여 ( 각 경로를 통해 Origin Server 로 특정 Object 에 대한 HTTP GET 및 HTTP 200 OK 메시지 송수신 ) Latency 가 가장 작은 경로 2 개를 고르고 1) 이 중 Latency 가 작은 Path 1 이 Best Path 가 되어 이 경로를 통해 Origin 서버와 User 간에 트래픽을 전달하고 2) Path 2 는 Path 1 구간 네트워크 장애 발생 시 대체 경로로 사용할 수 있도록 함 .

출처 | 넷매니아즈 블로그 , Akamai SureRoute 소개

Page 36: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 36 -

• Best Path 선정되면 Origin Server 와 User 사이에 있는 Edge Server 들은 HTTP Proxy 기능을 수행하여 , Web Server 와 User 사이의 연결은 아래와 같이 3 개의 구간으로 나누어 지게 됨 .1. 연결 1: Origin Server – Edge Server 2 (Low Latency 구간 )2. 연결 2: Edge Server 2 – Edge Server 1 (High Latency 구간 )3. 연결 3: Edge Server 1 – User (Low Latency 구간 )

• Origin Server 에서 User 로 향하는 트래픽 (패킷 ) 의 IP 주소 정보도 1) 연결 1 에서는 Source IP = Origin Server, Destination IP = Edge Server 2, 2) 연결 2 에서는 S. IP = Edge Server 2, D. IP = Edge Server 1, 3) 연결 3 에서는 S. IP = Edge Server 1, D. IP = User 로 변경되며 전달됨 .

• 이와 같이 Edge 서버가 Origin Server 와 User 사이의 HTTP/TCP 연결을 분리 (split) 시킴으로 인해 , Latency 가 가장 큰 인터넷 미들 마일 (Edge Server 2 ~ Edge Server 1) 에 대해 다음과 같은 추가 기능을 수행하여 User 에게 보다 빠르게 데이터를 전달해 줌 .

1. TCP Optimization: TCP Windowscaling, Selective ACK (SACK), Fast Start,Advanced Congestion Avoidance Algorithm,Forward Error Correction (FEC)2. HTTP Optimization: Web object prefetching

출처 | 넷매니아즈 블로그 , Akamai SureRoute 소개

Route Optimization – Akamai SureRoute

Page 37: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 37 -

TCP Optimization

• TCP Optimization: TCP 는 Delay 가 큰 WAN 에 최적화되어 있지 않기 때문에 , TCP 전송 효율을 최대화 (Optimization) 해야 함 .1.TCP 최적화의 예 1: Packet Drop 이 발생해도 TCP 전송 속도를 거의 줄이지 않는 방법

(표준 TCP 프로토콜은 50% 로 감소시킴 ) – Advanced Congestion Control 알고리즘2. TCP 최적화의 예 2: TCP Window size 를 수 MB까지 올려 WAN 구간의 Delay 가 커도 TCP

전송 성능 (Throughput, bps 로 측정 ) 을 Line Rate (Link Speed) 로 유지3. TCP 최적화의 예 3: Forward Error Correction (FEC) – 전송 후 에러 발생 시 에러 검출 및

재전송 요청하지 않고 정정

출처 | 넷매니아즈 블로그 , WAN 가속기 소개

Page 38: CDN technology overview

Copyright CDNetworks, All rights reservedⓒ - 38 -

Other ADN technology

• Data Compression: PC 에서 파일을 압축하여 하드디스크 공간을 절약하듯이 , WAN 으로 전송되는 패킷들을 압축하여 트래픽의 양을 줄이는 개념임 .

• Data Deduplication: 최초 전송한 패킷들의 Payload 내 bit stream 을 일정 조각으로 잘라 to-ken (또는 reference 라고 부름 ) 값과 함께 저장하고 있다가 동일 bit stream 이 포함된 패킷들이 수신되면 bit stream 대신 token 값 (token 의 길이는 bit stream 길이보다 짧음 ) 을 보내는 개념임 . 이를 수신한 반대편에서는 token 값을 bit stream 으로 바꿔 클라이언트로 전달함 .

출처 | 넷매니아즈 블로그 , WAN 가속기 소개

Page 39: CDN technology overview

Product Management team | 김유현 차장 Tel. 02-3441-0591 | 010-9942-0510

E-mail. [email protected] | [email protected] www.cdnetworks.com


Recommended