Computer Science/네트워크 2021. 10. 28. 11:49

출처 : https://anangpratika.wordpress.com/2011/06/07/content-delivery-networkcdn-and-timthumb/

정의

콘텐츠 전송 네트워크(Content delivery network 또는 content distribution network) CDN은 콘텐츠를 효율적으로 전달하기 위해 여러 노드를 가진 네트워크에 데이터를 저장하여 제공하는 시스템을 말한다.

CDN을 알기 전 기본지식

CDN에 대해 알아보기 전 간단히 기본지식을 짚고 가자.

1) DNS

도메인 네임 시스템(Domain Name System : DNS)은 호스트의 도메인 이름을 호스트의 네트워크 주소로 바꾸거나 그 반대의 변환을 수행한다.

ex > 구글의 기본 DNS : 8.8.8.8

기본적으로 통신사가 제공하는 DNS는 서버가 한국에 소재하여 빠른 응답 속도를 보여주고, 구글의 DNS는 한국에 서버가 소재하진 않지만 인접국인 일본에 서버가 소재하고 있어, 40ms 미만의 응답속도를 보여준다.

2) PROXY

프락시 서버란 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터이다.

IP를 바꾸기 위한 용도로 많이 사용되고 있고, 사용자의 요청을 cache 해서 동일 요청이 들어오면 cache 자원을 반환하여 서비스의 속도를 높이는 역할을 한다.

3) GLB

로드밸런서라는(Load Balancer : LB) 의미부터 먼저 살펴보자면,

서버에 가해지는 부하(=로드)를 분산(=밸런싱)해주는 장치 또는 기술을 통칭한다.

클라이언트와 서버풀(Server Pool, 분산 네트워크를 구성하는 서버들의 그룹) 사이에 위치하며, 한 대의 서버로 부하가 집중되지 않도록 트래픽을 관리해 각각의 서버가 최적의 퍼포먼스를 보일 수 있도록 한다.

로드밸런싱을 하게되는 예를 들어보면 다음과 같다.

일반 인터넷 사용자는 KT 사용자도 있고, SK 사용자도 있고 다양한 인터넷 서비스를 이용한다.
만약 네이버 포털 서버가 KT IDC에 위치한다면, KT 인터넷 망 장애 시 모든 인터넷 사용자들이 네이버에 접속할 수가 없다. 따라서 다수의 인터넷 망에 각각 서버들을 두어 하나의 사업자 망에 장애가 발생해도 다른 사업자 망을 통해 포털 서비스를 제공받을 수 있게 하고 있다. 이 각각의 서버들은 멀리 떨어져 있는데 이 서버들 간의 트래픽을 안전하게 분산해주는 기능을 로드밸런싱이 담당하고 있다.

위의 기능을 글로벌로 할 수 있도록 하는 기능이 글로벌 로드 밸런서(Global Load Balancer : GLB)이다.

GLB가 아닌 DNS 레코드를 추가하는 방식의 부하 분산을 할 수도 있는데 (예> 라운드로빈 알고리즘 이용) 이 둘의 차이점을 확인해보자.

DNS 방법과 GLB와의 차이점

출처 : https://smashingpumpkins.tistory.com/entry/Global-server-load-balancing-GSLB-다-쓰는-이유가-있는-구성

1 ) '서버 헬스체크'를 하느냐 안 하느냐 이다.

헬스체크를 하지 않으면 해당 서버가 장애가 나서 접속이 불가능해도, 해당 내용을 모르고 네임 서버가 접속할 수 있는 서버의 IP 주소를 알려준다.

2) 다른 하나의 차이는 GLB는 사용자의 위치를 고려해 가장 가까운 곳에 있는 서버로 연결한다.

즉, GLB는 지능적으로 상황에 맞게 부하 분산을 한다는 것이다. 이때 L4/L7 스위치를 이용한다.

4) POP

상호접속지점(Point of Presence : POP)으로 ISP망 상호간의 접속점일 수 있으며 가입자망에서 인터넷 백본망으로서의 액세스를 위한 접근점을 뜻할 수 있다.

해외에 다른 ISP와 연동을 할 때도 상호간의 접속점을 pop라 할 수 있다.

