[AWS] 📚 CloudFront 개념 원리 & 사용 세팅 💯 정리

...

CloudFront

클라우드프론트는 개발자 친화적 환경에서 짧은 지연 시간과 빠른 전송 속도로 데이터, 동영상, 애플리케이션 및 API를 전세계 고객에게 안전하게 전송하는 고속 콘텐츠 전송 네트워크(CDN) 서비스이다.

CloudFront는 CDN 서비스와 이외에도 기본 보안 기능(Anti-DDoS)을 제공한다.

CDN 이란?

CDN(Content Delivery Network or Content Distribution Network, 콘텐츠 전송 네트워크) 은 콘텐츠를 효율적으로 전달하기 위해 여러 노드를 가진 네트워크에 데이터를 저장하여 제공하는 시스템이다.

인터넷 서비스 제공자(ISP,Internet Service Provider)에 직접 연결되어 데이터를 전송하므로, 콘텐츠 병목을 피할 수 있는 장점이 있다.

우리가 프론트 공부할때 제이쿼리 같은 라이브러리를 링크 src로 불러온적이 있을텐데, 이게 바로 CDN 서비스를 이용하는 것이라고 보면 된다.

CDN 특징

웹 페이지, 이미지, 동영상 등의 컨텐츠를 본래 서버에서 받아와 캐싱
해당 컨텐츠에 대한 요청이 들어오면 캐싱해 둔 컨텐츠를 제공
컨텐츠를 제공하는 서버와 실제 요청 지점 간의 지리적 거리가 매우 먼 경우 or 통신 환경이 안좋은 경우
→ 요청지점의 CDN을 통해 빠르게 컨텐츠 제공 가능
서버의 요청이 필요 없기 때문에 서버의 부하를 낮추는 효과

엣지 로케이션

컨텐츠가 캐싱되고 유저에게 제공되는 지점
AWS가 CDN 을 제공하기 위해서 만든 서비스인 CloudFront의 캐시 서버 (데이터 센터의 전 세계 네트워크)
cloudFront 서비스는 엣지 로케이션을 통해 콘텐츠를 제공
CloudFront를 통해 서비스하는 콘텐츠를 사용자가 요청하면 지연 시간이 가장 낮은 엣지 로케이션으로 라우팅되므로 콘텐츠 전송 성능이 뛰어나다.
콘텐츠가 이미 지연 시간이 가장 낮은 엣지 로케이션에 있는 경우 CloudFront가 콘텐츠를 즉시 제공

[AWS] 📚 아마존 웹 서비스 구조 (Region / AZ / Edge Location / Cache) 완벽 정리

AWS 글로벌 인프라 구성 AWS 글로벌 인프라는 리전(Region), 가용영역(AZ, Availability Zones), 엣지 로케이션(Edge Location), 리전 엣지 캐시(Regional Edge Cache) 네가지 요소로 구성 되어 있다. AWS를 입..

inpa.tistory.com

CloudFront 동작방식

CloudFront는 AWS 백본 네트워크를 통해 콘텐츠를 가장 효과적으로 서비스할 수 있는 엣지로 각 사용자 요청을 라우팅하여 콘텐츠 배포 속도를 높인다.

일반적으로 CloudFront 엣지가 최종 사용자에게 가장 빨리 제공한다.

콘텐츠가 엣지 로케이션에 없는 경우
- CloudFront는 콘텐츠의 최종 버전에 대한 소스로 지정된 오리진(Amazon S3 버킷, MediaPackge 채널, HTTP 서버(예 : 웹 서버)등) 에서 콘텐츠를 검색
- 컨텐츠를 제공하는 근원에서 제공받아 전달
콘텐츠가 엣지 로케이션에 있는 경우
- 바로 전달

예시를 들어보자.

우리나라의 대표적인 스트리밍 서비스는 아프리카 TV가 있다고 하자.

