🐢꾸준함의 미학

CDN에 관한 고찰

26 min read

모던 웹에서 레이턴시는 서비스의 사용자 경험에 크게 영향을 줄 수 있는 요소이다.

latency 시스템에서 특정 요청이나 이벤트가 처리되기까지 걸리는 지연 시간

이러한 레이턴시의 중요성은 데이터를 통해 입증되었다.

  • 1초안에 로드되는 페이지는 5초 걸리는 페이지보다 3배 더 큰 전환율을 보임
  • 이커머스의 전환율은 로드 시간이 1초씩 늘어날 때마다 0.3%씩 날아감
  • 상품 구매를 최대화하는 최적 로딩 시간은 2초 이내

전환율(conversion rate) 웹사이트나 앱 방문자 중 특정 행동을 완료한 비율을 나타내는 마케팅 지표

그런만큼, 정말 지리적으로 멀리 떨어져 있는 원 서버들은 매번 원 서버를 통해 콘텐츠를 보내게 되면 지리적인 거리때문에라도 더 늦게 로드된다. 아무리 네트워크가 이동하는 속도가 빛의 속도라고 해도 빛의 속도라고 말하면 빨라 보이지, 미국이랑 한국이랑 왔다갔다 하는 데는 많은 시간이 걸린다. 이럴 때, 지리적으로 분산된 서버들을 두고 해당 서버를 통해서 콘텐츠를 갖다주는 것이 바로 CDN(Content Delivery Network)이다.

유저가 CDN을 사용하는 웹사이트나 애플리케이션에 대해서 요청을 보내게 되면, 그 요청은 가장 가까운 CDN 서버로 리다이렉팅된다. 지리적으로 가까운 CDN 서버를 통해 정적인 콘텐츠를 바로 건네주면서 데이터가 오고가는 레이턴시를 줄일 수 있으며, 이는 곧 전체적인 성능 향상에 기여한다.

ATM을 생각하면 편하다. 매번 먼 은행에 가는 것보다는 근처 ATM가서 딸깍! 만 하면 돈이 뚝딱! 나온다.

CDN과 관련된 솔루션들은 2028년에는 거의 $38B에 육박할 것이라고 예상된다. Akamai, Cloudflare, Amazon CloudFront와 같은 것들이 이 시장의 거물들로 더 향상된 CDN 성능을 제공하기 위해 많은 투자를 하고 있다.

어떻게 작동할까?

처음에 브라우저에 google.com을 치면 일어나는 일에 대해서 생각해보자 브라우저의 네트워크 프로세스는 새로운 주소를 입력하면 다른 url로 네트워크 요청을 보내게 되는데, 가장먼저 일어나는 것은 DNS 캐시를 살펴본다. 브라우저 내부 DNS -> OS의 DNS -> OS의 hosts에 설정해놓은 DNS -> 로컬 DNS 프록시 서버 -> ISP(인터넷 서비스 제공자)의 DNS 서버 요청 -> 루트 DNS -> 권한 DNS 순서대로 살펴본다.

DNS 탐색 과정

DNS 서버를 통해 도메인에 대한 정보를 받았다면, 이후에는 DNS Resolver를 통해서 이름을 IP주소로 변환한다. Resolver는 DNS 서버에 조회 메시지를 보내며 거기에 반송되는 응답 메시지를 클라이언트(DNS 서버에 대한)에게 전달한다.

DNS Resolver는 세 가지 네임 서버를 순차적으로 돌면서 최종 IP 주소를 가지게 된다. 각 네임 서버는

  • 루트 네임서버
    • DNS 서버의 최상위 네임 서버로 DNS 해석부터 발생한 DNS 요청에 대하여 적절한 TLD 네임서버 정보를 반환
  • TLD(Top Level Domain) 네임 서버
    • .com, .net 또는 URL의 마지막 점 뒤에 오는 것 같은 일반적인 도메인 확장자를 공유하는 모든 도메인 이름의 정보를 유지
    • 루트 네임서버로부터 응답을 받고 권한 있는 네임서버를 지정하여 반환
  • 권한 있는 네임서버(Authoritative NS)
    • 일반적으로 IP 주소를 확인하는 확인자의 마지막 단계이며 도메인 이름에 고유한 정보를 포함하여 DNS 서버에 Response를 넘김 와 같이 동작한다.