ex> 미국 동부 pop, 미국 서부 pop

출처 : http://www.ktword.co.kr/test/view/view.php?m_temp1=1759

5) Edge Server

예를 들어 구글 Docs, 네이버의 NDrive 등의 클라우드 컴퓨팅에 해당 서비스를 이용하는 사람이 급속도로 늘어나면서 서버 및 데이터 센터에서 처리할 수 있는 데이터의 양을 넘어가기 시작했다. 여기에서 발생되는 데이터 처리 속도, 용량 및 보안 등의 문제들을 해결하기 위해 탄생한 것이 에지 컴퓨팅이다.

엣지 컴퓨팅은 데이터 처리를 데이터 센터에서 하지 않고 장치에서 물리적 위치에 좀 더 가까이 이동시킨 것이다.

예를 들면 커넥티드 자동차(Connected Car)의 경우, 대용량 데이터에 기반한 분석 작업을 위해 중앙 서버에 있는 컴퓨팅 기능을 전적으로 활용하는 것이 아닌 자동차 내부의 엣지 컴퓨팅 환경을 통해서 빠르게 처리한 결과를 중앙 서버에 전달하여 가공/분석하는 형태로 활용이 가능하다.

CDN의 생성 배경

기업 & 사용자가 만든 미디어 콘텐츠를 인터넷으로 접근 가능하도록 하는 가장 쉬운 방법은 웹서버를 통하는 것이다.

웹 서버 내에 미디어 파일을 놓아두면, 브라우저와 같은 클라이언트 프로그램이 도메인에 서브 경로를 붙여 파일을 다울로드 하고 표시하거나 재생하는 방법이다.

하지만 콘텐츠의 크기 & 개수가 늘어나 네트워크 대역폭 제한이 걸리고, 이는 작은 크기의 미디어 파일이라도 동시 접근량이 늘어나면 대역폭 제한이 걸린다. 이 문제를 해결하기 위한 방법들을 확인해보자.

변화 1단계 ) 미디어 콘텐츠 서버의 사용

다수의 고객에게 동시에 콘텐츠를 전달해야 하는 상용 웹 서비스의 경우 하나의 웹서버 만으로 운용할 수 없는 경우가 대다수이다. 웹서버의 경우 로드밸런서를 통해 트래픽을 동일 한 여러 개의 웹서버로 분산하여 부하를 줄일 수 있다.

하지만 콘텐츠가 계속 추가되는 상황이라면 여러개의 웹서버가 동일한 미디어 파일을 유지할 수 있도록 동기화시켜야 하는 문제가 발생한다. 그래서 다른 기능 없이 미디어 콘텐츠만을 보관하고 제공하도록 미디어 콘텐츠 서버를 별도로 만들어 외부의 접근이 이곳으로 일원화되도록 한다.

하지만 미디어 콘텐츠 한 곳으로 트래픽이 몰리는 문제가 다시 발생한다.

변화 2단계 ) 지역별 미디어 콘텐츠 전용 서버들

글로벌한 서비스의 경우에는 지리적 문제점도 가지게되는데 한 곳에 미디어 콘텐츠 서버가 있다면 서버와 클라이언트 사이의 거리가 멀수록 통신속도가 느려지는 문제를 가지게 된다.

해법은 서버와 클라이언트 사이의 거리를 줄이는 것이다. 오리진(Origin) 서버라고 하는 원본 격인 미디어 서버를 구성하고 다수의 지역의 미디어 서버들(Edge Sever)이 오리진 서버로부터 데이터를 가져와 근처의 사용자에게 제공하는 것이다.

하지만 이는 막대한 서버 비용이들어가고, 높은 수준의 서버 관리도 필요하다.

변화 3단계 ) 전문 콘텐츠 배포망 서비스 등장

그래서 이것을 전문적으로 하는 서비스들이 생겨났는데 이를 CDN 서비스라고 한다.

즉, CDN은 서버와 사용자 사이의 물리적인 거리를 줄여 콘텐츠 로딩에 소요되는 시간을 최소화하기 위해 만들어졌다.

