[인프라] 클라우드 CDN 아키텍처

여러개의 리전에 흩어진 여러개의 클라우드들을 연결해야 할때에는 CDN(Contents Delivery Network)를 활용할 수도 있다. CDN이란 웹 콘텐츠를 인터넷에 효과적으로 배포하기 위한 HTTP에 최적화된 네트워크를 말한다.

 

구축할 시스템이 동영상처럼 대용량 파일의 비중이 높고, 클라우드 기반의 아키텍처를 사용할 수 있는 환경이라고 가정한다. 이런 환경에서 오브젝트 스토리지에 저장된 파일들을 사용자에게 제공할때는 DNS를 활용하여 최적의 라우팅 경로로 파일이 전송되도록 만들 필요가 있다. 최근에는 웹 브라우저로 접속하는 사용자 외에도 모바일 기기로 접속하는 사용자가 많아져서 일시적으로 요청이 많아 한 곳으에 부하가 몰리는 경우도 종종 생긴다. 이러한 문제를 해결하기 위해 DNS와 오브젝트 스토리지, 혹은 로드 밸런서 사이에 CDN을 구성하는 사례가 늘어나고 있다. CDN은 HTTP 통신에 최적화되어 있고, 사용자와 가장 가까운 엣지 서버를 통해 캐시 기능을 제공하는가 하면, 네트워크 라우팅 기능은 물론 보안 기능까지 두루 갖추고 있다보니 국제적으로 서비스하려는 시스템에 반드시 필요한 구성 요소 중의 하나로 꼽힌다.

 

CDN을 제공하는 서비스로는 Akamai, Amazon Cloud Front, EdgeCast, Limelight, CDNetworks 등이 있다. CDN의 사실상 표준인 Akamai와 AWS가 제공하는 Amazon CloudFront를 중심으로 설명한다.

 

CDN을 클라우드로 정의하기에는 다소 논란의 여지가 있다. 리소스가 추상화되어 있고, API로 제어할 수 있으며, 인터넷을 통해 접근하면서도 클라우드 환경과 쉽게 조합할 수 있다는 면이 일반적인 클라우드 서비스에서 볼 수 있는 시스템에 대한 접근 방법과 매우 비슷하다.

 

---

인터넷 구조와 CDN 기본 아키텍처

CDN은 인터넷을 고속화하기 위한 기술이다. 단, 통신 속도 자체를 높이는 것이 아니라 리소스를 적재적소에 분배하고 가까운 분배지로 통신 경로를 연결하는 방법으로 최적화한다. 이때 통신 경로는 논리적으로 정의할 수 있기 때문에 API로 제어할 수 있다.

 

인터넷은 BGP 프로토콜을 이용해서 AS와 AS 사이를 라우팅하는 네트워크이다. AS는 그 수가 많고 계층 관계를 형성하는데, 그 중에서도 하위에 많은 AS 계층을 포함한 최상위의 AS를 티어1(tier1)이라고 한다. 이는 DNS 트리와 비슷한 개념이다. 통신 경로상에 수많은 AS들을 거쳐야 하는 경우라면 티어1을 통할 확률이 높다. 티어1을 기준으로 그 하위 규모의 AS를 순서대로 티어2, 티어3이라고 부른다.

 

인터넷은 수많은 라우터들의 집합이라고도 볼수 있는데, CDN은 그 중에서도 사용자와 가장 가까운 라우터에 연결된 서버라고 생각할 수 있다. 이 서버는 고속처리를 위해 필요한 DNS, 라우팅 정보 관리, 캐시 관리와 같은 기능이 있으며 이러한 정보를 바탕으로 최적의 라우팅 정보를 만들게 된다.

 

CDN의 엣지 서버군: 대형 CDN 업체일수록 더 많은 AS에 엣지 서버를 배치하고 있어서 전송 속도가 빨라질 가능성이 높다.

 

 

엣지 