여기서 CDN은 가장 마지막인 권한 있는 네임서버에서부터 CDN의 도메인 주소가 붙어있는 계층에서부터 관리를 하게 되는데, 이 내용은 후술한다.

CDN이 필요한 결정적인 이유

CDN이 필요한 이유는 그저 지리적으로 가까운 곳에서 컨텐츠를 받음으로써 레이턴시를 줄이는 것 뿐만 아니라 여러 가지가 있다.

  • 성능 향상
  • 가용성을 높일 수 있음
    • 일부 서버에서 장애가 일어나도 다른 cdn으로 옮겨 요청하면 되므로 장애 대응이 용이
  • 대역폭 비용 감소
    • 엣지 서버의 콘텐츠를 캐싱함으로써 매번 원 서버에서 가져와야 할 많은 양의 데이터 송신을 줄일 수 있음 → 컨텐츠 제공자의 대역폭 비용 감소
  • 확장성
    • CDN은 필요할 경우 스케일을 줄이거나 늘릴 수 있기 때문에 급증하는 트래픽에 대해 유연하게 대응 가능

CDN 자체의 동작 원리

유저가 네트워크 요청을 보낼 때부터 한 단계씩 알아보자.

  1. DNS Resolution
    • 유저가 CDN으로 서빙되는 웹사이트나 애플리케이션에 요청을 보내면 사용자의 디바이스는 DNS 쿼리를 IP 주소로 변환한다. CDN의 DNS 시스템은 쿼리를 다루면서 분산되어 있는 서버(edge server)들 중 지리적 거리나 서버 로드 등을 고려하여 최적의 서버를 결정해줌
  2. 라우팅 요청
    • 1번이 끝나면, 유저의 디바이스는 최적 엣지 서버의 IP 주소를 보냄
  3. Cache Lookup
    • 엣지 서버는 요청을 받고 요청된 컨텐츠에 대해서 로컬 캐시를 확인함
    • cache hit && 유효한 캐시(TTL이 아직 유효한 경우)일 경우 엣지 서버는 유저에게 캐시를 바로 보냄
  4. Origin Fetch
    • Cache Miss || 캐시 콘텐츠가 만료되었다면 엣지 서버는 원 서버에 요청을 보내 콘텐츠를 다시 받아옴
  5. Caching and Delivery
    • 엣지 서버가 원 서버로부터 콘텐츠를 받으면 복사하여 로컬 캐시로 두고 사용자에게 콘텐츠를 보냄
    • 콘텐츠에 TTL(Time-To-Live) 값을 부여
  6. Optimization and Security
    • 콘텐츠 전송 프로세스를 통해 CDN은 다양한 최적화와 콘텐츠 보호를 위한 보안 측정 수행
    • 압축, 축소, SSL/TLS 암호화, DDOS Mitigation

DDOS Mitigation (DDOS 완화) 릴레이 네트워크를 보호하여 네트워크에 대한 분산 서비스 거부 공격(DDOS)의 영향에 대해서 완화하기 위한 네트워크 관리 기술 및 도구

트래픽 패턴을 분석하여 네트워크 트래픽에 대한 기준 조건을 세우고, 여기서 IP 주소, 쿠키 변형, HTTP 헤더 및 브라우저 지문을 포함하여 트래픽의 다양한 속성을 검사한 뒤 필터링함으로써 완화한다.

CDN 아키텍처와 컴포넌트

전형적인 CDN 아키텍처는 몇몇 키 컴포넌트로 구성되어 있다.

  • Origin Server
  • CDN Edge Servers
  • Domain Name System(DNS)
  • CDN Control Plane
  • Monitoring and Analytics

각각의 요소에 대해 알아보자.

Origin Server(원 서버)

  • 원 서버는 CDN이 분산하는 콘텐츠의 주 소스이다.
  • 인증된 버전의 콘텐츠를 호스팅해주고 CDN이 접근하려는 콘텐츠가 가장 최근 버전임을 보장하는 서버이다.
  • 물리 서버일 수도 있고, 서버들의 클러스터일 수도 있으며, 클라우드 기반 서비스일 수도 있다.
  • 유저가 더이상 CDN 엣지 서버에서 이용불가능한 콘텐츠에 접근하려고 하면 원 서버로 요청을 보내고 이걸 캐시해서 서빙한다.

