풀스택 소프트웨어 엔지니어링 | 클라우드 매니지드 서비스 기업 (MSP)
agency@coovil.com
인천IT타워 1211호
What's CDN? Why we should use CDN?

CDN이란 무엇이며, 왜 CDN을 사용해야 하는가?

CDN은 Content Delivery Network의 약어로, 한글로는 콘텐츠 배포망으로 번역됩니다. CDN에 대하여 한번쯤 들어보신 분도 있고 처음 듣는 분도 있으실 것입니다. 중요한 것은 인터넷으로 미디어 콘텐츠를 일반 고객에게 제공하는 기업이라면, CDN은 반드시 알아야 할 기술이라는 것입니다. 이번 글에서는 CDN이 생겨난 이유에 대하여, 그 진화 단계를 하나씩 소개하는 방식으로 설명하겠습니다.

Rev. Step 0 - Media Contents in Web Server

진화 0단계 - 웹서버 내의 미디어 콘텐츠

기업이 직접 만들거나 또는 사용자가 직접 만들어 올린 미디어 콘텐츠를 인터넷으로 접근 가능하도록 하는 가장 쉬운 방법은 웹서버를 통하는 것입니다. 웹서버 내에 미디어 파일을 놓아두면, 브라우저와 같은 클라이언트 프로그램이 도메인에 서브 경로를 붙여 파일을 다운로드하고 표시 또는 재생하는 식입니다. 이 방법은 미디어 파일의 크기가 작고 접근 빈도도 작은 경우 별 문제가 없습니다.

그러나 파일 크기가 수백 메가바이트, 수 기가바이트라면 상황이 달라집니다. 다수의 클라이언트 프로그램이 동시에 수 기가바이트의 소프트웨어 설치파일이나 동영상을 받기 시작한다고 했을 때 웹서버 네트워크 카드의 대역폭 제한, 라우터의 대역폭 제한, 케이블의 대역폭 제한 또는 호스팅 업체에서 설정한 네트워크 대역폭 제한에 도달하게 됩니다. 작은 크기의 미디어 파일이라도 동시 접근량이 늘어난다면 같은 상황에 직면하게 됩니다.

이렇게 네트워크 대역폭 제한에 걸려버린 경우, 콘텐츠 다운로드 트래픽으로 인해 웹서버는 네트워크를 통해 들어오는 일반 요청도 받을 수 없게 되어 결국에는 어떠한 서비스도 더 이상 제공할 수 없는 ‘마비’ 상태에 빠지게 됩니다.

Rev. Step 1 - Using Media Contents Server

진화 1단계 - 미디어 콘텐츠 전용 서버의 사용

다수의 고객에게 동시에 콘텐츠를 전달해야 하는 상용 웹 서비스의 경우 하나의 웹서버 만으로 운용될 수 없는 경우가 대다수입니다. 웹서버의 경우, 로드밸런서를 통해 트래픽을 동일한 여러 개의 웹서버로 분산하여, 각 웹서버가 받는 부하를 1/N로 줄일 수 있습니다.

그러나 정적인 콘텐츠가 아닌, 콘텐츠가 계속해서 추가되는 상황이라면 여러 개의 웹서버가 동일한 미디어 파일을 유지할 수 있도록 동기화 시켜야 하는 문제가 발생하게 됩니다. 그래서 다른 기능없이 오로지 미디어 콘텐츠 파일 만을 보관하고 제공하는 웹서버인 ‘미디어 콘텐츠 서버’를 별도로 만들어 이 서버가 높은 네트워크 대역폭을 지원하도록 하고, 서비스 기능을 수행하는 웹서버와 클라이언트 프로그램으로 부터의 접근이 이곳으로 일원화 되도록 합니다.

