AWS CloudFront(CDN)

CloudFront 란?

- CDN(Contents Delivery Network) 서비스를 AWS에서 CloudFront라 부름

- Html, CSS, js 및 이미지 파일과 같은 정적 및 동적 웹 컨텐츠를 사용자에게 더 빨리 배포하도록 지원하는 웹 서비스 (정적 웹 사이트 콘텐츠 전송 속도 향샹)

CloudFront(CDN) 구동 방식

Simple 

1. 사용자가 웹사이트에 접속하여 이미지 파일 및 HTML 파일을 요청

2. DNS가 요청을 최적으로 서비스할 수 있는 CloudFront Edge Location에 요청을 라우팅 (지연시간과 관련해 가장 가까운 CloudFront Edge Location임)

3. Edge Location에서 CloudFront는 해당 캐시에 요청된 파일이 있는지 확인하고 없다면 아래와 같은 절차 수행

    3-1) CloudFront는 파일 형식에 적절한 오리진 서버 (이미지 파일 - S3 버킷 / HTML 파일 - HTTP 서버)로 전달

    3-2) 오리진서버는 다시 CloudFront로 파일 전달

    3-3) CloudFront는 오리진서버에서 첫번째 Byte가 도착하면 파일을 사용자에게 전달하기 시작 (이때 해당 파일을 캐시에 추가)

Detail

1. www.terry.com 라는 웹사이트로 Client가 접속

2. Client는 DNS 서버를 통해서 www.terry.com 의 주소를 Lookup 한다. 이 때 www.terry.com은 Cloud Front의 URL로 맵핑이 되어있어야 하는데 CNAME 레코드를 이용하여 www.terry.com을 해당 사이트에 대한 CloudFront URL로 맵핑해 놓는다. 여기서 asdf.cloudfront.net 이라고 가정

3. Client는  asdf.cloudfront.net 의 주소를 다시 Lookup하는데 Route53에 의해서 Client와 가장 가까운 위치에 있는 CloudFront의 Edge Node 두소를 Return 받게 된다

4. Client는 리턴 받은 IP를 가지고 CloudFront의 Edge Server로 접속

5. CloudFront에서는 URL에 따라 리소스의 위치를 Rule로 정해 놓는데 위의 예제에서는 /image 디렉토리의 파일은 S3에 원본을 두고 CloudFront에 캐싱하도록 하고 /css 아래 파일들은 원격지(AWS 서비스가 아닌 HTTP 서버)에 있는 서버에 캐싱을 하도록 하였다. *.jsp 파일은 캐싱 없이 직접 원본 서버로 가도록 구성

6. 만약 /image 나 /css 에 있는 파일을 Client가 요청하였을 경우 Edge Node에 캐쉬를 체크해보고 캐쉬에 내용이 없다면 원본 서버(Origin Server)로부터 파일을 읽어 캐쉬에 저장한 후 Client에게 리턴한다. 캐쉬에 있을 경우 바로 Client에게 리턴

(Origin Server : 원본 파일이 저장된 곳, AWS S3 버킷 이나 EC2 인스턴스 또는 다른 서버가 될 수 있음)

서비스 가능한 컨텐츠 종류 및 Cache 동작

CloudFront 서비스 가능한 컨텐츠

1. Download Distribution : HTTP 프로토콜을 이용해서 다운로드 받을 수 있는 이미지나 기타 정적인 리소스 파일

2. Streaming Distribution : HTTP Progressive Download 나 RTSP (Real Time Streaming Protocol)을 지원하는 동영상 컨텐츠

Cache 동작

- CDN은 기본적으로 컨텐츠를 Edge Node에 캐쉬 해놓는 것을 기본 기능으로 하는데 캐쉬이기 때문에 유지시간이 있다. 유지시간 TTL의 기본 시간은 24시간이고 최대 1시간 까지 줄일 수 있다.

- 만약 파일을 잘못 올렸거나 수정이 필요할 때 캐쉬의 TTL 시간에 의해서 수정한 부분이 Edge Node에 반영되는 시간은 최소 1시간이 소요된다.

- 위의 문제를 해결하기 위해 CloudFront는 Invalidation API (특정 파일을 캐쉬에서 지우는 기능)를 제공하는데 한번에 3개의 invalidation request 밖에 실행할 수 없고 각 invalidation request는 최대 1000개의 파일까지만 지원한다. 그리고 invalidation request는 모든 Edge node에 반영되어야 하기 때문에 보통 5-10분 정도의 시간이 소요된다.

- 캐쉬에 컨텐츠를 업데이트하는 시간을 줄이는 방법

• 파일명 변경
  - 좀 더 빠르게 캐쉬에서 컨텐츠를 업데이트 하기 위해서는 버전을 사용하기를 권장하는데 이 말의 의미는 파일명을 바꾸도록 하는 것이다.
  (Ex. /image/photo.png가 있을때 이 파일이 변경되기를 원할 경우 HTML 원본에서 해당 이미지 명을 /image/photo_v2.png로 변경하고 새로운 파일명도 photo_v2.png로 저장을 하면 별도의 cache invalidation 작업 없이 바로 변경 내용을 반영할 수 있음)
