AWS Cloudfront의 work flow 살펴보기

Origin 요청과 Edge location 요청 간 응답시간 비교

S3를 cloudfront로 배포했을 때 응답 시간 감소의 효과가 얼마나 좋은건지 직접 확인해 보고 싶었다. 

라이브 스트리밍 프로젝트를 진행하면서 동일한 ts파일에 대한 GET 요청을 보냈을 경우 cloudfront에 배포할 때와 단순히 Origin(S3)에서 GET 요청을 보낼 때의 차이를 비교하는 방식으로 테스트를 진행하고자 했다. 그래서 Chrome의 inspector창을 열어 '네트워크'의 '타이밍' 항목을 통해 응답 대기 시간을 비교해 보았다.

방식은 간단하다. 다시보기 서비스 이용을 통해 cloudfront의 캐시 정책을 no-cache로 설정하여 전혀 캐싱을 하지 않을 때와 Elemental-MediaPackage 캐시 정책을 적용했을 때 동일한 ts 파일을 가져오는데 걸리는 시간을 책정하는 방식이다.

응답 속도에 대한 결과는 위 차트와 같았다.
캐시를 전혀 사용하지 않고서 매번 S3에 요청할 때는 상대적으로 고정적인 대기 시간을 확인할 수 있었고, 오히려 더 오래 지연되기도 하는 것을 확인할 수 있었다. 하지만 Cloudfront의 경우 3번째 부터 약 1/10에 달하는 대기 시간 감소 효과를 보여주었다. 이는 여러 개의 크롬창 또는 시크릿 크롬창을 생성한 테스트를 통해 크롬 캐시의 영향력을 배제한 상황에서 진행하였고, 결론적으로 edge location에 캐시 히트가 되면서 위 표와 같이 5ms 대의 응답 시간을 유지하는 것을 확인할 수 있었다.

특히 주목할 점은 캐시 히트의 결과이다. 두 단계에 거쳐 응답 대기 시간이 줄어든 뒤 이후 요청 응답에 걸리는 시간이 고정되는 것을 확인할 수 있는데, 왜 단계적으로 감소했는지에 대한 의문이 생겼다.

이유를 먼저 얘기하자면 원본 데이터가 담긴 Origin 이외에도 Regional edge caches, Edge location 이라는 두 곳의 CDN에 캐시가 있는지 확인하기 때문이다. cloudfront는 기본적으로 이 세 단계를 거쳐 데이터를 가져오는 구조이기에 총 세 차례에 거쳐 응답 시간이 감소하는 것을 확인할 수 있는 것이다.

아래 내용을 통해 그 구조를 좀 더 자세히 살펴보도록 하자

 

cloudfront는 왜 싱가포르 서버에 요청을 보낼까?

우연히 청구서를 보다가 의문점이 생겼다. 그것은 바로 Cloudfront가 싱가포르에 http ot https 요청을 보내는가? 였다.
s3의 경우 서울 리전으로 버킷을 생성했기에 s3에 콘텐츠 GET, POST 요청을 할 경우 청구서에도 서울 리전에 대한 request가 반영되는 것을 확인할 수 있었다.

하지만 위 사진에서 볼 수 있듯이 cloudfront의 청구서를 확인해보면 cloudfront의 요청이 싱가포르에 위치한 CDN에 접근하는 것을 확인할 수 있다.

단순하게 생각했을 때 cloudfront 사용의 장점이 가까운 Edge location에 데이터를 캐싱한 뒤 해당 데이터를 가져올 수 있다는 점, 그로 인해 요청 응답 시간을 줄일 수 있다는 점에서 사용하는 것인데 왜 한국을 두고 멀리 싱가포르까지 요청을 보내는 건 너무 우회하는게 아닌가? 라는 의문이 들었다.

아래는 AWS에 기재된 cloudfront에 대한 설명이다.

