[AWS] CloudFront

CloudFront

• CDN(Content Delivery Network) = 컨텐츠 전송 네트워크이다.
• 웹사이트의 컨텐츠를 서로 다른 엣지 로케이션에 미리 캐싱하여 읽기 성능을 높이는 것이다.
• 컨텐츠가 네트워크 전체에 캐싱되므로 전세계 사용자들이 낮은 레이턴시로 접근할 수 있어서 사용자 경험을 증대 시킬 수 있다.
• 현재 CloudFront는 전세계에 있는 총 216개의 엣지 로케이션을 통해 구성되어 있다.
• 컨텐츠가 전체적으로 분산되어 있어서 DDoS 공격에서 보호를 받을 수 있다. 이 외에도 Shield, 방화벽 등이 있다.
    - DDoS : 동시에 모든 서버가 공격을 받는 방식

• 위의 AWS의 엣지 지돌르 보면, 전세계에 있는 AWS 엣지와 엣지 캐쉬 분포를 볼 수 있다.
• 가령 호주에 위치한 S3 버킷에 웹사이트를 만들었다 하더라도 미국에 있는 사용자는 CloudFront를 이용해 미국에 있는 엣지에 컨텐츠를 요청하게 된다. 그러면 CloudFront가 호주에서 이 컨텐츠를 페치해서 가져오게 된다. 그리고 미국의 다른 사용자가 똑같은 컨텐츠를 요청한다면, 이 컨텐츠는 호주에서 출발하지 않고 엣지에서 직접 컨텐츠를 제공받게 된다.
• 위와 같은 방식으로 컨텐츠를 제공받을 수 있다.

 

CloudFront - Origins

• CloudFront의 원본 제공 방식은 다음과 같다.

S3 bucket

• CloudFront를 통해 파일을 분산하고 캐싱할 수 있게 한다. 그리고 버킷에는 CloudFront만 접근할 수 있게 보장한다.
• 이를 가능하게 하는 것이 OCA라 불리는, Origin Access Contrl(원본 접근 제어)로 기존의 OAI를 대체한다.
• CloudFront를 통해 버킷에 데이터를 보내는 방법도 가능한데, 이를 Ingress라고 한다. 

Custom Origin (HTTP)

• HTTP 백엔드와 같은 사용자 정의 원본을 쓸 수 있다.
• 어플리케이션 로드 밸런서나 EC2 인스턴스, 또는 S3 웹사이트가 그 예시이다.
    - 단, S3 웹사이트의 경우 버킷을 활성화해서 정적 웹사이트로 설정해야 한다. 그 외의 다른 HTTP 백엔드도 가능하다.

 

CloudFront at a high level

• CloudFront의 작업 방식을 확인해보자.
• 전세계에 퍼져 있는 CloudFront의 엣지가 있고 여기에 연결할 원본이 있다. 이는 S3 버킷이나 HTTP 서버이다. 이제 클라이언트가 연결해서 엣지 로케이션에 HTTP 요청을 보내면, 엣지는 이것이 캐싱되어 있는지 확인한다.
• 캐싱되어 있지 않을 경우에는, 원본으로 가서 요청 결과를 가져온다. 그리고 결과를 가져오면서, 이를 로컬 캐시에 저장을 해서 다른 클라이언트가 같은 컨텐츠를 같은 엣지에 요청할 시 사용한다. 이러면 원본을 다시 가져올 필요가 없다.

 

CloudFront - S3 as an Origin

• S3를 원본으로 사용한다고 해보자.
• AWS 클라우드의 어떤 리전에 있는 S3 버킷이 원본일 것이다. 그리고 전세계의 엣지 로케이션이 있고 여기에서는 LA로 예시로 들어보겠습니다.
• LA 엣지에 접근하는 사용자는 LA 엣지가 직접 컨텐츠를 제공하게 된다. 하지만 먼저 내부 AWS 망을 통해 S3 버킷 원본을 받아오고, 이 버킷은 OAS로 보호받으며, S3 버킷 정채에 의해서만 수정할 수 있다.
• 브라질의 상파울로에 있는 사용자에게도 마찬가지로 적용된다. 브라질에서 가장 가까운 엣지가 있을 것이고, 내부망을 통해 버킷으로부터 원본을 받아 사용자에게 제공할 것이다.
• 이렇게 CloudFront과 엣지 로케이션을 이용해, 특정 리전에 속한 S3 버킷을 전세계의 엣지 로케이션으로 분산시킬 수 있다.

 

 

