CDN(Content Delivery Network)에 대해 이해하기

이번에는 CDN(Content Delivery Network)에 대해 알아보려고 한다.

 

간단한 예시를 들어보자.

상파울루에 서버가 존재하고, 상파울루와 서울 두 나라 모두 사용자가 존재한다고 가정하자.

 

이 때 특정 페이지를 서울 사람과 상파울루 사람이 동시에 열었다면 누가 더 빠른 속도로 접속이 가능할까?

 

정답은 상파울루 사람이 더 빠르게 데이터에 접근이 가능하다.

1차원적으로 이해해도 당연히 상파울루에 서버가 있기 때문에 더 가까운 상파울루 사람이 더 빠르게 접근이 가능하지 않을까라고 생각할 수 있다.

 

더 디테일하게 생각해보자.

 

먼저 물리적인 거리(지연 시간)이다. 위에서 말했던 당연한 이유이다.

서울에서 상파울루까지는 약 18,000km이다. 즉 서울 사람이 요청을 보내면 상파울루까지 요청을 보내고 다시 서울까지 돌아와야하는 것이다. 요청이 여러번 반복되면 지연이 계속해서 발생하게 된다.

 

두 번째는 거쳐 가는 장비의 수(홉)이다.

서울에서 상파울루까지 데이터가 직통으로 가는 것이 아니라 중간에 수십 개의 라우터를 거치게 되고, 거리가 멀수록 거치는 장비가 많아지게 된다. 그렇기 때문에 장비를 거칠수록 약간의 처리 지연이 생긴다.

 

그렇기 때문에 서울에도 서버를 두어야 서울에 있는 사용자는 지연으로 인한 불편함을 겪지 않을 수 있다.

 

CDN는 이러한 문제를 해결하기 위해 전 세계 곳곳에 콘텐츠를 캐싱하여 저장할 수 있는 서버를 설치하고, 사용자가 가장 가까운 곳에서 받을 수 있게 해주는 서버 네트워크이다.

 

원본서버는 데이터를 저장하고 있는 본진 서버이다.

 

엣지 서버는 원본 서버의 데이터의 사본을 가지고 있는 각 지역에 흩어져있는 서버들이다.

사용자는 원본 서버가 아닌, 각자 지역에 아까운 엣지 서버를 통해 데이터를 받을 수 있다.

 

이러한 방식을 캐싱이라고 하는데, 엣지 서버에서 처음 요청이 올 때 원본에서 콘텐츠를 한 번 받아와서 저장해두고 다음 요청부터는 사본을 내어준다.

 

어떻게 보면 CDN 기술은 리버스 프록시의 개념과 동일하다고 볼 수 있다.

 

그렇다면 각각의 엣지 서버에는 어떤 데이터가 들어가야 할까?를 고민해봐야한다.

 

제공 가능한 컨텐츠는 정적, 동적 콘텐츠 2가지로 나누어서 볼 수 있다.

 

정적 콘텐츠는 누구에게나 동일한 데이터(로고, 이미지, JS, 동영상 등)

동적 콘텐츠는 사람마다 다른 데이터(계좌 잔액, 장바구니, 추천 목록 등)이다.

 

만약 엣지 서버에서 동적 콘텐츠를 캐싱한다면, 내가 받은 사본을 다른 사람이 받게 되고, 내 계좌 잔액이 상대에게 보이는 말도 안되는 상황이 발생하게 된다. 그렇기 때문에 누가 받든 문제 없는 동일한 데이터, 즉 정적 콘텐츠를 캐싱해서 제공해야한다.

전에 CDN을 써본 적이 있는데, S3에 올린 이미지나 동영상을 캐싱해서 보여주는 용도였다. 그래서 '정적 데이터'라고 하면 당연히 이미지, 동영상 같은 미디어 파일을 말하는 거라고 생각하고 있었다.

 

그런데 공부하다 보니 웹 페이지 자체도 CDN으로 제공된다는 걸 알게 됐다. 처음엔 좀 의외였는데, 생각해보면 당연한 얘기였다. HTML, CSS, JS도 내용이 안 바뀌는 고정된 파일이니까 결국 이미지랑 똑같은 정적 자산인 거다. 내가 좁게 알았던 건 CDN의 용도가 아니라 정적 데이터라는 개념 자체였던 셈이다.

 

이렇게 보니까 프론트 배포 방식도 이해가 됐다. 프론트엔드를 빌드하면 결국 HTML, CSS, JS 파일 묶음이 나오는데, 이미지를 S3에 올렸던 것처럼 이 빌드 결과물도 S3에 올리고 그 앞에 CDN을 붙이면 페이지를 빠르게 띄울 수 있다. 다들 S3 + CDN으로 프론트를 배포하는 이유가 이거였다.