예를 들어 미국에 있는 사용자가 한국에 호스팅 된 웹 사이트에 접근하는 경우 미국에 위치한 PoP 서버에서 웹사이트 콘텐츠를 사용자에게 전송하는 방식이다.

CDN의 작동방법 (Azure CDN 기준)

CDN 서비스를 여러 회사에서 제공하고 있는데, 그중 Azure CDN을 기준으로 하여 작동 방법을 확인해보자.

출처 : https://docs.microsoft.com/ko-kr/azure/cdn/cdn-overview

사용자(Alice)가 특수 도메인 이름(예: <endpoint name> .azureedge.net)이 있는 URL을 사용하여 파일(자산이라고도 함)을 요청한다. 이 이름은 엔드포인트 호스트 이름 또는 사용자 지정 도메인이 될 수 있다.
DNS는 가장 성능이 좋은 POP 위치로 요청을 라우팅한다. 이 위치는 대개 사용자와 지리적으로 가장 가까운 POP이다.
POP의 에지 서버의 캐시에 파일이 없으면, POP는 원본 서버에서 파일을 요청한다.
원본 서버는 Azure Web App, Azure Cloud Service, Azure Storage 계정 또는 공개적으로 액세스 할 수 있는 웹 서버이다.
원본 서버는 파일을 POP의 에지 서버로 반환한다.
POP의 에지 서버는 파일을 캐싱하고 원래 요청자(Alice)에게 파일을 반환한다.
파일은 HTTP 헤더로 지정된 TTL(Time-To-Live)이 만료될 때까지 POP의 에지 서버에 캐시된 상태로 유지된다.
원본 서버가 TTL을 지정하지 않은 경우, 기본 TTL은 7일이다.
다른 사용자가 Alice가 사용한 것과 동일한 URL을 사용하여 동일한 파일을 요청할 수 있으며 동일한 POP로 이동할 수도 있다.
파일의 TTL이 만료되지 않았으면, POP 에지 서버는 캐시로부터 직접 파일을 반환한다.
이러한 프로세스를 통해 보다 신속하고 응답성이 뛰어난 사용자 환경이 가능해진다.

CDN의 Caching 방식 분류

CDN의 엣지서버(Cache Server)가 오리진 서버(Origin Server)에서 데이터를 가져와 저장하고 있는 방식에는 2가지가 있다.

분류	설명
Static Caching	사용자의 요청이 없어도 오리진 서버에 있는 Content를 운영자가 미리 캐시 서버에 복사한다 따라서 사용자가 Cache Server에 접속하여 Content를 요청하면 무조건 그 Content는 Cache Server에 있다 대부분의 국내 CDN에서 이 방식을 사용함 (예. Pooq 동영상 스트리밍/다운로드, NCSOFT 게임파일 다운로드 등)
Dynamic Caching	최초 캐시 서버에는 Content가 없음 사용자가 Content를 요청하면 해당 Content가 있는지 확인하고, 없으면(Cache Miss) 오리진 서버로 부터 다운로드 받아(Cache Fill) 사용자에게 전달해 준다. 이후 동일 Content를 요청 받으면 저장(캐싱)된 Content를 사용자에게 전달한다. 각 Content는 일정 시간(TTL)이 지나면 캐시 서버에서 삭제될 수 있고, 혹은 오리진 서버를 통해 Content Freshness 확인 후에 계속 가지고 있을 수 있다. Akamai, Amazon과 같은 Global CDN 업체, 그리고 Cisco나 ALU의 통신사업자향 CDN 장비 솔루션에서 이 방식을 지원한다.

CDN의 Caching 규칙

많은 회사들이 CDN 서비스를 제공하고 있으므로 Caching의 규칙은 각 회사마다 다르다는 것을 알아두길 바라고, 기본적인 규칙에 대해서 알아보자.

1) Cache-Control

웹 게시자에게 콘텐츠에 대한 제어 권한을 더 많이 부여하고 Expires 헤더의 제한 사항을 해결하기 위해 HTTP 1.1에 도입되었다. Expires 헤더와 Cache-Control이 모두 정의 된 경우 전자의 헤더를 대체한다.

