Amazon S3 + CloudFront + Route 53

예전에 뤼튼에서 진행했던 프로젝트에서 서비스를 배포한 경험이 있었다. 그 때는, 각각의 서비스들이 대략적으로 어떤 역할을 하고 있는지 파악하고 배포를 하는데 집중 하였기 때문에 각각의 서비스들의 기능을 명확히 하고 싶었다. 따라서 이번 기회에 각각의 서비스들을 심도있게 정리 해보았다.

Amazon S3

Amazon S3란?

Amazon Simple Storage Service(Amazon S3)는 확장성, 데이터 가용성, 보안 및 성능을 제공하는 객체 스토리지 서비스입니다.

쉽게 말하자면 Google One, iCloud와 같은 파일 저장 서비스입니다. 버킷(컨테이너)에 객체(파일)를 저장할 수 있습니다.

주요 개념

객체(Object)
- AWS는 S3에 저장된 데이터 하나 하나를 객체라고 합니다. 하나 하나의 파일이라고 생각하면 쉽습니다.
- 데이터와 메타데이터로 구성되어 있습니다.
버킷(Bucket)
- 객체가 파일이라면 버킷은 연관된 객체들을 그룹핑한 최상위 디렉토리입니다. 버킷 단위로 지역(region)을 지정할 수 있고, 또 버킷에 포함된 모든 객체에 대해서 일괄적으로 인증과 접속 제한을 걸 수 있습니다.
S3 버전 관리
- S3 버전 관리를 사용하면 동일 버킷 내에 여러 개의 객체 변형을 보유할 수 있습니다. S3 버전 관리를 사용하여 버킷에 저장된 모든 버전의 모든 객체를 보존, 검색 및 복원할 수 있습니다. 또한 의도치 않은 사용자 작업 및 애플리케이션 장애로부터 쉽게 복구할 수 있습니다.
키
- 객체 키는 버킷 내 객체에 대한 고유한 식별자입니다. 버킷 내 모든 객체는 정확히 하나의 키를 갖습니다.
리전
- Amazon S3에서 사용자가 만드는 버킷을 저장할 지리적 AWS 리전을 선택할 수 있습니다. 지연 시간 최적화, 비용 최소화, 규정 요구 사항 준수 등 다양한 필요에 따라 리전을 선택할 수 있습니다.

버킷은 ‘통’ 이라는 의미를 가지고 있습니다. 이는 버킷을 좀 더 쉽게 직관적으로 이해할 수 있게 합니다.

아래의 사진은 객체(Object)와 버킷(Bucket)을 그림에 빗댄 것입니다.

한 계정 당 버킷은 최대 100개까지 사용이 가능하고, 버킷의 소유권은 이전할 수 없기 때문에 주의해야 합니다. 객체는 하나 당 1Byte에서 최대 5TB까지 저장이 가능하며 저장할 수 있는 객체의 수는 제한이 없습니다.

Amazon S3의 작동 방식

Amazon S3에 데이터를 저장하려면 먼저 버킷을 생성하고 버킷 이름 및 AWS 리전을 지정해야 합니다. 그런 다음 Amazon S3에서 객체로 해당 버킷에 데이터를 업로드합니다. 각 객체에는 키(혹은 키 이름)가 있으며, 이는 버킷 내 객체에 대한 고유한 식별자입니다.

Amazon S3의 장점

S3 버킷이 자동으로 확장 및 축소되기 때문에 스토리지 공간을 특정 크기로 할당할 필요가 없습니다.
S3는 서버리스 서비스이기 때문에 파일이 저장되는 서버를 관리하거나 패치할 필요가 없습니다.
애플리케이션에 정적 컨텐츠에 대한 요청이 필요없기 때문에 서버 크기를 줄일 수 있습니다.

Amazon S3를 사용하는 방법

S3를 사용하는 방법은 간단합니다.

버킷을 만들고
객체를 업로드하면 됩니다.

저의 경우에는 정적 웹 사이트를 호스팅하기 위한 용도로 사용하였기 때문에 정적 웹 사이트 호스팅 사용 설정을 따로 해주었습니다. 자세한 내용은 이곳에 나와있습니다.

버킷을 만드는 방법에 대한 내용은 이곳에서 객체를 업로드 하는 방법은 이곳에서 확인할 수 있습니다.

Why Amazon S3?

Amazon S3를 도입한 이유는 Amazon S3 - CloudFront - Route 53으로 이루어지는 간단하고 강력한 서비스를 제공받기 때문입니다. 뿐만 아니라, 가성비가 뛰어나고 가장 오래된 클라우드 서비스 제공사로써의 입지도 한 몫 했습니다.

우리가 S3를 사용한 방법

