CDN
콘텐츠의 복제본을 여러 곳에 두고 사용자와 가까운 곳에서 내려주는 서버망입니다. 요청은 원본을 가진 서버까지 가지 않고 가까운 복제본에서 끝납니다. 어느 복제본으로 요청을 보낼지 정하는 장치도 대개 이 망에 같이 놓입니다.
상세
물류창고 한 곳에서 전국으로 물건을 부치는 대신, 동네마다 같은 물건을 채워 둔 편의점을 두는 일과 닮았습니다.
CDN(Content Delivery Network, 콘텐츠 전송 네트워크)의 정의는 RFC(Request for Comments) 6707 에 있습니다. 콘텐츠를 사용자 에이전트에게 더 효과적으로 전달하려고 망 요소들이 4계층부터 7계층까지에서 협력하는 망 기반구조입니다. 한 대의 서버가 아니라 여러 요소가 협력하는 구성이라는 것이 정의의 중심입니다.
같은 문서는 CDN 이 대개 네 부분으로 이루어진다고 적습니다. 요청 라우팅 시스템, 서로게이트 집합을 포함하는 배포 시스템, 로깅 시스템, 그리고 CDN 제어 시스템입니다. 여기서 콘텐츠를 실제로 들고 있는 쪽이 배포 시스템의 서로게이트이고, 들어온 요청을 어느 서로게이트로 보낼지 정하는 쪽이 요청 라우팅 시스템입니다. 복제본을 여러 곳에 두는 일과 그 복제본 중 하나를 고르는 일이 대개 한 망 안에 같이 놓입니다. 복제본은 원본이 바뀌어도 저절로 따라 바뀌지 않습니다. 그래서 원본을 고친 뒤에도 한동안 낡은 복제본이 나갈 수 있습니다.
배경
RFC 3466 은 가장 단순한 형태를 이렇게 적습니다. 모든 사용자 에이전트가 모든 요청을 URL(Uniform Resource Locator) 의 호스트 부분에 적힌 오리진 서버로 곧장 보냅니다. 콘텐츠를 보는 사람이 늘면 오리진 서버가 받는 요구도 같이 늡니다. 이 단순한 구성을 손보는 방법은 여러 가지입니다. 그중 하나는 스위치 뒤에 서버 여러 대를 묶는 서버 팜입니다. 또 하나는 클라이언트와 서버 사이에 캐싱 프록시와 역방향 캐싱 프록시를 두는 것입니다. 캐싱 프록시는 성능을 개선하고 대역폭 사용을 줄이려고 사용자 가까이 배치됩니다.
같은 문서는 둘 다 쓸모 있는 기법이지만 한계가 있다고 적습니다. 서버 팜은 오리진 서버의 확장성을 개선합니다. 다만 서버와 그 밖의 요소들이 대개 오리진 서버 근처에 배치되므로, 망 혼잡에서 오는 성능 문제는 거의 개선하지 못합니다. 캐싱 프록시는 클라이언트 가까이 놓이므로 망 혼잡에서 오는 문제를 개선할 수 있습니다. 대신 클라이언트의 수요를 따라 객체를 캐시합니다. 어떤 객체를 찾는 요청이 전체로는 많아도 서로 다른 캐싱 프록시에 얇게 흩어지면 이 방식은 잘 듣지 않습니다. 극단적으로는 서로 다른 캐싱 프록시 n 개를 거쳐 n 번 요청이 나가, 캐싱 프록시가 하나도 없을 때와 똑같이 오리진 서버로 n 번의 요청이 갑니다. 그래서 인기 있는 콘텐츠를 가진 제공자는 큰 서버 팜과 부하 분산, 넓은 대역폭 회선에 투자해야 하는 자리에 놓입니다. 그렇게 투자해도 망 전체의 혼잡 때문에 사용자 경험은 여전히 떨어질 수 있습니다.
이 한계를 다루려고 배치가 늘어난 것이 CDN 입니다. RFC 3466 은 CDN 을 서버 팜에 가까운 구성을 캐싱 프록시가 놓이던 망 위치로 옮긴 것이라고 설명합니다. CDN 은 호스팅하는 콘텐츠 항목마다 복제본을 여럿 둡니다. 브라우저의 요청 하나는 그중 적절한 복제본으로 갑니다. 여기서 적절하다는 것은 대개 오리진 서버에서 가져올 때보다 짧은 시간에, 적절한 무결성과 일관성을 지켜 클라이언트에게 내준다는 뜻입니다. 지리적 위치와 망 연결에 대한 정적 정보만으로는 복제본을 고르는 데 대개 충분하지 않습니다. 그래서 CDN 은 대개 망 상태와 복제본의 부하에 대한 동적 정보를 함께 넣어 부하가 고르게 퍼지도록 요청을 보냅니다. RFC 6707 은 인터넷으로 전달되는 영상·멀티미디어 콘텐츠의 양이 빠르게 늘고 있고 앞으로도 그럴 것으로 본다고 적습니다. 그러면서 캐시 가능한 콘텐츠에 대해 CDN 이 주는 이점으로 전달 비용 감소, 최종 사용자의 체감 품질 개선, 전달의 견고성 증가를 듭니다.
동작
요청이 어느 서버에서 처리될지 정하는 일부터 시작합니다. RFC 3568 은 이것을 요청 라우팅이라 부릅니다. 콘텐츠 라우팅이나 콘텐츠 리다이렉션이라고도 한다고 같은 문서가 적습니다. 요청 라우팅 시스템은 여러 지표를 써서 그 요청을 가장 잘 처리할 수 있는 서로게이트로 사용자를 보내려 시도합니다. 지표로는 망 근접도, 대역폭 가용성, 서로게이트 부하, 콘텐츠 보유 여부 같은 것을 듭니다. 방식은 크게 셋으로 갈립니다. DNS(Domain Name System) 요청 라우팅, 전송 계층 요청 라우팅, 애플리케이션 계층 요청 라우팅입니다.
DNS 기반 방식은 DNS 해석 과정에 전용 DNS 서버를 끼워 넣습니다. 그 서버는 사용자가 정한 정책이나 지표, 또는 둘의 조합에 따라 A·NS(Name Server)·CNAME(Canonical Name) 레코드를 다르게 돌려줍니다. 응답을 하나만 주는 방식에서는 요청한 DNS 서버에 가장 나은 서로게이트 하나의 IP(Internet Protocol) 주소를 A 레코드로 돌려줍니다. 여러 개를 주는 방식에서는 여러 서로게이트의 A 레코드를 함께 돌려줍니다. 클라이언트 쪽 DNS 서버 구현은 흔히 그 응답들을 라운드로빈으로 돌아가며 씁니다. 애플리케이션 계층 방식은 전송 계층 헤더 너머까지 들여다봅니다. 객체 단위까지 내려가는 요청 라우팅 제어가 여기서 나옵니다. URL 로 콘텐츠를 가려낼 수 있는 경우가 많습니다. URL 의 앞이나 뒤 일부만 봐도 요청 라우팅 판단이 서는 경우도 많습니다. 302 리다이렉션 방식에서는 요청이 먼저 가상 서로게이트로 해석됩니다. 그러면 그 서로게이트가 HTTP(HyperText Transfer Protocol) 의 302 같은 응답 코드를 돌려 클라이언트를 선택된 서로게이트로 보냅니다.
보낼 곳이 정해지면 그다음은 히트와 미스의 갈림입니다. 요청 라우팅이 고른 서로게이트, 곧 사용자 가까이 놓인 엣지 서버가 요청을 받아 자기 캐시부터 봅니다.
flowchart TD
U[사용자 에이전트] -->|요청| R[요청 라우팅]
R --> E[엣지 서버]
E -->|캐시 히트| U
E -->|캐시 미스| O[오리진 서버]
O -->|객체| E
AWS(Amazon Web Services) CloudFront 개발자 문서가 이 갈림을 단계로 적어 둡니다. 사용자가 객체를 요청하면 DNS 가 그 요청을 처리할 PoP(Point of Presence) 로 요청을 보냅니다. 지연 기준으로 대개 가장 가까운 PoP 입니다. 엣지 로케이션이라고도 부르는 자리입니다. CloudFront 는 요청받은 객체가 자기 캐시에 있는지 봅니다. 있으면 그대로 사용자에게 돌려줍니다. 없으면 요청을 배포 설정과 대조한 뒤 오리진 서버로 넘깁니다. 오리진 서버는 Amazon S3 버킷일 수도 있고 HTTP 서버일 수도 있습니다. 오리진 서버가 객체를 엣지 로케이션으로 돌려주면 CloudFront 는 첫 바이트가 도착하는 즉시 사용자에게 전달을 시작합니다. 그리고 다음에 누군가 같은 것을 요청할 때를 위해 그 객체를 캐시에 넣습니다.
이 갈림이 한 겹 더 있기도 합니다. CloudFront 의 리전 엣지 캐시는 오리진 서버와 PoP 사이에 놓입니다. PoP 에서 미스가 나면 대개 가장 가까운 리전 엣지 캐시로 객체를 가지러 갑니다. 리전 엣지 캐시도 자기 캐시를 다시 봅니다. PoP 에도 리전 엣지 캐시에도 없는 객체에 대해서만 요청이 오리진 서버까지 올라갑니다.
CDN 을 서로 이어 붙일 때도 같은 갈림이 반복됩니다. RFC 7336 이 그리는 흐름에서는 하류 CDN 의 전달 노드가 자기 캐시를 먼저 봅니다. 캐시 히트면 뒤 단계 없이 전달 노드가 최종 사용자에게 콘텐츠를 바로 돌려줍니다. 캐시 미스면 콘텐츠를 상류 CDN 에서 받아와야 합니다. 하류 CDN 은 CDN 도메인을 보고 이 콘텐츠를 상류 CDN 에서 가져와야 한다는 것을 압니다. 이때 하류 CDN 은 그 CDN 도메인이 아는 피어의 것인지 검증할 수 있습니다. 열린 프록시 노릇을 하도록 속는 것을 피하려는 장치입니다.
예시
Cache-Control 의 공유 캐시 지시자
MDN(Mozilla Developer Network) 은 오리진 서버와 클라이언트 사이에 존재하는 캐시를 공유 캐시라 부릅니다. 프록시와 CDN 이 그 예입니다. 공유 캐시는 응답 하나를 저장해 여러 사용자에게 되풀이해 씁니다. 그래서 개인화된 콘텐츠를 공유 캐시에 저장하지 않도록 하라고 적습니다.
Cache-Control: s-maxage=604800
s-maxage 는 공유 캐시에서 응답이 신선하게 남는 시간을 정합니다. 개인 캐시는 이 지시자를 무시합니다.
공유 캐시에서는 max-age 나 Expires 가 함께 있어도 이 값이 그것들을 덮습니다.
Cache-Control: max-age=604800
Age: 100
max-age=n 은 응답이 생성된 뒤 n 초 동안 신선하게 남는다는 뜻입니다. 응답이 지나온 경로의 다른
캐시가 그 응답을 100 초 동안 저장하고 있었다면, 그 사실은 Age 응답 헤더로 알려집니다. 브라우저
캐시는 자기 신선도 수명에서 그 100 초를 뺍니다.
MDN 은 CDN 을 매니지드 캐시로도 분류합니다. 매니지드 캐시는 서비스 개발자가 오리진 서버의 부담을
덜고 콘텐츠를 효율적으로 전달하려고 명시적으로 배치하는 캐시입니다. 리버스 프록시, CDN, 그리고 캐시
API(Application Programming Interface) 와 함께 쓰는 서비스 워커가 그 예입니다. 매니지드 캐시의
성질은 배치한 제품에 따라 다릅니다. 대부분의 경우 Cache-Control 헤더와 각자의 설정 파일이나
대시보드로 동작을 제어할 수 있습니다. HTTP 캐싱
명세는 캐시를 명시적으로 지우는 방법을 사실상 정의하지 않지만, 매니지드 캐시에서는 저장된 응답을
언제든 지울 수 있습니다.
cf-cache-status 헤더
Cloudflare 문서는 자원이 캐시됐는지를 cf-cache-status 응답 헤더 값으로 알린다고 적습니다.
cf-cache-status: HIT
cf-cache-status: MISS
HIT 는 자원을 Cloudflare 캐시에서 찾았다는 뜻입니다. MISS 는 캐시할 수 있는 응답이지만 요청
시점에 Cloudflare 캐시에 없어서 오리진 웹 서버에서 받아 내줬다는 뜻입니다. Cloudflare 가 캐시하지
않기로 고른 응답은 MISS 대신 BYPASS 를 돌려줍니다.
같은 문서는 Age 응답 헤더를 자원이 Cloudflare 캐시에 머문 시간을 초로 적은 값이라고 설명합니다.
자원이 재검증되거나 퍼지되거나 축출된 뒤 다시 캐시되면 이 값은 초기화됩니다. Age 는 캐시에서 내준
응답에만 붙고 캐시 미스에는 나타나지 않습니다.
관련 항목
콘텐츠가 놓이는 망 위치
엣지 서버 · PoP · 엣지 로케이션 · 리전 엣지 캐시 · 서로게이트 · 오리진 서버 · 노드
요청을 어느 서로게이트로 보낼지 가르는 방식
요청 라우팅 · DNS 기반 라우팅 · CNAME 리다이렉션 · NS 리다이렉션 · 302 리다이렉션 · Anycast · 부하 분산
그 방식이 참고하는 지표
캐시 동작을 지시하는 헤더·지시자
Cache-Control · max-age · s-maxage · Age 헤더 · Vary 헤더 · TTL(Time To Live) · stale-while-revalidate · 캐시 키
캐시가 거치는 상태와 절차
요청이 엣지에서 갈리는 결과
캐시 히트 · 캐시 미스 · BYPASS · cf-cache-status
헷갈리는 캐시 이웃
개인 캐시 · 프록시 캐시 · 티어드 캐시
CDN이 딛고 선 프로토콜과 식별자
HTTP · DNS · URL · 헤더 · 레코드 · IP 주소(Internet Protocol, IP)
CDN을 대신할 수 있는 다른 매니지드 캐시
CDN에 관여하는 역할·참여자
사용자 에이전트 · 브라우저 · 서비스 개발자 · 콘텐츠 제공자
CDN이 비롯된 배경
망 혼잡 · 서버 팜 · 캐싱 프록시
CDN이 속하는 상위 분류
CDN을 이루는 구성 요소
CDN을 실제로 구현·채택한 제품
AWS · CloudFront · Cloudflare · Amazon S3
CDN을 정의하는 표준·문서
RFC 6707 · RFC 3466 · RFC 3568 · RFC 7336 · CDNI(CDN Interconnection) · MDN
다른 이름: Content Delivery Network · Content Distribution Network · 콘텐츠 전송 네트워크