AWS CloudFront와 S3로 간단하게 웹 배포해보기

※ 해당 글은 AWS Cloud Clubs EWHA에서 진행한 테크 세미나(AWS CloudFront & S3로 웹 배포해보기)에서 다뤘던 내용을 정리한 내용임을 밝힙니다.

CloudFront의 개념

CloudFront에 대한 개념을 들어가기 전에, 두 상황을 가정해보자.

첫 번째 시나리오

한국에서 새롭게 동영상 스트리밍 서비스를 오픈했다고 해보자. 그리고 평소 게임 스트리밍 서비스를 즐겨보는 한국 사는 길동이와 호주에 사는 브라이언이 있다. 이 둘은 서비스 오픈 시각에 맞춰 동시에 접속을 시도한다. 이때, 길동이는 바로 접속을 하여 영상을 볼 수 있었지만 브라이언은 1분을 대기했다가 서비스에 접속할 수 있었다. 이 둘의 서비스 접속 시간에 차이가 발생한 이유는 무엇일까?

 

그 이유는 바로 스트리밍 서비스의 서버의 위치 때문이다. 스트리밍 서비스의 서버 위치가 한국에 있었기 때문에, 서버에 더 가깝게 위치하고 있었던 길동이가 더 빠르게 콘텐츠를 제공받을 수 있었던 것이다. 즉, 콘텐츠가 저장이 된 서버와 물리적 거리가 멀수록 콘텐츠를 제공받는 시간에 딜레이가 발생할 수 있다.

두 번째 시나리오

또 다른 시나리오를 생각해보자. 동영상 스트리밍 서비스는 오픈은 성공적으로 이뤄져 전 세계 각 국의 사람들이 접속하는 대규모 서비스가 되었다. 하지만 서비스 담당자들은 예상보다 많이 유입된 초기 사용자들에 대해 유연하게 대처하지 못했다. 이에 시간이 지날 수록 서비스 접속이 느려진다, 영상이 끊긴다는 등의 사용자 컴플레인이 우후죽순 쏟아졌다.

이때, 너무 많은 사용자들의 유입으로 인해 서비스의 서버가 다운된다. 트래픽 과부화를 서비스가 견디지 못한 것이다.

 

 

 

결론

두 시나리오에서 볼 수 있듯이 사용자들이 콘텐츠를 접속하는 과정에서 겪는 불편함은 총 2가지이다.

 

첫째, 서버와의 물리적인 거리가 멀어 요청 후 콘텐츠 제공 시간이 지연되는 것

둘째, 콘텐츠를 소유한 서버에게로 모든 요청이 몰려 서버에 전달되는 부하가 심해지는 것.

 

콘텐츠를 전달하는 과정에서 이 두 문제를 해결하기 위해, AWS에서는 CloudFront 서비스를 제공한다.

 

AWS CloudFront란?

AWS CloudFront는 짧은 지연 시간과 빠른 전송 속도로 데이터, 동영상, 앱 및 API를 전세계 사용자들에게 안전하게 전송하는 AWS만의 CDN 서비스이다.

 

여기서 CDN이란?

CDN(Content Delivery Network)이란 콘텐츠 전송 네트워크로, 물리적 거리와 상관 없이 낮은 지연 시간으로 콘텐츠를 전달할 수 있는 기술을 의미한다. CDN 기술 사용 시 서버와 사용자 사이에 웹 페이지, 이미지, 동영상 등의 콘텐츠를 저장할 수 있는 캐싱용 서버를 여러 대 배치하게 된다. 이렇게 되면 콘텐츠를 가지고 있는 서버와 엄청 멀리 위차한 사용자가 콘텐츠 요청을 해도 가까운 캐싱 서버에서 응답을 받을 수 있으므로 빠르게 받아볼 수 있다. 또한, 캐싱 서버 덕분에 콘텐츠를 저장하고 있는 서버에 직접 요청을 보내는 횟수도 감소하므로 서버 부하도 자연스래 감소할 수 있다.

CloudFront 원리

CloudFront의 동작 원리를 그림으로 확인해보면 아래와 같이 표현할 수 있다.

 

1. 특정 리전 A에 위치한 S3가 오리진(Origin, 원본)으로 존재한다. 그리고 전세계에 엣지 로케이션(Edge Location)이 존재한다.

 

※ 여기서 오리진과 엣지 로케이션이란?

오리진(Origin, 원본)이란 실제 데이터 원본이 위치한 곳을 의미한다.