CloudFront  vs  S3 Cross Region Replication

CloudFront

• 전세계의 엣지 네트워크를 이용한다.
• 216개의 엣지 로케이션에 하루 동안 파일들이 캐싱된다.
    - 특히, 전세계를 대상으로 한 정적 컨텐츠를 사용하고자 할 때 용이하다.

S3 Cross Region Replication

• 복제를 원하는 각 리전에 이 설정이 되어 있어야 한다.
    - 즉, 전세계를 대상으로 한 것이 아니다.
• 파일은 거의 실시간으로 갱신된다.
    - 즉, 캐싱이 되지 않고, 또한 읽기 전용으로만 설정 가능하다.
• 일부 리전을 대상으로 동적 컨텐츠를 낮은 지연 시간으로 제공하고자 할 때 유용할 수 있다.

 

CloudFront는 전세계에 걸치 컨텐츠 전송 네트워크이며, 반면 S3 교차 리전 복제는 다른 리전으로의 버킷 복제인 것이다!

 

 

 

CloudFront  - EC2 or ALB as an origin

• 위에서 설명했듯이, CloudFront는 사용자 지정 HTTP 백엔드에도 접근 할 수 있다.
• 여기에는 EC2 인스턴스나 어플리케이션 로드 밸런서도 포함된다.

EC2

• EC2 인스턴스를 통해 HTTP 백엔드를 개발한다고 해보자.
• 사용자들이 CloudFront를 통해 접근하길 원하고, 사용자들은 CloudFront의 엣지 로케이션에 접근할 것이고, 어플리케이션이 EC2 인스턴스에 요청을 보낼 것이다.
• 따라서 위의 둘은 모두 퍼블릭으로 설정되어야 한다. 그렇지 않으면, CloudFront에는 가상 프라이빗 클라우드가 없기 때문에 EC2 인스턴스에 접근할 수 없게 된다.
• 따라서 엣지 로케이션의 모든 공용 IP가 EC2에 접근 할 수 있도록 하는 보안 그룹 역시 설정해줘야 한다.
• CloudFront의 IP 목록은 이 URL을 따라가면 확인할 수 있다.

 

ALB

• EC2와 마찬가지로 공용 설정이 되어야 한다.
• 반면 백엔드의 EC2 인스턴스는 프라이빗 설정을 사용해도 문제 없다. 로드 밸러스와 인스턴스 간에 가상 프라이빗 네트워크가 설정되어 있으니깐 단순히 EC2 인스턴스의 보안 그룹이 로드 밸런서를 허용하게끔 설정해주면 된다.
• 사용자는 엣지 로케이션으로 접근하기 때문에, 연결이 맺어질 수 있도록 어플리케이션의 공용 IP가 로드 밸런서의 보안 그룹 정책에 허용이 되어 있어야 한다.

 

 

CloudFront - Geo Restricion(지리적 제한)

• 배포판에 접근할 수 있는 사용자를 국가에 따라 제한할 수 있다.
• 허용 목록을 설정하여 승인 국가 목록을 정의할 수 있다. 또는 차단 목록을 설정하여 금기 국가 목록을 설정할 수 있다.
• 국가는 GeoIP 데이터베이스를 사용하여 사용자의 IP를 해당 국가에 매핑하는 방식으로 결정된다. 
• 지리적 제한을 사용하는 사례는 콘텐츠에 대한 접근을 제어하기 위한 저작권법이다. 따라서 지리적 제한을 설정하려면 보안(security)으로 가야한다.

 

 

CloudFront - Pricing(요금)

