CloudFront
- CloudFront = Content Delivery Network(CDN)
= 컨텐츠 전송 네트워크
웹사이트의 컨텐츠를 서로 다른 엣지 로케이션에 미리 캐싱해 읽기 성능을 높인다.
컨텐츠가 네트워크 전체에 캐싱되므로 전세계 사용자들이 낮은 레이턴시로 접근 가능 -> 사용자 경험 향상 - CloudFront 216개의 엣지 로케이션을 통해 구성되어 있다.
엣지 로케이션 = AWS 의 CDN들의 여러 서비스들을 가장 빠른 속도로 제공(캐싱) 하기 위한 거점 - 컨텐츠가 전체적으로 분산되어 있어 DDoS 공격으로부터 보호받는다.
CloudFront Origins
- CloudFront 원본 제공 방식
- S3 버킷
- CloudFront를 통해 파일을 분산하고 캐싱할 수 있게 한다.
- 버킷은 CloudFront만 접근할 수 있게 보장
-> OAC(Origin Access Control) 원본 접근 제어
--> 기존 OAI를 대체 - 버킷에 데이터 보내기
Ingress
- Custom origin(HTTP)
- ALB(Application Load Balancer)
- EC2 인스턴스
- S3 웹사이트(먼저 버킷을 활성화해 정적 웹사이트로 설정)
- 다른 HTTP 백엔드
- S3 버킷
CloudFront 작업 방식
-> 클라이언트가 엣지 로케이션에 HTTP요청을 보내면 캐싱되어 있는지 확인하고 캐싱되어 있지않다면 원본으로 가서 요청 결과를 가져온다.
-> 원본 요청 결과는 로컬 캐시에 저장해 다른 클라이언트가 같은 컨텐츠를 같은 엣지에 요청시 사용하게 된다.
- S3를 원본으로 사용할 때
어떤 리전에 있는 원본 S3 버킷이 있다. 이 버킷은 전세계의 엣지 로케이션이 있다.
LA 엣지에 접근하는 사용자는 AWS내부 망을 통해 S3 버킷 원본을 받아와 LA 엣지가 직접 컨텐츠를 제공한다.
그리고 이 원본 버킷은 OAS로 보호받고 S3 버킷 정책에 의해서만 수정 가능하다.
다른 지역도 같은 방식으로 사용자에게 제공한다.
=> 즉, CloudFront와 엣지 로케이션을 통해 특정 리전에 있는 S3 버킷을 전세계의 엣지 로케이션으로 분산시킬 수 있다.
CloudFront vs S3 Cross Region Replication
- CloudFront
- 전세계의 엣지 네트워크를 이용
- 하루 동안 파일들이 캐싱된다.
- 전세계를 대상으로 한 정적 컨텐츠를 사용하고자 할 때 용이
- S3 CRR(교차 리전 복제)
- 복제를 원하는 각 리전에 이 설정이 되어 있어야 한다. -> 전세계 대상 x
- 파일들은 거의 실시간으로 갱신된다. -> 캐싱 x, 읽기 전용으로만 설정 가능
- 일부 리전을 대상으로 동적 컨텐츠를 낮은 지연 시간으로 제공할때 유용
[정리]
CloudFront = 전세계에 걸친 컨텐츠 전송 네트워크
CRR = 다른 리전으로의 버킷 복제
Cloud Front 실습
퍼블릭이 아닌 이미지를 액세스하는 방법
- 원본 버킷으로 사용할 버킷 생성(파일도 업로드)
- CloudFront콘솔 -> 오리진 도메인 선택(생성한 버킷) -> 오리진 액세스 선택 -> 오리진 액세스 컨트롤 세팅(OAC) -> WAF에서 보안 보호 비활성화(선택) -> 기본값 루트 객체(index.html로 설정)
+ 커스텀 HTTP 오리진을 포함해서 원하는 어떤 도메인 이름도 입력 가능
+ 오리진 액세스: 퍼블릭(버킷이라면 버킷도 퍼블릭이어야한다), OAC, OAI
+ 오리진 액세스 컨트롤 세팅을 하면 버킷 정책을 업데이트 해줘야한다. -> 그래야 버킷에 액세스 가능.
- CloudFront를 생성하면 상단에 '정책 복사' 클릭
+ CloudFront -> 오리진 -> 생성한 오리진 누르고 '편집' -> 스크롤 내리다 보면 정책을 복사 할 수 있는 탭이 보인다.
- 버킷 콘솔 -> 권한탭 -> 버킷 정책 '편집' -> 복사한 정책 붙여넣기.
=> 이제 배포물이 S3 버킷에 액세스하도록 허용된 것.
- 생성한 CloudFront에서 도메인을 복사해 열면 S3 버킷에 있는 html파일과 퍼블릭이 아닌 이미지까지 보인다.
+ 이제 같은 페이지를 새로고침하면 S3 버킷으로부터가 아닌 CloudFront 캐시에서 제공한다.
CloudFront - ALB, EC2
CloudFront는 사용자 지정 HTTP백엔드에도 접근 가능하다.(+ 인스턴스, ALB)
- EC2 인스턴스
- 사용자가 CloudFront를 통해 인스턴스에 접근하고 싶다.
- 사용자들은 CloudFront의 엣지 로케이션에 접근하고, 애플리케이션이 EC2 인스턴스에 요청을 보낼 것이다.(둘다 퍼블릭으로 설정되어 있어야 한다.)
-> 엣지 로케이션의 모든 공용 IP가 EC2에 접근할 수 있도록 하는 보안 그룹을 설정 해야 한다.
-> CloudFront IP 목록: https://d7uri8nf7uskq.cloudfront.net/tools/list-cloudfront-ips
- ALB
- 퍼블릭 설정이 되어있어야 하지만 백엔드 인스턴스는 프라이빗 설정해도 된다.(보안 그룹을 로드밸런서 허용하게 설정하면 된다.)
- 사용자가 엣지 로케이션으로 접근하기 떄문에 연결이 될 수 있도록 애플리케이션의 공용 IP가 로드 밸런서의 보안 그룹 정책에 허용이 되어 있어야 한다.
지리적 제한 기능
- 사용자들의 지역에 따라 배포 객체 접근을 제한할 수 있음.
- 접근 가능한/불가능한 국가 목록
- 국가는 서드 파티 지역 DB에서 설정한 것으로 사용자의 IP가 어떤 국가에 해당하는지를 확인.
- 사용 사례
컨텐츠 저작권법으로 인한 제한 - 실습
CloudFront -> 지리적 제한 탭 -> 허용/제한 목록 지정
CloudFront - 요금 & 가격 등급
요금
- 엣지 로케이션은 전 세계에 분포해 있다.
즉, 엣지 로케이션마다 데이터 전송 비용이 다르다. - 전송 데이터가 많을 수록 비용은 낮아진다.
가격 등급
- 방법 1
비용 절감을 위해 CloudFront를 분산할 전 세계 엣지 로케이션 수를 줄이기
- 가격 등급(3가지)
- Price Class All: 모든 리전을 사용하고, 최상의 성능을 제공, 비싸다.
- Price Class 200: 대부분 리전을 사용할 수 있지만 가장 비싼 리전은 제외
- Price Class 100: 저렴한 리전만 사용가능하다.
CloudFront - 캐시 무효화
- CloudFront에는 항상 백엔드 오리진이 있다.
- CloudFront 엣지 로케이션은 백엔드 오리진을 업데이트할때 업데이트 사항을 모른다.
- 캐시의 TTL(time to live)가 만료되면 백엔드 오리진으로부터 업데이트된 콘텐츠를 받는다.
- 그러나 이 동작을 원하지 않는다면? 최대한 빨리 새 콘텐츠를 받고 싶을때 어떻게 할까?
- 캐시를 강제로 새로고침해 캐시에 있는 TTL를 제거
이를 위해 CloudFront 무효화를 실행해야 한다.
-> 이때 특정 파일 경로를 전달해야 함. (ex: 또는 images/ 같은 특정 경로를 무효화) - 즉, 파일을 업데이트하면 배포자가 업데이트한 파일과 경로를 무효화하고, CloudFront는 캐시에서 두 파일을 무효화 하도록 엣지 로케이션에 지시하고, 엣지 로케이션은 캐시를 지운다.
이후 사용자가 index.html파일을 요청하면 새로운 파일을 받게 된다.
- 캐시를 강제로 새로고침해 캐시에 있는 TTL를 제거
Global Accelerator
애플리케이션을 배치했다고 가정해보자.
이는 글로벌 애플리케이션이고
글로벌 사용자들이 직접 접근하려고 한다.
그러나 애플리케이션은 한 리전에 배치되어 있다.
예를들어, 인도에서 공용 애플리케이션 로드 밸런서를 배치했다.
그러나 사용자는 전세계에 퍼져있다.
그래서 사용자들이 애플리케이션에 접근할때 공용 인터넷을 통하게 되는데 라우터를 거치는 동안 수많은 홉으로 지연시간이 길 것이다. 또한 중간에 끊길 위험이 있다.
위 상황의 위험과 지연시간을 최소화하기 위해 AWS 네트워크를 통하는것이 좋다.
-> 그러기 위해서 Global Accelerator를 사용한다.
[참고] 유니캐스트 vs 애니캐스트
유니캐스트: 하나의 서버가 하나의 IP주소를 가짐, 1대1통신
애니캐스트: 모든 서버가 동일한 IP 주소를 가지고, 클라이언트는 가장 가까운 서버로 라우팅된다.
Global Accelerator
- 애플리케이션을 라우팅하기 위해 AWS 내부 글로벌 네트워크를 활용
공용 인터넷을 사용하는 것이 아니라 가장 가까운 엣지 로케이션을 통해 내부 AWS 네트워크로 ALB와 곧바로 통신하는 방법 - 2개의 애니캐스트 IP를 사용
글로벌 서비스
이 애니캐스트 IP는 사용자와 가장 가까운 엣지 로케이션에 트래픽을 직접 전달 - Global Accelerator는 어떤 애플리케이션이든 전 세계의 사용자에게 두 개의 고정IP 주소를 제공할 수 있도록 해준다.
- 탄력적 IP, 인스턴스, ALB, NLB등 공용또는 사설일 수 있다.
- 안정적인 성능
(ㄱ) 지능형 라우팅으로 지연시간이 가장 짧은 엣지 로케이션으로 연결
(ㄴ) 빠른 리전 장애 조치
(ㄷ) 아무것도 캐시하지 않아 클라이언트 캐시와 문제가 없다.
단지, 우리가 사용하는 2개의 애니캐스트 IP는 변하지 않는다.
(ㄹ) 엣지 로케이션 다음에 내부 AWS 네트워크가 온다. - 상태 확인
(ㄱ) Global Accelerator가 애플리케이션에 대해 상태 확인을 실행
(ㄴ) 그다음 애플리케이션이 글로벌한지 확인(상태확인을 실패하면 자동화된 장애 조치가 1분안에 정상 엔드포인트로 실행)
(ㄷ) 상태 확인으로 인해 재해 복구에 뛰어남 - 보안
(ㄱ) 클라이언트가 화이트리스트 해야 하는 2개의 외부 IP만 존재하기 떄문에 보안측면에서 안전하다.
(ㄴ) Global Accelerator를 통해 DDoS 보호도 자동으로 받게 된다.
Global Accelerator vs CloudFront
- 공통점
둘 다 동일한 글로벌 네트워크를 사용
둘 다 AWS가 생성한 전 세계의 엣지 로케이션을 사용
DDoS 보호를 위해 둘 다 AWS Shield와 통합된다. - 차이점
- CloudFront
(ㄱ) 이미지나 비디오같이 캐시 가능한 내용 향상
(ㄴ) API 가속 및 동적 사이트 전달 같은 동적 내용 모두에 대해 성능을 향상
(ㄷ) 컨텐츠는 엣지 로케이션으로 제공
(ㄹ) 엣지 로케이션은 가끔 한번씩 오리진으로 컨텐츠를 가져오고 대부분 캐시된 내용을 엣지로 가져와 전달한다. - Global Accelerator
(ㄱ) TCP나 UDP상의 다양한 애플리케이션 성능을 향상
(ㄴ) 패킷은 엣지 로케이션으로부터 하나 이상의 AWS 리전에서 실행되는 애플리케이션으로 프록시 된다.
-> 모든 요청이 애플리케이션 쪽으로 전달된다.(캐싱 x)
(ㄷ) 게임, IoT, Voice over IP같은 비 HTTP를 사용할 경우 적합
(ㄹ) 글로벌하게 고정 IP를 요구하는 HTTP를 사용할 때도 유용
(ㅁ) 결정적이고 신속한 리전 장애 조치가 필요할 때 유용
- CloudFront
Global Accelerator 실습(유료)
(ㄱ) 여러 리전에 EC2 인스턴스 생성(public)
(ㄴ) Global Accelerator 생성
이름,리스너,엔드포인트 그룹, 상태확인, 엔드포인트 설정
* 리스너: ports(80), protocol(tcp), Client affinity(클라이언트 밀접성,None)
* 엔드포인트 그룹: 리전별로 엔드포인트를 그룹화(리전, 트래픽 다이얼설정(100))
* 상태확인: 80,HTTP,'/', 10, 3
* 엔드포인트: 엔드포인트 타입(ALB, NLB, 인스턴스, 탄력적 IP), 엔드포인트(인스턴스 ID), 가중치(128)
(ㄷ) Accelerator를 생성하면 두개의 고정 IP가 보인다.
이것이 애플리케이션에 접근하기 위한 글로벌 애니캐스트 IP이다.
DNS 이름도 있다.
(ㄹ) 이제 DNS를 통해 테스트를 해보면 가장 가까운 리전으로 자동으로 배치될 것.
VPN으로 바꿔가면서 잘 바뀌는지 체크 해보자.
(ㅁ) 만약 한 리전에 장애가 발생하면 상태체크로 장애가 발생한 리전 인스턴스는 비정상으로 바뀔 것이다.
-> 그럼 VPN으로 아시아쪽으로 받던것이 다른 나머지 리전으로 받게 될 것.
