[AWS] CloudFront

CloudFront

cloudfront는 동적, 정적, 실시간 웹사이트 컨텐츠를 사용자에게 더 빨리 전달하기 위해 나온 서비스다. 

 

CDN이라는 개념을 이해하는게 중요하다. Content Delivery network의 약어로 웹페이지가 어디에서 호출되는지, 웹페이지를 호출한 사용자가 어느 지역에 거주하는지 등에 근거하여 웹페이지에 전달해준다.

-> cdn을 통해 html, javascript, image 등 컨텐츠들의 로딩 속도를 아주 빠르게 향상시킬 수 있다.

 

예) 한국에서 호스팅중인 웹사이트에 전 세계 각지에서 접근하려하면 지역마다 웹페이지의 로딩 속도가 다를 것이다. (이때 한국은 origin이라고 부름)멀어질수록 더욱 느리다. CDN은 사용자에게 가까운 위치에 있는 Edge Location을 통해 컨텐츠를 전달한다. (엣지 로케이션은 ATM이다.)

O는 Origin, E는 Edge Location

 

 

엣지 로케이션은 컨텐츠들의 정보를 캐시에 저장하고, 만약 엣지로케이션의 캐시에 컨텐츠가 없다면 오리진으로부터 컨텐츠를 받아와서 캐시에 저장하여 뿌린다. -> 그 이후 요청은 캐시를 참조하여 더욱 빠르게 전달된다. 하지만 캐시에 저장된 컨텐츠는 영구적으로 저장되지 않는다.

 

관련 용어

Edge Location : 컨텐츠들이 캐시에 보관되어지는 장소

Origin : 원래 컨텐츠가 있는 곳, 웹서버 호스팅 지역 -> S3, EC2 인스턴스가 오리진이 될 수 있다.

Distribution : CDN에서 사용되며 Edge Location을 묶고 있다는 개념

 

CloudFront를 써보자

1. 버킷을 만들어보자(origin을 만드는 것)

public한 버킷을 위해 아래와 같이 ACL 설정과 public access를 허용해주었다.

 

2. 생성한 버킷에 object를 올리자

실제 업무를 진행할때는 ACL을 진행해 권한을 제한해야 하지만 원활한 실습을 위해 object에도 public 권한을 부여했다.

 

그리고 파일을 열어보면 상당히 빠르게 열린다. 왜냐면 서울 리전에서 버킷을 생성했기 때문이다. 똑같은 과정으로 다른 리전에 버킷을 생성하고 동일한 파일을 업로드 한 다음 파일을 열어보자.

 

세부 권한 설정은 위와 동일함. ACL, public access 부여

그 다음 object url을 통해 사진을 띄워보자.

 

육안상으로는 큰 차이가 없지만 서울 리전은 사진을 불러오기까지 21ms, 버지니아는 221ms가 소요되었다. 무려 10배차이다. 이만큼 차이가 난다

왼쪽이 서울 / 오른쪽이 버지니아

 

cloudfront를 진짜로 만들어보자

cloudfront 생성 화면으로 가면

 

origin domain : origin domain을 선택해준다.

origin path : 선택사항이며, 버킷에 여러 폴더가 존재하고 특정 폴더 선택만 하기 위해 존재한다.

origin access : public-> 누구나 접근 가능 / origin access control settings-> 버킷의 컨텐츠는 cloudfront를 통해서만 접근이 가능 / legacy access identities-> OAI(origin access identity)를 이용하여 접근, OAI는 클라우드 프론트에 존재하는 가상 신원임. 해당 실습에서는 legacy access identities로 설정하여 진행했다.

 

create new OAI를 생성하고 그것을 그대로 사용하면 된다. 

 

그리고 bucket policy를 적용하여 버킷의 읽기 권한을 OAI에게 부여해주기 위해 사용한다고 체크해주었다.

 

origin shield의 원본 부하를 줄이고 가용성을 향상시켜준다는데 추가 비용이 발생하기 때문에 No 체크하였다.

 

 

자동 압축은 aceept-encoding 헤더에 뷰어가 지정된 경우에만 사용 가능하다고 하니 참고하면 좋을 것 같다.

restrict viewer access 옵션을 사용하면 cloudfront에 서명된 url이나 서명된 쿠키를 사용해야만 컨텐츠에 접근 가능

함수 연결 - cloudfront를 사용하며 생기는 다양한 이벤트를 개발자가 구현한 코드에 근거하여 처리한다는 뜻임(cloudfron function과 lambda function 중 선택하여 사용 가능)

 

옵션은 대부분 기본 옵션을 적용하였으며 optional인 경우 선택을 하지 않았다.

 

가장 중요한 비용 관리를 위해 최대 갯수의 edge location를 만들지 않고 Use North America, Europe, Asia, Middle East, and Africa 옵션을 선택하였다.

 

CloudFront 살펴보기

Origin 탭에 들어가면 origin 파일의 정보가 보인다.

 

그리고 behaviors 탭에 가면 아까 선택한 viewr protocol도 볼 수 있다.

 

CloudFront에서 파일 접근하기

Distribution domain name + 파일 이름으로 접근이 가능하다.

 

만약 파일 이름이 abc.jpg라면 https://test.cloudfront.net/abc.jpg or http://test.cloudfront.net/abc.image가가 될 것이다. 앞에 에 http나 https와 같이 viewer protocol도 생성한 규칙마다 다르다. 참고하면 좋다.

 

캡처를 못했지만 첫 접근때는 700ms 정도 걸렸는데, 다시 접근했더니 서울 리전보다 2ms 빠른 속도로 로딩이 되었다. 왜냐면 처음에는 origin에 요청해서 컨텐츠를 갖고와 캐시에 저장하고 제공해주기 때문이다.

 

 

cloudfront 바로 삭제하기

실습을 다 마치고 정리하려는데 cloudfront는 바로 delete가 활성화가 되지 않았다.

이는 캐시에 저장된 데이터 때문이라는데,,

 

cloudfront의 invalidation 옵션에서 제거할 캐시의 경로를 지정해주자. 파일이 한개밖에 없었지만 파일 이름이 길기도 해서 /* 로 전체를 날려버린다고 했다.

 

create invalidation을 하니 약간의 시간이 흐른 후 delete가 활성화되어 삭제까지 완료하였다.