[AWS cloudfront에 대한 설명]
Viewers in different geographical regions With Amazon CloudFront, you inherently get a reduced load on your origin because requests that CloudFront can serve from the cache don’t go to your origin. In addition to CloudFront’s global network of edge locations, regional edge caches serve as a mid-tier caching layer to provide cache hits and consolidate origin requests for viewers in nearby geographical regions. Viewer requests are routed first to a nearby CloudFront edge location, and if the object isn’t cached in that location, the request is sent on to a regional edge cache.

[출처]https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/origin-shield.html?icmpid=docs_cf_help_panel

위 글에서는 Edge location과 캐싱의 장점에 대해 설명하고 있지만 그 중 Viewer의 요청이 처음에는 가까운 edge location에 접근하지만 캐시가 없다면 regional edge cache에 접근한다는 문구가 눈에 들어왔다.

그렇다면 대한민국 서버는 edge location에 해당하고 싱가포르가 regional edge cache에 해당하는가? 라는 질문이 생겼고, 그에 앞서 두 location의 차이점이 무엇인지 살펴보았다.

[Edge Locations and Regional Edge Caches]
Regional Edge Caches are located between origin web servers and global edge locations and have a larger cache. Regional Edge Caches have larger cache-width than any individual edge location, so your objects remain in cache longer at these locations. Regional Edge caches aim to get content closer to users.

[출처]https://digitalcloud.training/amazon-cloudfront/#edge-locations-and-regional-edge-caches

위 글에 따르면 Edge location과 origin 사이에 위치한 서버가 Regional Edge Cache이며 이는 Edge location보다 더 넓은 범위의 캐시를 보관할 수 있다고 한다. Regional Edge Caches의 주요 목적 역시 유저 위치가 가까운 곳에서 컨텐츠를 전달하는 것에 있다고 한다.그럼 Regional Edge Cache가 왜 필요한지에 대한 궁금증이 생겼고, 아래 자료를 찾아볼 수 있었다.

[How CloudFront works with regional edge caches]
CloudFront points of presence (also known as POPs or edge locations) make sure that popular content can be served quickly to your viewers. CloudFront also has regional edge caches that bring more of your content closer to your viewers, even when the content is not popular enough to stay at a POP, to help improve performance for that content.

[출처]https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/HowCloudFrontWorks.html

Regional edge caches는 origin으로 요청한 컨텐츠를 캐싱하지만 이 중 popular한 컨텐츠로 판단된 데이터에 대해서는 Edge location에 캐싱한다는 얘기다.

해당 포스트에 싣지 않았지만 내용을 좀 더 살펴보면 Edge location에 캐싱된 콘텐츠는 또 다른 신규 인기 콘텐츠를 배치하기 위해 비주류에 해당하는 콘텐츠는 날려버린다고 한다. 하지만 해당 데이터는 Regional edge caches에서 더 오랜 기간(아마도 설정한 TTL만큼의 기간일 것으로 예상된다.) 보관하므로 웬만해서는 origin까지 가지 않도록 하려는 의도이다.

여기까지 Regional edge caches와 Edge location에 대해서 이해하게 되었다. 하지만 근본적인 의문이 풀리지 않았다. 바로 싱가포르가 Regional이고 서울이 Edge location인가? 라는 점이다. 하지만 아래 자료를 통해 오히려 의문은 더 커졌다.

[글로벌 엣지 네트워크]

[아시아]
엣지 로케이션:
인도 뉴델리(14), 인도 첸나이(8), 인도 뭄바이(8), 인도 푸네(4), 인도 방갈로르(5), 인도 하이데라바드(5), 싱가포르(7), 일본 오사카(5), 일본 도쿄(22), 대만 타오위안(3), 한국 서울(8), 태국 방콕(2), 인도 콜카타(4), 인도네시아 자카르타(5), 말레이시아 쿠알라룸푸르(2), 필리핀 마닐라(2), 베트남 하노이(1), 베트남 호치민(1)

리전별 엣지 캐시:
인도 뭄바이, 싱가포르, 대한민국 서울, 일본 도쿄

[출처]https://aws.amazon.com/ko/cloudfront/features/?whats-new-cloudfront.sort-by=item.additionalFields.postDateTime&whats-new-cloudfront.sort-order=desc#Global_Edge_Network

