[Network] CDN(Content Delivery Network)

개요

---

Valkey 발표 및 전환을 앞두고..! 이번 스프린트에서 드디어 CloudFront Datadog Alert 작업을 시작하게 되었다. 윈터테크 인턴 시절 CloudFront 리소스에서 Additional Metrics가 비활성화된 점을 발견하고, 프로덕션 환경에 한해 이를 활성화하여 모니터링을 강화하자는 제안을 했으며 팀에서 이를 받아들여 적용하였다.

 

그러나 Additional Metrics 활성화 이후 기존 CloudFront Datadog Alert의 정확도가 떨어지는 문제가 발생했다. 이번 스프린트에서는 이 문제를 개선하여 Alert 정확도를 높이고, CDN 모니터링을 체계적으로 강화하는 것을 목표로 한다. 이번 포스팅으로 CDN에 대해 잘 정리해보겠다!

 

1. CDN 기본 구조와 목적

---

CDN은 정적/동적 컨텐츠(HTML, CSS, JS, 이미지, 동영상)을 전 세계에 분산 배치된 Edge 서버에서 제공하는 시스템이다. CDN이 점점 발전하면서 단순 캐싱 이외에도 DDoS 방어, WAF, 동적 라우팅 등등의 기능을 제공하게 되었다. 이 포스팅은 이러한 CDN의 근본적인 내용을 학습하고 정리하는 목적으로 작성한다!

• 사용자와 가까운 위치에서 응답해서 Latency를 줄인다.
• Origin(원본) 서버의 부하를 낮춘다.
• CDN은 전 세계 Edge Location에 분산되어 있기 때문에, Origin Server보다 더 많은 트래픽을 처리할 수 있다.
• 네트워크 트래픽 비용을 절감시킨다.

 

2. Why CDN?

---

2.1 클라이언트 <-> 서버 Latency 해소

이미지와 같이 Client와 Server 간 지리적 위치가 차이나면, 단순히 요청이 한번 왔다갔다 하는 데에도 많은 응답 시간이 걸린다. 이에 CSS와 같이 바뀌지 않는 정적 파일에 대해 Edge Location Server에 저장(캐싱)하여 빠르게 전송하는 방식을 고안하였고, 그게 CDN이다.

• 현재는 정적 파일 뿐만 아니라 Cache-Control 헤더를 활용하여 API 응답과 같은 동적인 부분도 캐싱한다.

2.2 HTTP/1.1의 도메인 연결 제한

또한 HTTP/1.1 시절, 브라우저는 도메인당 동시 연결 수를 제한했다. (HTTP Connetion Management Guide From MDN)

As a solution, browsers open several connections to each domain, sending parallel requests. Default was once 2 to 3 connections, but this has now increased to a more common use of 6 parallel connections. There is a risk of triggering DoS protection on the server side if attempting more than this number.

 

브라우저가 하나의 도메인에 동시에 열 수 있는 TCP 연결이 최대 6개로 제한된다는 뜻이다. 7번째 패킷은 앞의 1~6 번째 패킷의 통신이 끝날 때까지 대기해야 하므로, 응답 성능이 좋지 않다.

  <!-- 모두 example.com → 총 6개 연결만 사용 -->
  example.com/logo.png     [연결 1]
  example.com/banner.jpg   [연결 2]
  example.com/icon1.png    [연결 3]
  example.com/icon2.png    [연결 4]
  example.com/style.css    [연결 5]
  example.com/script.js    [연결 6]
  example.com/footer.png   [대기...]  <!-- 7번째는 대기 -->

 

(참고) HTTP/2.x로 업그레이드되면서 이 점은 해소되었다. 2015년에 IETF에서 RFC 7540으로 공식 발표되었고, 현재 대부분의 브라우저와 서버가 지원하고 있다. 아래는 필자의 깃허브 페이지에 접속했을 때 주고받는 프로토콜이 대부분 h2(HTTP/2)로 설정되어있음을 확인할 수 있다.

 

3. CDN Architecture

---

CDN은 전 세계에 Edge Server를 두고 Origin Server의 콘텐츠를 캐싱한다. 사용자 요청이 들어오면 가까운 Edge에서 빠르게 캐싱된 내용을 응답으로 제공한다.

 

• Last Mile: 지역 ISP로부터 일반 사용자에게 콘텐츠가 전달되는 구간
• Middle Mile: Edge Server들과 ISP 사이 구간
• First Mile: Origin Server와 ISP 사이 구간

3.1 Edge Server와 PoP(Point of Presence)

각 PoP는 CDN의 물리적 위치를 나타낸다. 하나의 PoP는 여러 대의 Edge Server로 구성된다. 사용자의 요청은 가장 가까운 PoP로 라우팅 된 뒤, 그중 내부 Edge Server 하나가 응답을 한다.

