CDN(콘텐츠 분배 네트워크)

1. 단일 원본 서버의 한계

애플리케이션 서버를 단일 데이터 센터(원본 서버)에서 운영할 경우, 다음과 같은 3가지 주요 한계점이 존재한다.

1. 네트워크 병목 및 지연 (Bottleneck & Latency)
   • 설명: 모든 전 세계 사용자의 요청이 단 하나의 물리적 위치로 집중된다.
   • 문제: 원본 서버와 사용자 간의 물리적 거리가 멀수록 응답 시간(RTT)은 필연적으로 증가한다. 또한, 서버가 처리할 수 있는 트래픽의 총량(Bandwidth)이 한계에 도달하면 병목 지점이 발생하여 서비스 전체가 느려진다.
2. 트래픽 비용 낭비 (Cost Inefficiency)
   • 설명: 인기 있는 콘텐츠(예: 고용량 이미지, JS/CSS 파일)가 요청될 때마다 원본 서버는 동일한 파일을 반복적으로 송신한다.
   • 문제: 대부분의 클라우드 환경에서는 서버에서 밖으로 나가는 트래픽(Egress Traffic)에 대해 과금한다. 이는 심각한 비용 낭비를 초래한다.
3. 단일 장애 지점 (SPOF, Single Point of Failure)
   • 설명: 서비스의 모든 기능이 단일 데이터 센터에 의존한다.
   • 문제: 해당 데이터 센터에 네트워크 장애, 정전, 또는 하드웨어 문제가 발생할 경우, 전체 서비스가 중단될 위험이 있다.

CDN은 이러한 문제들을 전 세계 다수의 거점에 캐시 서버(Edge Server)를 분산 배치하여 해결한다.

 

 

2. CDN의 핵심 아키텍처 전략

전략	Enter Deep (Akamai 방식)	Bring Home (Limelight 방식)
비유	동네 편의점	지역 거점 대형 마트
배치	수천~수만 개의 소규모 서버 클러스터를 ISP 네트워크망 깊숙이(엣지)에 배치	수십~수백 개의 대규모 서버 클러스터를 주요 인터넷 교환 지점(IXP)에 배치
장점	사용자에게 가장 가까워 지연 시간(Latency)이 최소화(최고의 성능)	서버 클러스터 수가 적어 유지보수 및 관리 비용이 효율적
단점	분산된 수많은 서버의 관리 비용이 매우 높음.	Enter Deep 방식에 비해 사용자로부터의 거리가 상대적으로 멀다.

 

 

3. CDN의 동작 원리

3.1. 요청 라우팅: DNS 기반 트래픽 분산

CDN은 DNS를 통해 사용자의 요청을 원본 서버가 아닌 최적의 캐시 서버로 유도한다.

1. DNS 조회: 사용자가 service.example.com에 접속을 시도.
2. 권한 위임 (CNAME): service.example.com의 DNS 설정은 해당 도메인의 IP 주소 조회를 CDN 사업자의 DNS 서버(예: cdn.provider.com)로 위임(CNAME 레코드).
3. 최적 서버 결정: CDN의 DNS 서버는 요청을 보낸 사용자의 IP 주소를 확인.
4. IP 반환: CDN DNS는 클러스터 선택 정책에 따라 사용자에게 "가장 최적인" CDN 캐시 서버(Edge Server)의 IP 주소를 반환.

 

3.2. 클러스터 선택 정책

CDN이 '최적의' 캐시 서버를 선택하는 기준은 다음과 같다.

• 지리적 근접성 (Geo-location): 사용자의 IP를 기준으로 물리적으로 가장 가까운 PoP(Point of Presence)에 위치한 서버를 선택. (가장 보편적인 방식)
• 부하 분산 (Load Balancing): 가장 가깝더라도 해당 서버의 CPU, 네트워크 부하가 높다면, 차순위의 서버를 선택.
• 네트워크 상태: 서버까지의 네트워크 경로 상태(지연 시간, 패킷 손실률)를 실시간으로 측정하여 결정.

 

