Amazon Cloudfront로 글로벌 웹 서비스 전개

Ash Park
Spoon Radio
Published in
6 min readOct 23, 2019
AWS Cloudfront

안녕하세요. 스푼라디오(마이쿤)에서 AWS 인프라 전개와 유지보수를 담당하는 Ash(박민호)입니다. Spoon Radio 글로벌 사용자에게 보다 향상된 WEB 서비스를 제공하기 위해 Amazon Cloudfront(이하 CF)를 적용하였던 과정을 정리해 보았습니다.

Global Service

사용자가 www.spooncast.net 접속 시 Static Contents(css, js, png, etc..)가 전달되는 과정은 아래와 같습니다.

Static Contents는 S3에 저장을 하여 WEB(Proxy)서버가 처리

서버 한 곳에서 Static Content와 Dynamic Contents 요청을 모두 처리 하고 있습니다. 사용자 브라우저에서 Static Contents를 요청하면 WEB 서비스가 요청을 받아 S3에 저장된 리소스를 전달하고, Static Contents가 아닌 Dynamic Contents 요청이 전달되면 같은 서버에 있는 API 서버가 처리하고 있습니다. 한 서버에서 두 가지 서비스가 제공되고 있습니다.

이와 같은 구조는 Origin 에서 지리적으로 먼 사용자들에게 굉장히 낮은 WEB 서비스를 제공하게 되어, CF를 사용해 이를 개선하기해 보기로 하였습니다.

먼 지역의 Client가 접속 하였을때 문제

Amazon Cloudfront

CF를 적용하면서 기본설정만으로 충분한 퍼포먼스 나오기 때문에 CNAME에 대한 설정만 할 뿐 기타설정은 하지 않았습니다.

그러나 하나의 CF로 Static Contents와 Dynamic Contents를 모두 처리하기 위해 Behaviors의 값 조절이 필요했습니다. 그래서 하나의 CF Distribution에서 Static Contents와 Dynamic Contents를 모두 다 처리 할 수 있도록 아래와 같이 구성하여 테스트를 진행하였습니다.

API서버가 있기 때문에 CF의 Behaviors 설정이 중요

Dev 환경과 Stage 환경에서는 이슈 없이 검증이 되었습니다. Static Contents의 Response Header에는 Hit from cloudfront를 확인하였고 그 밖의 Dynamic Contents 테스트에도 이슈가 없어 Production에 적용하였습니다.

힝~ 속았지?

Production에 적용 후 Response Header를 확인 결과 캐시가 Hit 하지 않았다는 메시지를 확인하였습니다. 새로 고침을 연속(F5 연타)으로 눌러야 겨우 Hit가 되었습니다.

Cache Hit % 올리기

캐시가 히트하지 않는 이유는 이전의 요청과 지금의 요청 중 무언가가 달라 Origin 데이터를 요청하는 것으로 예측하여 디버깅을 시작 하였습니다. 하지만 S3 Static Contents가 바뀔 일은 없었습니다. 그래서 CF Behaviors 설정과 Request Headers를 집중적으로 검토하였습니다.

크롬의 개발자 도구를 열어 같은 Request 여러 개를 비교한 결과 Request Header Cookie 항목 중 일부가 지속적으로 변경되고 있는 것을 발견하였습니다.

Dev와 Stage에서는 나오지 않고 오직 Production에만 나오는 Cookie, 사용자 패턴 분석입니다. 해당 Cookie는 요청할 때마다 값이 달라지기 때문에 Cache가 Hit되지 않고, Origin으로 Object를 계속 요청하고 있었습니다.

상상도 못한 정체

실시간으로 변하는 Cookie가 분석에 필요한 항목이라면 캐싱을 할 수가 없습니다. 담당자와 논의를 통해 Static Object는 분석을 할 필요가 없다는 것을 확인하였습니다. 그래서 Cookie를 무시하도록 CF를 설정 하였습니다.

이슈가 된 Behaviors의 Cookie 설정

이에 Behavior를 Static Contents의 확장자 수 만큼 추가하는 쪽으로 방향을 잡았습니다. 각 Behavior 설정에는 Path만 일치하면 Cache에 Hit 할 수 있도록 설정하였습니다. 더 나아가 Static Contents Behavior가 추가된 만큼 실제 파일들은 S3에 있으므로 Origin에 S3를 추가하여 WEB 서버를 거치지 않고 바로 S3로 요청할 수 있도록 변경하였습니다.

정의한 Static Contents는 S3가 처리
Cloudfront의 Behaviors 설정

이렇게 하여 CF Behaviors를 통하여 Static Contents는 S3로 전달하여 처리하게 하고, 나머지는 Dynamic Contents로 판단하여 Default (*)인 ALB를 전달하는 구조로 변경되었습니다.

Static Contents Cache Hits 99.6%

Cache를 위한 작업의 결과는 원하는 방향대로 흘러갔습니다. 명시한 Static Contents는 CF에 Hit 되어 Origin까지 요청 없이 효과적으로 배포되었습니다. 각국의 사용자들은 Static Contents가 들어있는 S3까지 올 필요 없이 가까운 CF PoP에 캐싱된 데이터로 원하는 리소스를 받을 수 있게 되었습니다.

마치며

본문을 다 쓰고 다시 검토하니 당연한 얘기만 서술하였습니다. CF에 대한 자료는 넘쳐 나고 있습니다. 이중에서 원하는 자료를 찾아 검증 및 테스트 통해 Production 적용 하였지만, 적용 결과는 기대하는 것과는 다를 수 있다는 것을 알게 되었습니다. 또한 지식으로만 가지고 있는 것을 Production에 적용한다는 것은 결코 다른 레벨의 범주라는 것을 알게 되었습니다.

CF 적용으로 빨라진 네트워크 속도 뿐만 아니라 Behavior의 캐싱에 대한 설정으로 보다 쾌적해진 Spoon Radio 접속환경과 인프라 환경을 글로벌 유저에게 제공 하게 되었습니다.

Static Contents 를 WEB 서버를 통하여 요청하던 부분을 S3가 직접 처리 (WEB Server/Network InBound)

--

--