블로그 릴레이 - Amazon CloudFront 입문

안녕하세요! AWS 사업 본부의 김재욱입니다.

본 블로그는 당사의 한국어 블로그 릴레이의 첫 번째 블로그입니다.

이번 블로그의 주제는「Amazon CloudFront 입문」입니다.

Amazon CloudFront란?

Amazon CloudFront는 사용자에게 동영상, 이미지와 같은 정적 콘텐츠를 사용자에게 빠르고 안전하게 배포할 수 있는 CDN 서비스입니다. 사용자는 에지 로케이션에서 콘텐츠를 빠른 속도로 안전하게 전송받을 수 있습니다. 여기서 말하는 에지 로케이션은 무엇일까요?

에지 로케이션

에지 로케이션은 오리진 서버의 콘텐츠를 서로 다른 지역에서 빠르게 접근할 수 있도록 만드는 캐시 서버의 모음입니다. 예를 들어 다음과 같이 서로 다른 지역의 사용자 A, B, C가 있을 때 독일, 미국에서 거주하는 사용자 B, C가 서울에 있는 오리진 서버의 데이터에 접근한다면 어떻게 될까요?

아마도 사용자 A가 데이터 접근이 가장 빠르고 사용자 B, C는 느릴 것입니다. 이를 해결하려면 사용자 B, C가 접근하고자 하는 데이터를 중간에 캐시하면 됩니다. 에지 로케이션은 사용자와 오리진 서버 사이에서 데이터를 캐시하는 역할을 합니다. 만약 에지 로케이션에 캐시가 남아 있다면 사용자에게 캐시를 반환하고, 캐시가 없다면 오리진 서버에서 데이터를 검색하여 에지 로케이션에 캐시를 저장한 다음 사용자에게 반환합니다.

AWS는 에지 로케이션을 이용하여 Amazon CloudFront라는 CDN 서비스를 제공합니다. 사용자는 가장 가까운 에지 로케이션에서 콘텐츠를 빠른 속도로 안전하게 전송받을 수 있고 서버의 트래픽과 비용까지 절감할 수 있습니다. 다음 그림과 같이 AWS에서 제공하는 Amazon CloudFront를 사용하면 각 리전에서는 에지 로케이션을 통해 빠르게 사용자가 원하는 데이터에 액세스할 수 있습니다. 하지만, 에지 로케이션에 캐시가 없다면 먼 거리의 오리진 서버에서 콘텐츠를 취득해야 합니다. 이러한 상황이 발생한다면 어떻게 문제를 해결해야 할까요?

이러한 문제를 해결하는 방법은 바로 오리진 서버와 에지 로케이션 사이에 캐시 서버를 배치하는 것입니다. 이렇게 캐시 서버를 배치함으로써 캐시 서버에 저장된 데이터는 에지 로에키션에서 바로 접근하여 사용자에게 콘텐츠를 제공할 수 있습니다. 여기서 중요한 부분은 캐시 가능한 용량에 있습니다. 에지 로케이션은 용량 문제로 자주 접근하는 데이터만을 캐시하고, 다른 캐시를 삭제하여 최적화합니다. 반면, 캐시 서버는 더 큰 캐시를 저장할 수 있기 때문에 오리진 서버로 직접 접근하는 빈도를 줄일 수 있으며, 오리진 서버에 직접 접근하지 않고도 사용자에게 캐시를 반환할 수 있습니다. 이러한 캐시 서버는 사용자로부터 물리적으로 가까운 거리에 위치하기 때문에 성능 저하를 줄일 수 있습니다.

연동 가능한 서비스

Amazon CloudFront는 다양한 서비스와의 연동을 제공합니다. Amazon Route53, Amazon S3, Amazon EC2, Elastic Load Balancer와 같은 서비스와 연동할 수 있으며, 사용자는 Amazon CloudFront를 통해 보다 빠르게 콘텐츠를 전송받아볼 수 있습니다.

