Cloudflare, Workers 앞단 전용 캐시 공개…서버 렌더링 비용 줄인다

Cloudflare 공식 블로그에 따르면 회사는 Workers Cache를 공개하고, 서버리스 Worker 앞단에서 HTTP 응답을 캐시하는 기능을 제공한다고 밝혔다. 이 기능은 Worker가 원점처럼 동작하는 서버 렌더링 애플리케이션에서 매 요청마다 코드를 실행해야 하는 부담을 줄이는 데 초점을 맞췄다.

Workers Cache가 활성화되면 캐시 가능한 요청은 먼저 Cloudflare 캐시를 거친다. 신선한 캐시 응답이 있으면 Worker 코드는 실행되지 않고, 응답은 엣지에서 바로 반환된다. 캐시가 없을 때만 Worker가 실행되며, 해당 응답이 캐시 조건을 충족하면 다음 요청을 위해 저장된다.

Cloudflare는 이 기능이 기존 존 단위 캐시 설정과 다르다고 설명했다. Workers Cache는 특정 존이 아니라 Worker에 속한 캐시로 동작한다. 같은 Worker가 커스텀 도메인, workers.dev, 서비스 바인딩, 프리뷰 환경에서 호출되더라도 Worker의 캐시 정책을 중심으로 작동한다는 의미다.

공식 문서에 따르면 Workers Cache는 표준 HTTP Cache-Control 지시문을 사용한다. 개발자는 별도의 캐시 규칙 화면을 구성하지 않고 Worker 응답 헤더에서 max-age, stale-while-revalidate 같은 값을 설정할 수 있다. 콘텐츠 변경 시에는 태그나 경로 기준으로 캐시를 지우는 방식도 제공된다.

기술적으로 중요한 부분은 계층형 캐시다. Cloudflare 문서는 Workers Cache가 기본적으로 가까운 데이터센터의 하위 캐시와 여러 지역을 묶는 상위 캐시를 함께 사용한다고 설명한다. 한 지역에서 첫 요청이 캐시를 채우면 이후 다른 지역 요청도 Worker 실행 없이 상위 캐시에서 응답을 받을 수 있어, 단일 엣지 캐시보다 적중률을 높일 수 있다는 설명이다.

또 하나의 변화는 Worker 엔트리포인트 사이에도 캐시를 둘 수 있다는 점이다. Cloudflare는 기본 export, 이름이 붙은 WorkerEntrypoint, ctx.exports를 통한 루프백 호출, 서비스 바인딩 호출에 캐시를 적용할 수 있다고 밝혔다. 인증·라우팅을 담당하는 외부 Worker는 매번 실행하고, 비용이 큰 데이터 처리나 서버 렌더링을 담당하는 내부 엔트리포인트만 캐시하는 식의 구성이 가능해진다.

서버 렌더링 프레임워크를 Workers 위에 배포하는 개발자에게는 선택지가 넓어진다. 지금까지는 모든 요청을 렌더링하거나, 빌드 시점에 정적 페이지를 미리 만들어야 하는 경우가 많았다. Workers Cache는 요청 시점에 한 번 렌더링한 결과를 HTTP 캐시로 재사용해 정적 사이트에 가까운 응답 속도와 서버 렌더링의 최신성을 함께 노리는 방식이다.

다만 모든 요청에 적합한 기능은 아니다. Cloudflare 문서는 요청마다 바뀌는 사용자별 응답, POST·PUT·DELETE 같은 비멱등 작업, 매번 새로 계산해야 하는 응답에는 캐시가 유용하지 않다고 안내한다. 인증된 응답을 다룰 때도 Cache-Control, Authorization 헤더 처리, ctx.props 기반 캐시 키 분리를 신중히 설계해야 한다.

이번 공개는 엣지 서버리스 플랫폼이 단순 실행 환경에서 애플리케이션 성능 제어 계층으로 확장되고 있음을 보여준다. 서버 렌더링, API 조합, 데이터 변환처럼 반복 계산이 많은 워크로드에서 캐시가 Worker 실행 횟수와 지연 시간을 줄일 수 있다면, 개발자는 별도 원점 서버나 프레임워크별 증분 정적 생성 기능에 덜 의존하는 구조를 선택할 수 있다.

출처: Cloudflare Blog https://blog.cloudflare.com/workers-cache/ · Cloudflare Docs https://developers.cloudflare.com/workers/cache/