Cloudflare, Origin Range Requests 기능 출시로 대용량 파일 캐싱 효율 개선

Cloudflare, Origin Range Requests 기능 출시

Cloudflare는 대용량 파일 전송의 효율성을 높이기 위해 'Origin Range Requests' 기능을 모든 요금제에서 셀프 서비스로 제공한다. 이 기능은 HTTP Range 요청을 처리하는 캐싱 방식을 재구축한 것으로, 기존의 고정된 범위 크기 설정 방식이 가진 비효율성을 해결한다. 고객은 더 이상 복잡한 범위 크기를 튜닝할 필요 없이 캐시 규칙을 통해 기능을 활성화할 수 있으며, Cloudflare가 나머지 캐싱 및 조정을 자동으로 처리한다.

기존 캐싱 방식의 한계와 개선 배경

이전 Cloudflare의 Range 요청 캐싱 구현은 Nginx 기반이었으며, 각 클라이언트 요청을 고정된 크기의 파일 범위에 매핑하는 방식이었다. 이 고정된 범위 크기는 작은 범위 요청 시 많은 원본 요청과 메모리 압박을, 큰 범위 요청 시 클라이언트가 필요로 하는 것보다 훨씬 많은 데이터 다운로드를 유발하는 트레이드오프 문제를 안고 있었다. 또한, 범위 크기 변경 시 캐시 항목이 무효화되었고, 동시 요청이 서로를 차단하거나 동시 스트리밍(concurrent streaming)과 결합할 수 없는 문제가 있었다. 이러한 비효율성은 불필요한 네트워크 대역폭 낭비와 디스크 작업 증가로 이어졌으며, 고객이 Cloudflare의 내부 캐싱 메커니즘을 깊이 이해해야 하는 불편함을 초래했다. Cloudflare가 Nginx에서 Pingora 기반 캐싱 서버로 전환하면서 이러한 구현 문제를 해결할 기회를 얻었다.

새로운 Origin Range Requests의 동작 방식

새로운 Origin Range Requests는 Pingora가 중단된 다운로드를 쉽게 재개하기 위해 모든 캐시 파일을 고정 크기 청크로 디스크에 저장하는 방식에서 착안했다. 클라이언트가 파일의 일부를 요청하면, Cloudflare는 요청된 바이트 중 이미 캐시된 부분을 직접 제공한다. 누락된 바이트에 대해서는 캐시의 고정 크기 청크 경계에 맞춰 원본에서 해당 범위를 가져온다. 가져온 데이터는 일반 캐시 저장소와 동일한 청크에 저장되며, 클라이언트에게는 요청된 바이트만 반환된다.

이 과정에서 엣지 서버는 자산 헤더와 범위 커버리지 메타데이터를 조회하고, 디스크 또는 메모리에서 데이터를 읽고, 누락된 부분을 정렬된 범위(aligned ranges)를 사용하여 원본에서 가져와 기록하며, 이 조각들을 결합하여 클라이언트 응답을 구성한다. 또한, 기존 다운로드가 다른 요청의 바이트를 커버하는 경우, 새 원본 페치 대신 기존 다운로드에 연결하여 작업을 공유할 수 있다. 캐시 데이터 모델은 기존과 동일하게 헤더로 자산 버전을 식별하고, 본문은 제한된 청크에 저장되며, 메타데이터는 성공적으로 기록된 범위를 기록한다.

구성된 범위 응답은 모든 바이트가 동일한 표현에 속할 때만 유효하며, 코디네이터는 각 원본 응답이 요청된 범위와 일치하는지, 총 자산 크기가 안정적인지, 엔티티 태그(entity tag)가 하위 요청 전반에 걸쳐 일관적인지 확인한다. `If-Range` 헤더를 통해 클라이언트는 알려진 유효성 검사기와 표현이 일치하는 경우에만 범위를 요청할 수 있으며, 일치하지 않으면 Cloudflare는 전체 표현을 반환한다. Cloudflare는 압축 해제를 앞둔 표현에 대해서는 범위 구성을 피한다. 결과적으로 만족 가능한 범위는 `206 Partial Content`와 정확한 `Content-Range`를, 만족 불가능한 범위는 `416 Range Not Satisfiable`을, 안전하게 범위 지정할 수 없는 응답은 전체 표현으로 제공하는 표준 HTTP 동작을 따른다.

성능 향상 및 트래픽 절감 효과

Cloudflare는 Origin Range Requests 기능을 모든 사용자에게 공개하기 전, 기존 Range 캐싱 기능을 사용하던 워크로드를 새로운 구현으로 전환했다. 특히 R2(Cloudflare의 객체 스토리지)는 가장 큰 내부 사용자였으며, 이전에는 64MiB의 고정 범위 크기를 사용했다. 새로운 구현 적용 후, R2의 스토리지 리전 전반에서 p99 TTFB(Time To First Byte)가 캐시 히트 및 미스 모두에서 약 절반으로 감소하는 결과를 보였다.

또한, 코디네이터가 디스크에 있는 바이트와 원본에서 가져온 바이트를 단일 응답으로 결합하도록 개선한 후, R2 및 유사 워크로드에 대한 계층형 캐시(tiered cache) 트래픽이 주간 약 6% 감소했다. 이는 매일 페타바이트 단위의 데이터가 데이터 센터 간 이동하는 양이 줄어들었음을 의미한다.

개발자 및 사용자 활용 시나리오

Origin Range Requests는 클라이언트가 대용량 캐시 가능 객체의 일부를 자연스럽게 요청하는 트래픽에 특히 적합하다. 주요 활용 시나리오는 다음과 같다: MP4와 같은 점진적 및 탐색 가능한 비디오 스트리밍, 중단 후 재개 가능한 대용량 파일 다운로드, 소프트웨어 배포 및 패키지 저장소, 디스크 이미지, 아카이브 및 기타 멀티 기가바이트 객체 전송, 그리고 대규모 모델 파일을 전송하거나 모델 아티팩트의 특정 영역을 가져오는 AI 학습 및 추론 워크로드 등이 있다. 또한, 대용량 파일의 메타데이터나 작은 영역을 가져오는 클라이언트에게도 유용하다.

Cloudflare는 이 기능을 특정 파일 형식에 대한 기본 서비스 방식으로 설정할 예정이며, 캐시 규칙으로 수정할 수 있도록 할 계획이다.

적용 조건 및 제한 사항

Origin Range Requests 기능은 일반적인 캐시 적격성(cache eligibility)을 변경하지 않는다. 즉, 이 기능을 활성화한다고 해서 원래 캐시할 수 없는 응답이 캐시 가능해지는 것은 아니다. 또한, 부분 원본 페치(partial origin fetches)가 유용하려면 원본 서버가 바이트 범위(byte ranges)를 지원해야 한다.

새로운 방식은 요청이 청크 크기보다 작거나 정렬되지 않은 범위(non-aligned ranges)에 대해 여전히 해당 청크 전체를 가져와야 할 수 있어 추가 작업을 발생시킬 수 있다. 그러나 이러한 추가 작업은 예측 가능하며, 기존 방식처럼 고객이 선택한 범위 크기로 인해 발생했던 예측 불가능한 영향은 제거된다는 점에서 개선되었다.