• CloudFront 엣지 로케이션은 전 세계에 고루 분포해 있고 전역에 퍼져 있으므로, 엣지 로케이션마다 데이터 전송 비용이 다르다.
• 위의 이미지가 바로 요금표이다. 보시다시피 엣지 로케이션이 위치한 대륙이나 지리 위치에 따라 각기 다른 요금이 책정되어 있다.
• 도표의 숫자를 보면 멕시코, 미국, 캐나다의 경우 첫 10GB는 1GB당 0.085달러가 든다. 하지만 인도의 엣지 로케이션같은 조건에서 전송된 데이터에 대해 1GB당 두 배인 0.17달러가 든다.
• CloudFront에서 더 많은 데이터가 전송될수록 비용은 낮아진다.
• CloudFront의 미국 엣지 로케이션에서 5PB 이상 전송하면 1GB당 0.02달러가 든다.
• 왼쪽에서 오른쪽으로 갈 수록 비용이 비싸진다.

 

CloudFront - Price Classes(가격 등급)

• 비용 절감을 위해 CloudFront를 분산할 전 세계 엣지 로케이션 수를 줄이는 방법이 있다.
• 모든 리전을 사용하며 최상의 성능을 제공하는 Price Class All은 비용이 다소 많이 든다. 왜냐면 위의 이미지로 보시다시피 인도 엣지 로케이션이 미국 엣지 로케이션보다 비싸다.
• 대부분의 리전을 사용할 수 있지만 가장 비싼 리전은 제외이다.
• Price Class 100은 가장 저렴한 리전만 사용할 수 있다.

 

• 위의 그림을 보면 전 세계에는 수 많은 엣지 로케이션이 있다.
• Price Class 100은 북미와 유럽 엣지 로케이션을 제공한다.
• Price Class 200은 일부 리전이 추가된다.
• Price Class All은 전 세계 모든 엣지 로케이션을 사용한다.

 

 

CloudFront - Cache Invalidations(캐시 무효화)

• CloudFront에는 항상 백엔드 오리진이 있고, CloudFront 엣지 로케이션은 백엔드 오리진을 업데이트 할 때 업데이트 사항을 모를 것이다. 캐시의 TTL(Time To Live)가 만료되면 백엔드 오리진으로부터 업데이트된 콘텐츠를 받게 된다. 하지만 이런 동작을 원하지 않고 최대한 빨리 새 콘텐츠를 받고 싶을 수도 있다.
  그래서 우리는 전체 또는 일부의 캐시를 강제로 새로고침해서 캐시에 있는 TTL을 모두 제거할 수 있다.
• CloudFront 무효화를 실행하기 위해서는 특정 파일 경로를 전달해야 한다. 별표(*)로 시작하는 파일이나 /images/*와 같은 특정 경로를 무효화 할 수 있다.

• 위의 예시를 통해 작동원리를 알아보자.
• 여러 엣지 로케이션 CloudFront를 분산하고 각 엣지 로케이션이 가진 고유의 캐시에는 index.html파일과 오리진인 S3 버킷에서 가져온 이미지가 있다고 가정해보자.
  이 파일들의 TTL을 하루로 설정할 수 있는데 즉, 하루 24시간 안에 엣지 로케이션이 이 파일들을 캐시로 다시 가져오는 것이다. 관리자인 우리는 S3 버킷에 이 파일들을 업데이트 할 것이다. 이미지를 추가하거나 바꾸고 index.html 파일도 수정할 것이다. 또 해당 업데이트 사항이 CloudFront 사용자에게 최대한 빨리 반영되길 원할 것이다.
  이럴 땐 두가지 경로를 무효화하면 된다.
    - 첫 번째는 특정 파일을 무효화하는 /index.html이다.
    - 두 번째는 무효화할 경로는 엣지 로케이션의 캐시에 있는 모든 이미지를 지우는 /images/*이다.
• CloudFront는 캐시에서 이 두 파일을 무효화하도록 엣지 로케이션에 지시할 거고, 엣지 로케이션은 캐시로부터 파일을 지울 것이다. 이후에 사용자가 index.html 파일을 요청하면 특정 엣지 로케이션에 CloudFront가 요청을 보내면 더 이상 캐시에 해당 파일이 없다는 것을 알테고 그럼 엣지 로케이션은 오리진에 요청해서 업데이트된 새로운 index.html 파일을 받을 것이다.