Cloud Front
- 콘텐츠 전송 네트워크, 즉 CDN이다.
- 여러 엣지 로케이션에서 웹사이트의 콘텐츠를 캐시 처리해 읽기 성능을 높인다.
- 전 세계에서 콘텐츠가 캐시 처리되기 때문에, 전 세계 사용자의 지연 시간이 줄고 사용자 경험이 향상된다.
- 전 세계에 분포된 CDN 엣지 로케이션에서 컨텐츠가 캐시되어 읽기 성능을 높임
- 클라우드 프론트는 전 세계 216개의 접속 지점이 있고 각각이, AWS 엣지 로케이션에 해당한다.
- AWS는 엣지 로케이션을 계속 추가해 사용자 경험을 향상 시키고 있다.
- sheild 와 web Application Firewall을 통해 디도스 공격에 대비한다. 뒤쪽에 자세히 나옴
- 다음과 같이 엣지에 캐시된 데이터를 제공하기에 데이터가 먼 곳에 담겨있다고 하더라도 빠르게 컨텐츠를 제공할 수 있다.
CloudFront - Origins
- 데이터 저장소
- S3 버킷
- 클라우드 프론트를 사용해 엣지에 파일을 분산하고 캐리 처리하는 데 사용된다.
- 클라우드 프론트만 버킷에 액세스 하도록 하기 위해 OAC(오리진 액세스 제어)를 사용하고,
이 기능은 기존의 오리진 액세스 ID를 대체한다. - 클라우드 프론트를 사용해 데이터를 S3 버킷에 전송할 수도 있다.
- Custom Origin (HTTP)
- 애플리케이션 로드 밸런서
- EC2 인스턴스가 될 수도 있다.
- S3 정적 웹사이트도 가능하다.
- 이 외의 어떠한 HTTP 프로토콜을 사용하는 백엔드도 오리진 즉, 데이터 저장소가 될 수 있다.
클라우드 프론트 작동 방식
- 전 세계에 엣지 로케이션이 존재한다.
- 엣지 로케이션은 오리진에 연결될 것이다.
- 클라이언트가 엣지 로케이션에 연결해 HTTP 요청을 보내면,
엣지 로케이션은 캐시에 콘텐츠가 있는지를 먼저 확인한다. - 캐시에 없으면 오리진에서 요청 값을 가져온다.
오리진이 S3인 경우
- 엣지 로케이션은 S3에서 데이터를 가져오기 위해 오리진 액세스 컨트롤을 사용해야 한다.
- 이는 엣지 로케이션만 S3에 접근 가능하게 하는 보안 도구다.
- 이 오리진 액세스 컨트롤과 버킷 정책(OAC에서만 버킷 접근 가능)으로
보안도 챙기고 private 네트워크를 통해 엣지 로케이션은 데이터를 가져갈 수있다.
S3 복제하지 왜 클라우드 프론트 사용함?
- 클라우드 프론트는 약 216개의 POP로 이뤄져 있고, 각 엣지 로케이션에서 파일이 하루 정도 캐시된다.
- 정적 컨텐츠를 제공할 때 매우 유용한 기능이다.
- S3는 특정 리전에 버킷의 전체 내용을 복제한다.
- 캐시와 비교했을 때 굉장히 비효율 적이다.
- 그럼 언제 유리할까?
- 소수의 리전에 아주 낮은 지연 시간으로 동적 컨텐츠를 제공하고자 할 때 S3 복제가 유용하다.
클라우드 프론트 캐싱
캐시가 어떻게 동작하는지 알아보자
- 캐시는 엣지 로케이션 각각에 저장되기 때문에 엣지 로케이션 수만큼 캐시가 생성된다.
- 캐시의 각 객체는 캐시 키로 식별된다.
- 우선 엣지 로케이션에 요청이 들어오면, 캐시에 저장이 돼있는지
TTL은 만료가 되지 않았는지 확인한다. - 캐시에 없으면 이 요청은 오리진으로 전달된다.
- 우선 엣지 로케이션에 요청이 들어오면, 캐시에 저장이 돼있는지
- 따라서 오리진으로 보내는 요청을 최소화하고 캐시 적중률을 높여야 한다.
캐시 키란?
- 캐시 키는 캐시에 있는 각 객체의 고유 식별자이다.
- 달리 변경하지 않는다면 기본적으로 캐시 키는 호스트 이름과 URI의 리소스 부분으로 구성된다.
- 이 예시를 보면 캐시 키는 mywebsite.com + /content,,,,,,, 으로 구성된다.
- 사용자, 디바이스, 언어, 사용자 위치 정보를 기반으로 캐시 키를 만들 수도 있다.
- 클라우드 프론트 캐시 정책을 통해 쿼리 어쩌구 저쩌구 여러가지 다 추가 가능,,
클라우드 프론트 캐시 정책
- 먼제 HTTP 헤더를 기준으로 캐시 처리하도록 정책을 설정할 수 있다.
- 아무것도 선택하지 않으려면 None을 포함할 항목을 선택하려면 WhiteList를 선택하면 된다.
- 쿠키를 기준으로 캐시처리 가능하다.
- None, Whitelist, include All-Except, All
- 네 가지 중에서 선택 가능하다.
- 쿼리 String을 기준으로 캐시 처리 가능하다.
- None, Whitelist, include All-Except, All
이를 통해 캐시 키를 생성할 방법을 구성한다.
캐시 정책에서 TTL도 제어할 수 있다.
TTL은 0초에서 1년까지 가능하다.
- 한 가지 중요한 점은, 설정한 모든 구성요소들이 오리진 요청에 자동으로 포함되어 전달된다.
- 캐시 정책을 기반으로 클라이언트가 클라우드 프론트에 보낸 요청이 캐싱된다.
- 오리진 요청 정책을 기반으로 클라우드 프론트에서 오리진에 요청을 보낼 때 같이 보낼 값이 정해진다.
- 예를 들어 API 키나 보안 키 같은 것은 캐싱할 필요가 없고 오리진에만 보내면 된다.
- 이런 경우에 사용한다.
클라우드 프론트 캐시 무효화
- 오리진이 업데이트 될 경우 엣지 로케이션은 이를 알 수 없다.
- 이 경우 TTL이 만료될 때까지 예전의 정보를 전송한다.
- 이 경우 캐시 리프레시를 적용해 캐시에 있는 모든 캐시를 없앨 수 있다.
- 파일 경로를 지정해야 한다.
- 와일드 카드를 통해 모든 파일을 무효화하거나 특정 경로만 무효화할 수도 잇다.
- /index.html을 보내면 Index.html이 무효화 되고
- /images/*를 보내면 모든 이미지 파일이 무효화 된다.
- invalidate 명령이다.
캐시 동작 방식
- 사용자에게 들어오는 요청을 리소스 기반으로 라우팅 할 수 있다.
- /api/*을 로드밸런서로 라우팅하게 설정할 수 있다.
- 기본값은 /*이며 기본값은 세부적인 모든 설정을 다 검색해보고 일치하는 리소스가 하나도 없다면 기본값으로 라우팅된다.
클라우드 프론트 지리에 따른 제한
- 클라우드 프론트에서 허용 목록을 설정하여 승인 국가 목록을 정의할 수 있다.
- 차단 목록을 설정해서 금지 국가 목록도 설정할 수 있다.
- 사용자의 지리적 위치를 통해 국가 IP와 매핑하여 사용자를 차단한다.
- 이는 콘텐츠가 국가별로 제한이 다른 경우에 사용된다.
presigend URL
- 프리미엄을 결제한 사용자들에게만 특정 컨텐츠를 보여주려한다.
- 이럴 경우 CloudFront Presigned URL 또는 Signed Cookies를 사용한다.
- URL의 만료 시간과 허용 IP 범위를 지정한다.
- 음악과 영화같은 컨텐츠는 몇 분 정도의 만료 시간이면 충분하다.
- 사용자가 오랫동안 액세스할 개인 콘텐츠라면 만료 시간은 몇 년 동안 유지되도록 지정한다.
- URL과 쿠키의 차이점은 무엇일까?
- URL은 개별 파일의 액세스를 제공해서 파일 하나에 URL이 하나이다.
- 공유할 파일이 100개라면 URL도 100개다.
- 쿠키는 여러 파일에 대한 액세스를 제공하고 재사용이 가능하다.
- 여러 파일에 하나의 서명된 쿠키를 사용한다.
- 예시다.
- 애플리케이션 서버를 통해 사용자가 본인의 인증을 진행한다.
- 인증에 성공했다면 서버는 클라우드 프론트에서 Presgined URL을 발급받는다.
- 해당 결과물을 클라이언트에게 반환하고
- 클라이언트는 해당 URL을 기반으로 컨텐츠에 접근한다.
클라우드 프론트 Sigend URL 생성 방법
signed URL을 만들기 위해선 키 쌍이 필요하다.
서명자는 두 부류로 나뉘며 권장 방식은 키 그룹의 사용이다.
- API를 활용해서 키를 생성하고 재발급 받을 수 있다.
- 키를 생성하고 재발급 받는 API를 IAM을 통해서 엄격하게 관리할 수 있다.
- 두 번째 방법은 클라우드 프론트 키 페어를 보유한 계정을 사용하는 것이다.
- 이 방법을 통한 키 관리에서는 루트 계정이 필요하며 AWS 콘솔을 사용해야 하기에 권장되지 않는다.
여러 개의 신뢰할 수 있는 키 그룹 생성이 가능하다.
- 키 그룹은 공용키와 개인키로 이뤄진다.
- 개인키는 애플리케이션에서 인스턴스가 URL에 서명을 할 때 사용된다.
- 공용키는 서명된 URL에 접근할 때 사용된다.
클라우드 프론트 오리진 그룹
- 오리진 그룹을 통해 고 가용성을 확보할 수 있다.
- 오리진 그룹은 하나의 주 오리진과 하나의 보조 오리진으로 구성된다.
- 만약 주 오리진에 장애가 발생하면 클라우드 프론트가 보조 오리진을 사용하게 한다.
클라우드 프론트 필드 레벨 암호화
- 사용자가 민감한 정보를 전송할 때마다 엣지 로케이션이 이를 암호화하고
개인 키에 대한 권한을 지닌 사용자만이 정보를 해독할 수 있도록 하는 기능이다. - 비대칭 암호화를 사용한다 공개키를 통한 암호화 개인키의 권한이 있는 사용자만이 해독
- 포스트 요청을 보낼 때 최대 10개의 필드까지 암호화를 지정할 수 있다.
- 이 때 암호화를 진행할 공용 키도 함께 지정된다.
- 클라이언트는 공용키를 엣지 로케이션에 보낸다.
- 엣지 로케이션은 암호화를 진행한 후 클라우드 프론트에 보낸다.
- 이후 로드밸런서에 도착하고 웹 서버로 들어간다.
- 웹 서버엔 해독이 가능한 개인키가 저장돼있다.
- 이 로직을 살펴보면 오로지 웹 서버만이 정보를 해독할 수 있다는 사실을 알 수 있다.
클라우드 프론트 실시간 로그
- 클라우드 프론트의 로그는 실시간으로 키네시스 데이터 스트림에 전송할 수 있다.
- 성능을 모니터링, 분석하고 그에따라 조치를 취할 수 있다.
- 클라우드 프론트에서 로그를 실시간으로 키네시스 데이터 스트림으로 보내고 해당 데이터를 람다함수에서 처리한다.
- 이건 거의 실시간 모델이다.
- 데이터 스트림에서 데이터 파이어호스로 데이터를 보낸다.
- 파이어호스는 데이터를 원하는 모든 곳으로 보낼 수 있는 서비스다.
- 이를 통해 S3, 오픈 서치, 등등 원하는 대상으로 로그를 보내 처리할 수 있다.
- 이 때 수신할 비율을 설정할 수 있어서 트래픽이 상당히 높은 경우 모든 요청이 아닌 일부 샘플만 수신할 수 있다.
'AWS' 카테고리의 다른 글
[AWS] aws 강의 섹션 23 (API GateWay) (0) | 2025.02.04 |
---|---|
[AWS] aws 강의 섹션 31 (AWS의 기타 서비스들) (0) | 2025.01.02 |
[AWS] aws 강의 섹션 30 (KMS, SSM Parameter Store, CloudHSM, Nitro Enclaves) (0) | 2024.12.26 |
[AWS] aws 강의 섹션 29 (고급 IAM 정책) (2) | 2024.12.18 |
[AWS] aws 강의 섹션 28 (Step Function, AppSync, Amplify) (3) | 2024.12.05 |