태그 값	설명
max-age	캐시는 지정된 시간(초)동안 콘텐츠를 저장할 수 있다. 예를 들어 Cache-Control: max-age=5 이 지시문은 콘텐츠가 최신으로 간주되는 최대 시간을 지정한다.
no-cache	콘텐츠를 캐시하지만 캐시에서 전송할 때마다 그 전에 콘텐츠의 유효성을 검사한다. Cache-Control: max-age=0과 동일하다.
no-store	콘텐츠를 캐시하지 않는다. 이전에 저장된 콘텐츠가 있으면 제거한다.

2 ) ETag & Last-Modified

ETag는 모든 파일 및 파일 버전에 대해 고유한 문자열을 정의해서 파일의 유효성을 확인한다.

ex > ETag: "17f0ddd99ed5bbe4edffdd6496d7131f"

Last-Modified는 마지막 수정 날짜를 파악해서 파일의 유효성을 확인한다.

두 태그로 유효성을 검사해서 유효성 검사기와 일치하면 응답에 상태 코드 304(수정되지 않음)가 전송되고, 버전이 다른 경우 서버는 상태 코드 200(정상)과 업데이트된 리소스로 응답한다.

CDN의 Dynamic Caching 작동방법

자원이 많을 경우에는 Dynamic Caching이 Static Caching 보다 훨씬 메모리 효율이 좋으므로 Dynamic Caching을 기준으로 caching 방법을 간단하게 확인해보자.

출처: https://www.netmanias.com/ko/post/blog/5654/cdn-http/http-cache-control-expiration-and-validation

이용자 Chris가 cache 서버로 다음과 같이 image 파일을 요청한다.
Chris가 최초로 콘텐츠를 요청했으므로 캐시 서버에는 해당 파일이 없다.
캐시 서버는 오리진 서버에게 image 파일을 요청한다.
오리진 서버는 image 파일과 해당 콘텐츠의 메타 태그 정보를 캐시 서버로 전달한다. 메타 태그에는 다음과 같은 정보가 포함되어 있다.
- Last-Modified: Mon, 1 Oct 2012 09:00:00 - 오리진 서버에 저장되어 있는 image.jpg 파일은 2012년 10월 1일 오전 9시 정각에 업데이트되었음
- Cache-Control: max-age=100 - image.jpg 파일의 캐싱 유효시간은 100초이다. "100초 동안만 캐싱하고, 그 이후에는 다시 오리진 서버로 콘텐츠 요청 혹은 freshness 확인을 해라"라는 의미
캐시 서버는 t = 0 시각에 image 파일을 수신한다. 그리고 수신한 파일을 캐싱(저장)하고, 이 콘텐츠의 캐싱 유효시간 100초를 Cache Control Table에 기록한다.
캐시 서버는 오리진 서버로부터 수신한 콘텐츠를 Chris에게 전달한다. 이때 max-age는 오리진 서버가 명시한 값 100초를 그대로 전달한다. Chris(웹브라우저)는 image 파일을 100초 동안 캐싱하며 따라서 이 시간 동안 캐싱된 콘텐츠에 대한 재요청을 하지 않는다.

다른 사람이 재요청을 할 때는 캐시 서버에 있는 데이터를 가져다 쓸 수 있다.

자세한 caching 방법을 좀 더 알고 싶다면 아래의 링크로 들어가면 완벽한 설명을 볼 수 있다.

https://www.netmanias.com/ko/post/blog/5654/cdn-http/http-cache-control-expiration-and-validation

CDN 캐시 서버의 Cache Control - Expiration and Validation

다들 잘 아시는 바와 같이 CDN 캐시 서버는 (i) 이용자와 가까운 곳에서 위치하고 (ii) 오리진 서버(웹 서버)의 콘텐츠를 캐싱하여 (iii) 오리진 서버를 대신하여 콘텐츠를 이용자에게 다운로드 해

www.netmanias.com

https://www.netmanias.com/ko/?m=view&id=blog&no=5630

CDN의 Request Routing 기술

Request Routing은 사용자의 Content Request(예. 쿵푸펜더2 볼래요~)에 대해 최적의 Cache Server를 선택해 주는 기능으로 이를 위해 CDN 망에는 Request Router가 존재합니다. (이름에 Router가 들어갔다고 IP Routing