CDN Edge Servers

  • CDN 인프라의 백본으로 PoPs(Points of Presence)로도 알려져 있다.

Pops(Points of Presence) 인터넷 사용자가 인터넷 서비스 제공자를 만나는 곳. 즉, 상호접속지점(수신 지점)

백본(Backbone) 컴퓨터 네트워크 인프라의 일부로 서로 다른 네트워크를 서로 연결하고 서로 다른 네트워크 간에 데이터를 교환할 수 있는 경로를 제공해주는 네트워크

서버들은 전략적으로 세계 각 곳의 데이터 센터들에 포진되어 있으며 다른 지리적 지역들의 유저들이 효율적으로 콘텐츠를 받을 수 있도록 해줌

캐시한 콘텐츠를 사용자에게 서빙하는 것이 가장 주요 역할. 사용자가 콘텐츠에 대해서 요청을 받으면 가장 가까운 엣지 서버로 라우팅되고 그쪽 엣지 서버의 캐시에서 콘텐츠를 가져옴

  • 로드밸런싱 : 여러 개의 서버로 요청 분산 관리
  • 콘텐츠 최적화 : 로드 타임을 줄이기 위한 압축, 최소화, 콘텐츠 최적화 등
  • 보안 : DDOS 완화, SSL/TLS 암호화, WAF(Web Application Firewall)

웹방화벽 (Web Application Firewall, WAF) 웹 애플리케이션 보안에 특화되어 개발된 방화벽 SQL Injection, XSS과 같은 웹 공격을 탐지하고 차단

CDN Control Plane

CDN Control plane은 CDN의 운영을 관리하는 중앙 관리 및 제어 시스템이다.

엣지 서버들을 관리하고 모니터링하며 CDN 운영이 효과적으로 관리되고 있도록 한다. 컨트롤 플레인은

  • 콘텐츠 분산 및 캐싱 정책 관리
  • 실시간 성능과 트래픽을 모니터링하고 분석
  • 엣지 서버 설정
  • 기타 장애가 일어나는 문제들 해결
  • 보고 및 분석

등의 기능을 수행한다.

CDN Request Routing

CDN에서 요청을 라우팅할 때 쓰는 중요 개념이 있다.

Global Server Load Balancing(GSLB)

GSLB는 CDN 제공자들이 들어오는 트래픽을 세계 여러 곳에 분산된 서버나 데이터 센터에 분산시켜 놓는 기술이다. 이를 위해서는 요청에 대해 가장 최고의 성능과 가용성을 낼 수 있는 서버로 갈 수 있도록 해야하는데, 이 과정에서 지리적 위치, 서버 로드, 네트워크 상태 등을 고려한다.

GSLB 시스템은 보통 CDN의 전체 DNS 인프라에 통합되어 있으며 기본적인 DNS 계층 구조와 함께 작동한다. 이 기본적인 DNS 계층 구조는 위에서 설명하였듯이 루트 DNS 서버, TLD 서버, 권한 있는 네임 서버 로 이루어진 계층구조이다.

DNS 설정에 따라 GSLB는 가장 마지막인 권한 있는 네임 서버의 레벨에서 작동한다. 그렇다면 다시 사용자의 디바이스에서 네트워크 요청을 보내는 과정을 다시 생각해보자

  1. 유저의 디바이스가 도메인 이름을 DNS 쿼리를 보내 도메인 이름을 IP 주소로 변환함
  2. 쿼리는 주로 인터넷 제공자(ISP)에게 받은 로컬 DNS 리졸버로 감
  3. 로컬 DNS 리졸버가 캐시된 IP 주소가 없다면 루트 DNS 서버에 쿼리를 보내 재귀적으로 DNS 변환
  4. 루트 DNS가 관련된 TLD DNS 서버와 함께 IP 주소를 응답
  5. TLD DNS 서버는 도메인의 권한 있는 DNS의 IP 주소를 응답
  6. CDN 설정에서 권한 있는 DNS 서버는 CDN 제공자에 의해 관리되고 GSLB 시스템으로 통합됨
  7. GSLB가 DNS 쿼리를 받으면 유저의 지리적 위치, 서버 로드, 네트워크 상태 등을 분석하여 가장 최적의 CDN 엣지 서버를 찾아내고 로컬 DNS 리졸버에게 IP 주소를 반환
  8. DNS 리졸버가 유저의 디바이스로 IP주소를 보내면 이 IP 주소(엣지 서버의 IP 주소)로 요청을 보냄 의 순서로 이루어지는 것이다.

