대용량 파일(게임 다운로드 , VOD 영상 , 이미지)을 포함한 콘텐츠들을 서버에서 관리하여 제공한다고 했을 때
하나의 웹페이지가 로딩됨과 동시에 img 태그, video 태그, 기타 api들의 요청을 수백 이상의 요청이 서버로 들어갈 것이다. 그리고 불특정 다수를 기반한 서비스들을 * 접속자 만큼의 트래픽을 감당할 것이다.
게임 다운로드 , VOD 영상 , 이미지 콘텐츠들을 엄청난 크기를 자랑하는데 이러한 콘텐츠 자체들의 관리영역을 서버가 아닌 다른 곳에서 서빙하는 것이 CDN이다.
이로써 부하가 분산되므로 사용자에게 더 빠르게 응답할 수 있으며 예외 또한 따로 모니터링하며 문제점을 파악하기도 용이해진다.
CDN의 효과적인 콘텐츠 종류 구분하기
정적 콘텐츠 (static content)
한번 만들어진 후 변경되지 않을 콘텐츠를 정적 콘텐츠라 불린다.
예를 들면 웹 레이아웃을 구성하는 css,js,jpg, 웹 서비스 고정 로고 등이 있다.
이러한 콘텐츠들을 개발자가 미리 cache server에 미리 로드하는 방식이 효과적이다.
동적 콘텐츠 (dynaminc content)
사용자 요청에 따라 가공하거나 개인 정보를 포함하여 요청별로 달라지는 콘텐츠들을 동적 콘텐츠라 한다.
예를 들면 주문 플랫폼 사용자가 해당 상품의 이미지를 다른 것으로 변경한 후에는 일반 사용자들은이전 이미지가 아닌 바꾼 이미지로 제공해야하는 경우를 들 수 있다.
CDN의 핵심 := 캐시 (Cache)
캐시란 일반적으로 하드웨어 혹은 소프트웨어 데이터를 저장하여 추후의 요청에 대비하게 데이터를 빠르게 제공하는 기술 용어이다.
대용량 파일 포함된 콘텐츠들을 빠르게 제공하기 위해 CDN은 콘텐츠를 캐싱하는 캐시 서버로 활용된다.
캐시는 영구적으로 어떤 것을 가지고 있지 않는다.
일정 시간 동안만 가지고 있거나 제한된 수용량만을 가지고만 있는다.
캐싱 상태
캐싱의 여부를 확인하기 위해 ‘캐시 미스(Cache Miss)’와 ‘캐시 힛(Cache Hit)’으로 상태를 나눌 수 있다.
‘Cache Miss’
캐시 서버에 콘텐츠가 없는 상태로, 최초 콘텐츠 요청이나 캐시가 삭제된 이후 콘텐츠 요청이 들어온 상태이다.
이럴경우 원본 서버로부터 콘텐츠를 가져와 저장(캐싱) 후 응답을 전송한다.
‘Cache Hit’
캐시 서버에 콘텐츠가 저장된 상태로 콘텐츠 요청이 들어와 원본서버 요청 없이 바로 응답을 전송할 수 있는 상태이다.
이럴 경우 원본서버로 요청하고 응답받는 과정을 거치지 않아 더 빠르게 응답할 수 있다.
CDN의 동작원리
기본적으로 사용자가 원격지에 있는Origin-Server로부터 Content를 다운로드 받을 때 가까이 있는 서버에서 받는 것보다 시간이 오래 걸리므로, 사용자와 가까운 곳에 위치한 Cache Server에 해당 Content를 저장(캐싱)하고 Contetn 요청시에 Cache Server가 응답을 주는 기술이다.
이로써 하나의 CDN 서버로 몰리는 트래픽 또한 부하 분산하여 서빙할 수 있다.
CDN 사용 x
CDN 사용
가능한 사용자와 가까운 CDN과 연결해 불필요한 연결 설정 비용을 줄일 수 있다.
일부 CDN은 인터넷에 분산된 여러 CDN 서버들을 통해 트래픽을 Origin Server로 라우팅함으로 최적화된 경로를 통해 발생한다.
BGP는 인터넷 라우팅 프로토콜이지만 성능지향적이 아니다.
이에따라 BGP가 결정한 경로는 CDN 서버간에 최적화 경로보다 성능이 떨어질 수 있다.
Q. CDN에 없으면 바로 Origin - Server로 가는것인가?
동적 콘텐츠 변경을 위한 퍼징(Purging)
Cache Eviction 처럼 일정시간 기다렸다가 삭제되는 것이 아닌 바로 콘텐츠를 제거하는 매커니즘이다.
CDN 서버에서 캐쉬된 리소스를 즉각 삭제를 지원하는 경우 동적인 컨텐츠를 관리하는데 용이하다. (긴 TTL을 사용하는 컨텐츠)
해당 방식을 사용해 언제 업데이트 되는지 모르는 동적인 리소스의 캐싱 기간을 최대한 길게 유지 할 수 있다. ( hold -till - told -caching 이라고 함)
규모에 따라 퍼징을 사용할 때 캐시 태그, 삭제 캐시 키라는 개념을 사용한다.
하나의 리소스에 식별자를 연결한 다음, 태그를 사용해 세분화된 삭제를 할 수 있다.
예)
사이트 하단 푸터가 포함된 /about, /blog 리소스에 footer라는 태그를 추가한다.
사이트 하단 푸터가 업데이트 되면 foot 태그를 가진 CDN에 있는 모든 리소스를 퍼징한다.
콘텐츠 교체할 때 주의할 점
서비스 운영상 편의로 파일명이 변경되지 않고 파일의 교체나 내용이 갱신되는 경우가 있다.
웹 브라우저에 랜더링 된 콘텐츠 요청은 서비스 URL로 이루어지는 것을 알고 있어야한다.
그렇기 떄문에 텍스트적인 변경 없이는 콘텐츠 속내의 변경을 알 수 없다.
파일이 교체된 경우, 캐시서버에서는 구 콘텐츠 내용을 전송할 수 있다.
이처럼 동일한 파일명을 사용하여 CDN의 콘텐츠를 갱신하고 싶다면 ‘퍼징’을 활용할 수 있다.
하지만 콘텐츠 대상이 상상 이상의 파일의 용량이거나 사용량이 많은 경우 ‘퍼징’이 독이 될 수 있다.
그러면 CDN 오리진 서버에 대해 부하가 생겨 장애를 유발할 수 있다.
또한 ‘퍼징’은 캐시 서버의 콘텐츠 갱신의 역할만 하고 웹 브라우저의 Local Cache된 콘텐츠 갱신을 보장하지 않을 수 있다.
그러므로 사용자 브라우저까지 최신성을 보장하기 위해서는 파일명과 서비스 링크(URL) 자체를 변경하여 새롭게 캐싱하는 것이 좋다.
CDN 꿀팁
[원본 CDN, 캐싱 CDN 콘텐츠 통일]
queryString으로 인해 Cache Hit율이 하락할 수 있다.
origin server 콘텐츠 요청이 ${domainName}/file.png 일떄,
캐싱 server 콘텐츠 요청이 ${domainName}/file.png?query=12345 일떄,
파일은 동일하나, ‘query=12345’의 쿼리스트링에 따라 캐시 서버는 개별 콘텐츠로 캐시하여 Cache Hit율이 하락합니다.
쿼리스트링 무시(Ignore Query String)’ 설정을 적용하는 것이 좋다
[WAS 설정 최적화]
원본에서 HTTP Header와 콘텐츠 응답에 따라 Cache Hit률을 높이고 사용자 응답 시간을 줄일 수 있다.
HTTP 또한 헤더에 따라 캐싱을 제공하기 때문이다.
gzip 압축 적용
압축을 하면 원본 서버의 트래픽을 줄이고 응답 시간을 개선할 수 있어 사용하는 것이 좋다.
Cache-Control 헤더 사용 시 주의
원본 서버에서 응답 헤더의 ‘Cache-Control’ 헤더 값 내에 ‘private, no-cache, max-age=0, must-revalidate, no-store’가 포함되면 캐싱을 활용하지 않고 사용자 요청이 모두 원본으로 유입된다.
원본 서버 응답 시 이 값들이 포함되지 않는 것이 좋다.
Etag, Vary 헤더 사용 시 주의
원본 서버에서 응답 헤더의 ‘Vary’ 헤더 값에 ‘User-Agent’가 포함되면 요청의 User-Agent에 따라 동일한 콘텐츠이더라도 개별 콘텐츠로 캐싱될 수 있다.
Browser나 사용자 환경 별로 다른 콘텐츠를 서비스하지 않는다면 원본 서버 응답 시 이 값이 포함되지 않는 것이 좋다. 그러나 ‘Vary: Accept-Encoding’ 헤더는 압축 여부에 대한 사항으로 포함되어도 영향이 없다.
ETag 사용 시 inode가 포함되면 서버 별로 속성값이 달라지므로 캐시 갱신 여부를 확인 시 Cache Refresh Miss로 Cache Hit률이 하락할 수 있다.
따라서, 원본 응답 시에 ETag를 제거하거나 inode 속성값을 포함하지 않는 것이 좋다.
