프론트엔드 다섯 개의 정적 자산을 CDN 으로 옮겼습니다. 노린 것은 둘입니다.
이그레스 비용. 첫 화면 한 번 여는 데 오가는 바이트가 전부 로드밸런서 이그레스로 과금되고 있었습니다.
깨우기 지연. 안 쓰는 개발 환경을 재우는 구조를 쓰고 있어서, 자는 파드를 깨우는 데 11 초가 걸립니다. 정적 자산이 CDN 에서 나가면 그 요청들은 파드를 기다리지 않습니다.
먼저 쟀다
앱마다 첫 화면 한 번 로드에 무엇이 오가는지 전부 측정했습니다. 앱에 따라 파일 13~36 개, 0.69~2.19 MB 였고, 그중 약 98% 가 해시 붙은 정적 자산 이었습니다.
해시가 붙어 있다는 건 내용이 바뀌면 이름이 바뀐다는 뜻이라, 캐시를 1 년으로 두고 무효화를 신경 쓰지 않아도 됩니다. 캐시하기에 이보다 좋은 조건이 없습니다.
초판 설계를 버렸다
처음엔 "모든 트래픽을 CDN 으로 통과시키고 정적 자산만 캐시"로 잡았습니다. 그러면 HTML 도, API 도 전부 CDN 을 거칩니다. 규칙 하나만 잘못 써도 캐시되면 안 되는 것이 캐시됩니다.
공식 지침을 읽고 자산 경로만 CDN 을 가리키게 하는 방식으로 바꿨습니다. 동적 요청은 CDN 을 아예 지나지 않습니다. 위험 표면이 비교가 안 되게 작아집니다.
그리고 한 번 틀렸다
문서 초판에 "이미지 최적화를 쓰는 앱은 하나뿐"이라고 적었습니다. 틀렸습니다. 다섯 개 중 세 개만 보고 단정한 결과였습니다. 나중에 전수로 다시 재고 고쳤습니다.
세 개를 보고 다섯 개를 말한 것이 문제였습니다. 표본이 부족한 게 아니라, 부족한 표본으로 전체를 말한 게 문제입니다.
한 앱은 아예 다른 빌드 도구를 써서 자산 경로 규칙 자체가 달랐습니다. "프론트엔드 다섯 개"라고 묶어 부르던 것들이 실은 같은 물건이 아니었습니다.
결과
적중률 99.0%. 24 시간 기준 22 만 건 넘는 요청이 CDN 에서 나가고, 그만큼의 바이트가 로드밸런서 이그레스에서 빠졌습니다.