예를 들어, Amazon CloudFront에 Amazon Route53와 웹 사이트를 운영하고 있는 Amazon EC2에 Load Balancer를 연동합니다. 사용자는 브라우저에 도메인을 입력하여 웹 사이트에 접속을 시도하면, Amazon Route53를 통해 해당 도메인 이름이 연결된 Amazon CloudFront의 엔드포인트로 이동하며, 사용자가 위치한 가장 가까운 에지 로케이션에서 콘텐츠를 빠르게 전송합니다. 또한, 캐시 서버가 있으므로 사용자는 오리진 서버인 EC2 인스턴스에 직접 접근할 필요 없이, 캐시 서버에 저장된 데이터를 바탕으로 사용자에게 콘텐츠를 제공할 수 있습니다.

Amazon CloudFront를 사용하기 전 알아야 할 것들

앞서 살펴본 것 처럼 Amazon CloudFront에는 오리진 서버, 에지 로케이션 등 생소한 용어들이 등장합니다.

이번에는 Amazon CloudFront를 사용하기 전에 알아야 할 용어들에 대해 배워보도록 합시다.

오리진 도메인

오리진 도메인은 사용자에게 제공할 콘텐츠의 리소스를 의미합니다. 이 오리진 도메인은 주로 웹 서버 등의 콘텐츠 제공자가 위치한 서버를 가리킵니다.

오리진 경로와 오리진 액세스

Amazon CloudFront를 생성하면, 배포 도메인 이름이 생성되며 사용자는 이 배포 도메인 이름을 사용하여 콘텐츠에 접근할 수 있습니다. 또한, Amazon CloudFront에서는 오리진 경로를 설정할 수 있습니다.

기본적으로 오리진 경로는 상위 경로가 설정되어 있습니다. 예를 들어 Amazon S3의 file 객체에 접근하기 위해서는 [배포 도메인 이름] + [file] 형식, 즉 https://xxxxx.cloudfront.net/file 형식으로 접근을 합니다. 여기서 Amazon S3의 production 폴더를 기본 오리진 경로로 지정했다면, [배포 도메인 이름] + [file] 에 대한 접근을 요청했을 때, 실제로는 [배포 도메인 이름] + [production] + [file]에 대한 요청이 이루어집니다.

그 외, Amazon CloudFront는 OAI 즉, Origin Access Identity를 설정하여 Amazon CloudFront를 통해서만 접근할 수 있도록 설정할 수 있습니다. OAI는 Amazon CloudFront의 에지 로케이션과 오리진 서버 사이의 인증을 관리합니다. OAI를 설정하는 이유는 외부로부터 S3 버킷에 대한 직접적인 접근을 금지하고 Amazon CloudFront를 통해서만 액세스 권한을 수행하도록 하기 위함입니다. 이렇게 함으로써 보안을 강화하고, 콘텐츠에 대한 액세스를 CloudFront를 통해 제어할 수 있습니다. 보안 모범 사례로 가장 최근 업데이트 혹은 업그레이드 된 기능을 사용하는 것을 권장하며, 기존에 OAI를 사용하고 있는 사용자도 OAC로 마이그레이션 하는 것을 권하고 있습니다.

경로 패턴과 뷰어

경로 패턴은 오리진 경로와 달리 경로 패턴을 설정하면 경로에 따라 원하는 파일이 저장된 S3 버킷으로 라우팅하거나 로드 밸런서로 라우팅 하는 등 결로를 기반으로 라우팅을 할 수 있습니다.

뷰어에는 다음과 같은 설정을 실시할 수 있습니다.

• 뷰어 프로토콜 정책
• 허용된 HTTP 메소드
• 뷰어 액세스 제한

먼저 뷰어 프로토콜 정책은 다음 옵션을 지정할 수 있습니다.

• HTTP and HTTPS : HTTP 혹은 HTTPS로의 접근을 허용합니다. 사용자는 HTTP와 HTTPS 프로토콜로 접근할 수 있습니다.
• Redirect HTTP to HTTPS : HTTP로 접근할 시 HTTPS로 리다이렉션하여 보안 연결을 강제합니다.
• HTTPS only : HTTPS 접근만을 허용합니다.

허용된 HTTP 메소드에서는 GET, HEAD, POST, PUT, DELETE, OPTIONS와 같은 허용할 HTTP 메소드를 지정합니다. 예를 들어 GET의 경우 리소스의 정보를 요청하는 메소드이며, 서버에서 클라이언트로 데이터를 전달합니다. 선택할 수 있는 옵션은 다음과 같습니다.

• GET, HEAD
• GET, HEAD, OPTIONS
• GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE

