AWS 가 제공하는 관리형 CDN 서비스
- Global Service
Use-cases
1. 정적 컨텐츠 제공 (Serving Static Contents)
-
정적 컨텐츠란 무엇인가?
-
동적으로 변경되지 않는 것
-
이미지, HTML, File, Video
#### 유즈 케이스 - Image / Video / File (PDF 등) - Web - WAS (Web Application Server) - JSP / PHP - 서버에서 웹 페이지를 전부 렌더링해서 클라에 전달해주는거 #### Static Web - Client-side Rendering - API Server의 유행 - 각 클라이언트에서 동일한 API와 통신 - Static Web - HTML / CSS / JS / Image / Fonts - 웹브라우저 - 모바일 - 모바일 웹 브라우저 - 네이티브앱 웹뷰 - 가장 최적화해서 전달할 수 있는 방법 CDN ### AWS 케이스 - S3 에다가 웹 스태틱 파일들을 저장 - CloudFront를 통해서 서빙 ### SSR (Server-side Rendering) - 시나리오에 따라 캐싱을 적용할 수 있는 부분이 있겠죠 - 예시 시나리오 - GitHub My Profile 을 SSR로 구현해보자 - example.com/profile - 캐싱을 할 때 캐싱 키를 설정할 수 있음 - 캐싱 키로 user-id 를 잡는거 (cookie, url path, query parameter, 어딘가)
-
2. 비디오 스트리밍 (Video Streaming) (특수 케이스)
- 스트리밍 vs 다운로드
- 다운로드: 비디오를 다 다운로드 받아야 볼 수 있음
- 스트리밍: 순차적으로 영상 데이터를 보내서 실시간으로 볼 수 있게 해주는 것
3. 동적 컨텐츠 캐싱 (Caching Dynamic Contents)
-
데이터가 최신 데이터가 아닐 수 있음
-
왜 하지?
-
딱히 데이터의 정확도가 중요하지 않으나 성능이 중요할 때
-
캐싱의 TTL (Time-to-live)
-
1H 1시간 뒤에 Cache Miss가 나고 Origin 데이터를 가져온다.
#### 유즈케이스 - Blog Post API - `GET /api/posts` Post JSON 응답 - 요구사항 - 대상이 글로벌 - 속도가 빨랐으면 좋겠음 - 포스팅이 올라가자 마자 보이지 않아도 됨 - 설계 - Origin - Blog API - Cache TTL: 6H (하루에 4번 갱신) - 주식 / Crypto Currency - Ticker - 실시간 시세 - CDN을 붙이는데 Cache TTL: 1S / 0.1S
-
Concepts
CDN (Content Delivery Network)
- 전세계 Edge Locations 을 통해서 요청한 사용자로부터 가장 가까운 곳에서 캐싱하던 데이터를 전달해주는 것
- 그래서 성능이 빠르고 지연이 적다
- 글로벌 서비스가 가능해진다
Edge Location
-
캐싱 목적으로만 존재하는 기능 제한적인 서버들
-
당연히 이것도 데이터센터에 존재하기는 하는데, AWS거가 아니더라도 전세계 데이터 센터 내에 엣지로케이션 목적으로 서버 임대해서 캐싱 제공
-
vs Data Center
-
AWS 기준 데이터 센터(AZ)는 현재 전세계적으로 105개가 존재
### Edge Location은 2023년 7월 기준 450개 이상의 엣지 로케이션 존재 - Edge Location: 단기 캐싱을 통해 사용자 요청에 대한 빠른 응답 제공. - Regional Edge Cache: 장기 캐싱을 통해 Origin 서버로의 요청 빈도를 줄이고, Edge Location의 캐싱 효율성을 높임.
-
-
L1, L2캐시와 같은 방식?
-
결국 요청을 보내면 origin 까지 와야하는게 아닌가요? -=> 공부가 필요! 캐시에 대해서 지식이 너무 없다!
Components
배포 (Distribution)
- CDN에 배포하는 컨텐츠 단위
- CDN 컨텐츠에 접속 가능한 도메인 발급 (asjdlfjaskldfj.cloudfront.net)
- 사용자가 소유한 도메인에 연결할 수 있음 (cdn.singsongsangsong.life)
- 반드시 SSL (HTTPS) 인증서를 같이 설정
- 버지니아 ACM에 인증서 발급
- Global -> us-east-1이다
- ap-northeast-2 에서 만든 인증서는 무쓸모다
- 사용자가 소유한 도메인에 연결할 수 있음 (cdn.singsongsangsong.life)
Price Class
- 전세계 450개 이상의 엣지 로케이션이 있는데, 얼마나 사용할꺼냐
- 아시아 사람들에게 굉장히 불리합니다.
Restrict Viewer Access
- CloudFront 로 콘텐츠를 서빙하면 기본적으로 Public
- Cookie / Parameter 기반으로 컨텐츠에 접근 가능한 사람을 한정시킬 수 있음
- 인증된 사용자가 다운로드/조회 가능하도록 할 때 많이 씀
Origins
- CDN이 컨텐츠를 제공하기 위해 요청하는 실제 컨텐츠를 서빙하는 원천지
- 하나의 Distribution은 여러 Origin을 가질 수 있어요
- S3 Origin
- S3 Bucket - Custom Origin URL을 입력
- ALB
- API GW
- Media Store
- ETC - Origin Group
- Fail-over
- 사실 S3의 경우에는 무의미
- Custom Origin
- sever1.api.com (Primary)
- server2.api.com (Secondary)
- S3 Origin
Behaviors
-
접근 경로에 따라서 다른 Origin으로 연결시킴
-
Behavior 마다 정책을 다르게 가져갈 수 있어요
### 캐싱을 어떻게 할 것인가 - Origin Request를 어떻게 보낼 것인가 - Origin에서 온 Response를 어떻게 처리할 것인가 - Default Behavior - 다른 Behavior 규칙에 매칭되지 않으면 마지막에 매칭되서 실행되는거
Invalidation
- cdn.singsongsangsong.life/promotion.mp4 (v1 비디오)
- 프로모션 동영상을 메인 페이지에 서빙
- 캐싱 1달
- cdn.singsongsangsong.life/promotion.mp4 (v2 비디오)
- 웹 어플리케이션 배포 자동화 파이프라인
- s3 버킷에 신규 웹 앱 코드 업로드
- cloudfront에서 invalidation
- (구닥다리까지는 아닙니다)
- 네이티브 웹이냐
- 모바일에서 불러다 쓴느 웹뷰냐
- cloudfront
- hash를 해서 여러 버전을 가지고 있는 방법
- demo-app-v1
- demo-app-v2
- demo-app-v3
- manifest.json
- currentVersion: demo-app-v1
OAI (Origin Access Identity)
- 2022년 말쯤까지 주로 쓰던 방법 (Legacy)
- S3만 사용 가능
OAC (Origin Access Control)
- 2022년 말쯤 출시한 신규 기능
- S3 외 오리진도 사용 가능
Policies
총 3가지 종류
- Cache Policy Edge Location에서 어떻게 캐싱을 할 것인가?
- Cache TTL
- Cache Key
- Origin Request Policy Viewer Request를 토대로 Origin에 어떻게 요청을 날릴 것인가?
- Cookie / Header / Query Parameter 등 특정 키만 포워딩한다.
- Response Policy Origin Response를 토대로 Viewer에게 어떻게 응답할 것인가?
- Header를 추가하거나 삭제하거나
- Cookie를 추가하거나 삭제하거나
- 등등
- 사전에 만들어져서 제공되는 관리형 정책과 사용자 정의 정책
