[CDN/공부일지] CDN이란?

CDN

만약 미국 리전에 있는 컨텐츠가 정말 너무 재밌어서 한국에도 유행하기 시작했다고 해보자. 우리가 정보를 요청할 때 데이터가 태평양을 건너올텐데 수만명이 그 컨텐츠를 요청하면 수만개의 요청이 느리게 바다 위를 건너갈 것이다.

만약 한국에 그 컨텐츠가 있었다면 정말 빠르게 받았을 지 모른다. 아래 그림을 살펴보자

비록 원본은 미국에 있다고 하더라도 한국에 캐시 서버가 있다면 어떨까?? 바로 그것을 CloudFront, CDN이라고 한다.

그 CDN이 있다면 한국의 캐시 서버에 그 컨텐츠를 보내놓고 수만개의 요청이 바다 위를 건너갈 필요없이 한국에 있는 캐시 서버에서 빠른 속도로 시청 가능할 것이다. 

 

Origin & Edge Location

이 때 데이터의 원본이 저장된 곳을 Origin이라고 하는데 위의 경우에는 미국 리전의 S3 버킷 등이 Origin이 될 것이다.

필요에 따라 EC2 서버나 외부 웹 서버도 Origin이 될 수 있다. 

또 위의 예시에서는 Origin에 있는 데이터를 한국의 캐시 서버에 저장한다! 라고 했는데 이때 그 데이터 센터를 Edge Location이라고 한다. 한국에서 미국에 있는 컨텐츠를 보고 싶으면 미국까지 건너갈 필요없이 가까운 Edge Location에서 데이터를 받아가면 된다.

 

Cache Hit & Miss

하지만 그 컨텐츠를 처음 한국에서 요청했다고 가정해보자 당연히 컨텐츠는 한국 Edge Location에 없고 Origin 쪽에 있을 것이다. 

이 때, 이 경우를 Cache Miss 라고 하고 Edge Location은 자기가 없는 파일을 Origin으로부터 가져오려고 할 것이다!(처음은 느림)

하지만 그 다음 요청부터는 자신에게 있는 파일이므로 Cache Hit 가 되어서 바로 사용자에게 전달할 수 있을 것이다. 

 

이렇듯 CloudFront를 쓴다면 속도 향상의 효과가 바로 있다. 뿐만 아니라 전송이기 때문에 HTTPS 인증서를 적용해 보안도 높일 수 있을 것이고 S3 버킷은 CDN으로만 데이터를 접근하도록 할 수 도 있다. S3의 길을 그렇게 강제하면 비용 절감의 효과까지 있다고 한다.

TTL

CDN의 Edge Location 은 처음에 소개할 때 "캐시 서버" 라고 했다. 즉 disk와 달리 file 영구적으로 존재하지는 않을텐데, 그래서 file을 Egde Location에 얼마나 오래 보관할 것인가를 결정해야한다. 이는 Time To Live, 캐시의 유통기한을 결정해줘야한다는 소리다.

이 설정 방식은 CloudFront 콘솔에서 직접 설정하고 Origin에서 파일마다 max-age=3600 같은 헤더를 붙여서 보내면 CDN이 그걸 보고 정하는 것이다.

 

TTL의 종류에는  

• Default TTL(기본) : cache-control 헤더를 안보내줬을 때의 기본값
• Minimum TTL(최소) : origin이 0초만 캐시하라고 해도 이 값이 60초면 무조건 60초만큼은 강제로 캐시함
• Maximum TTL(최대) : origin이 10년동안 캐시하라고 해도 이 값이 1년이면 1년을 넘기지 않는다.

TTL은 보통 파일마다 다르게 잡곤 한다. 

 

• 정적 파일 (이미지, JS, CSS): 변경이 거의 없으므로 길게 잡는 것이 유리! ex) 1 year
• 자주 변하는 데이터 (공지사항 JSON 등): 짧게 잡거나, 아예 캐시를 안 할 수도 있음 ex) 5 minutes

Cache Invalidation

파일을 수정했을 때 캐시를 강제로 지우는 방식이다. 만약 캐시 무효화가 제때 이뤄지지 않으면 사용자는 오래된 가격, 만료된 정책, 변경된 UI를 보지 못하거나 심하면 잘못된 결제 흐름을 경험한다. 자세한 원인이나 전략들은 아래 블로그를 참고하길 바란다.

 

https://www.devteam.co.kr/blog/caching/cache-invalidation-failure-solutions-cdn-caching-optimization-guide#:~:text=%EC%BA%90%EC%8B%9C%20%ED%82%A4%20%EB%B6%88%EC%9D%BC%EC%B9%98:%20%EC%BF%BC%EB%A6%AC%EC%8A%A4%ED%8A%B8%EB%A7%81%2C%20%ED%97%A4%EB%8D%94(Vary)%2C%20%EC%BF%A0%ED%82%A4%20%ED%8F%AC%ED%95%A8%20%EA%B7%9C%EC%B9%99%EC%9D%B4%20POP%EB%A7%88%EB%8B%A4&text=HTML%20Cache%2DControl%20%EC%A0%95%EC%B1%85%20%EC%9E%AC%EC%A0%95%EC%9D%98(s%2Dmaxage%2C%20stale%2Dwhile%2Drevalidate);

 

Cache Versioning

파일을 수정했을 때 대처할 수 있는 또 다른 방법으로 파일 이름 자체에 버전을 넣는 방식이다.

Invalidation과 다르게 무료인 장점도 있고 새로운 이름의 파일이므로 즉시 반영된다. 또 문제가 생기면 HTML에서 이름만 이전 버전으로 돌리면 되므로 롤백이 쉽다!!

 

 

S3 + CloudFront 권장 구조

위에서 말했던 S3 버킷은 CDN으로만 데이터를 접근하도록 할 수도 있다 방식을 안쓰고 Public으로 배포해서 한다면 전 세계 어디서 이 S3를 접속하든 서울 리전까지 와야한다.

하지만 S3 버킷을 private로 잠그고 CDN을 앞에 붙여서 거기로만 통하게 한다면 S3 버킷 이름도 노출이 안되니 보안 효과와 성능 향상까지 받게 되고 확장성까지 커지게 된다.

Regional Edge Caches (중간 물류 센터) 

엣지 로케이션에 데이터가 없을 때 바로 오리진(미국 S3)까지 가는 게 아니라, 해당 지역(예: 아시아 전체)을 담당하는 거대한 중간 캐시 서버

 

이러한 방식을 OAC(Origin Access Control)이라고 하며 private로 잠그면 원래 아무것도 못들어가지만 CDN만은 들여보내주겠다고 약속을 하는 장치이기도 하다.