뷰어 액세스 제한은 No, Yes를 선택할 수 있으며, 기본적으로 뷰어 액세스 제한은 No로 설정되어 있습니다. 뷰어 액세스를 제한하는 경우에는 서명된 URL 또는 서명된 쿠키를 사용하여 콘텐츠에 접근해야합니다. 서명된 URL은 일정 시간동안 콘텐츠에 접근할 수 있는 URL 혹은 쿠키를 의미하며, 설정한 시간이 지나면 사용할 수 없기 때문에 다시 서명된 URL 혹은 쿠키를 받을 필요가 있습니다. 이러한 뷰어 액세스 제한은 기간 한정으로 공개하는 웹 사이트나 특정 회원을 대상으로 하는 사이트에 적합합니다.

캐시 정책과 가격 분류

캐시 정책에서는 TTL, 헤더, 쿼리 문자열, 쿠키를 설정할 수 있습니다. TTL은 Amazon CloudFront가 콘텐츠를 캐시하는 시간을 나타냅니다. TTL을 길게 설정하면, 사용자가 콘텐츠에 대한 요청을 할 때 Amazon CloudFront가 로컬 캐시에서 해당 콘텐츠를 찾을 가능성이 높아지기 때문에 웹 사이트의 성능을 향상시킬 수 있습니다.

하지만, TTL을 길게 설정하면 서버 측에서 컨텐츠를 업로드하여도 Amazon CloudFront에서 캐시한 콘텐츠가 업데이트 되지 않을 수 있습니다. 즉, 사용자에게 새로운 콘텐츠가 제공되지 않고 이전 콘텐츠가 제공될 가능성이 있습니다. 이러한 캐시 정책을 고려할 때 캐시 히트 비율을 생각해야 합니다. 캐시 히트 비율은 Amazon CloudFront가 캐시한 파일을 사용자에게 반환하면 캐시 적중률이 높아지며, 사용자가 요청한 파일이 없으면 오리진 서버에 파일을 요청하기 때문에 캐시 적중률이 감소합니다. 이것을 캐시 히트 비율이라고 하며, 이 캐시 히트를 높이려면 TTL로 캐시하는 시간을 적절하게 늘리거나 보다 상세하게 캐시 설정을 수행할 필요가 있습니다. 캐시 정책에서 헤더, 쿼리 문자열, 쿠키를 설정하면 보다 상세하게 캐시 설정이 가능합니다. 예를 들어 헤더, 쿼리 문자열, 쿠키와 같은 정보가 요청에 포함된 경우에만 캐시를 수행하는 설정이 가능합니다.

Amazon CloudFront에서는 다음 세 가지 가격 분류를 선택할 수 있습니다.

• 모든 에지 로케이션에서 사용(최고의 성능) : 모든 지역의 에지 로케이션에서 서비스를 제공받을 수 있습니다.
• 북미 및 유럽만 사용 : 북미와 유럽 지역의 에지 로케이션에서만 서비스를 받을 수 있습니다.
• 북미, 유럽, 아시아, 중동 및 아프리카에서 사용 : 북미, 유럽, 아시아, 중동 및 아프리카 지역의 에지 로케이션에서 서비스를 받을 수 있습니다.

모든 엣지 로케이션은 다른 옵션에 비해 높은 비용을 필요로 하지만, 모든 지역에서 에지 로케이션을 사용할 수 있어 모든 사용자에게 빠르게 콘텐츠를 제공할 수 있는 장점이 있습니다.

마무리

이번 블로그에서는 Amazon CloudFront에 대해 살펴보았으며, Amazon CloudFront를 사용하기 전에 이해하고 넘어갔으면 하는 부분들을 정리해 봤습니다.

Amazon CloudFront를 활용하기 전에, 기본적인 Amazon CloudFront의 동작 원리와 용어에 대해 알고 싶은 분들에게 도움이 되었으면 좋겠습니다.

이상, 한국어 블로그 릴레이의 첫 번째 블로그「Amazon CloudFront 입문」편이었습니다. 다음 두 번째 블로그 릴레이는 임채정 님의 「ec2 인스턴스의 SSH 접속의 작동 방법을 알아봤다」 입니다.

끝까지 읽어주셔서 감사합니다! 이상, AWS 사업 본부의 김재욱이었습니다.