CDN에서는 캐시 서버가 존재하는 데이터 센터를 리전이라고 하지 않고 엣지, 혹은 엣지 로케이션이라고 부른다. 전세계 각지에 수많은 엣지가 분포되어 있는데 요청이 들어오는 곳에서 가장 가까운 엣지로 라우팅을 하도록 만들어 HTTP 응답 속도를 향상 시킨다. 이때, 요청한 지역에서 얼마나 가까운 곳에 엣지가 위치하느냐에 따라 응답 속도가 결정되므로 CDN 서비스 제공자는 타 사업자와의 차별화를 위해 엣지의 개수와 운영 장소를 지속적으로 늘리고 있다.

 

오리진 

사실 CDN은 네트워크 망에 불과하기 때문에, 실제로는 컨텐츠를 보관할 서버가 필요하고 이것을 오리진이라고 한다. CDN에서는 HTTP 통신을 하기 때문에 오리진은 HTTP 서버로 구성해야 한다. 통상 동적 웹사이트에서는 웹서버 앞에 로드 밸런서를 둘때가 많아, 오리진은 HTTP 로드 밸런서 중심으로 구성된다. 반면, 정적 웹사이트에서는 오브젝트 스토리지가 HTTP 서버를 내장하고 있기때문에, 오리진은 오브직테 스토리지를 중심으로 구성된다.

 

디스트리뷰션 

CDN은 DNS와 오리진 사이에 위치하고 있어서 URL을 통해 서비스를 이용하는 사용자는 CDN의 존재를 의식하지 못한다. CDN에는 최적의 엣지를 구성할 수 있도록 각종 규칙을 정의하는 논리적인 단위가 있다. 이 논리적 단위를 Amazon CloudFront에서는 디스트리뷰선, Akamai에서는 엣지 호스트라고 한다. 이들은 각각 오리진과 연관 관계가 있다. 참고로 디스트리뷰션에는 CDN이 정의하는 하나의 CNAME 레코드가 있고 여기에는 엣지를 가리키는 여러 개의 IP 주소가 할당되어 있다. 이것이 CDN의 동작 방식의 핵심 요소다.

 

Amazon CloudFront에서는 웹관련 데이터를 다루는 디스트리뷰션과 스트리밍 관련 데이터를 다루는 디스트리뷰션으로 두가지 형태가 제공되며, API와 리소스도 각각 별도로 존재한다. 대부분의 컴포넌트들은 엔드포인트에 리전 정보가 포함되어 있었는데 CloudFront는 리전 정보가 들어가지 않는다. 즉 'cloudfront.amazonaws.com'과 같은 형태로 접근하는데 이것은 디스트리뷰션 리소스가 여러 개의 엣지를 포함하고 있기 때문에 어느 하나로 지정할 수 없기 때문이다.

 

디스트리뷰션의 설정은 CORS(Cross Origin Resource Shared) 설정과 비슷한 방법으로 HTTP 바디 부분의 <DistributionConfig>안에 정의한다. 설정할 부분으로는 오리진을 지정하는 <Origin>이나 캐시 설정을 할 <CacheBehavior>, 그리고 접근 이력을 남기기 위한 <Logging> 등이 있다. 스트리밍 디스트리뷰션도 이와 유사한데 URI만 조금 다르다.

 

Behavior

Behavior는 디스트리뷰션에서 정의하는 내용으로 사용자 요청을 오리진과 연결하고 오리진의 응답을 사용자에게 연결해주는 기능을 의미한다. 이때 오리진은 오브젝트 스토리지일 수도 있고 로드밸런서를 앞세운 웹서버일 수도 있다. 디스트리뷰션인 FQDN이라고 비유한다면 비헤이비어는 URI의 패스 부분에 해당한다고 볼 수 있는데, 이 패스의 내용이 무엇인지에 따라 어떤 오리진을 연결을 할지 결정하게 된다. 비헤이비어를 사용하면 HTTP 메소드나 캐시를 위한 TTL 정의, 그리고 분산할 엣지를 한정하는 등의 다양한 설정을 할 수 있다.

 