Anycast DNS

Anycast(애니캐스트)는 하나의 IP 주소가 여러 개의 서버(노드)에 할당되어 있고, 네트워크는 가장 가까운(최적의) 서버로 트래픽을 라우팅해주는 통신 방식이다.

CDN에서의 Anycast는 주로 들어오는 트래픽을 처리하기 위해 요청을 받을 수 있는 가장 가까운 테이터 센터로 라우팅시킨다.

이를 통해 어떻게 작동하냐면,

  • CDN 제공자가 다른 여러개의 엣지 서버에게 같은 IP주소 할당
  • 유저의 디바이스가 IP주소로 변환하기 위해 DNS 쿼리를 보내면 쿼리는 DNS 라우팅 프로토콜을 사용한 DNS 쿼리 서버로 라우팅됨
  • DNS 서버는 여러 엣지 서버가 공유하고 있는 IP주소를 보내줌
  • 요청은 네트워크 토폴로지와 라우팅 프로토콜에 기반하여 자동으로 가장 가까운 엣지 서버로 보내줌

이렇게 트래픽이 몰릴 때에도 결국 이 트래픽을 하나의 IP주소로 보내면서 CDN이 이러한 요청을 분산시켜주다보니 DDOS 공격 예방에도 효과적이다.

IXP의 역할

IXP(Internet Exchange Points)는 인터넷 회사들(ISP, 클라우드 사업자, CDN 제공자 등)이 서로 직접 데이터를 주고받는 장소이다. 즉, 여러 네트워크가 상호 접속하기 위해 모여 있는 중립적인 물리적 장소이다.

IXP가 없으면 서로 다른 ISP 간의 트래픽이 중간 네트워크를 거쳐가 갈 수 있고, 그 과정에서 Tromboning이라는 비효율적인 현상이 발생할 수 있다.

Tromboning 인터넷 트래픽이 같은 도시 안에서 이동해야 하는데, 중간 네트워크를 거치느라 멀리 있는 다른 도시(또는 대륙)까지 갔다가 다시 돌아오는 현상

그렇게 되면 정작 CDN을 쓴다 해도 CDN의 이점을 누리지 못하는 상황이 되는 것이다. 이를 위해 CDN 제공자들은 접근과 연결성을 향상시키기 위한 IXP를 구축한다.

IXP는 CDN으로 들어오는 트래픽이 다른 ISP와 네트워크들이 바로바로 주고받으 수 있게끔 해주면서 CDN과 종단 유저간의 왕복 시간을 줄인다.

CDN 성능 최적화

CDN 성능을 최적화시키는 것은 전 세계로 제공하는 콘텐츠 제공 속도에 큰 영향을 끼치기 때문에 중요 고려사항이다. CDN의 성능을 최적화 하기 위해서 아래와 같은 방법들을 시행한다.

캐싱 최적화

  • 캐시 히트율을 높이기 위한 캐싱 전략을 수립하여 원 서버에서 가져오는 콘텐츠 페칭 최소화
  • 업데이트 빈도와 중요도를 고려하여 적절한 TTL값을 설정
  • cache-control 헤더 사용하여 유효기간, 만료기간 등을 설정
  • 필요한 경우에는 캐시에 있는 콘텐츠 무효화 메커니즘

콘텐츠 최적화

  • 텍스트 기반 정적 파일들(HTML, CSS, JS) 압축 및 최소화하여 사이즈를 줄이도 로드 시간 향상
  • 적절한 포맷으로 이미지 압축(JPEG, PNG, WebP) + 디바이스에 따라 반응형 이미지 제공
  • 중요하지 않은 요소들에 대해 필요한 경우 지연 로딩(lazy loading)
  • 유저들이 요청할 것 같은 콘텐츠에 대해 pre-fetching, pre-rendering

pre-rendering HTML을 미리 생성 해두고 사용자가 요청하면 즉시 그 HTML을 제공