보통 S3가 데이터 원본을 저장하는 객체로 사용이 된다. S3를 오리진으로 설정할 경우 CloudFront를 통해 파일을 분산 및 캐싱하여 사용할 수 있다. 만약 S3를 오리진으로 활용하고 싶을 경우, CloudFront가 S3 버킷으로 접근할 수 있어야 하기 때문에 S3 버킷에서 CloudFront만 접근 가능하게 따로 권한 설정을 해줘야 한다. 이는 OAC(구 OAI)로 설정해줄 수 있다. OAC(Origin Access Control, 원본 접근제어)는 AWS S3 오리진에 인증된 요청을 전송하는 방법이며, 현재는 OAI보다 OAC 이용을 권장한다.

S3 말고도 EC2나 ALB를 오리진으로 설정해 커스텀 오리진을 만들 수도 있다. 이는 정적 콘텐츠를 저장하는 S3와 달리 동적 콘텐츠를 전송하는 경우가 많을 때 오리진으로 활용이 된다.

엣지 로케이션(Edge Location)이란 한 번 불러온 콘텐츠들을 캐싱하는 서버를 의미한다. 그래서 만약 동일한 콘텐츠에 대한 요청이 반복적으로 일어날 때 오리진 서버 대신 콘텐츠를 보내주는 역할을 한다.

 

2. LA에 살고있는 사용자가 S3에 있는 콘텐츠를 요청한다.

 

3. 만약 사용자가 로컬 캐시에 데이터를 가지고 있을 경우 콘텐츠 데이터를 바로 전달해준다.

 

4. (로컬 캐시에 콘텐츠가 없을 경우) LA의 엣지 로케이션은 내부 AWS망을 통해 S3 버킷의 콘텐츠를 가지고 온다. 이때, S3 버킷은 OAC로 보호 받으며 CloudFront와 연결이 되어있다.

 

5. S3 버킷에서 받은 오리진 내용은 엣지 로케이션의 로컬 캐시에 저장이 되고 => 이후 사용자에게 전달이 된다.

 

6. 이후 동일한 콘텐츠에 대한 요청이 들어온다면 엣지 로케이션의 캐시에서 콘텐츠를 바로 줘 지연 시간을 줄인다.

CloudFront의 다양한 기능

1) 정적/동적 콘텐츠 관리

AWS CloudFront의 경우에는 다른 CDN 서비스와 다르게 정적 및 동적 콘텐츠를 모두 처리할 수 있으며, 이 둘을 분별해서 처리할 수 있다. 이때 정적 콘텐츠란 서버의 개입이 불필요한 데이터로 이미지, 문서, HTML 파일과 같은 파일들을 의미한다. 그리고 동적 콘텐츠는 서버의 연산이나 조회가 필요한 데이터 형식으로 API 요청이 그 예가 될 수 있다. CloudFront는 어떤 콘텐츠를 요청하느냐에 따라 정적 콘텐츠로 처리를 할지, 동적 콘텐츠로 처리를 할지 구분해 설정할 수 있다.

 

2) 지리적 제한 설정 가능

CloudFront에서는 지리적 제한을 설정해 특정 국가의 사용자들만 배포된 콘텐츠를 접근할 수 있도록 설정할 수 있다. CloudFront 배포 보안 설정에서 AllowList와 BlockList를 지정해 어떤 국가를 허용하거나 제한할지 결정할 수 있다. 이는 콘텐츠 저작권법을 적용해야 하는 특정 국가들이 있어 제한을 둬야 할 때 사용할 수 있다.

 

3) 캐시 무효화(Cache Invalidation) 기능

CloudFront의 중요한 기능 중에 하나인 캐시 무효화는 전체 혹은 일부의 캐시를 강제로 새로 고침하여 캐시에 있는 TTL(time to live)를 제거해주는 기능이다. 만약 오리진 서버에 있는 콘텐츠 데이터가 다른 콘텐츠로 업데이트가 되었다고 해보자. 그럼 업데이트 된 사항은 바로 CloudFront 엣지 로케이션으로 업데이트가 될까? 아니다! 그 이유는 바로 TTL 때문이다. 엣지 로케이션에 있는 콘텐츠의 유효기간, TTL이 만료가 되면 그제서야 오리진 서버로부터 업데이트를 하게 된다.

하지만 사용자 입장에서 때로는 업데이트된 콘텐츠를 최대한 빠르게 받아보고 싶은 경우가 있을 수 있다. 이럴 때 설정을 해주는 것이 바로 캐시 무효화이다. 이는 말그대로 캐시에 있는 유효기간을 깡그리 초기화시킨다는 얘기로, 계속 엣지 로케이션으로 하여금 오리진에게서부터 업데이트된 내용을 거의 실시간으로 받아오게 한다.

 

4) HTTPS 지원

오리진을 구축할 때 HTTPS 설정이 되어있지 않았더라도, CloudFront 내에서 HTTPS 통신을 지원하도록 설정 가능하다.

CloudFront 장점

1) 데이터 전송 속도 향상

CloudFront는 CDN 서비스이기 때문에 사용 시 데이터 전송 속도가 빨라지며 지연 시간이 줄어드는 장점이 있다.

 

