캐시 응답 규칙 소개

Cloudflare의 Cache Response Rules는 원본 서버 응답이 도착한 뒤, 캐시에 저장되기 전에 응답 헤더와 캐시 지시사항을 수정하는 기능이다. Set-Cookie, 잘못된 Cache-Control, 과도한 ETag 등으로 캐시되지 않던 콘텐츠를 원본 코드 변경 없이 캐시 가능하게 만들 수 있다. 다만 캐시 키처럼 요청 단계에서 이미 결정된 사항은 변경할 수 없으므로 기존 Cache Rules를 대체하지 않고 보완한다.

캐싱 판단이 이루어지는 시점

• CDN은 가능한 한 캐시에서 응답하고, 캐시에서 처리할 수 없을 때만 원본 서버에 요청한다.
• 캐시 적중률이 낮으면 원본 서버의 대역폭과 인프라 비용이 증가하고 응답 속도도 느려진다.
• 원본 서버의 응답 헤더는 다음과 같은 캐싱 정책을 결정한다.
  • 얼마나 오래 캐시할지
  • 언제 재검증할지
  • 애초에 캐시할 수 있는지
• 많은 캐싱 문제는 요청 시점이 아니라 원본 응답이 도착한 뒤에 드러난다.
  • 정적 파일에 실수로 Set-Cookie가 포함됨
  • 캐시해도 안전한 리소스에 Cache-Control: no-cache가 설정됨
  • 브라우저용 지시사항이 Cloudflare 캐싱에도 적용됨
  • 지나치게 공격적인 ETag로 조건부 요청마다 재검증이 발생함

기존 방식의 한계

• 요청 단계에서는 원본 서버가 반환할 응답 헤더를 알 수 없다.
• 따라서 요청 시점에 동작하는 Cache Rules만으로는 Set-Cookie, ETag, Last-Modified, 원본의 Cache-Control 문제를 해결할 수 없다.
• 기존 선택지는 다음과 같았다.
  • 원본 서버 코드나 설정 변경
  • Worker로 응답을 다시 가져와 헤더 수정
  • 낮은 캐시 적중률을 감수
• 특히 원본 서버 담당 팀과 CDN 담당 팀이 다르면 단순한 헤더 하나를 바꾸는 데도 긴 조율이 필요했다.

Cache Response Rules의 동작 방식

• 실행 시점은 다음과 같다.
  1. Cloudflare가 캐시 미스 후 원본 서버에 요청
  2. 원본 응답 수신
  3. Cache Response Rules 적용
  4. 수정된 응답을 Cloudflare 캐시에 저장
• 다음과 같은 응답 변경이 가능하다.
  • Set-Cookie 제거
  • ETag 및 Last-Modified 제거
  • Cache-Control 지시사항 수정
  • 캐시 태그 설정 및 관리
• 모든 변경은 Cloudflare에서 처리되므로 원본 애플리케이션이나 서버 설정을 수정할 필요가 없다.

Cache Rules와 Cache Response Rules의 역할 차이

• Cache Rules는 요청 단계에서 동작한다.
  • 응답을 캐시할지 여부
  • 어떤 캐시 키로 저장할지
  • Edge TTL, 브라우저 TTL, stale 응답 제공 여부
• Cache Response Rules는 응답 단계에서 동작한다.
  • 원본 응답이 캐시에 적합한지 조정
  • 캐시를 막는 헤더 제거
  • 원본의 Cache-Control 수정
  • 캐시 태그 설정
• 두 규칙이 충돌하면 Cache Response Rules가 우선한다.
• 하지만 응답 단계에서는 캐시 키를 변경할 수 없다. 캐시 키는 원본 요청 전에 이미 결정되기 때문이다.

응답 단계에서 가능한 것과 불가능한 것

• 가능한 작업:
  • Set-Cookie를 제거해 캐시 가능하게 만들기
  • 캐시 가능한 응답에 no-store를 설정해 저장하지 않기
  • 원본의 캐시 TTL이나 캐시 지시사항 변경
  • 캐시 무효화를 위한 태그 지정
• 불가능한 작업:
  • 이미 정해진 캐시 키 변경
  • 요청 단계에서 캐시 대상에서 제외된 요청을 뒤늦게 캐시 대상으로 전환
• 따라서 Cache Response Rules는 Cache Rules의 대체재가 아니라, 원본 응답 헤더를 보정하는 보완 기능이다.

실용적인 결론

정적 리소스가 불필요한 Set-Cookie나 잘못된 Cache-Control 때문에 캐시되지 않는다면, 원본 서버를 수정하기 전에 Cache Response Rules를 활용하는 것이 효율적이다. 다만 캐시 여부의 기본 정책과 캐시 키는 Cache Rules에서 먼저 설계하고, 응답 단계에서는 헤더와 TTL 등 원본 응답의 캐시 관련 정보를 보정하는 방식으로 함께 사용하는 것이 적절하다.