만일 미국과 남아프리카, 호주에서 우리나라 서비스 아프리카TV의 방송이나 영상을 보고 싶다면, 당연히 아프리카TV 본사가 위치하고 있는 한반도 리전에 접속해서 다운로드 해야 한다.

사진에서 볼수 있듯이 길게 설명안해도 속도가 엄청나게 느릴것 같아 보인다.

거기다 오늘 보고 끄고, 내일 또 방송을 보고싶을때 그 멀리까지 다시 연결해 다운받아야 할 것이다.

이러한 단점을 극복하기위해 엣지 로케이션 이라는 개념과 시설을 사용 하는 것이다.

각 거점마다 가깝고 적당한 곳에 엣지 로케이션(임시 데이터 저장소 센터)을 배치한다. 하늘색 바둑알이 엣지 로케이션이다.

그러면 각 대륙의 사람들(검은색 바둑알)은 가까이 위치한 지역내의 엣지 로케이션에 접속해 스트리밍 서비스를 이용할 수 있게 된다.

당연히 훨씬 속도 면에서 유리하고, 또한 일정기간동안 요청한 데이터를 저장하는 기능(캐시, 콘텐츠 복사)도 갖춰 있어서 오늘 보고 내일 또 보고싶을때 저 멀리 까지 재연결 하는 일 없이 바로바로 볼 수 있는 장점도 있다.

그리고 이 엣지로케이션에 내 서비스를 등록하는 AWS 서비스가 바로 CloudFront이다.

CloudFront 데이터 전달 과정

클라이언트로부터 Edge Server로의 요청이 발생한다.
Edge Server는 요청이 발생한 데이터에 대하여 캐싱 여부를 확인
사용자의 근거리에 위치한 Edge Server 중 캐싱 데이터가 존재한다면 사용자의 요청에 맞는 데이터를 응답
사용자의 요청에 적합한 데이터가 캐싱되어 있지 않은 경우 Origin Server로 요청이 포워딩
요청받은 데이터에 대해 Origin Server에서 획득한 후 Edge Server에 캐싱 데이터를 생성하고, 클라이언트로 응답이 발생

CloudFront 장점

AWS 네트워크를 사용하면 사용자의 요청이 반드시 통과해야 하는 네트워크의 수가 줄어들어 성능이 향상
파일의 첫 바이트를 로드하는 데 걸리는 지연 시간이 줄어들고 데이터 전송 속도가 빨라진다.
파일(객체)의 사본이 전 세계 여러 엣지 로케이션에 유지(또는 캐시)되므로 안정성과 가용성이 향상
보안성 향상
- 오리진 서버에 대한 종단 간 연결의 보안이 보장됨(https)
- 서명된 URL 및 쿠키 사용 옵션으로 자체 사용자 지정 오리진에서 프라이빗 콘텐츠를 제공하도록 할 수 있음

CloudFront 다양한 기능

정적 & 동적 컨텐츠 분별 제공

정적(Static) 컨텐츠

서버를 거치지 않고 클라이언트에서 직접 보여주는 내용
ex) 이미지, CSS, 기타 서버가 필요없는 내용들
캐싱으로 접근속도 최적화

동적(Dynamic) 컨텐츠

서버 계산, DB조회 등이 필요한 내용
ex) 로그인, 게시판 등
네트워크 최적화, 연결 유지, Gzip 압축 등을 사용
서버랑 통신을 할 때 전처리 작업이 있는데, 주소가 어디로 전달되는지(DNS Lookup), TCP Connection, Titm to First Byte 등을 CloudFront에서 네트워크를 최적화한다.
실제로 내용을 최적화 해서 보내는 것이 아니라, 통신을 최적화 해서 속도를 최적화 시키는 것

동적 / 정적 컨텐츠 처리

경로 패턴으로 URL에 따라 정적/동적 컨텐츠 분기 처리 한다.

HTTPS 지원

Origin에서 HTTPS를 지원하지 않더라도 클라우드 프론트내에서 HTTPS 통신을 지원할 수 있도록 구성 가능

