728x90
CDN(Contents Delivery Network)
- 이미지 동영상 같은 IP 기반의 컨텐츠를 전송
CDN이 태어난 이유
- 땅이 넓어서 (Ex. 미국). 사용자에 가까운 쪽에 시스템 구축해서 전송할 수 있게
- 국내의 경우는 ISP 연동망의 영향을 최소화하기 위해
CDN 서비스 이용 고객
- 이미지 서비스 이용 고객
- 동영상 라이브 서비스 이용 고객
- 게임 파일 배포
- 네비게이션 파일 맵 정기 업데이트
POP
- 주요 도시의 CDN 서비스에 필요한 서버
IX(Internet Exchange)
- ISP 사업자 (KT, SK 브로드밴드, LG 유플러스) 간 맞물리는 구간
- 과거에는 각각 ISP 간의 이해 관계 때문에 투자 차이에 의해서 ISP 간의 접점 부근에 품질 이슈가 발생했음
국내 CDN 서비스 초기
- CDN 사업자가 ISP의 CDN 서비스 각각의 IDC POP 운영
- 각 ISP 별로 CDN 운영 (토폴로지 구성) - 현재는 네오텍만 이 형태로 운영
Big Traffic
- 자체적으로 서버를 운영하면서 트래픽을 소화하기에는 어려운 대규모 서비스를 위해서 CDN을 이용
대규모 CDN 서비스를 처리하기 위해서는 각각 CDN 서버들을 그룹으로 묶고 POP 운영 - GSLB를 통해서 각각의 서버와 POP 간의 로드밸런싱
CDN을 왜 쓰는지 요약
- 대규모의 트래픽을 보다 빠르고 안정적이게 처리, 비용 절감
CDN의 기본 원리
CDN
- CDN = DNS + HTTP + Cache
CDN 기본 구조
- 사용자(End User)가 웹사이트의 이미지를 보려고 할 때
- CDN 서버에 HTTP 요청
- CDN 서버는 Origin 서버(웹 서버 - 이미지 원본 서버) HTTP 요청
Cache
- 엑세스하는 데이터나 프로그램 명령을 반복해서 검색하지 않고도 즉각 사용할 수 있도록 저장하는 영역
CDN에서의 Cache
- Cache Miss
- CDN 서버에서 Cache가 되어 있지 않고, 또다른 원본 서버로 요청
- Cache Hit
- CDN 서버에서 이미 저장되어 있는 상태
- 원본 서버를 거치지 않아서 시간 절약
CDN POP
- 여러 대의 서버의 하나의 IDC에 그룹으로 묶어서 서비스
Multi-POP
- 하나의 IDC에 POP을 운영하는게 아니라, CDN 서비스를 위해서는 이중화 삼중화(특정 IDC의 가능 불능 상황 방지)
- First Mile - Origin 서버와 CDN 서버가 있는 구간 (Origin - CDN)
- Middle Mile - IX 구간 (CDN - CDN)
- Last Mile - CDN Edge 서버에서 End User 간 구간 (CDN Edge - User)
CDN 서비스 품질 보장 구간
DNS Flow
- CDN 서비스를 위해서는 CDN에서 제공하는 도메인을 CNAME 처리 해야함
- CNAME 처리 (CDN에서 제공하는 LB로 가세요)
일반적인 DNS WorkFlow에서 CDN 서비스 하기 위해서는 CDN에서 제공하는 DNS의 CNAME 처리 (CDN 쪽으로 LB 요청을 바꿔주세요)
- 사용자가 Local DNS(LDNS) 통해서 DNS 요청 (컨텐츠 요청) - CDN에서 제공하는 LB로 바꿔주세요
- LDNS가 CDN 쪽에서 제공하는 LB로 물어봄 (컨텐츠 어디있나요)
- GSLB 쪽은 CDN에서 Cache 서버의 헬스 상태를 수시로 체크 (각각의 Cache 서버가 정상적인지, 가용한지) - 정상적으로 응답 가능한 서버로 안내
- LDNS는 End User한테 해당 서버 IP를 전달
- End User가 해당 서버 IP를 통해서 CDN 쪽에 컨텐츠 요청
ISP 토폴로지 (KT 사용자는 KT 서버 통해서 컨텐츠 전송)
- 각각의 토폴로지를 어떻게 확인할까 - LDNS 정보를 이용해서 확인
- GSLB에는 DNS 요청이 어느 LDNS 통해서 왔는지 (KT,LG,SK) 확인 가능
8.8.8.8 (구글 제공 DNS) or CloudFlare(1.1.1.1) 같은 글로벌 업체가 제공하는 DNS 사용하는 경우에는 토폴로지 형태로 구현되어 있지 X
반드시 LDNS (KT,LG,SK)
HTTP
- 첫 번째 사용자는 HTTP Get으로 CDN 서버에 요청
- CDN 서버는 자료가 없으니까 HTTP로 Origin 서버에 요청
- Origin 서버는 정상적인 컨텐츠 전달 (200 응답)
- CDN 서버는 로컬 디스크에 응답 받은 컨텐츠 저장 & End User에게 200 응답 하면서 Miss 정보를 같이 전달 (Miss 전달은 선택적)
- CDN 서버가 Origin으로 요청하는 과정이 없고, 기존에 저장되어있는 콘텐츠를 바로 200으로 응답 (HIT)
IMS(If-Modified-since)
- CDN Cache 서버에 저장되어 있는 콘텐츠의 Max-Age(TTL)이 만료되어 Origin에 콘텐츠가 변경되었는지 확인하는 요청
304 Response
- 콘텐츠를 갱신하지 않고 기존에 저장되어 있는 콘텐츠 전송 (Not Modified)
컨텐츠가 변경되었다면?
- Origin 서버는 304 응답을 하지 않고, 새로 바뀐 파일을 변경 해서 200 응답과 함께 전달
CDN 서버에서는 유효 기간이 지나지 않으면, Origin 서버에서 파일이 변경된 사실을 모름
Purge (=Flush, 캐시 무효화)
- 고객 운영자가 Origin 서버의 컨텐츠가 변경되었으면 CDN 쪽으로 Purge(Cache 서버의 데이터를 삭제)해줘야지만, CDN 서버는 변경된 파일을 Origin으로 다시 요청하여 변경된 사실을 인지
Response Time (속도 성능 이슈 트러블 슈팅의 기초)
- Response Time = DNS Lookup + TCP Connection + Time To First Byte + Contents Download
- 도메인을 조회하고 (DNS Lookup)
- 서버에 연결한 다음 (TCP Connection)
- 첫 번째 Byte를 다운받고 (Time To First Byte)
- 나머지 Data를 다운받음. (Contents Download)
- HTTP로 서비스한 것 보다 CDN에서 자원을 많이 소모 (SSL HandShake 과정에 의해서 CPU Job 소모 & 데이터 암호화에도 CPU 사용)
- HTTPS (사용자와 CDN Cache 서버 간 데이터 암호화)
HTTPS Response Time
- Response Time = DNS Lookup + TCP Connection + SSL HandShake + Time To First Byte + Contents Download
One Time URL (One Time Token)
- 컨텐츠를 전송하는데 있어서, 사용이 인가된 정상적인 User에게만 컨텐츠 전송
- 인증되지 않은 사용자의 다운로드를 방지하기 위해 One Time URL 제공
- 사용자는 One Time URL Key를 통해서 CDN 서버에 요청
- CDN 서버는 전달받은 키를 통해서 트래픽을 정상적으로 Delivery
- 특정 파일의 해쉬된 쿼리스트링(? 뒤의 파라미터) 값이 올바르면 전달
- AWS POP을 이루는 모든 리전과 Edge는 AWS 전용 회선으로 연결
1차 캐시 (=쉴드, 미들 캐시, 릴레이 캐시)
- Origin 보호를 위해 Origin으로의 요청을 최소화하기 위한 Layer 구성
- 물리적 여러 대의 Cache 그룹이, 하나의 논리적 Cluster 형태로 구성되어, Origin으로의 요청 최소화
Multi CDN
- Provider 별 다양한 정책 관리
- 대용량 트래픽 관리
- 가용성 확대
728x90