비헤이비어는 <CacheBehavior>에 설정하게 되는데 Amazon CloudFront에서는 한번 정의한 디스트리뷰션을 수정하는 일이 많기 때문에 설정 관리를 위한 별도의 리소스가 제공된다.

 

 

헤더 필터/에러 페이지/SSL 인증서 

CDN은 HTTP에 특화된 네트워크이다. 그래서 OSI 모델 중 L3 레벨에서 제어하지 않고 L7 레벨에서 제어한다. Amazon CloudFront를 예로 들면 접근 제어를 할때, 화이트 리스트에 허용할 HTTP 헤더를 조건으로 걸수 있다거나, HTTP 상태 코드에 따라 적절한 에러 페이지로 포워딩을 하도록 설정하기도 한다.

 

클라우드 환경에서는 웹 애플리케이션 방화벽 서비스(WAF: Web Application Firewall)를 사용할 수 있는데 HTTP를 기반으로 하는 CDN과 조합이 가능하기때문에 CDN의 주요 서비스로 활용되리라 예상된다.

 

통신이 대부분 HTTPS로 이루어진다. 그리고 HTTPS 통신을 위해서는 서버에 SSL 인증서가 설치되어야 한다. CDN은 도메인을 사용한 통신에서 접점 역할을 하기 때문에 SSL인증서를 설치하는 최적의 장소가 된다. 실제로 CDN을 사용할 경우, SSL 인증서는 디스트리뷰션에 업로드하게 되는데, 별도로 구매한 사용자 정의 도메인을 사용하는 경우라면, 해당 도메인이 여러 개의 엣지에 할당된 IP 주소들을 대응할 수 있어야 하기 때문에 각 엣지로 SSL 인증서가 분배되어야 한다.

 

SSL 인증서에는 일반적인 인증서와 여러개의 CNAME를 지원할 수 있는 SNI 인증서 두 종류가 있다. 일반적인 인증서는 엣지가 있는 IP 주소를 특정 디스트리뷰션의 CNAME으로 점유하는 형태가 되는것에 반해, SNI 인증서는 각각의 엣지를 여러개의 디스트리뷰션의 CNAME에서 공유하는 형태가 된다.

 

 

클라우드 사설 네트워크 

CDN을 사용할때, 디스트리뷰션과 오리진 사이에 사설 네트워크를 구성하도록 만들수도 있다. 이렇게 하면 오리진은 반드시 CDN을 통해서만 접근할 수 있어 일반적인 방법으로는 접근하지 못하도록 차단할 수 있다. 그밖에도 HTTP 접근은 CDN을 통해 서비스를 계속하면서도 그 뒤의 오리진을 다른 클라우드로 교체하는 것도 가능하다.

 

이러한 기능은 Amazon CloudFront에서 OAI(Origin Access Identity)라고 부르고 오리진으로 Amazon S3를 선택하는 것도 가능하다.

 

---

CDN의 캐시 제어 방식 

CDN의 핵심이 되는 캐시 기능은 HTTP 헤더와 디스트리뷰션의 설정 내용에 따라 제어된다. 캐시를 제어하는 HTTP 헤더로는 Cache-Control과 Expires 두가지인데 둘다 설정된 경우에는 Cache-Control이 우선한다.

 

Expires는 캐시가 무효화되는 시점을 지정할때 사용하고, Cache-Control은 캐시가 유효한 시간(초 단위)를 지정할 때 사용하기 때문에 용도로 구분해서 의도한 대로 잘 동작하도록 설정해야 한다. 그 밖에도 CDN의 디스트리뷰션 설정에는 캐시의 수명을 제어하는 TTL 설정이 있다.

 

HTTP 헤더와 디스트리뷰션 둘 다 설정되어 있으면 엣지 서버의 캐시 제어는 디스트리뷰션의 설정이 우선하고, 브라우저의 캐시 제어는 HTTP 헤더의 설정만 적용된다.

 

