[CS] Web Proxy와 CDN(Content Delivery Network)

 

 

Web Proxy

 

필요성 : 웹 트래픽의 급격한 증가, Latency 증가, Web Accesser들의 불균형 -> 서버 및 네트워크 Load Hotspot이 생성됨

해결책 : Web Proxy Cache 사용 -> Latency, Server/Network Load 감소

 

웹 프록시 : 클라이언트와 서버 간의 트래픽을 중계하는 서버. 클라이언트는 웹 프록시를 경유하여 서버에 접근하고, 웹 프록시는 클라이언트의 요청에 대한 응답을 제공한다. 이 과정에서 웹 프록시는 중간에서 요청과 응답을 캐싱하여 빠른 응답을 제공할 수 있다.

 

 

 

Web Proxy의 Consistency

 

일관성 문제 : 웹페이지는 다양한 업데이트 빈도를 가지고 있음.

 

프록시 캐시의 일관성 유지 방법 : Send Invalidate/Update, Push based vs pull based

 

Push-bashed 접근

1. 서버는 객체를 요청한 모든 프록시를 추적, 수정된 경우 각 프록시에 Notify
2. Notification의 종류
   1. Invalidate(무효화) : 변경되었음을 나타냄
   2. Update(갱신) : 객체의 새 버전을 보냄
   3. 자주 요청되는 Object에 대해서는 Update를 보내고, 나머지는 Invalidate를 보낸다.
3. 장점 : 엄격한 일관성 제공 (프록시는 수동적)
4. 단점 : 서버가 Stateful 해야 함(참고로 HTTP는 stateless), Crash에 대한 복원 불가능

 

Pull-based 접근

1. 프록시가 일관성 유지를 전적으로 담당
2. 프록시가 주기적으로 서버를 Polling하여 변경점 확인
3. Polling은 Server에서 할당된 TTL에 일어남
4. Intelligent Polling : Refresh 간격을 동적으로 결정 가능
   1. 두 폴링 사이 간격에 객체가 변경되면 간격을 줄이고, 아니면 늘린다.
5. 장점 : 서버가 Stateless, Failure에 대한 복원력, HTTP를 사용한 구현
6. 단점 : Weak Consistency(폴링 간격 사이에 일관성이 깨짐), Message Overhead

 

Hybrid 접근 : Leases(임대)

1. Lease : 서버가 프록시에게 수정 사항을 알리는 데에 동의하는 기간
2. 첫 요청 시 Lease를 발행, 만료될 때 까지 Notification을 보냄
3. State + Message Exchange의 균형
   1. Lease = 0 : Polling
   2. Lease = 무한 : Push
4. Lease Duration -> 효율성 결정
5. Lease Duration의 결정
   1. Age-based : 객체의 예상 수명이 길어질수록 기간이 길어짐
   2. Renewal-Frequency based : 갱신이 빈번한 객체는 기간이 길어짐
   3. Server-load based:
      1. 서버 과부하 시 기간 단축

 

 

 

 

Cooperative Caching

 

캐싱 인프라에는 여러 웹 프록시가 있을 수 있음 프록시는 계층 구조 혹은 기타 구조를 가짐 프록시는 서로 협력 가능(클라이언트 요청에 응답, 서버 Notification의 전파)

 

 

 

---

 

CDN (Content Delivery Network)

 

1. 서버와 클라이언트 사이의 프록시의 모음 : CDN은 전 세계에 분산된 여러 프록시 서버로 구성된다. 이들 프록시 서버는 사용자에게 웹 콘텐츠를 빠르게 전송하고 성능을 최적화하는 역할
2. 가장 가까운 프록시가 클라이언트의 요청 처리 : 더 빠른 응답 시간과 콘텐츠 로딩 시간
3. 캐시 일관성을 유지해야 함 
4. 지리적으로 분산된 여러 사이트에 여러개의 Resource Copies를 저장/제공
5. Enter Deep : 사용자에게 가까운 지리에서의 접근 강조 (Akamai CDN)
6. Bring Home : 엑세스 네트워크 근처의 POP(Point of Presence)에서 대규모 클러스터를 구축하여 네트워크 근처에서 콘텐츠를 제공 (Limelight CDN)

단일 Mega Server의 한계 :SPoF, Network Bottleneck, 먼 거리, 여러개의 Resource Copy본을 전송, Scalable하지 못함.

 

 

CDN 클러스터 선택 전략

 

1. 지리적으로 가까운 CDN 노드 선택
2. Best 방법 : Latency가 짧은 노드 선택 -> CDN 노드가 Access ISP에 주기적으로 Ping을 보내고, CDN DNS에 보고
3. 현실적 대안 : 클라이언트가 결정 : 클라이언트가 서버에 Ping을 보내고 Best를 선택한다. -> Netflix Approach

 

 

 

---

CDN 사례

 

Akamai CDN

Akamai는 전 세계에 분산된 서버 네트워크를 보유한 CDN 기업

클라이언트에게 가장 가까운 서버를 사용하여 빠른 콘텐츠 전송을 지원

자체 DNS 서비스 운영 (<-> Public Root, TLD, 계층 구조)

 

 

Netflix

 

초기에는 No Infra, 3개의 타사 CDN을 이용하였다. -> 2012년부터 자체 CDN 개발하여 성능 향상

 

DASH : Dynamic adaptive Streaming over HTTP, 넷플릭스는 이를 이용하여 동영상 콘텐츠를 제공한다.

Dash의 Server와 클라이언트는 아래와 같이 동작한다.

1. Server
   1. 비디오를 여러 Chunks로 나눔, 각 청크는 다른 속도로 저장되고 인코딩됨
   2. Manifest File : Chunk에 대한 URL 제공
2. Client
   1. Server-Client Bandwidth를 주기적으로 측정
   2. 한 번에 하나의 Chunk 요청.
   3. 시간 Point에 따라(Bandwidth에 따라) 다른 Coding Rate를 선택 가능
   4. 클라이언트가 다음 사항들을 직접 결정
      1. Chunk의 요청 시점(Buffer Starvation/Overflow가 일어나지 않도록)
      2. Encoding Rate (더 많은 Bandwidth 사용 가능할 때 높은 품질의 Rate 사용)
      3. Where : 사용 가능한 대역폭이 높은 곳으로

 

Bandwidth 변화에 따른 적응(Adaptation)의 두 가지 방법

1. 새로운 CDN 서버에서 비디오를 가져옴
2. DASH를 통해 스트리밍 속도를 변경

 

 

Netflix의 자체 CDN은 이러한 동적적이고 효율적인 콘텐츠 전송을 지원하고, 높은 수준의 서비스 안정성과 품질을 제공한다.

 

 

 

 

 

 

 

---

Content / Image Reference 

 

Tannenbaum and Van Steen :: Distributed Systems: Principles and Paradigms (PDF)