3.3. 캐싱 전략: Pull vs. Push

• Pull 방식 (기본값):
  • 동작:
    1. 사용자가 엣지 서버에 특정 콘텐츠(예: image.jpg)를 요청.
    2. 엣지 서버에 해당 콘텐츠가 없으면(Cache MISS), 원본 서버(Origin)로 요청.
    3. 원본 서버로부터 콘텐츠를 가져와서(Pull) 사용자에게 전달함과 동시에 엣지 서버에 저장(캐싱).
  • 특징: 설정이 간편하며, 요청되는 콘텐츠만 캐싱하므로 효율적입니다. 대부분의 웹사이트 CDN이 이 방식을 사용합니다.
• Push 방식:
  • 동작: 서비스 관리자가 사용자의 요청이 있기 전에 특정 콘텐츠(예: 대용량 패치 파일, VOD)를 CDN 엣지 서버로 미리 밀어 넣는다(Push).
  • 특징: 첫 번째 사용자부터 지연 없이 캐시된 콘텐츠를 받을 수 있습니다. 하지만 미리 어떤 파일을 올릴지 관리해야 하는 부담이 존재.

 

4. 사례 연구: 넷플릭스 오픈 커넥트 (Netflix Open Connect)

넷플릭스는 일반적인 CDN을 사용하는 대신, 'Open Connect'라는 자체 CDN 프로그램을 운영한다. 이는 위에서 언급된 개념들을 영리하게 혼합한 하이브리드 전략을 사용한다.

 

4.1. 하이브리드 아키텍처

넷플릭스는 '최적의 서버'를 선택하기 위해 두 가지 전략을 동시에 사용한다.

1. [1순위] ISP 내장 캐시 (Enter Deep 방식):
   • 설명: 넷플릭스는 전 세계 주요 ISP(예: KT, SKT)와 파트너십을 맺고, 해당 ISP의 데이터 센터 내부에 자사의 캐시 서버 장비("CDN 서버 랙")를 무상으로 직접 설치. (이것이 "Open Connect Appliance" 이다.)
   • 효과: 해당 ISP 사용자는 외부망을 거칠 필요 없이, ISP 내부망에서 바로 넷플릭스 콘텐츠를 받아보므로 최고의 속도를 경험.
2. [2순위] IXP 연동 캐시 (Bring Home 방식):
   • 설명: 만약 사용자의 ISP에 Open Connect 장비가 없거나, 있더라도 찾는 콘텐츠가 없는 경우, 넷플릭스는 차선책을 사용.
   • 효과: 여러 ISP가 만나는 인터넷 교환 지점(IXP)에 위치한 넷플릭스 캐시 서버("IXP 서버")로 트래픽을 유도. 이는 1순위보다 느리지만, 원본 서버까지 가는 것보다는 훨씬 빠르다.

 

4.2. 예측 기반 푸시 캐싱(Push Caching)

대부분의 CDN이 Pull 방식을 사용하는 것과 달리, 넷플릭스는 Push 방식을 적극적으로 사용한다.

• 이유: 넷플릭스의 콘텐츠(영화, 드라마)는 사용자가 요청하기 전에 어떤 것이 인기를 끌지 예측하기 쉽다. (예: '오징어 게임' 신규 시즌 공개)
• 동작: 넷플릭스는 사용량이 적은 심야 시간을 이용해, 신규 인기 콘텐츠를 전 세계 ISP와 IXP에 배치된 "CDN 서버 랙"과 "IXP 서버"로 미리 밀어 넣는다(Push).
• 결과: 공식 출시 시간에 수백만 명의 사용자가 동시에 '재생'을 눌러도, 이미 가장 가까운 캐시 서버에 파일이 준비되어 있으므로 원본 서버의 과부하 없이 안정적인 스트리밍이 가능.