• Query String
  - 파일명을 바꾸는게 어려울 경우 Query String을 사용할 수 있음
  (Ex. /image/photo.png?version=1.0 으로 HTML에서 이미지 경로를 걸어 놓으면 CloudFront는 “photo.png?version=1.0”을 Key로 캐쉬에 파일을 저장한다. Origin Server에 이렇게 파일을 요청하게 되면 이 파일은 정적인 컨텐츠이기 때문에 Query String은 무시되고 Origin Server는 “photo.png” 파일만 리턴한다. 원본 컨텐츠가 바뀌었을 경우, 원본 컨텐츠의 파일명은 변환할 필요가 없이 똑같이 “photo.png” 파일로 저장을 하되 HTML의 참조명을 /image/photo.png?version=2.0 으로만 변경해주면 CloudFront 입장에서 리소스의 이름이 아까와 다른 이름이기 때문에 캐쉬에서 찾지 못하고 다시 Origin Server로 요청하게 된다.)
  - Query String을 버전명으로 사용하기위해서는 CloudFront 설정에서 Query String by pass 기능을 On 해주어야 함

비공개 컨텐츠에 대한 접근 제어

- 정적인 컨텐츠를 다루다 보면 특정 사용자에게만 서비스를 제공해야하는 경우가 있음 (유료 다운로드 , 유료 동영상 서비스 등등)

- CloudFront는 Signed URL 이라는 기능을 이용해서 CDN 컨텐츠에 대한 접근 제어 기능을 제공

- 구동 원리는 CDN의 특정파일에 대한 접근 권한을 {ip 주소, 다운로드 가능 시간 - 끝} {접근 권한의 각 필드는 필수가 아닌 선택 사항 / IP 주소는 특정 IP나 IP 주소 대역으로 지정 가능} 으로 정하고 URL을 생성한 후 암호화하여 사용자에게 제공하고 해당 URL로 CDN 내의 컨텐츠를 접근하면 접근 권한에 정의된 조건을 충족하면 다운로드 할 수 있게 해준다.

(Ex. 샘플

• 1번 부분은 리소스 파일명을 정의
• 2-3번 부분은 Query String을 정의하는 부분으로 Origin Server로 전달되는 Query String이다.
• 4번은 Policy로 접근 가능 정책 {IP 주소, 접근 가능 기간} 을 JSON으로 정의한 후에 Encoding한 String이다.
• 5번은 HMCA과 유사하게 이 URL이 변조되는 것을 막기 위해서 URL에 대한 Signature를 Base64 Encoding을 이용하여 생성해서 붙인 부분 (일종의 Hash 값으로 URL에 대한 Hash이고 URL 변조되면 이 Hash 값이 맞지 않음)
• 6번은 Key로 AWS CloudFront를 사용하기 위해서 발급된 Key

- Signed URL 이외에 사용자 계정을 통해서 접근을 제어할 수 있는 방법이 있는데, 이 계정은 아마존 계정 서비스인 IAM을 통해서 생성된 계정만 가능하다.

(IAM 계정 서비스는 최대 5000개의 계정만 생성 및 관리가 가능하기 때문에 대외 서비스보다 소규모 대내 서비스나 내부 관료용도로 CDN 접근 제어를 할 때 유용하게 사용 가능)

성능 향상 방법

1. Domain Sharding

- 일반적으로 웹 브라우저는 하나의 도메인 주소에 대해서 동시에 열 수 있는 Network Connection 수가 제한이 있다. 그런데 일반적인 웹 페이지에서 동시에 로딩되는 리소스는 대략 20-50개 정도 된다.

(웹 브라우저가 여는 Connection 수로는 한번에 모든 리소스 로딩이 어렵다는 것)

- CDN에도 적용될 수 있는 기법으로 하나의 시스템에 여러 도메인을 적용하는 것

- Ex) Server IP : 210.113.119.210 / Domain : www.terry.com 일 경우 CNAME으로 image.terry.com , css.terry.com , resource.terry.com 형식으로 여러개의 도메인을 같은 URL을 가리키도록 하고 HTML에서도 image url을 <src=“http://image.terry.com/img/image.png”> 식으로 지정해놓게 되면 브라우저 입장에서는 전혀 다른 사이트로 인식하기 때문에 별도의 Network Connection을 열 수 있다. 

- 해당 방법을 사용하면 브라우저의 Connection을 최대로 열어 전체적인 웹사이트 Loading Time을 증가시킬 수 있음

2. Compression

- CDN은 Network에 관련된 서비스이기 때문에 당연히 원본 컨텐츠의 Size가 작으면 사용하는 대역폭도 작아지고 성능이 높아진다.

- 압축 기능을 사용하기 위해서는 Origin Server가 Apache와 같은 웹서버인 경우에는 gzip 압축 기능을 웹서버에 적용해주면 되지만 S3를 Origin Server로 사용하는 경우에는 S3 자체에는 gzip 압축기능을 가지고 있지 않기 때문에 컨텐츠를 업로드 할때 gzip으로 압축해서 업로드 하고 “Content-Encoding”을 gzip으로 명기해주면 된다. 

참조 URL 

- https://bcho.tistory.com/796

- https://happyer16.tistory.com/entry/CloudFront%EB%9E%80