"기록 공유"
개인 발표
Final Project 의 개인 기술 발표 주제를 AWS CloudFront 의 기초 이해로 잡아보았습니다. 한 번 이해하고 나면 생각보다 간단한데, 배포를 처음 접하는 입문자 입장에서 어디서부터 이 문제를 해결해나가야 하는지 막막했던 경험에 기초한 발표입니다.
발표 영상을 위해 작성한 멘트를 그대로 옮겼습니다. 아래에서 소개하는 방법은 따로 블로깅을 했던 내용이기도 합니다. 블로깅 했던 내용은 별도로 링크를 걸어두도록 하겠습니다.
안녕하세요. 소프트웨어 엔지니어링 코스를 통해서 개발자로 성장하고 있는 29기 수강생 김은성입니다.
제목을 "한국인이 원하는 빠른 배포" 라고 잡아보았습니다. 이 영상을 통해서 저는 AWS의 CloudFront 서비스에 대한 기초적인 이해와 함께, 빌드한 결과물을 빠르게 배포에 반영하는 방법에 대한 기술발표를 진행할 예정입니다.
전체적인 구성은 다음과 같습니다. 먼저 CloudFront 가 어떤 서비스인지 간략하게 이해해보면서 그 동작 방식에 대해서도 살펴볼 예정이구요. 입문자들을 당황하게 하는 문제와 이를 해결하는 방법을 끝으로 발표를 마무리하려고 합니다.
AWS CloudFront, 정확히 어떤 서비스일까요? AWS 에서는 CloudFront 를
고속 콘텐츠 전송 네트워크(CDN, Content Delivery Network) 서비스
라고 정의하고 있습니다. 우리가 개발한 웹앱을 전 세계 어디에서나 빠르게 접근할 수 있게 해주는 서비스라는 것이죠.
물론 우리가 프로젝트 과정에서 CloudFront 를 사용하는 이유는 대부분 HTTPS 로 쉽게 배포할 수 있다는 점 때문일 겁니다. 프로젝트의 사이즈가 전 세계를 대상으로 해야할 정도로 크지는 않으니까요. HTTPS 는 CloudFront 가 가진 또 다른 장점이라고 할 수 있죠. 그러나 기본적으로 CloudFront 는 CDN, 콘텐츠를 전송하는 네트워크 서비스가 핵심 내용이라는 거에요.
그러면 CloudFront 는 어떤 방식으로 동작할까요? 제 나름대로 한 문장으로 정리를 해봤는데요.
CloudFront 는 엣지 로케이션에 S3 객체들을 캐시해두었다가 요청이 왔을 때 가장 가까운 엣지 로케이션에서 캐시한 데이터를 바로 돌려주는 방식으로 빠른 CDN 서비스를 제공합니다.
CloudFront 를 아직 잘 모르신다면 이 문장 안에서 아마도 처음 보는 단어들이 좀 있을 겁니다. 그래서 하나하나 풀어서 이해해보도록 하겠습니다.
먼저 엣지 로케이션이라는 것은 쉽게 말해서 AWS 가 가지고 있는 전 세계의 데이터 센터들을 의미합니다. 그리고 캐시한다는 건 어떤 데이터를 임시로 복사해두는 것을 말하죠.
이를 바탕으로 이 문장을 풀어서 해석한다면, 우리가 빌드해서 S3 에 업로드한 클라이언트의 결과물을, AWS CloudFront가 전 세계의 데이터 센터들에 미리 복사해서 저장을 해둔다는 거에요. 그렇게 저장을 해두었다가 요청이 왔을 때 굳이 원본이 있는 곳까지 접근하지 않고도 저장해둔 데이터를 가장 가까운 데이터 센터, 엣지 로케이션에서 바로 돌려주는 방식으로 빠르게 콘텐츠를 제공해주는 겁니다. AWS 가 이미 세계 곳곳에 데이터센터를 구축해 두었기 때문에 가능한 방식이라고 할 수 있는거죠.
문제는 이 서비스가 너무 좋은 방식이긴 한데 개발하는 과정에서 때때로 배포한 결과물이 즉각적으로 반영되지 않는다는 데 있습니다. 배포 자동화 작업이 완료된 후에 개발 중인 서비스의 도메인 주소로 접속해보면 여전히 예전 빌드가 나온다던가, 아니면 팀원간에 서로 다른 빌드가 나온다던가 할 때가 있거든요. CloudFront 가 어떻게 동작하는지를 모르는 상태라면 배포 자동화는 다 잘 끝났는데 대체 어디에서 문제가 생긴건지, 또 어떻게 해결해야 할지 막막할 때가 있습니다.
게다가 개발을 하다 보면 배포 환경에서 생기는 오류들이 있을 때가 많잖아요. 개발 환경에서는 알지 못했던 여러 이슈들을 해결해야 되는데, 배포가 빠르게 적용되지 않으면 무턱대고 기다릴 수도 없고, 참 답답할 때가 많습니다.
이런 상황은 바로 CloudFront 의 "캐시" 때문에 일어나는 상황입니다.기본적으로 CloudFront 는 S3 의 원본 데이터를 캐시해서 24시간, 그러니까 만 하루라는 만료 시간을 두고 보관을 했다가 24시간이 지나면 원본에 수정사항이 있는지를 체크해서 업데이트를 진행하게 되어있습니다. 그래서 그 24시간 동안에는 원본인 S3에 업데이트가 있다 하더라도 캐시해둔 예전 데이터를 그대로 돌려주도록 되어있는 거죠. 이렇기 때문에 빌드한 결과물이 즉각적으로 반영되지 않는 겁니다.
캐시 정책을 변경하는 것으로도 이 문제를 해결할 수 있지만, 또 다른 방법으로 엣지 로케이션에 캐시된 데이터들을 제거하는 방법이 있습니다. 아주 간단한, 사실상 오늘 기술발표의 핵심적인 팁인데요. 바로 무효화(Invalidation) 입니다. 지난 8월 말쯤부터 CloudFront 를 한글로도 사용할 수 있게 되면서 보다 더 직관적으로 기능을 이해할 수 있게 되었는데요. CloudFront 에 보면 상단의 탭에서 이 무효화를 확인할 수 있구요. 여기에서 와일드카드를 사용하거나, 필요한 객체를 따로 지정해주기만 하면 아주 손쉽게 각 엣지 로케이션에 캐시된 데이터들을 제거해서, 원본에서부터 다시 데이터들을 받아가게끔 할 수 있습니다.
다만 주의사항이 있다면, 이 작업을 많이 반복할 경우에는 추가적인 비용이 발생할 수도 있다는 점입니다. 그래서 AWS 에서는 파일을 캐시에서 자주 제거해야 하는 경우에는 만료 시간을 짧게 설정해두는 편을 권장하고 있는데요. 이 부분은 동작 탭에서 기존의 동작을 선택해 편집을 누르고 새로운 캐시 정책을 따로 생성해서 TTL 을 조정해주는 것으로 변경이 가능합니다. 근데 이렇게 하게 되면 또 반대로 S3 에 요청이 집중되기 때문에 S3 쪽에서 비용이 발생할 수도 있습니다. 그래서 빠르게 확인이 가능하다는 이유로 너무 자주 배포를 진행하게 되면 비용이 발생할 수도 있다는 점을 늘 염두에 두시고, 배포 과정을 진행하셔야한다는 점을 잊지 않으셨으면 좋겠습니다.
제가 발표할 내용은 여기까지입니다. 발표한 모든 내용은 AWS 의 공식 문서를 기초로 하고 있습니다. 특별히 FAQ 에 가시면 보다 더 자세하고 정확한 내용들이 정리되어 있으니까요. 이 영상이 CloudFront 공식 문서의 내용들을 조금 더 쉽게 이해하는 발판이 되었으면 합니다. 그러면 이것으로 기술발표를 마치도록 하겠습니다. 영상을 시청해주셔서 대단히 감사합니다.