예를 들어, S3 정적 웹 호스팅 URL 같은 경우 SSL설정이 쉽지 않은데, CloudFront를 통해서 HTTPS 통신을 지원할수 있게끔 할 수 있다.

지리적 제한 설정

특정 지역의 컨텐츠 접근을 제한 가능 하다.

예를들어 아프키라 티비 스트리밍 서비스를 하는데 라이센스나 계약에 따라 일본권에서는 볼 수 있지만, 아프리카권은 볼수 없게 설정 가능하다.

다른 서비스와 연계

AWS WAF, Lambda@Edge 등과 연동 가능

Lambda@Edge

엣지 로케이션에서 돌아가는 람다
람다엣지 사용 사례 :
- 한국에서 요청이 올 경우 한국 웹서버, 미국에서 요청이 올 경우 미국 웹서버로 분산
- 커스텀 에러 페이지
- Cookie를 검사해 다른 페이지로 리다이렉팅 → A/B 테스팅
- CloudFront에서 Origin 도착 이전에 인증 ..등

유저에서 CloudFront 도착하기 전,
CloudFront에서 Origin에 요청 보내기 전,
Origin에서 CloudFront로 응답을 보내기 전,
CloudFront에서 유저한테 응답 보내기 전

이 4단계에서 람다를 실행 해서 이 전달 내용을 변경 할 수 있다.

CloudFront Function

Lambda@Edge의 6분의 1 비용으로 경량 javascript 실행
아주 간단한 액션에서만 사용
사용사례 : 캐싱, 헤더 조작 등

CloudFront 리포팅

주요 CloudFront 이용 지표 확인 가능
ex) 캐시 상태, 가장 많이 요청 받은 컨텐츠, Top Referrer(어디를 타고 들어와서 어느 웹사이트를 보고있는지..)
구글 애널리틱스 같은거라고 보면 된다.

CloudFront 뷰어 정보

CloudFront에서 뷰어의 정보를 헤더에 더해 Origin에 전송한다.

디바이스 타입 (Android / IOS / SmartTV / Desktop / Tablet)
IP Address
Country / 도시 / 위도 / 경도 / 타입존 등

이 뷰어 정보를 통해서 어떤 Country에서는 어떤 컨텐츠를 제공한다던지, 위도 경도에 따라 서울에서는 서울에 맞는 아이템을 추천한다던지 처리를 할 수 있다.

CloudFront 정책과 보안

CloudFront 정책

CloudFront는 총 3가지 정책 설정 가능하다.

캐시 정책 (Cache Control) : 캐싱 방법 및 압축
- TTL 및 Cache Key 정책
- CloudFront가 어떻게 캐싱을 할지를 결정
원본 요청 정책 (Origin Request) : Origin으로 어떤 내용을 보낼 것인가
- Origin에 쿠키, 헤더, 쿼리스트링 중 어떤 것을 보낼 것인가
응답 헤더 정책
- CloudFront가 응답과 함께 실어 보낼 HTTP Header

CloudFront 보안

Signed URL

어플리케이션에서 CloudFront의 컨텐츠에 접근 할 수 있는 URL을 제공하여 컨텐츠 제공을 제어하는 방법이다.

URL에는 시작시간, 종료시간, IP, 파일명, URL의 유효기간 등의 정보를 담을 수 있음
이 URL 접근 이외의 접근을 막고 허용된 유저에게만 URL을 전달하여 컨텐츠 제공을 제어 가능
단 하나의 파일 또는 컨텐츠에 대한 허용만 가능
S3 Signed URL과 비슷한 방식

Signed URL은 하나의 컨텐츠만 제공 제어를 한다고 하면, Signed Cookie는 다수의 컨텐츠의 제공방식을 제어하고 싶을 때 사용된다.

Signed URL과 마찬가지로 여러 제약사항 설정 가능
다수의 파일 및 스트리밍 접근 허용 가능
사용사례 : 정기 구독 프리미엄 유저만 볼 수 있는 강의 동영상 등