2) 보안 향상

오리진 서버에 대해 HTTPS 연결을 보장해 안전하게 연결할 수 있다. 뿐만 아니라 Signed URL이나 Signed 쿠키와 같은 설정을 추가하여 특정 유저들만 콘텐츠 접근을 할 수 있도록 제한을 둘 수 있다.

 

3) DDoS 공격에 강함

DDoS(Distributed Denial of Service, 분산 서비스 거부 공격)는 다수의 시스템이 네트워크 인프라나 서버, 서비스의 정상적인 트래픽을 많은 양의 요청으로 방해하는 공격을 의미한다. CloudFront는 기본적으로 수많은 엣지 로케이션에 콘텐츠가 분산되어 있기 때문에 DDoS 공격을 방지할 수 있으며, 만약 AWS Shield나 WAF를 함께 이용하면 더 안전하다.

 

※ AWS Shield : 분산 서비스 거부 공격(DDoS)로부터 웹 애프리케이션을 보호해주는 AWS 서비스

※ WAF : AWS로 전달되는 HTTP 및 HTTPS 요청을 모니터링할 수 있는 웹 애플리케이션 방화벽

본격적으로 CloudFront 실습해보기

실습 목표

S3를 서비스 오리진으로 설정한 후, CloudFront로 배포해보기

1. S3 버킷 생성

 

 

AWS S3 버킷을 생성해준다. 버킷 이름을 제외한 나머지 부분은 디폴트 설정 값으로 두고 생성을 해주면 된다.

생성된 S3 버킷의 권한 설정 부분을 확인해보면 버킷 및 객체가 퍼블릭이 아니라는 것을 확인할 수 있고, 퍼블릭 액세스도 차단되어있는 걸 확인 가능하다.

 

※ 여기서 타임 > S3로만 정적 웹 사이트 호스팅을 한다면?

이때는 S3 버킷 생성 시 ACL 활성화를 해줘야 하며, S3 버킷과 객체를 공개 상태로 생성을 해야 한다. 하지만 이는 근본적으로 본다면 보안에 취약한 구조라고 할 수 있는게, 애초에 버킷과 객체를 공개 상태로 둔다는 게 보안적으로 좋지 않다. 또한 S3로 정적 웹사이트 호스팅 시 HTTP 통신을 하기 때문에 보안성이 좋지 않다. 하지만 CloudFront 사용 시 S3에서 퍼블릭 설정을 따로 해주지 않아도 CloudFront가 HTTPS 통신을 지원해주고, 안전하게 버킷과 객체에 접근할 수 있어 굿이다.

2. S3에 정적 파일 업로드

 

이제 생성한 S3 버킷에 배포하고 싶은 정적 파일을 업로드해야 한다. 나는 간단하게 리액트 프로젝트를 하나 만들어 빌드한 후, 파일들을 모두 업로드해주었다. 주의할 부분은 S3 버킷에 build 파일 자체를 업로드하는 것이 아니라 build 폴더 내에 있는 파일들을 업로드해야 배포가 잘 된다는 점이다. build 폴더 자체를 업로드하고 CloudFront로 배포를 하니, 나 같은 경우에는 접근 권한이 없다는 AccessDenied 에러가 떴다.

3. CloudFront로 배포하기

 

이제 CloudFront 서비스를 이용해 배포를 해줄 일만 남았다.

 

 

콘솔에서 CloudFront 서비스를 선택해 이동한다. 이동 후 우측을 보면 CloudFront가 글로벌 서비스임을 확인해볼 수도 있다. 어쨌든! 여기서 배포 생성을 클릭해준다.

 

 

 

 

생성할 때 우선 오리진을 선택해주는 부분이 나온다. 여기서 아까 생성한 S3 버킷을 선택해주면 된다. 그럼 원본 액세스 부분을 설정해줄 수 있을텐데, 이 부분이 바로 아까 언급한 OAI, OAC.. 부분이다. 즉, 여기서는 선택한 오리진에 대한 CloudFront의 접근 권한을 설정해주는 부분이다. S3의 경우 공개, 원본 액세스 제어, Legacy Access Identity - 이렇게 3가지 옵션이 제시된다. 공개(Public) 옵션의 경우 버킷 자체가 퍼블릭 상태일 때 사용할 수 있고, 원본 액세스 제어는 OAC를 활용한다. 마지막으로 Legacy Access Identity는 OAI를 활용한다 . 현 실습에서는 OAC로 설정을 해준다.

 

 

OAC 선택을 하면 OAC를 생성해줘야 한다. Create Control Setting 부분을 눌러 OAC를 만들어준다. 추후 배포 완료 뒤 콘솔 좌픅의 원본 액세스 부분을 눌러보면 OAC가 하나 생성되어 있는 것을 확인 할 수 있다.

 

 

 