네트워크 최적화

  • Anycast Routing을 구현하여 유저 요청을 자동으로 가까운 CDN 서버로 라우팅 되도록 설정
  • DNS 로드 밸런싱 기술을 사용하여 여러 개의 CDN 서버에 트래픽 분산 및 최적 서버 선택 보장
  • TCP/IP 설정을 최적화(TCP Fast Open, TCP 컨트롤 알고리즘)하여 네트워크 성능을 향상.
  • HTTP/2, HTTP/3 프로토콜을 구현하여 멀티플렉시, 헤더 압축, 서버 푸시 등을 사용하면서 성능 향상

보안 최적화

  • SSL/TLS 암호화를 구현하여 유저와 CDN 간 민감 데이터와 개인정보를 보호
  • DDoS 공격을 분산시켜 방어하는 메커니즘
  • WAF(Web Application Firewall)을 구현하여 웹 취약성과 위험 예방
  • CDN 서버에 대해 주기적인 업데이트와 패치고 보안적 취약성 보완 및 보안 인프라 유지보수

CDN이 동적 콘텐츠를 전달할 수 있을까?

실시간 기반으로 개인화된 콘텐츠나 유저 인터랙션, 데이터베이스 쿼리 등에 의해 바로바로 업데이트되는 동적 콘텐츠의 경우에는 기존의 정적 콘텐츠를 캐싱해서 보내는 방식과는 조금 다르다.

CDN은 동적 컨텐츠 전달을 위해 다양한 방식의 기술을 사용한다

  • 동적 콘텐츠 캐싱
    • 동적 컨텐츠를 ‘Cache-Control’이나 ‘Expires’와 같은 헤더를 통해 캐싱
  • Edge-Side Includes(ESI)
    • ESI는 동적 콘텐츠가 각 분산되어있는 엣지 서버들의 캐시된 정적 요소들을 합치는 혁할을 한다. 모든 요소들을 합치는 것이 아닌, HTML 페이지 일부를 <esi:include> 태그로 넣은 다음에 동적으로 CDN이 조립할 수 있도록 해줌
  • 서버리스 컴퓨팅
    • 몇몇 CDN들은 서버리스를 지원하여 동적 콘텐츠 생성과 엣지서버에서 실행할 수 있도록 해줌.
    • Cloudflare의 Worker와 같은 기능을 통해서 엣지 서버에서도 서버리스 함수를 실행할 수 있다.

넷플릭스의 CDN 전략

넷플릭스는 이러한 CDN을 이용하여 스케일링을 잘 하는 대표적인 기업이다. 넷플릭스는 2009년 서드 파티 CDN을 사용했지만 2012년에 자기들만의 CDN을 만들어 네트워크 효율성과 사용자 경험을 샹상시켰는데, 그 CDN이 Open Connect이다.

이러한 Open Connect의 특성은 아래와 같다.

  • ‘Open Connect Appliance(OCA)‘라고 불리는 전용 서버 장비를 인터넷 서비스 제공업체(ISP)의 네트워크나 인터넷 교환 지점(IXP)에 배치함으로써 사용자에게 더 가까운 위치에서 콘텐츠를 전달할 수 있어서 데이터 이동 거리를 줄임
  • OCA는 넷플릭스 콘텐츠를 효율적으로 저장하고 전송하도록 설계되어 있으며, 대용량 저장소와 영상 스트리밍에 최적화된 소프트웨어 스택을 갖추고 있습니다.
  • 넷플릭스는 하나의 콘텐츠를 여러 비트레이트와 형식으로 미리 인코딩해둠으로써 네트워크 속도나 사용자 기기에 따라 적절한 화질로 제공할 수 있습니다.
  • 인코딩된 콘텐츠는 지역 수요, 인기도 등을 기준으로 각 OCA에 분산 저장되어 있기 때문에 자주 요청되는 콘텐츠는 미리 캐시에 저장되어 있습니다.
  • 사용자가 넷플릭스 콘텐츠를 요청하면, 가장 가까운 OCA로 요청 → 만약 요청한 콘텐츠가 OCA 캐시에 있다면, OCA는 즉시 스트리밍을 시작 → 이때, 네트워크 대역폭 등 상황에 따라 실시간으로 비트레이트와 화질이 조절

그래프 뷰

백링크