Origin Access Identity (OAI)

S3의 컨텐츠를 CloudFront를 사용해서만 볼 수 있도록 제한하는 방법이다.

즉, S3의 정적인 컨텐츠 URL로 바로 접근하는게 아니라 CDN을 통해서 접근하는 것이다.

왜냐하면 S3로 직접 접속을 하면 캐싱을 못해 속도 측면에서 마이너스가 될수 있고, 국가별 라우팅, 인증 등이 CloudFront에 구현 되어있다면 유저가 직접 S3로 접속하면 안되기 때문이다.

S3는 CloudFront와 잘 맞는다 → 정적인 컨텐츠를 호스팅 하기 때문에 CDN과 찰떡궁합
CloudFront만 권한을 가지고 S3에 접근하고 나머지 접근권한은 막음 → CloudFront는 유저와 S3사이에서 중개하는 역할
S3 Bucket Policy로 CloudFront의 접근을 허용해야 사용 가능

Field Level Encryption

CloudFront로부터 Origin 사이의 통신을 암호화
최대 10개의 필드까지 가능
공개키 방식으로 암호화 → CloudFront에 공개키를 제공 후 Origin에서 Private Key로 해독

CloudFront 실전 구축 세팅하기

EC2 웹서버 띄우기

배포에 앞서 우선 EC2 웹서버를 하나 띄우자.

$ sudo -s
$ yum install -s httpd # 웹서버 설치
$ service httpd start # 웹서버 실행

웹서버를 실행했으면 요청 로그들을 볼수있게 세팅하자.

$ cd /var/log/httpd
$ ls
access_log  error_log

$ tail -f access_log

그리고 마지막으로 index.html 웹페이지를 만들자.

$ vi /var/www/html/index.html

<html>
<body>
	<h1>Hello World</h1>
</body>
</html>

CloudFront 배포 만들기

뷰어 프로토콜 정책
- HTTP and HTTPS : http또는 https 둘다 사용할때
- Redirect HTTP to HTTPS : 만일 http로 접속하면 https로 리다이렉트. 보통 가장 많이 쓰임
- HTTPS only : https로만

캐시 키 (Cache Key)
- 어떤 기준으로 컨텐츠를 캐싱할 것인지 결정
- 기본적으로 URL로 캐싱
- 설정에 따라 Header와 Cookies, 쿼리스트링 등을 사용 가능 (같은 URL로 접속했지만 헤더나 쿠키를 이용해 영어로된 컨텐츠를 보여주거나 광고를 보여주거나 등 다르게 세팅 가능)

TTL (Time to live)
- 캐싱된 아이템이 살아있는 시간 → TTL초 이후에는 캐싱에서 삭제

정책
- CloudFront가 동작하는 방법을 정의한 정책
- 어떻게 캐싱을 할지, 어떤 내용을 Origin에 보낼지, 어떤 헤더를 허용할지 등 결정

+ 캐시 정책 종류

캐시 정책

- Minimum TTL : 오리진으로 요청이 전달되기 전에 Cloudfront캐시에 머무르는 최소 시간
- Maximum TTL : 오리진으로 요청이 전달되기 전에 Cloudfront캐시에 머무르는 최대 시간, 특정 HTTP 헤더(Cache-Control, max-age...)가 존재할 경우에만 작동.
- Default TTL : 오리진으로 요청이 전달되기 전에 Cloudfront캐시에 머무르는 기본시간 (24시간 1일)

- Forward Cookies : 오리진으로의 쿠키 정보 포워딩에 관한 설정, 오리진에는 쿠키를 처리하지 않기 때문에 쿠키를 전달하는 경우 가능성이 줄어든다

- QueryString Forwarding and Caching : 쿼리 스트링을 통해 각각의 컨텐츠를 버전별로 관리할 수 있다.
- QueryString whiteList : 쿼리스트링 포워딩 시 오리진으로 전달할 쿠키 정보의 필터링 역할을 한다.

