Skip to content
Blog
Go back

CloudFront: 티켓팅 화면 caching 설계

신사업 TF의 티켓팅 웹 플랫폼에서 화면 caching을 설계하고, 그 그림을 팀에 공유했다. WebView 글의 그 신사업이다. CloudFront는 티켓 서비스에만 썼다. React 티켓팅 화면은 우리 팀이 만들어 배포했다.

문제 파악

티켓팅은 짧고, 그 사이에 트래픽이 몰린다. 이 화면은 우리 팀이 배포한 React build였다. server로 페이지를 그릴 필요가 없었다. 파일을 그대로 두면 요청이 앱을 서빙하는 Graviton instance에 바로 닿는다. 회사 instance 앞에는 load balancer가 하나 있었다. 그 load balancer는 내가 관리하지 않았다. 화면은 CloudFront 뒤에 두었다.

cache된 페이지가 나갔는지는 CloudFront 응답 header X-Cache로 봤다. Hit from cloudfront면 edge cache에서 나간 것이고, Miss from cloudfront면 origin에서 가져온 것이다.

문제 정의

이건 순간 트래픽을 origin에서 떼어 내는 caching 설계였다. React build의 index.html은 짧게 두고, CSS, JS, font는 파일 이름이 바뀔 때까지 길게 둬야 했다. 남은 좌석 같은 동적 값은 cache하지 않아야 했다.

문제 해결

TTL은 CloudFront cache policy로 줬다. index.html은 24시간이다. index.html이 불러오는 CSS, JS, font는 1년이다. 24시간이 지나 새 index.html이 나가면, 그 안의 CSS, JS, font 참조는 hash가 붙은 파일 이름으로 바뀐다. 그래서 asset을 길게 cache해도 새 HTML이 옛 파일을 집지 않는다.

다만 index.html을 24시간 cache하면, invalidation 없이는 그 파일이 만료되기 전까지 옛 index.html이 나간다. 길면 24시간이다. 급한 수정은 그래서 cache를 지워야 했다. AWS를 관리하던 부서와 맞춰 CloudFront invalidation으로 지웠다. invalidation은 만료 전에 edge cache에서 파일을 빼고, 다음 요청이 origin의 최신을 가져가게 한다.

남은 좌석 같은 동적 데이터는 API로 따로 가져왔다. 그 응답은 cache하지 않았다.

Miss면 요청은 CloudFront에서 load balancer를 거쳐 Graviton instance로 간다. 그 instance가 React build를 서빙한다.

트래픽 테스트에서는 CloudFront를 거치는 편이 비용이 훨씬 낮았다. instance의 CPU와 memory는 안정적으로 유지됐고, 죽지 않았다. 수치는 없다.

팀에 공유하려고 그렸던 구성을 다이어그램으로 다시 적는다.

개선할 점

24시간 동안 옛 index.html이 남을 수 있고, 그것을 당장 지우려면 AWS를 맡은 부서의 invalidation을 기다려야 했다. 다음에 같은 설계를 하면, 그 공백을 먼저 보겠다.

참고


Share this post:

Previous Post
HLS: master playlist
Next Post
WebView: postMessage handshake