- 서울 PoP(ICN)
- 도쿄 PoP(NRT)
- 싱가폴 PoP (SIN)
- 샌프란시스코 PoP(SFO)

3.2 Origin Shield

Origin Shield는 Origin Server 바로 앞단에 위치한 캐시 계층이다. 모든 CDN Edge 요청을 단일 지점으로 모은다. 

• Shiled가 없을 때
  • 100개의 Edge Server Cache Miss로 인한 -> Origin 동시 요청
    • 같은 콘텐츠를 동시에 100번 요청으로 Origin 부하가 폭증한다.
• Shiled가 있을 때
  • Origin Shiled가 100개의 Edge Server 요청을 모아서 한 번에 Origin에 요청
    • Shiled가 대표로 1번만 요청하고 나머지 99개는 Shield에서 대기한다.

4. CDN과 DNS

CDN은 DNS를 시작점으로 사용한다.

1. 사용자가 cdn.example.com 요청
2. DNS 서버가 해당 도메인의 위치를 CDN 서비스에 알려줌
3. CDN은 Location PoP의 Edge Server에 캐싱된 내용 요청

CloudFront 예시를 통해 알아보자.

AWS CloudFront를 통해 Origin에 대한 CDN을 설정하면, Alternate Domain Name (CNAME) & Custom SSL Certificate 또한 입력 및 생성된다. CloudFront를 생성하면 기본 도메인이 xxxxx.cloudfront.net 이런 도메인이 생성되는데, 이는 사용자가 기억하기 어려운 도메인이다.

 

그래서 CF 자신의 도메인(xxxxx.cloudfront.net)을 R53에서 생성된 도메인과 CNAME으로 연결한다. 

AWS CloudFront 생성 화면

 

하위 Tenant 화면이긴 하지만.. 하나의 Distribution에 Domain 설정과 ACM 설정이 되어있는 걸 확인할 수 있다.

5. CDN Cache 정책

5.1 TTL(Time To Live) 설정

TTL은 패킷이 네트워크 내부에서 존재하도록 설정된 기간이다. 인터넷 환경에서 목적없이 라우터 <-> 라우터간 무한정으로 떠도는 유령 패킷을 방지하기 위해 설계되었다. 

CDN은 이 TTL을 사용하여 Origin 업데이트 사안을 가져오기 전에 캐싱된 콘텐츠를 얼마나 유지할 것인지 결정한다.

 

TTL 값이 너무 길면, Origin과 Edge의 콘텐츠 내용이 차이가 날 수 있다. 반면 TTL 값이 너무 짧으면 Edge Server에 캐싱하는 게 무의미할 수 있기에 잘 설정해야 한다.

 

이러한 TTL 설정은 보통 Cache-Control 헤더에서 확인할 수 있다.

헛 cloudflare의 blog의 js 파일을 열었을 때의 Cache-Control 헤더;;  31536000이면 1년 설정이다.

 

보통 이렇게 설정하는 건 파일 이름에 해시값이 들어간다. 내용이 바뀌고 빌드가 되면, 파일명도 바뀐다. 사용자는 새로운 파일명을 로드하므로, 캐시와 상관없이 최신 파일을 받는다. 뭔가 업데이트가 드문 리소스의 경우에는 TTL 설정을 길게 잡고, Origin에 요청이 많이 가지 않도록 한다. 

5.2 Cache-Control Header

브라우저에서 오고가는 패킷을 살펴보면 위와 같은데, Cache-Control에 다양한 옵션들이 보인다.

 

• public: CDN이 자유롭게 캐싱해도 문제 없는 공개 자원으로, 응답을 모든 캐시(브라우저 & CDN/Proxy)에 저장 가능
• private: 오직 개인 캐시(브라우저)에만 저장 가능하고, 공유 캐시(CDN/Proxy)에는 저장 불가능
• max-age: Origin에서 브라우저와 Edge Server에 얼마나 캐싱할 건지 유효시간(TTL) 설정한 값
  • age: CDN POP에 캐싱된 시간(CDN POP에서 자동으로 등록하는 것)
• s-maxage: 공유 캐시(CDN/Proxy)에만 적용되는 캐시 유효 시간
• no-cache: 캐시에 저장은 가능하지만, 사용 전에 항상 Origin Server에 검증
• no-store: 아예 저장 자체 금지!
• must-revalidate: TTL이 지난 후, 반드시 Origin Server 검증 필요
• immutable: 바뀌지 않는값이니, 캐시된 걸 그대로 써라는 뜻
• stale-while-revalidate, stale-if-error: 만료 후에도 일정 시간은 캐시를 그대로 사용(옛 캐시 보여줌)

 

CDN에 대한 기본적인 내용을 정리해보았다. TLS를 CDN에 설정하면 어떻게 될까?. Dynamic/Static CDN 등등 더 공부해야할 내용이 많은데.. 심화 버전으로 찾아와보도록 하겠음