관리형 캐시 정책 사용 - Amazon CloudFront

관리형 캐시 정책 사용 CloudFront 에서는 배포의 캐시 동작에 연결할 수 있는 일련의 관리형 캐시 정책을 제공합니다. 관리형 캐시 정책을 사용하면 자체 캐시 정책을 작성하거나 유지 관리할 필

docs.aws.amazon.com

가격 분류 (Price Class)
- 어느 지역 범위까지의 Edge Node를 사용할 건지 선택

AWS WAF 웹 ACL
- 원하지 않는 요청에 대한 방화벽을 설정
- 방화벽에 의해 거절된 요청을 HTTP Status 403(Forbidden)을 응답받는다.

대체 도메인 이름 Alternate Domain Names(CNAMEs)
- CloudFront 생성 시 할당받는 도메인 이름 대신 객체의 URL에 사용할 하나 이상의 도메인 이름을 지정

SSL 인증서
- HTTPS를 사용하여 객체에 접근하는 경우 인증서를 등록해야 한다.
* Default CloudFront Certificte : 기본적으로 CloudFront에서 제공하는 인증서 사용
* Custom SSL Certificate : 사용자 지정 SSL 인증서를 사용, 개인 소유의 SSL 인증서나 ACM을 통해 발급받은 SSL 인증서를 사용

지원되는 HTTP 버젼(Supported HTTP Versions)
- 사용자와 CloudFront 간 사용할 HTTP version을 선택

기본값 루트 객체 (Default Root Object)
- 특정 객체가 아닌 배포 URL을 요청할 때 CloudFront가 Origin에 요청할 객체 정보

클라우드 프론트는 만들어지는데 시간이 오래 걸린다는 특성이 있다.
왜냐하면 전세계에 있는 모든 엣지 로케이션에 대상으로 배포를 하기 때문에 시간이 걸린다.

CloudFront 캐싱 확인하기

배포까지 무사히 세팅했으니 이제 정말로 CloudFront 캐싱이 되는지 확인해보자.

$ sudo -s
$ cd /var/log/httpd
$ tail -f access_log

로그를 띄우고 이제 EC2 DNS로 접속해보고, CloudFront DNS로 접속해보자.

이처럼 강력한 캐싱 기능으로 사용자에게 컨텐츠 서비스를 빠르게 제공할수 있다는 점을 확인하였다.

CloudFront 무효화 생성

자 그러면 위에서 생성한 index.html의 내용을 한번 바꿔보자.

$ vi /var/www/html/index.html

그리고 :wq를 쳐서 저장하고 또다시 EC2 DNS와 CloudFront DNS로 각각 접속해보자.

당연히 CloudFront가 기존의 내용을 이미 캐싱하고 있기때문에 바로 수정내용이 반영되지 않았기 때문이다.

물론 위에서 설정한 캐시 정책(TTL)에 따라 일정 시간이 지나면 캐싱 내용이 업데이트 되겠지만, 만일 급한 중요한 버그 수정과 같은 상황이라면 마냥 기다리기에는 서비스 이용에 치명적인 결과가 일어날수 있다.

따라서 무효화 기능(invalidation)을 통해 수정된 파일이 캐시로 바로 반영하도록 설정해야 된다.

파일 무효화(invalidate)
- TTL이 지나기 전에 강제로 캐시를 삭제 하는 것
- 주로 새로운 파일을 업데이트 한 후 TTL을 기다리지 못할 상황에 사용 (예를 들어, TTL이 2일인데 어떤 오류가 생겨서 버그수정한 파일을 업로드했지만, 유저에게 전달된 파일은 이미 캐싱된 구버젼 버그가 있는 파일을 CDN하기 때문에 이 기능을 사용한다고 보면 된다)
- 추가 비용 발생 (한달 1000건은 무료. 초과는 요청 하나당 5~6원 받음)
- CloudFront API, 콘솔, third-Party 툴 등을 사용해서 파일 무효화 기능을 사용할수 있음