캐시 무효화, 전체 퍼지를 피하는 방법

전체 무효화는 원본에 부하를 몰아 줍니다

배포할 때 전체 캐시를 지우는 방식은 간단하지만 대가가 큽니다. 캐시가 비는 순간 모든 요청이 원본으로 가므로, 평소 적중률이 높았던 만큼 원본 부하가 갑자기 커집니다. 트래픽이 많은 시간대에 배포하면 그 순간 응답이 느려지거나 원본이 포화됩니다. 그래서 전체 무효화는 마지막 수단으로 둡니다. 대신 세 가지 방법을 먼저 씁니다. 첫째, 이름에 식별자를 넣어 무효화 자체를 없앱니다. 둘째, 바뀐 경로만 지정해 무효화합니다. 셋째, 태그를 붙여 관련 자원 묶음만 지웁니다. 세 방법 모두 원본 부하를 거의 만들지 않습니다.

무효화 대신 주소를 바꾸는 쪽이 낫습니다

가장 좋은 전략은 무효화를 하지 않는 것입니다. 정적 자원의 파일 이름에 내용 기반 식별자를 넣으면, 내용이 바뀔 때 주소가 바뀌어 새 주소로 요청이 갑니다. 예전 주소의 캐시는 그대로 남아 있어도 아무도 요청하지 않으므로 해를 끼치지 않습니다. 이 방식에서는 무효화 작업이 아예 없어지고 배포 직후 부하도 생기지 않습니다. 이름을 바꿀 수 없는 것은 진입 문서 하나뿐입니다. 그 문서만 짧은 캐시 시간으로 두거나 배포 시 그 경로만 무효화합니다. 즉 무효화 대상이 전체에서 한 경로로 줄어듭니다.

원본 추가 요청을 계산합니다

학습용 가정으로 계산합니다. 가정값은 월 배포가 40회이고, 전체 무효화를 하면 회당 18,000건의 요청이 추가로 원본에 간다고 두겠습니다. 월 추가 요청은 720,000건입니다. 대상을 지정해 무효화하면 회당 400건이므로 월 16,000건입니다. 중간 계산값인 차이는 704,000건입니다. 최종 판단은 원본 용량으로 합니다. 원본이 처리할 수 있는 여유가 회당 18,000건의 급증을 받아들일 수 있는지 확인해야 합니다. 받아들일 수 없다면 전체 무효화는 사실상 장애를 만드는 작업이므로 절차에서 제외해야 합니다.

무효화가 즉시 반영되지 않습니다

결론을 뒤집는 조건은 반영 시간입니다. 무효화 요청을 보내도 모든 지점에서 즉시 사라지지는 않고 수초에서 수분이 걸릴 수 있습니다. 그래서 '무효화했으니 바로 새 내용이 보인다'고 전제한 배포 절차는 어긋납니다. 확인 단계에서 몇 번 재시도하도록 절차에 적어 둡니다. 두 번째 조건은 브라우저 캐시입니다. 전송 서비스에서 지워도 사용자 브라우저에 남은 응답은 그대로이므로, 브라우저 캐시 시간이 길면 무효화 효과가 보이지 않습니다. 그래서 진입 문서의 브라우저 캐시 시간을 짧게 두는 설정이 무효화 전략의 전제가 됩니다.

성능 최적화 실행 전 점검표

• 정적 자원에 내용 기반 식별자를 넣어 무효화를 없앴다
• 무효화 대상을 경로나 태그로 지정했다
• 원본이 급증을 받을 수 있는지 확인했다
• 진입 문서의 브라우저 캐시 시간을 짧게 두었다