AWS CloudFront 이해
AWS에서 제공하는 Amazon CloudFront를 이해해보자.
- Amazon CloudFront 개요
- Amazon CloudFront 동작 방식
- Amazon CloudFront 구성
- Amazon CloudFront 기능
- Amazon CloudFront 정책
- Amazon CloudFront 보안
Amazon CloudFront 개요
AWS에서 소개하는 Amazon CloudFront 설명을 보면
Amazon CloudFront는
개발자 친화적 환경
에서짧은 지연 시간
과빠른 전송 속도
로 데이터, 동영상, 애플리케이션 및 API를전 세계 고객에게 안전하게 전송
하는 고속 콘텐츠 전송 네트워크(CDN) 서비스입니다.
1. 엣지 로케이션
위 그림은 전세계의 AWS 엣지 로케이션의 위치
를 나타냄
엣지 로케이션이란, 컨텐츠가 캐싱되고 유저에게 제공되는 지점
입니다.
2. Content Delivery Network(CDN)
Content Delivery Network(CDN)란 다음과 같습니다.
웹페이지, 이미지, 동영상 등의 컨텐츠
를 본래 서버에서 받아와 캐싱해당 컨텐츠에 대한
요청이 들어오면
캐싱해 둔 컨텐츠를 제공컨텐츠를 제공하는 서버
와실제 요청 지점
간의지리적 거리
가 매우 먼 경우, 혹은통신 환경이 안좋은 경우
요청지점 근처의 CDN을 통해 빠르게 컨텐츠 제공 가능서버로 요청이 필요 없기
때문에,서버의 부하를 낮추는
효과가 있음
위 그림은 세계 각 지점(검정색)에서 우리나라에 위치한 서버(초록색)로 데이터를 요청 할 때
의 상황을 나타낸 것입니다.
각 지점으로부터 우리나라까지의 위치가 굉장히 멀리 떨어져 있기 때문에
, 필연적으로 속도가 느려집니다.
따라서 위 그림과 같이 각 지역별로
엣지 로케이션(청록색)을 둠으로서 서울에 위치한 서버로부터 엣지 로케이션으로 각각 데이터를 받아와 전송
해줄 수 있습니다.
Amazon CloudFront 동작 방식
Amazon CloudFront 동작 방식은 다음과 같습니다.
요청 받은 컨텐츠가
엣지 로케이션에 있다면, 바로 전달
요청 받은 컨텐츠가 엣지 로케이션에
없다면, 컨텐츠를 제공하는 근원에서 제공받아 전달
Amazon CloudFront 구성
- Origin :
실제 컨텐츠가 존재하는 근원(S3, EC2, ELB, Route53 등)
- AWS 서비스(EC2, ELB, S3 등)
- 온프레미스 서버
Distribution : CloudFront의
CDN 구분 단위
로여러 엣지 로케이션으로 구성된 컨텐츠 제공 채널
- 주요 설정 및 용어
- TTL(Time To Live) :
캐싱된 아이템이 살아 있는 시간
-> TTL 초 이후 캐싱에서 삭제 - 파일 무효화(invalidate) :
TTL이 지나기 전에 강제로 캐시를 삭제하는 것
- 주로 새로운 파일을 업데이트 한 후 TTL을 기다리지 못할 상황에 사용
- 비용 발생
- CloudFront API, 콘솔, Third-Party 툴 등을 사용 가능
- Cache Key
어떤 기준으로 컨텐츠를 캐싱할 것인지 결정
기본적으로 URL
- 이후
Header와 Cookie, 쿼리 스트링 등을 사용 가능
- 정책(Policy)
- CloudFront가
동작하는 방법을 정의한 정책
어떻게 캐싱을 할지, 어떤 내용을 Origin에 보낼지, 어떤 헤더를 허용할 지 등을 결정
- CloudFront가
- TTL(Time To Live) :
Amazon CloudFront 기능
1. CDN
- CDN :
컨텐츠를 최적화
하여 보다빠르게 유저에게 제공
- 정적/동적 컨텐츠 모두 최적화
- 정적(Static) 컨텐츠 : 서버를 거치지 않고
클라이언트에서 직접 보여주는 내용
- 이미지
- CSS
- 기타 서버가 필요 없는 내용들
- 동적(Dynamic) 컨텐츠 :
서버 계산, DB조회 등이 필요한 내용
- 로그인
- 게시판
보통의 다른 CDN
에서는 동적 컨텐츠
는 캐싱을 잘 못시키는데
, CloudFront
에서는 동적 컨텐츠 또한 지원
합니다.
일반적인 CloudFront의 처리 패턴
은 위 그림과 같습니다.
동적 컨텐츠는 동적 컨텐츠를 제공하는 Origin으로, 정적 컨텐츠는 정적 컨텐츠를 제공하는 Origin으로
경로 패턴을 분기 처리 합니다.
각 컨텐츠별 최적화 방식을 보면
정적 컨텐츠 :
캐싱으로 접근 속도 최적화
동적 컨텐츠 :
네트워크 최적화, 연결 유지, Gzip 압축 등을 사용
- DNS Lookup, TCP Connection, Time to First Byte 등을 최적화
2. HTTPS 지원
- HTTPS 지원
Origin에서 HTTPS를 지원하지 않더라도 HTTPS 통신을 지원
할 수 있도록 구성 가능
일반적으로 웹 브라우저
를 통해서 웹서버에 접근하면 HTTP만을 지원
합니다.
이 경우 위와 같이 주의 요함
이 뜨게 됩니다.
하지만 CloudFront를 사용하면 지원 가능
하며 다음과 같습니다.
웹서버(EC2)와 CloudFront간의 통신
은 HTTP 통신
이지만, 사용자와 CloudFront 사이의 통신
은 AWS Certificate Manager(ACM)를 통해서 HTTPS 통신
으로 만듭니다.
3. 지리적 제한
- 지리적 제한 :
특정 지역의 컨텐츠 접근을 제한 가능
다른 나라에서의 저작권이나 계약
에 의해 해당 지역에서 서비스를 지원할 수 없을 경우 접근을 제한
4. 다른 서비스와 연계
- 다른 서비스와 연계
- AWS WAF(웹 애플리케이션 방화벽 보안 서비스), Lambda@Edge 등과 연동 가능
I. Lambda@Edge
Lambda를 사용
사용 사례
- 예 :
한국에서 요청
이 올 경우한국 웹 서버
,미국
에서 올 경우미국 웹 서버로 분산
커스텀
에러 페이지- Cookie를 검사해
다른 페이지
로 리다이렉팅 -> A/B 테스팅 - CloudFront에서
Origin에 도착 이전에 인증
등
- 예 :
과정은 다음과 같습니다.
Lambda@edge는 위와 같이 4가지 case으로
사용자로부터 CloudFront에 도착하기 전(Viewer Request),
CloudFront에서 웹서버(Origin)로 요청을 보내기 전(Origin Request),
웹서버에서 CloudFront로 응답을 보내기 전(Origin Response),
마지막으로 CloudFront에서 사용자에게 응답을 보내기 전(Viewer Response)
각 단계에서 Lambda를 실행
해서 전달 내용을 변경, 로깅, 분석
등을 할 수 있습니다.
II. CloudFront Function
Lambda@edge 1/6의 비용으로 경량 javascript 실행
사용 사례 :
캐싱, 헤더 조작
등
5. 리포팅
- 주요 CloudFront 이용 지표 확인 가능
캐시 상태
가장 요청을 많이
받은 컨텐츠- Top Referrer
어디서 들어와서 해당 웹 애플리케이션을 보고 있는지
다음은 위 요소들의 화면으로
이 뿐만 아니라 어떤 OS, 어떤 나라에서 접속했는지도 알 수 있으며 이러한 리포트들은 모두 Origin에 전달할 수 있습니다.
아래 뷰어 정보 확인 항목 참조 바람.
Amazon CloudFront 정책
- 총 3가지 정책 설정 가능하며
- Cache Control :
캐싱 방법 및 압축
TTL 및 Cache Key 정책
- CloudFront가
어떻게 캐싱을 할 지
를 결정
- Origin Request :
Origin으로 어떤 내용을 보낼 것인가
- Origin에
쿠키, 헤더, 쿼리스트링 중
어떤 것을 보낼 것인가
- Origin에
- 뷰어에게 보낼 HTTP header
- CloudFront가
뷰어(사용자)에게
응답
과 같이 실어보낼 HTTP Header
- CloudFront가
- Cache Control :
1. CloudFront의 뷰어 정보 확인
CloudFront에서
뷰어(사용자)의 정보
를헤더에 더해 Origin에 전송
확인 가능한 뷰어의 정보
- 디바이스 타입 : Android/IOS/SmartTV/Tablet/Desktop
- IP Address
- Country/도시/위도, 경도/타임존 등
이를 토대로 사용자에게
보여줄 컨텐츠를 분기
할 수 있습니다.
뷰어의 정보
중 Country가 미국이라면, 영어로 된 컨텐츠를 보여주고, 한국이라면 한글로 된 컨텐츠를 보여주는게 가능
Amazon CloudFront 보안
1. Signed URL
- Signed URL :
애플리케이션에서 CloudFront의 컨텐츠에 접근
할 수 있는URL을 제공하여 컨텐츠 제공을 제어
하는 방법- URL에는
시작시간, 종료시간, IP파일명, URL의 유효기간 등의 정보
를 담을 수 있음 - 이 URL 접근 이외의 접근을 막고 허용된 유저에게만 URL을 전달하여 컨텐츠 제공을 제어 가능
- 단 하나의 파일 또는 컨텐츠에 대한
허용만 가능
- S3 Signed URL과 비슷한 방식
- URL에는
2. Signed Cookie
- Signed Cookie : 다수의 컨텐츠의
제공 방식을 제어
하고 싶을 때 사용- Signed URL과 마찬가지로 여러 제약 사항 설정 가능
- 다수의 파일 및 스트리밍
접근 허용 가능
- 예 : 로그인 했을 때 해당 사용자에게
허락된 컨텐츠들을 제공
- 예 :
프리미엄 유저만
볼 수 있는 강의 동영상 등
3. Origin Access Identity(OAI)
- Origin Access Identity(OAI)
- S3의 컨텐츠를
CloudFront를 사용해서만 볼 수 있도록 제한
하는 방법- S3의 컨텐츠는
정적이기 때문에 CloudFront를 자주 사용함
- S3의 컨텐츠는
CloudFront만 권한
을 가지고 S3에 접근하고나머지 접근권한은 막음
S3 Bucket Policy
로CloudFront의 접근을 허용
해야 사용 가능
- S3의 컨텐츠를
4. Field Level Encryption
- Field Level Encryption
- CloudFront로부터 Origin 사이의 통신을 암호화
최대 10개의 필드
까지공개 키 방식
으로 암호화 ->CloudFront에 공개 키
를 제공 후Origin에서 Private Key로 해독
과정은 다음 그림과 같습니다.
유저
가CloudFront에 요청
을 보내고CloudFront에서
웹서버(EC2)로 요청
을 보냅니다.
이 과정에서생각보다 많은 과정
을 거치게 되기 때문에CloudFront에 Public Key를 제공
하여암호화
하도록 시킵니다.
암호화된 요청(필드)
은웹서버(EC2)에서 Private Key를 통해 해독
됩니다.이러한 과정에 꺼려진다면
웹서버에 HTTPS 통신을 사용하도록 구현하면 되나 과정에 까다로울
수 있습니다.
- Ref