그러나 미디어 다운로드 트래픽이 계속 늘어난다면 어떻게 될까요? 단일 미디어 콘텐츠 전용 서버의 네트워크 대역폭을 무한대로 늘릴 수는 없습니다. 호스팅 업체의 최대 네트워크 대역폭에 도달하기도 전에 해당 서버의 네트워크 카드가 가진 대역폭 최대치에 먼저 도달하게 될 것입니다. 이럴 때는 어쩔 수 없이 미디어 콘텐츠 서버를 여러 대 운용해야 합니다. 미디어 콘텐츠 서버가 여러 대가 되면 역시 서버 간의 파일 동기화 문제가 발생합니다. 클라이언트가 어떤 임의의 내부 미디어 서버에 도달한다고 해도 같은 파일에 접근할 수 있어야 하는데 그것이 랜덤으로 (받을 수도 있고 못 받을 수도 있고) 된다면 안되니까요. 새로운 미디어 파일을 고객이 업로드하던 기업이 업로드하던 모든 미디어 콘텐츠 서버에는 동일한 시점에 동일하게 올라가야 합니다.

Rev. Step 2 - Media Contents Servers per Region

진화 2단계 - 지역별 미디어 콘텐츠 전용 서버들

글로벌한 서비스의 경우에는 또다른 지리적 문제에 직면하게 됩니다. 문제의 원인은 지구가 크다는 것이죠. 미디어 콘텐츠 서버는 지구 어딘가 특정 지점에 위치하는데 반하여, 글로벌 서비스의 경우 지구에 있는 사용자든 접근하기 때문에 서버와 클라이언트 사이의 거리가 멀면 멀수록 통신 속도는 느려지게 됩니다.

결국 해법은 서버와 클라이언트 사이의 ‘거리’를 줄이는 것입니다. 다수의 미디어 콘텐츠 서버를 여러 개의 지역에 분산 배치하여 트래픽을 분산시키는 방식입니다. 오리진(Origin) 서버라고 하는 모든 데이터의 원본 격인  미디어 서버를 구성하고 나머지 미디어 서버들이 오리진 서버로부터 데이터를 가져와 근처의 사용자에게 제공하는 것입니다. 그러나 위와 같이 파일을 동기화하고, 사용자가 근처의 서버에 접근하도록 하는 등의 처리는 중소형 기업이 감당하기에 쉬운 일이 아닙니다. 막대한 서버 비용이 들어가며, 높은 수준의 서버 관리도 필요하죠.

Rev. Step 3 - Commercial Content Delivery Network Service

진화 3단계 - 전문 콘텐츠 배포망 서비스의 등장

위와 같이 오리진(Origin) 서버를 두고 에지(Edge) 서버(지역별 미디어 콘텐츠 서버)를 두는 것은 정말 좋긴 하지만 생각보다 큰 규모의 작업이며 운용 비용도 만만치 않습니다. 그래서 이것을 전문적으로 서비스하는 기업들이 생겨났습니다. 이들이 제공하는 서비스가 바로 CDN 입니다. CDN 서비스는 고객사가 직접 이 모든 것을 처리하는 것에 비하여 더 저렴하고 더 편리하고 더 안정적으로 사용자에게 콘텐츠를 제공합니다. 또한 디도스 공격 등으로 인한 대규모 트래픽 증가에 대해서도 염려할 필요도 없습니다.

대표적인 CDN 서비스로는  ‘Akamai(아카마이) CDN’과 AWS의 ‘CloudFront(클라우드 프론트)’ 제품이 있습니다. Akamai CDN은 정말 빠르고 매우 많은 에지 서버를 갖추고 있습니다. 그러나 다른 CDN 서비스에 비해 비싸다는 단점이 있습니다. 쿠빌은 다른 AWS 제품들과의 연동성도 좋고 주요한 국가들에서 좋은 성능을 보여주는 CloudFront 제품을 추천합니다.

Conclusion

마무리

지금까지 CDN 서비스가 생기게 된 과정을 하나씩 알아보았습니다. 이제 CDN 서비스가 무엇이며, 왜 사용해야 하는지 자연스럽게 알게 되셨을 것이라 생각합니다.

CDN은 더 이상 옵션이 아닌 필수입니다. 아마존의 CDN 서비스인 CloudFront 제품은, 강력한 CDN 기능을 저렴하게 종량제로 (사용량 만큼만, 발생한 트래픽 만큼만) 지불하여 사용할 수 있도록 합니다. 고객사에서도 쿠빌의 클라우드 매니지드 서비스와 마이그레이션 서비스를 통해 고객사의 서비스에 CDN 기능을 적용해보시기 바랍니다.