Amazon S3를 통해 애플리케이션 호스팅을 하였습니다. 이를 통해 안정성과 확장성이 뛰어나며 저렴한 비용으로 웹 애플리케이션을 배포, 설치, 관리할 수 있었습니다. Amazon S3를 사용하여 정적 웹 사이트를 호스팅하도록 버킷을 설정하면 됩니다.

기타

메타데이터란?

CloudFront

CloudFront란 ?

CloudFront는 직접 만들 수 있는 CDN(Content Delivery Network) 입니다.

CDN은 세계에 널리 퍼진 중계 서버들의 집합입니다. S3와 같은 일반적인 정적 호스팅을 통해 웹 컨텐츠를 이용자들에게 제공하게 되면 물리적인 거리가 증가함에 다라 컨텐츠를 로드하는데 걸리는 시간이 증가합니다. 예를 들어 한국에 정적 서버를 호스팅하는 컴퓨터가 있다고 했을 때 유럽과 같이 다른 먼 나라의 이용자들은 한국에 거주하는 이용자들에 비해 빠른 로딩 속도를 제공받기 어렵습니다.

이 비효율을 없애기 위해 전세계에 뿌려져 있는 각종 중계 서버들인 CDN이 웹 자원을 대신 전달하는 역할을 합니다. 프론트엔드 개발자는 단순히 정적 서버에 빌드된 번들 자바스크립트 파일과 여러 정적 파일을 업로드만 하면 배포를 마무리할 수 있지만 그 외에도 서비스 품질을 향상 시킬 수 있는 인프라 작업들도 본인의 몫이라 생각해야 합니다. 이를 CloudFront를 통해 이뤄낼 수 있습니다.

CloudFront는 엣지 로케이션이라고 하는 데이터 센터의 전 세계 네트워크를 통해 컨텐츠 서비스를 제공합니다. 엣지 서버를 사용해 컨텐츠를 캐싱하고 서비스를 제공하면 사용자가 위치한 곳을 기준으로 더 가까운 서버에서 컨텐츠를 전송할 수 있기 때문에 성능이 향상됩니다. 아래 지도의 그림처럼 CloudFront는 전 세계 곳곳에 엣지 서버가 있습니다.

사용자가 CloudFront에 컨텐츠를 요청할 경우 요청이 가까운 엣지 로케이션으로 라우팅됩니다. 이때 CloudFront에 요청된 파일의 캐시 사본이 있으면 CloundFront가 빠르게(low latency로) 응답하여 해당 사본을 사용자에게 전송합니다. 요청한 파일이 아직 캐싱되어 있지 않으면 CloudFront가 S3 버킷 같은 오리진 서버에서 파일을 가져옵니다. 이후부터는 동일한 컨텐츠를 로컬에서 요청하더라도 가까운 곳에 캐싱되어 있기 때문에 서비스를 빠르게 제공할 수 있습니다.

CloudFront가 컨텐츠를 엣지 로케이션에 캐싱하기 때문에 S3 버킷에 대한 부하를 줄일 뿐만 아니라 컨텐츠를 요청하는 사용자에게도 더욱 빠르게 응답할 수 있습니다. 또한 CloudFront를 사용해 컨텐츠 데이터를 전송하면 S3에서 직접 파일을 제공하는 것보다 경제적입니다.

그 밖에도 AWS 글로벌 프라이빗 네트워크를 이용해 월드와이드 네트워크 문제를 회피함으로써 정적/동적 컨텐츠의 전송 성능을 높입니다.

그림으로 더욱 쉽게 이해할 수 있습니다. 유럽의 한 지역에 위치한 S3 버킷에 컨텐츠가 저장되어 있고, 전 세계 사용자가 이 컨텐츠에 액세스하고 있습니다.

화살표를 보면 사용자가 컨텐츠를 요청할 때 마다 요청은 퍼블릭 인터넷을 통해 원본 위치인 유럽의 S3 버킷으로 전송됩니다. 이때 사용자의 위치에 따라 전송 시간을 길어질 수 있습니다. 이렇게 시간이 지연되면 일부 사용자 요청이 반송되어 페이지에서 오류를 반환할 가능성도 있습니다.

이번에는 S3 버킷과 함께 CloudFront를 설정했다고 가정하겠습니다. 아래 그림에서는 컨텐츠 사용을 위해 전 세계를 가로질러 전송되는 요청을 볼 수 없습니다. 대신에 요청이 가장 가까운 엣지 로케이션으로 라우팅됩니다. 그러면 초록색 화살표가 가리키듯이 CloudFront가 가까운 거리에서 요청한 사용자에게 캐싱된 컨텐츠를 직접 빠르게 제공합니다.