다시 OAC 설정으로 돌아와보면! OAC를 생성한 후에는 다시 배포 설정 페이지로 돌아온다. 이때 OAC 생성 직후 'S3 버킷 정책을 업데이트해야된다'라는 알림창이 뜬다. 현재 우리는 CloudFront가 S3에 접근할 수 있도록만 설정해줬지, 반대로 S3 버킷에서 CloudFront의 접근을 허용한 상황은 아니다. 따라서 CloudFront가 S3 버킷에 접근할 수 있도록 S3 버킷의 정책을 수정해야 한다. 우선 이 단계에서는 그렇군하고 넘어가준다.

 

 

 

이 후 추가로 Origin Shield를 배포 설정에 넣어줄 수 있다. Origin Shield는 CDN과 오리진 서버 사이에 추가적으로 존재하는 캐시 레이어를 의미한다. 이는 캐시 적중률을 개선하는 역할을 해주고, 오리진 서버에 대한 부하를 훨씬 더 감소시켜주며, 네트워크 성능을 전체적으로 향상시켜주는 옵션이다. 만약 사용해보고 싶다면 리전은 생성한 S3 버킷과 동일한 리전으로 설정해준다.

또 여기서 방화벽 역할을 해주는 WAF 옵션을 설정해줄 수도 있다.

 

 

마지막으로 기본 캐시 동작 부분에서 뷰어 프로토콜 정책을 설정할 수 있다. 여기서 바로 CloudFront가 HTTPS 통신을 하게 설정할 수 있다. Redirect HTTP to HTTPS로 설정을 해주면 오리진(지금은 S3 버킷)에서 따로 설정을 해주지 않아도 CloudFront가 자체 HTTPS 통신을 하게 해준다. 기본값 루트 객체는 index.html로 설정한다.

 

 

이제 CloudFront 배포는 끝났다! 대신 이제 정말 마지막으로 S3 정책을 바꿔주기만 하면 된다. 배포를 끝냈으면 아까 그렇군 하고 넘어갔던 S3 버킷 권한 수정 안내가 뜨게 된다. 여기서 수정해줄 정책을 복사하고 S3 버킷 정책으로 이동한다. 만약 여기서 정책 복사를 못했더라도 CloudFront > Origin 탭 > Bucket 정책을 확인할 수 있다. 여기서 복사를 해주면 된다!

4. S3 정책 편집

 

생성한 S3 버킷의 정책 부분에 복사한 정책을 옮겨준다.

5. 배포된 웹사이트 확인

정책 편집을 마치고 다시 CloudFront로 넘어가면 배포가 완료되었다는 것이 보인다. 아직 배포 중이라고 뜨면 조금만 기다리면 된다.

생성된 배포 도메인 이름을 복사해서 사이트에 들어가보면 S3에 넣었던 index.html 파일이 보인다.

 

 

그리고 URL이 입력된 주소창 옆을 확인해보면 HTTPS 설정도 잘 되어있는 것을 볼 수 있다.

그래서 진짜 효과가 있을까?

 

이거 속도 차이 나는 거 맞아..?

 

 

배포까지 마무리를 한 후, 실제로 서버로부터 콘텐츠를 불러오는 속도가 줄어들었는지 의문이 들었다. 사실 그냥 눈으로 보기에는 로딩 속도에 그렇게 큰 차이가 있나 싶었다.

 

 

그래서 개발자 도구에 들어가 네트워크 탭을 확인해보았다.

딱 처음에 사이트에 들어가 콘텐츠 로드 기록을 보면 'Miss from CloudFront'라는 내용이 뜬다. 이는 CloudFront 캐시에 콘텐츠가 없어 오리진으로부터 콘텐츠를 가지고 왔다는 것을 의미한다. 그리고 서버로부터 응답이 돌아오는 시간을 확인했을 떄도 약 80ms가 소요되었음을 확인할 수 있다.

하지만 다시 사이트의 이미지를 불러왔을 떄는 'Hit from CloudFront'라고 뜨는 것을 볼 수 있다. 이는 CloudFront 캐시에 콘텐츠가 저장이 되어있었고, 그 캐시에서 데이터를 가지고 왔다는 응답니다. 따라서 콘텐츠 캐싱이 실제로 잘 되는 것을 확인할 수 있다. 서버 응답 시간을 봐도 약 10ms로 처음보다 훨씬 단축된 것을 볼 수 있다.

 

이로서 우리는 AWS CloudFront가 어떤 서비스인지 알아보고, 정적 사이트를 배포해보는 실습을 통해 실제 CloudFront의 작동 원리를 알아볼 수 있었다. CloudFront라는 서비스를 이해하는데 조금이나마 도움이 되길 바라면서 마무리지어보겠다:0