대한민국 서울의 경우 엣지 로케이션의 역할도 하지만 리전 엣지 캐시의 역할도 하고 있다. 그렇다면 서울을 엣지 로케이션으로 활용하고 있다면 거리상 일본 도쿄를 리전 엣지 캐시로 사용해야하는 것이 아닌가? 라는 의문이 들었다. 거리상 일본이 훨씬 가깝기 때문이다.

추가적인 자료를 찾아봤지만 지금으로서는 지리적 거리 이외 네트워크 상황과 기타 여건에 따라 AWS에서 리전 엣지 캐시를 선정한다는 정도의 정보만 찾을 수 있었다. 그런 이유에서인지 청구서를 보면 간혹 유럽, 캐나다에도 요청을 보낸 흔적을 찾을 수 있었다.

캐시 서버의 층을 더하는 Origin Shield 서비스

cloudfront를 조사하면서 원본 탭에 자그마하게 비치된 Origin Shield라는 서비스를 발견할 수 있었다. 이는 위 그림처럼 Origin과 Regoinal 사이에 배치되는 것을 확인할 수 있다. 그래서 총 3 단계 캐시 층을 쌓은 전략을 적용하는 것이다. 

AWS에서는 크게 두 가지 케이스에 대해서 Origin Shield 사용을 적극 권장했는데 첫번째는 Viewer, 즉 콘텐츠를 요청하는 클라이언트가 글로벌하게 퍼져있을 때였고, 두번째로는 여러 개의 CDN을 사용하고 있을 때 였다.

위 사진이 마침 딱 첫번째 케이스에 대한 사용 사례에 해당한다. 만약 콘텐츠 주요 소비자가 한국과 미국에 있다면 Regional edge caches는 두 군데가 생성될 것이다. 한국은 싱가포르, 미국은 아마도 켈리포니아 혹은 버지니아 쪽이 아닐까 싶다. 그러면 Origin에서는 동일한 콘텐츠에 대해서 총 두 군데의 Regional edge caches에 응답해야한다. Origin에 요청을 보내는 횟수가 올라가는 것은 다 돈에 해당한다. 즉 요청비가 두 배씩 발생하는 것이다. 이를 방지하기 위해 Origin 앞에 Origin Shield를 세워 두는 것이다. 그렇게 되면 Origin 콘텐츠에 대한 요청는 오로지 Shield와 단 둘이서 소통하면 되므로 요청 비용을 절감할 수 있다는 즉, 비용 효율성을 높일 수 있다는 원리이다. 이는 Regional edge caches가 많을 수록 더 효과적일 것이다.

두번째는 아래 사진 예시와 같은데 위 사례와 비슷한 맥락이다.

만약 cloudfront를 위 사진과 달리 AWS 서비스가 아닌 타 CDN과 더불어 여러 CDN 중 하나로서 사용하고 각각의 CDN이 하나의 Origin을 바라본다고 한다면 이 또한 요청수가 상대적으로 높을 수 밖에 없을 것이다. 위 사례에서의 Regional edge caches가 여기서는 CDN에 해당하는 케이스라고 볼 수 있다. 이 케이스도 동일한 콘텐츠를 여럿 요청하는 사태를 방지하는 것에 목적이 있다. 그래서 타 CDN을 cloudfront의 cache 계층에 포함시키면서 최대한 Origin Shield에서 콘텐츠를 가져가도록 아키텍처를 수정한 사례이다.

라이브 스트리밍 서비스에서의 Origin Shield 서비스 적용?

서비스 이용자가 국내와 아시아 수준에 머문다면 Origin Shield는 불필요하다고 생각한다. 아시아 수준의 서비스는 Regional edge caches가 싱가포르 하나만 존재할 가능성이 높기 때문이다. 하지만 Regional edge caches는 내가 선택할 수 있는 사항이 아니므로 언제 리전이 늘어날지는 모를 일이다. 그래서 모니터링 결과에 따라 결정이 필요한 사항이라고 생각한다.