CDN 과 엣지 전달

CDN 은 거리를 줄이는 장치입니다. 서버가 하는 일을 빠르게 만들지는 않습니다.

특히 마지막이 자주 오해됩니다. POST 나 PUT 은 캐시할 수 없어 그대로 원본까지 갑니다. 읽기 위주 서비스에서 효과가 크고, 쓰기 위주면 이득이 거의 없습니다.

두 번째 열의 세 번째도 중요합니다. 로그인 사용자마다 다른 응답은 캐시하면 안 되고, 그러면 CDN 을 거쳐도 매번 원본까지 갑니다. 이때 CDN 은 지연을 줄이지 못하고 오히려 한 단계 더 거칩니다.

흔한 실수: CDN 을 붙였는데 응답이 안 빨라졌다고 원인을 CDN 에서 찾는 것. 캐시 적중률을 먼저 봐야 합니다. 적중률이 낮으면 캐시할 수 없는 응답을 보내고 있는 것입니다.

원인이 물리적 거리라면 서버 성능을 손대도 달라지지 않습니다. 거리를 줄이거나 왕복 횟수를 줄여야 합니다.

2번과 3번이 값싸고 효과가 큽니다. 왕복이 200밀리초라면 순차 호출 5번은 그것만으로 1초입니다. 병렬로 바꾸면 200밀리초가 됩니다.

6번은 비용이 크고 데이터 정합성 문제가 따라옵니다. 쓰기를 어디로 보낼지, 복제 지연을 어떻게 다룰지 정해야 합니다.

흔한 실수: 서버 사양을 올려 해결하려는 것. 서버가 10밀리초에 응답하고 왕복이 200밀리초라면, 서버를 두 배 빠르게 해도 전체는 205밀리초에서 200밀리초가 됩니다.

첫 번째를 기본으로 삼습니다. 빌드 결과에 내용 해시를 붙이면 새 배포가 새 주소가 되므로, 만료를 1년으로 걸어도 옛 파일이 남을 걱정이 없습니다.

HTML 은 이 방법을 쓸 수 없습니다. 주소가 고정이어야 하니까요. 그래서 HTML 은 짧게 캐시하거나 아예 캐시하지 않고, 그 안의 자원 주소만 바꿉니다.

흔한 실수: 정적 자원에 짧은 만료를 걸어 무효화 문제를 피하려는 것. 매번 다시 받아 CDN 을 둔 효과가 사라집니다. 파일명을 바꾸고 만료는 길게 가는 것이 맞습니다.

먼저 요청한 사람의 응답이 뒤이어 온 사람에게 나갑니다. 공유 캐시는 사용자를 구분하지 않습니다.

실제로 여러 서비스에서 발생한 사고 유형입니다. 개발 환경에서는 캐시가 없거나 사용자가 한 명이라 드러나지 않습니다.

마지막이 안전합니다. 기본이 캐시 허용이면 새로 만든 개인화 엔드포인트가 그대로 노출됩니다.

흔한 실수: 쿠키가 있으면 캐시가 안 될 것이라고 가정하는 것. CDN 설정에 따라 쿠키를 무시하고 캐시하는 경우가 있어서, 헤더로 명시해야 합니다.