이때 컨텐츠가 엣지 서버에 아직 캐싱되어 있지 않으면 CloudFront가 S3 버킷 오리진에서 해당 컨텐츠를 가져옵니다. 그 밖에도 CloudFront는 TCP 핸드셰이크를 최적화하기 때문에 컨텐츠 반환 속도가 퍼블릭 인터넷을 통해 액세스하는 것보다 훨씬 빠릅니다.

CloudFront의 이점

정적 웹 사이트 컨텐츠 전송 속도 향상

위에서 말했듯 CloudFront는 사용자가 사용자와 가장 가까운 거리에 있는 중계 서버(엣지 로케이션)를 통해 컨텐츠를 제공하기 때문에 더욱 빠르게 컨텐츠들을 제공합니다.

컨텐츠 보안 유지

S3와 같은 정적 호스팅 서비스는 모든 사용자를 대상으로 호스팅 서비스를 제공해야 하기 때문에 모든 컨텐츠의 접근 권한을 Public으로 설정해야만 합니다. 그러나 CloudFront를 통해 생성된 도메인을 통해 접근해야만 웹 자원에 접근할 수 있도록 설정해둔다면 서비스 사용자 외에 다른 사람이 웹 자원에 접근하는 것을 막을 수 있습니다. 이는 CloudFront의 **Origin Access Identity(OAI)**를 통해 가능합니다. 이 기능은 컨텐츠에 대한 액세스를 CloudFront를 통해서만 가능하도록 제어해줍니다.

추가적으로 웹 애플리케이션 방화벽 AWS WAF와 관리형 DDos 보호 서비스인 AWS Shield를 통해 악성 공격을 차단해줍니다.

커스텀 캐싱 전략 적용

정적 호스팅 서비스만을 이용하면 캐싱 전략을 파일별로 일일이 설정해야 하는 경우가 많습니다. 그러나 CloudFront는 다양한 캐싱 전략을 일괄적으로 간편하게 설정할 수 있도록 도와줍니다.

Amazon S3 + CloundFront 조합의 장점

CloudFront에서 데이터를 전송하는 것은 S3에서 데이터를 전송하는 하는 것보다 경제적입니다.
애플리케이션의 성능과 보안까지 최적화 할 수 있습니다.
커스텀 도메인이 사용 가능합니다.

도입 배경

애플리케이션의 성능과 보안을 최적화 시켜줍니다. 이는 서비스 품질을 향상시키기 위한 인프라 작업의 일종이었습니다.
비용을 절감시켜줍니다.
S3의 정적 사이트 호스팅 기능을 사용하면 http로는 되는데 https는 안 됩니다. 따라서 https로 시작하는 커스텀 도메인 주소를 사용하기 위함 이었습니다.

사용 방법

이 곳에서 사용 방법을 알 수 있습니다.

참고

TCP

3-Way HandShake
- TCP 통신을 이용하여 데이터를 전송하기 위해 네트워크 연결을 설정하는 과정
- 양쪽 모두 데이터를 전송할 준비가 되었다는 것을 보장하기 위함
- TCP/IP 프로토콜을 이용해서 통신을 하는 응용 프로그램이 데이터를 전송하기 전에 먼저 전송을 보장하기 위해 상대방 컴퓨터와 사전에 세션을 수립하는 과정
4-Way HandShake
- 네트워크 연결을 해제하는 과정이다.

Route 53

Route 53이란 ?

Route 53은 AWS에서 제공하는 DNS 웹서비스로 1. 도메인 등록 2. DNS 라우팅 3. 상태 확인을 조합하여 실행할 수 있습니다.

Route 53을 이해하기 위해선 우선 도메인과 DNS를 이해해야 합니다.

모든 컴퓨터는 ip라는 고유의 주소를 가지고 있습니다. 하지만, ip는 사람이 이해하고 기억하기 어렵기 때문에 이를 위해서 각 ip에 이름을 부여할 수 있게 했습니다. 이것이 바로 도메인입니다.

**DNS(Domain Name System)**는 도메인과 도메인에 해당하는 ip정보를 가지고 있다가 도메인 주소에 대한 요청이 들어왔을 때 이에 해당하는 ip를 알려주는 시스템입니다. 친구의 이름에 해당하는 번호를 가지고있는 전화번호부 같은 역할을 합니다.

Route 53 도입 배경

도메인 등록
1. example.com과 같은 이름을 가진 도메인 이름을 등록하기 위함입니다.
DNS 라우팅
1. 사용자가 웹 브라우저에 도메인 이름을 입력하여 웹 사이트를 요청하면, Route 53에서 사용자를 해당 컨텐츠로 라우팅하도록 도와줍니다. 즉, 라우팅을 위하여 도입하였습니다.