AWS CloudFront와 S3 구성
2021-07-14 작성
들어가기 전 이 그림을 먼저 보자
Amazon CloudFront?
Amazon CloudFront는 .html, .css, .js 및 이미지 파일과 같은 정적 및 동적 웹 콘텐츠를 사용자에게 더 빨리 배포하도록 지원하는 웹 서비스입니다. CloudFront는 엣지 로케이션이라고 하는 데이터 센터의 전 세계 네트워크를 통해 콘텐츠를 제공합니다. CloudFront를 통해 서비스하는 콘텐츠를 사용자가 요청하면 지연 시간이 가장 낮은 엣지 로케이션으로 요청이 라우팅되므로 가능한 최고의 성능으로 콘텐츠가 제공됩니다.
- 쉽게 말하면 AWS 에서 제공하는 CDN 서비스
- 캐싱을 통해 사용자에게 빠른 데이터 전송 속도를 제공함을 목적으로 함
- 전세계 여기저기에 Edge Server를 두고 클라이언트에 가장 가까운 Edge Server를 찾아 지연시간을 최소화함
- S3에 저장된 컨텐츠를 직접 접근하지 않아도 되므로 S3의 비용이 감소하며, 더 빠른 응답을 지원
참고(추가 설명)
CDN이 뭐야?
CDN은 서버와 사용자 사이의 물리적인 거리를 줄여 콘텐츠 로딩에 소요되는 시간을 최소화합니다. CDN은 각 지역에 캐시 서버(PoP, Points of presence)를 분산 배치해, 근접한 사용자의 요청에 원본 서버가 아닌 캐시 서버가 콘텐츠를 전달합니다.
CDN이 필요한 경우
인터넷을 통해 비즈니스를 운영하거나 웹 사이트에서 그래픽 이미지, 동영상 파일 등의 콘텐츠를 제공한다면 CDN 서비스를 이용할 필요가 있습니다. CDN은 동영상 스트리밍이나 온라인 게임, 대용량 파일 전송, 그리고 해상도가 높아 용량이 큰 이미지를 다루는 쇼핑몰, 포털 사이트 등에서 안정적인 서비스 제공을 위해 활용되고 있습니다.
하지만 특정 국가나 지역만을 타깃으로 하는 웹 서비스를 운영한다면 CDN 서비스를 활용할 필요가 없습니다. 이 경우 CDN을 이용하면 오히려 불필요한 연결 지점이 늘어나 웹 사이트의 성능 저하를 불러올 수 있기 때문입니다. (?) 쨌든
참고(추가 설명)
- [클라우드 이해] CDN이란?
- 참고로 저번에 깃허브 CDN이 터져서 사이트가 정상작동하지 않았던 문제도 있었음 (슬랙 캡쳐해둘걸...)
Amazon S3?
Amazon Simple Storage Service(Amazon S3)는 인터넷 스토리지 서비스입니다. 웹 규모 컴퓨팅 작업을 보다 쉽게 할 수 있도록 설계되었습니다.
Amazon S3에서 제공하는 단순한 웹 서비스 인터페이스를 사용하여 언제든지 웹상 어디서나 원하는 양의 데이터를 저장하고 검색할 수 있습니다. 또한 개발자는 Amazon이 자체 웹 사이트의 글로벌 네트워크 운영에 사용하는 것과 같은 높은 확장성과 신뢰성을 갖춘 빠르고 경제적인 데이터 스토리지 인프라에 액세스할 수 있습니다. 이 서비스의 목적은 규모의 이점을 극대화하고 개발자들에게 이러한 이점을 제공하는 것입니다.
생활코딩 설명
Simple Storage Service의 약자로 파일 서버의 역할을 하는 서비스다. 일반적인 파일서버는 트래픽이 증가함에 따라서 장비를 증설하는 작업을 해야 하는데 S3는 이와 같은 것을 대행한다. 트래픽에 따른 시스템적인 문제는 걱정할 필요가 없어진다. 또 파일에 대한 접근 권한을 지정 할 수 있어서 서비스를 호스팅 용도로 사용하는 것을 방지 할 수 있다.
참고(추가 설명은 여기서)
객체
object, AWS는 S3에 저장된 데이터 하나 하나를 객체라고 명명하는데, 하나 하나의 파일이라고 생각하면 된다.
버킷
bucket, 객체가 파일이라면 버킷은 연관된 객체들을 그룹핑한 최상위 디렉토리라고 할 수 있다.
버킷 단위로 지역(region)을 지정 할 수 있고, 또 버킷에 포함된 모든 객체에 대해서 일괄적으로 인증과 접속 제한을 걸 수 있다.
S3에서 생성할 수 있는 최상위 디렉토리의 개념으로 이름은 S3 리전 중에서 유일해야 한다.
버전관리
S3에 저장된 객체들의 변화를 저장. 예를들어 A라는 객체를 사용자가 삭제하거나 변경해도 각각의 변화를 모두 기록하기 때문에 실수를 만회할 수 있다.
RSS
Reduced Redundancy Storage의 약자로 일반 S3 객체에 비해서 데이터가 손실될 확률이 높은 형태의 저장 방식. 대신에 가력이 저렴하기 때문에 복원이 가능한 데이터, 이를테면 섬네일 이미지와 같은 것을 저장하는데 적합하다. 그럼에도 불구하고 물리적인 하드 디스크 대비 400배 가량 안전하다는 것이 아마존의 주장. (이미지 스토리지로 S3를 써야하는 이유)
S3와 CloudFront를 통한 요청의 흐름
용어 정리
- Origin Server : 원본 데이터를 가지고 있는 서버. 보통 AWS에서의 Origin Server는 S3, EC2
- Edge Server = Edge Location : AWS에서 제공하는 전 세계에 퍼져있는 서버. 요청받은 데이터에 대해서 같은 요청에 대해서 빠르게 응답해주기 위해 Cache 기능을 제공
- Edge Server의 기본 TTL은 24시간이라고 함
흐름
- 클라이언트가 바로 S3로 접근하는 것이 아니다!
- 클라이언트로부터 Edge Server로의 요청이 발생
- Edge Server는 요청이 발생한 데이터에 대하여 캐싱 여부를 확인
- 사용자의 근거리에 위치한 Edge Server 중 캐싱 데이터가 존재한다면 사용자의 요청에 맞는 데이터를 응답
- 사용자의 요청에 적합한 데이터가 캐싱되어 있지 않은 경우 Origin Server로 요청이 포워딩
- 요청받은 데이터에 대해 Origin Server에서 획득한 후 Edge Server에 캐싱 데이터를 생성하고, 클라이언트로 응답
우리의 프로젝트에서... 다시
퍼블릭 오픈도 불가합니다. 정적 리소스 읽기 작업은 Cloudfront를 통해 접근하도록 구성하시고, 쓰기 작업은 ec2-s3-deploy 역할이 부여된 인스턴스에서 가능합니다. (참고로 이 역할에 cloudwatch 권한도 부여해두었어요)
클라이언트의 CUD 요청에 대해서는...
- EC2 서버(우리의 애플리케이션 서버)에서 Multipart 데이터를 받고 S3 버킷으로 업로드하도록 구성
- 대신 우리의 EC2 서버에는 ec2-s3-deploy 역할을 부여해야함
클라이언트의 R 요청에 대해서는....
- CloudFront를 통해서 접근하도록 구성
- CloudFront 도메인 + S3에 저장한 이미지 경로를 클라이언트한테 알려주면 되겠다
S3 버킷 생성
- Skip
Cloud Front 설정
- 여기서 Bucket policy에서 Yes를 체크할 경우 해당 s3 정책에 이 cloud front에 대한 허용이 자동적으로 설정됨
Origin
Origin domain
- CloudFront에서 이 오리진에 대한 객체를 가져오려는 Amazon S3 버킷 또는 HTTP 서버의 DNS 도메인 이름
- 돋보기 누르면 우리 S3 버킷이 뜸
S3 bucket access
그리고, S3와 CloudFront를 각각 오리진 계정과 배포 계정으로 나누어서 구성해야 하는 경우가 있는데, 이 경우에도 S3의 버킷을 퍼블릭 엑세스를 허용해도 좋다면 역시 어렵지 않습니다.
그런데, 오리진 계정의 S3 버킷에 외부 접근은 차단하고 반드시 배포계정의 CloudFront를 통해서만 접근할 수 있도록 구성해야 한다면 S3 버킷에 대한 접근제어를 적절하게 구성해 주어야 합니다.
참고
Origin Shield
- Origin으로 등록한 스토리지(S3 등)에 전달되는 리퀘스트의 횟수를 줄여 관리비용을 줄일지 여부
Default cache behavior
Restrict viewer access
- CloudFront에서 서명된 URL 또는 Cookie를 통해서만 private content에 접근할 수 있도록 설정
Cache key and origin requests
- 캐시 정책 및 오리진 요청 정책을 사용하여 캐시 키 및 오리진 요청을 제어할 수 있음