무슨 일인가요
Cloudflare는 2026년 9월 1일 블로그에 '캐시 트랜스코딩' 프로토타입을 공개했습니다. 지금까지 Cloudflare CDN은 오리진 서버가 보낸 콘텐츠 인코딩(gzip, brotli, zstd, 비압축)을 그대로 캐시에 저장했습니다. 그 결과 같은 콘텐츠의 여러 인코딩이 캐시 계층에 함께 남아 저장 공간을 낭비했고, 분산 저장 시스템의 메모리 비용은 계속 오르고 있었습니다. 공식
새 방식은 Cloudflare의 Rust 기반 프록시 프레임워크 Pingora 안에서, 압축 가능한 자산을 디스크에 쓰기 전에 Zstandard로 인코딩합니다. 압축은 캐시 필 때 한 번만 하고, 해제는 클라이언트에 서브할 때마다 합니다. 공식 블로그는 "인코딩 비용은 자산이 캐시에 들어올 때 한 번 치르지만, 저장과 대역폭 절감은 그 자산이 재사용될 때마다 이어진다"고 설명했습니다. 공식
오리진 응답
gzip·brotli·zstd·비압축 혼재
캐시 필
Zstandard로 1회 인코딩
디스크 저장
원본의 약 1/3 크기
서브
요청마다 디코딩 (641 MB/s)
숫자로 보는 실험
2.834배
평균 압축비
적용 대상 자산의 디스크 크기가 원본의 약 3분의 1로
67.3% / 22.3%
적용 대상 비중 (요청 / 바이트)
압축 가능한 텍스트 자산 기준
232 → 641 MB/s
인코딩 → 디코딩 처리량
바이트당 4.31 ns → 1.56 ns
4 KiB
트랜스코딩 최소 크기
이 기준으로도 측정된 절감 효과의 대부분을 확보
| 항목 | 처리량 |
|---|---|
| 인코딩 (캐시 필 시 1회) | 232 |
| 디코딩 (서브 시 매번) | 641 |
출처: Cloudflare 블로그 (2026-09-01), 바이트당 4.31 ns / 1.56 ns 환산값
적용 대상인 압축 가능한 텍스트는 전체 요청의 67.3%를 차지하지만 바이트 기준으로는 22.3%입니다. 이 자산들의 평균 압축비는 2.834배였습니다. 공식 4 KiB 이상 자산만 트랜스코딩해도 측정된 저장 절감 효과의 거의 전부를 얻었고, 테스트 조건에서 CPU 사용량 증가는 몇 퍼센트 수준이었습니다. 공식 검증은 캐시 서버 10대에서 100만 건 이상의 요청으로 이뤄졌습니다. 공식
같은 회사가 8월 27일에 올린 글에서는 1.1.1.1 DNS 캐시 항목의 메모리 구조를 다섯 차례 바꿔 항목당 953바이트를 420바이트로 56% 줄이고, 전체 서버군에서 약 100테라바이트의 메모리를 확보했다고 밝혔습니다. 공식 두 글을 합쳐 보면 지금 Cloudflare 인프라 팀의 관심은 새 기능보다 저장·메모리 단가에 있다고 읽을 수 있습니다. 추정
왜 Zstandard였나요
블로그가 든 선택 기준은 압축과 해제의 비대칭입니다. 압축은 캐시 필 시점에 한 번이지만 해제는 자산을 서브할 때마다 반복되므로, 디코딩이 싼 알고리즘일수록 재사용이 쌓일수록 유리해집니다. 측정값에서 디코딩은 바이트당 1.56 ns로 인코딩 4.31 ns의 약 2.8배 빠릅니다. 공식
트랜스코딩 하한을 4 KiB로 둔 것도 같은 계산입니다. 작은 자산은 압축해도 줄어드는 절대량이 적은 반면 인코딩 비용은 그대로 들기 때문에, 이 기준만으로도 측정된 저장 절감 효과의 거의 전부를 확보했습니다. 공식 압축 대상이 요청의 67.3%인데 바이트로는 22.3%라는 분포도 같은 이야기를 합니다. 개수는 많고 크기는 작은 텍스트 자산이 캐시의 대부분을 차지한다는 뜻입니다. 추정
무엇을 보면 되나요
- 프로덕션 적용 여부: Cloudflare가 후속 글에서 전체 네트워크 절감량과 실제 CPU 비용을 공개하는지가 이 실험의 성패를 가릅니다.
- 압축 레벨 선택: 현재 결과는 낮은 레벨 기준입니다. 레벨을 올렸을 때 인코딩 비용과 압축비의 교환비가 어떻게 바뀌는지 봐야 합니다.
- 자사 캐시에 적용하려면: 자산의 인코딩 분포(요청 대비 바이트 비중)부터 재는 것이 순서입니다. 이 글의 67.3% 대 22.3%라는 숫자가 그 출발점입니다.