웹 애플리케이션의 URI에서 사용되는 쿼리 파라미터를 통해 캐시 여부를 판단하고 싶다면 디스트리뷰션에 'Forward Query Strings'를 활성화하면 된다. 비슷한 방법으로 HTTP 헤더의 쿠키 값을 활용해서 캐시 여부를 확인하고 싶다면 'Forward Cookies'를 활성화하면 된다.

 

엣지서버의 캐시 데이터를 수동으로 무효화하고 싶을 수도 있는데 이럴때는 관련 제어 API를 호출하되, InvalidationBatch에 무효화할 경로를 지정하면 된다.

 

---

CDN의 라우팅

캐시를 활용해서 콘텐츠의 제공을 최적화할 수 있다. 대부분의 트래픽이 대용량 파일을 참조할때 발생한다는 것을 감안하면 캐시를 활용하는 방법이 상당히 효과적일수밖에 없다. 다만 데이터가 변경되면 큰 효과를 보기는 어렵다.

 

최근에는 모바일 단말기의 수가 많아지고 동영상 데이터에 대한 처리량도 늘어나 CDN의 규모도 점점 더 커지고 있다. 이에 따라 기존의 인터넷을 구성하던 수많은 ISP(Internet Service Provider)들 보다 특정 CDN 벤더의 서버 수가 더 많아지는 상황에 이르렀다. 그러다 보니 데이터를 전송 받기 위해 수많은 ISP를 거치는 AS 간의 BGP 통신보다는 CDN 벤더의 라우팅이 더 빨라졌다. 예를 들면 Akamai에는 Sure Route라는 서비스가 있는데 엣지 서버들 간에 가상 네트워크를 구성하여 최적의 라우팅 경로를 만들어 낼 수도 있다.

 

이와 같이 CDN을 활용하면 데이터를 참조하는 HTTP의 GET 처리에 대해서는 캐시 기능을 활용하여 성능을 향상시키는 효과가 있다. 데이터를 변경하거나 삭제하는 HTTP의 PUT이나 DELETE 처리에 대해서는 SSL을 통한 보안성 향상과 CDN 라우팅을 통해 네트워크 통신을 최적화하는 효과를 기대할 수 있다.

 

 

멀티 클라우드에서의 CDN의 역할 

CDN은 원래 동영상과 같은 대용량 콘텐츠를 제공할때, 캐시를 통해 전송 속도를 빠르게 하고 전송 효율을 높이기 위한 목적으로 만들어졌다. 예를 들어 AWS에서는 오브젝트 스토리지인 Amazon S3에 대용량 파일을 저장하고 그 앞에 Amazon CloudFront를 두는 것이 일반적인 시스템 구성이다. 이러한 방식은 HTTP의 GET 처리에 효과적인데, 최근의 CDN은 이러한 기능뿐만 아니라 보안과 라우팅의 기능도 보강되어서 HTTP의 PUT/POST 처리에도 잘 대응하고 있다. 그 외에도 동영상 트랜스코딩 처리와 같은 확장 기능들도 조합이 가능해서 모바일망이나 기업망에서 활용되는가 하면, 사설 CDN도 사용할 수 있다.

 

특히 클라우드에는 웹시스템의 비중이 많고 웹 API를 통해 제어할 때가 많기 때문에 대부분 HTTP으로 통신한다. '국제적인 환경에 시스템을 구축하고 데이터를 동기화하되, 유사시에는 복구용 시스템으로 교체한다'거나 '멀티 클라우드를 구축해서 서버 리소스와 오브젝트 스토리지를 서로 다른 클라우드로 분리한다'와 같이 규모가 크고 복잡한 요구 사항이 들어오는 경우에는, 통신상의 지연이나 데이터의 공유 부분이 요구 사항을 충족하기 위한 중요한 핵심 요소로 작용한다. 결국 이를 위해서는 데이터 센터 간의 HTTP 통신이 최적화 되어야 하는데, 그런 의미에서라도 CDN은 클라우드 환경에서 중요한 컴포넌트로 자리매김할 것이다.

 

 

CDN 캐시서버에서 응답을 리턴하는데, 오리진 서버로 접속기록이 남는 이유는?