AWS의 CDN, CloudFront 서비스의 특징과 한계

아마존 클라우드 서비스(AWS)를 사용하면 기본적으로 전세계 7곳(US East (Northern Virginia), US West (Oregon), US West (Northern California), EU (Ireland), Asia Pacific (Singapore), Asia Pacific (Tokyo))에 위치한 데이터센터를 선택해서 서비스를 할수 있습니다. 하지만 그렇다고 하더라도 이 Region(AWS에서는 이를 region이라고 표현합니다)과 지역적으로 거리가 있는 지역에서는 필연적으로 발생할 수 밖에 없는 것이 Network의 거리에 따른 Latency입니다. 

그리고 이를 극복하기 위한 서비스가 바로 아마존의 CloudFront 입니다. CloudFront는 AWS를 사용할때에 함께 쓸수 있는 CDN서비스입니다. 아래의 그림에서 보면 아시겠지만 7개의 region으로 커버할수 없는 곳은 전세계의 22곳에 위치한 CloudFront의 Edge Location Server가 컨텐츠를 캐싱하여 이를 더 빠른 속도로 서비스 할수 있습니다.(24곳으로 증가했군요.) 

AWS의 글로벌 인프라스트럭쳐

링크된 CloudFront 소개 페이지를 보면 자세한 특징을 알수 있겠지만 이번에 블로그를 통해서 제가 실제 CloudFront를 설정하고 사용을 준비하면서 알게된 여러 특징과 극복해야할(중요한) 단점을 이야기 하고자 합니다. 

CloudFront의 기본적인 특징

1. 쉬운 설정과 사용계약
1. 글로벌 CDN 서비스의 대명사는 Akamai입니다. 서비스 성능도 일반적으로 더 나은것으로 알려져 있고, 상대적으로 통계등의 서비스 품질도 좋습니다. 하지만 Akamai를 쓰려면 계약과정이 필요하며, 계약이 전제되지 않으면 실제 테스트를 하는것도 쉽지 않은 경우가 많습니다. 
2. 반면 CloudFront는 AWS의 management console에서 쉽게 CloudFront Distribution을 설정할수 있고 따라서 테스트에 필요한 시간과 설정에 필요한 시간 외엔 추가로 필요한 절차가 없어서 편리합니다. 
   
   

   CloudFront를 설정하는 amazon management console 화면. origin server로 S3를 사용중이다.

2. 다양한 Origin Server 사용
1. Amazon에서는 origin server로 S3 사용을 권장하지만 EC2에 자체적으로 Contents Serving용 웹서버를 구성할 수도 있고, 클라우드가 아닌곳(On-Premise환경)에 구축한 서버를 활용할 수도 있습니다. 그리고 설정또한 간편합니다. 
3. CName설정을 통한 고유의 도메인으로 사용
1. CloudFront에 CName설정을 통해서 자체 도메인으로 사용할 수 있습니다. 하지만 이 부분은 아래에 다시 언급되겠지만 Http서비스에서만 가능하고, https서비스에서는 현재까지는 불가능합니다. 
4. 공개된 API를 통한 세밀한 제어
1. AWS에서는 Rest API를 통해서 여러가지 설정과 동작을 자동화 할수 있습니다. 또 이 REST API를 wrapping한 다양한 오픈소스 프로젝트[저는 fog(ruby)를 사용했습니다]가 나와있어 편한 언어를 선택해서 개발을 하면 자동화도 얼마든지 가능합니다.

CloudFront를 사용할 때 주의(혹은 극복)해야 할 부분

1. SSL환경으로는 자체 도메인을 쓸수 없다.
1. 현재까지 Https서비스를 CloudFront상에서 하려면 *.cloudfront.net 이라는 도메인에서만 가능합니다. A.com 과 같은 자체서비스 도메인으로 ssl서비스를 사용하려면 인증서를 설치해야 하는데, 이러한 서비스가 불가능 합니다.(Akamai는 인증서 발급을 대행하여 SSL인증서 설치를 통한 자체도메인 https서비스가 가능합니다.)
2. 이는 html상에 cloudfront.net 도메인이 노출되며 자사 서비스가 AWS CloudFront서비스를 이용중이라는 사실이 노출되는것을 꺼리는 회사에서는 신중하게 검토를 해야 합니다.
3. 아마존에서도 이에 대한 Needs가 많다는 것을 알고 있으며, 이를 해결하기 위한 노력을 하고 있다고 하니 곧 해결될것 같긴 하지만 아직이긴 합니다.
4. 참고 : 페이스북은 지난 10월 1일 부터 SSL Certificate를 요구하고 있습니다.
2. Contents의 Default Cache 타임은 24시간, 최소 시간은 1시간.
1. Origion Server에 컨텐츠를 배포할때 아무런 meta taggging을 하지 않았다면 기본으로 edge location 서버에서 origin server의 컨텐츠를 24시간 동안 캐싱합니다.
2. 이는 origin server에서 contents를 변경하더라도( file rename을 통한 versioning 정책을 취하지 않는 이상 ) 사용자는 24시간동안 변경된 내역을 볼수 없다는 이야기가 됩니다. 
3. 따라서 origin server에 contents를 배포할때는 cache 정책이 포함된 meta tag를 반드시 포함해야 합니다. 하지만 cache의 최소 시간은 1시간이 minimum이며, 아마존에서는 file rename으로 이 제한을 해결하라고 권고 합니다.(Akamai는 이러한 제한이 없습니다.) -> 예를 들어 file rename을 하지 않는 이상, file 내용이 변경되어도(아무리 object meta 정보를 활용하여 바로 expire하도록 세팅하더라도) 캐쉬서버는 최소 한시간은 캐싱된 데이터로 사용자에게 보여지지 않는다는 이야기 입니다.
4. 물론 cache를 삭제하기 위한 Invalidation(expire) API가 제공됩니다.
1. 하지만 이는 월 1000건의 object까지만 무료이고, 이후에는 과금이 발생됩니다.
2. 한번에 1000개의 object만 invalidate 요청될수 있으며 동시에 3개만 동작하기 때문에 많은 object를 edge location에서 삭제하려면 많은 시간이 걸립니다.
3. 기본적으로 하나의 object를 cache삭제 하려면 file size에 따라서 다르지만 최대 15분이 걸릴수 있습니다.(하지만 테스트 결과 1분 안에 invalidate되긴 합니다)
3. 통계데이터를 보려면 CloudFront Logging기능을 활용하여 자체 개발하거나 3rd Party 솔루션 이용해야함.
1. Akamai에서 제공하는 지역별 CDN통계등을 기대하시면 안됩니다. 
2. CloudFront에 logging 설정을 해야 하며, 이 로그는 S3 bucket에 gzip된 형태로 저장이 됩니다. 
1. 이를 활용해서 자체 개발하여 통계를 보거나, 별도의 3rd party 도구(보통 유료)를 사용해야 합니다.
2. 로그를 남기는것 자체는 과금이 발생하지 않지만 이러한 로그가 저장되는 S3 bucket의 사용량에 따른 과금은 발생하게 됩니다.

아마존 AWS 클라우드를 활용하게될 서비스의 특성에 따라서 이러한 CloudFront의 이러한 특징과 제약은 때에 따라서는 서비스 적용 자체를 고민하게 될 수 있습니다. 하지만 On-Demand 서비스가 가지고 있는 기본적인 장점이 분명하고, 더불어 지속적으로 진화하는 과정에 있는 서비스이기 때문에 잘 이해하고 활용한다면 기존의 CDN서비스와 비교해서도 여러가지 장점을 가질수 있는 서비스라고 생각합니다.