CDN
Content Delivery/Distribution Network의 약자로, 서버의 컨텐츠를 빠르게 전송하기 위해 다수의 네트워크 노드들에 컨텐츠를 저장(캐싱)해두는 시스템
오리진 서버가 컨텐츠를 여러 네트워크 노드(CDN 서버)에 미리 저장해두고
클라이언트가 오리진 서버의 컨텐츠를 가져오는 상황에서, 접속하는 클라이언트의 가장 근처의 네트워크 노드에 저장된 컨텐츠를 가져오게된다.
이렇게 CDN 서버에 저장된 컨텐츠를 가져옴에 따라 오리진 서버로의 요청 수를 줄이게되어 서버의 부하를 줄일 수 있다.
Cloudfront
AWS에서 제공하는 CDN 서비스로, CDN 방식으로 운영되는 캐싱 기반 컨텐츠 전송 네트워크 서비스이다
전 세계에 위치한 Edge Location(엣지 로케이션)을 통해 웹 사이트의 컨텐츠들을 캐싱해 클라이언트로 하여금 지연시간이 가장 낮은 엣지 로케이션으로 라우팅해준다.
간단하게 us-east-1에 위치한 웹 서버에 대해서 생각해본다
서울에서 이 웹서버에 있는 이미지/동영상을 액세스하는 경우, 저 멀리에 있는 us-east-1의 위치까지 연결이 이루어져야한다.
반면, Cloudfront를 통해 us-east-1의 웹서버를 배포한 경우, 접속자 근처 엣지 로케이션에 저장된 캐시데이터를 가져와 직접 us-east-1에 있는 서버까지 연결하는 것 보다 훨씬 빠르게 컨텐츠에 액세스할 수 있다.
Cloudfront의 동작과정
먼저 오리진 서버가 Cloudfront에 배포가 되어 각 엣지 로케이션에 컨텐츠들을 캐싱해둔다.
이후 클라이언트가 컨텐츠를 요청하는 경우, Cloudfront는 클라이언트의 위치에서 가장 가까운 엣지 로케이션으로 라우팅을 해준다. (지연시간이 가장 짧은 엣지 로케이션을 바라보게 됨)
클라이언트가 요청한 컨텐츠가 해당 엣지 로케이션에 저장되어있는 경우, 해당 컨텐츠를 바로 클라이언트로 반환하게 된다.
반면, 액세스하고자 하는 컨텐츠가 엣지 로케이션에 저장되어있지 않은 경우에는 Cloudfront는 연결된 오리진에서 컨텐츠를 검색 후, 엣지 로케이션에 캐싱 한 후 클라이언트로 전달하게 된다.
Cloudfront의 특징
1. 전송 중 암호화(HTTPS/SSL)
Cloudfront가 클라이언트와 서버 간의 연결의 사이에 위치한다는 점에서 오리진 서버가 SSL을 지원하지 않아도 Cloudfront를 이용해 SSL 연결을 할 수 있다.
클라이언트와 Cloudfront 사이에서 HTTPS 통신을 지원하는 구조인데, ACM을 통해서 발급받은 SSL 인증서나 import한 인증서를 Cloudfront 배포와 연결하는 것이다.
이때, Cloudfront에 ACM을 이용해 SSL 인증서를 연결하는 경우 ACM 리전을 us-east-1으로 지정해주어야 한다.
(Cloudfront는 글로벌 서비스라 us-east-1에서 총 관리를 하기 때문이다.)
2. 지리적 제한 설정(Geo-restriction)
접속하는 클라이언트의 지리적 정보에 따라 접근을 허용/제한할 수 있다.
화이트리스트(특정 국가만 접근가능) 방식과 블랙리스트(특정 국가의 접근을 제한) 방식 중 선택하여 설정 가능하다.
콘텐츠의 지리적 배포 제한 - Amazon CloudFront
CloudFront에서는 서드 파티 데이터베이스를 사용하여 사용자의 위치를 확인합니다. IP 주소 및 국가 간 매핑 정확도는 리전에 따라 다릅니다. 최근 테스트에 따르면 전반적인 정확도는 99.8%입니다.
docs.aws.amazon.com
3. AWS 서비스 간의 연동
Cloudfront 배포에 WAF를 연동해 7계층 수준의 공격을 차단/모니터링 할 수 있고, Cloudfront의 오리진 서버로 단일 인스턴스 뿐만 아니라 로드밸런서(ALB, NLB), S3 정적 호스팅 URL, Lambda 함수 URL 등을 지정할 수 있어 AWS 서비스 간의 결합도가 높은 것을 볼 수 있다.
CloudFront 배포에 다양한 원본 사용 - Amazon CloudFront
CloudFront 배포에 다양한 원본 사용 배포를 만들 때 CloudFront가 파일에 대한 요청을 보내는 원본을 지정합니다. CloudFront에서 여러 원본을 사용할 수 있습니다. 예를 들어 Amazon S3 버킷, MediaStore 컨테
docs.aws.amazon.com
속도 비교 with Cloudfront
간단하게 Cloudfront의 적용 유무를 기준으로 몇 가지 상황들에 대해 속도를 측정해본다.
큰 용량의 파일을 다운로드 하는 상황을 테스트해본다.
큰 용량의 파일(약 1GB)을 us-east-1 리전의 S3에 담은 후, S3 URL을 통해 직접 다운로드한 시간을 측정한다.
먼저 서울에서 버킷 object를 다운받을때의 모습이다. 다운로드 시작 시 1mb/s 정도의 속도를 보여주며 ETA는 약 18분 가량 찍히는 것을 볼 수 있었다.
동일한 리전에서 버킷 object를 다운받을때의 모습이다. 속도는 대략 6~70mb/s, ETA까지는 약 15초 걸리는 것을 볼 수 있었다.
그리고 S3를 오리진으로 하는 Cloudfront 배포 URL을 통해 파일을 다운로드한 시간을 측정해본다
방금 생성한 버킷을 오리진으로 설정 후 Cloudfront 배포를 생성한다. 그리고 다운로드 URL을 cloudfront 배포의 URL로 설정하고 파일을 다운로드했다.
서울에서 파일을 다운받을때의 속도는 약 10mb/s, ETA는 94초로 확실하게 증가한 것을 볼 수 있었다.
동일한 리전에서 다운로드시 속도는 객체URL로 직접 다운로드 받았을 때와 거의 동일하게 나타나는 것을 볼 수 있었다.
다음으로 웹을 통해 이미지를 로드하는 상황을 테스트해본다.
S3 객체URL로 직접 액세스하는 경우, 평균 200ms 소요됨을 볼 수 있었다.
cloudfront 배포 URL로 액세스하는 경우, 평균 10ms 이하로 로딩이 됨을 볼 수 있었다.
S3 객체URL로 액세스할때보다 약 20배 가량 빠른 것을 확인할 수 있었다.
정리
이렇게 간단하게 Cloudfront의 개념과 동작구조, 실제 속도 차이를 알아 보았다.
이번 글에서는 따로 적지 않았지만, Cloudfront 배포를 설정할때 다양한 캐싱 전략을 설정할 수 있다는 것을 볼 수 있었다. 컴퓨터 과학에서 캐싱의 어려움은 해결하기 어려운 주제인 것으로 유명한 만큼, 마주한 상황에 따라서 적절한 캐싱 전략을 세우는 것이 중요할 것 같다.
