클라우드플레어가 대용량 파일을 CDN으로 제공할 때 발생하는 대역폭 낭비를 근본적으로 해결하는 신기술 'Origin Range Requests'를 공식 출시했다. 모든 요금제에서 자동 활성화되며 별도의 튜닝이 불필요하다.

범위 요청(Range Request)은 영상 플레이어가 특정 구간으로 이동할 때, 전체 파일이 아닌 필요한 바이트만 받는 HTTP 프로토콜 표준이다. 그러나 클라우드플레어의 기존 구현에서는 고정 크기의 청크(Chunk)로 캐싱하도록 설정해야 했으며, 이 설정값이 작으면 원점 서버(Origin)에 수많은 요청이 발생하고, 크면 필요 이상의 데이터를 받아야 하는 딜레마가 있었다.

나이지닉스 캐시의 한계

클라우드플레어가 이전에 채택한 방식은 나이지닉스(Nginx)의 스마트 바이트 범위 캐싱 모델을 따랐다. 고객이 구간 크기를 설정하면, 그에 맞춰 캐시 키가 결정됐다. 예를 들어 100메가바이트(MB) 영상의 약 1MB 구간을 요청하는 경우, 설정된 크기가 128MB라면 클라우드플레어는 전체 128MB를 원점에서 받아서 데이터 센터 간 이동시킨 뒤 클라이언트에게 1MB만 전달했다. 시청자가 이미 떠난 후에도 다운로드가 진행되는 낭비가 발생했다.

또한 같은 128MB 범위 내에서 서로 다른 위치의 구간을 요청한 여러 사용자는 서로 블로킹됐고, 동시 스트리밍(Concurrent Streaming) 기능과 함께 쓰면 응답이 중단되는 문제도 있었다. 결과적으로 고객들은 범위 크기를 최적화하기 위해 클라우드플레어 지원팀과 협력해야 했다.

핑고라 기반 재설계

클라우드플레어가 이 문제를 해결한 방법은 자사의 프록시 서버인 핑고라(Pingora)로의 전환에서 비롯됐다. 핑고라는 중단된 다운로드를 재개할 수 있도록 모든 캐시 파일을 디스크에 고정 크기 청크로 저장한다. 클라우드플레어는 이 청크 모델을 범위 요청에 직접 활용했다.

사용자가 바이트 150250을 요청하면, 클라우드플레어는 해당 바이트를 포함하는 청크 경계에 정렬된 범위를 원점에서 받아온다. 하지만 클라이언트에게는 요청한 150250만 반환한다. 이렇게 되면 구간 크기는 더 이상 고객 설정값이 아니라 캐시 시스템의 내부 청크 크기로 자동 최적화된다.

계층화 캐시 효율성 극대화

클라우드플레어의 R2(객체 저장소) 서비스를 통한 측정 결과에서 Origin Range Requests의 효과가 명확히 드러났다. 99 백분위수 최초 바이트 시간(p99 Time To First Byte)이 약 50% 단축됐다. 계층화 캐시(Tiered Cache) 트래픽도 약 6% 감소했으며, 이는 불필요한 데이터 전송으로 인한 네트워크 비용 절감을 의미한다.

기술적으로 새로운 구현은 '조정자(Coordinator)' 역할을 한다. 캐시된 접두사, 진행 중인 다운로드, 새로 받아온 데이터를 조합하여 하나의 응답을 구성한다. 예를 들어 동시에 같은 파일의 서로 다른 구간을 요청하는 여러 사용자가 있을 때, 한 사용자의 원점 요청에 다른 사용자들이 '붙어서' 같은 다운로드를 공유할 수 있다.

캐시 일관성 보장

중요한 점은 여러 출처(Origin) 응답을 조합할 때 반드시 동일한 파일 버전에서만 바이트를 취합해야 한다는 것이다. 클라우드플레어의 시스템은 각 원점 응답이 요청한 범위와 일치하는지, 전체 자산 크기가 안정적인지, 엔티티 태그(ETag)가 일관되는지 검증한다. 만약 If-Range 헤더로 특정 버전만을 요청했는데 파일이 변경됐다면, 클라우드플레어는 구간이 아닌 전체 파일을 반환한다.

업계 의미와 개발자 영향

이번 변화는 CDN 산업에서 '고객 지원 없이 최적화'라는 새로운 기준을 제시한다. 종전에는 고급 기능을 쓰려면 제공자의 깊은 이해가 필요했다. 이제는 캐시 규칙(Cache Rule) 한 줄로 활성화하면 클라우드플레어 시스템이 자동으로 최적값을 적용한다. 특히 대용량 미디어, 소프트웨어 다운로드, 객체 저장소를 주로 다루는 개발자들과 스타트업에게는 인프라 운영 복잡도가 크게 낮아질 것으로 예상된다.