클라우드플레어가 대용량 파일의 부분 전송을 효율화하는 ‘오리진 레인지 리퀘스트(Origin Range Requests)’ 기능을 모든 요금제 이용자에게 셀프서비스 형태로 풀었다. 기존에는 대용량 데이터를 다루는 기업들이 별도의 범위 크기를 따로 조정하거나 고객지원팀에 문의를 남겨야만 쓸 수 있던 기능이었다. 이제는 대시보드 내 캐시 규칙(Cache Rule) 설정 화면에서 단추 하나로 바로 켤 수 있다.
HTTP 범위 요청은 동영상 플레이어에서 특정 재생 구간으로 넘어가거나 내려받다가 끊긴 대용량 소프트웨어를 이어 받을 때 쓰는 표준 방식이다. 파일 전체를 다시 불러오는 대신 필요한 특정 바이트 구간만 원본 서버에 요구한다.
그동안 네트워크 현장에서는 이 작은 부분 요청이 오가는 과정에서 병목이 잦았다. 캐시 시스템이 요청받은 작은 조각을 처리하려다 원본 서버에서 필요 이상으로 큰 용량을 한꺼번에 긁어오는 일이 벌어졌기 때문이다. 그렇다고 가져오는 범위를 너무 촘촘하게 쪼개면 원본 서버로 쏠리는 잔요청이 기하급수적으로 늘고 메모리 부하가 치솟는 악순환이 이어졌다.
클라우드플레어는 자체 캐시 인프라를 기존 엔진엑스(nginx) 구조에서 자사 신형 차세대 캐시 서버인 '핑고라(Pingora)'로 완전히 교체하면서 이 구조를 개편했다.
핑고라는 디스크에 저장되는 캐시 파일들을 고정된 크기의 청크(Chunk) 단위로 나누어 관리한다. 사용자 요청이 들어왔을 때 필요한 데이터 조각이 캐시 메모리에 없으면, 원본 서버에서 딱 해당 청크 경계에 맞는 만큼만 끌어와 디스크에 저장한다. 이후 사용자에게는 요청했던 바이트 구간만 잘라 즉시 응답하는 식이다.
엣지 노드는 요청이 들어온 자산의 헤더 정보와 범위 메타데이터를 실시간으로 대조한다. 이미 디스크나 메모리에 남아 있는 조각과 원본 서버에서 새로 끌어와야 하는 영역을 계산해 가장 빠른 조합으로 응답을 구성한다.
인기 있는 대용량 동영상이나 파일에 요청이 갑자기 몰릴 때 발생하는 중복 트래픽도 차단했다. 다른 사용자의 요청으로 필요한 데이터 조각을 원본에서 내려받고 있는 중이라면, 나중에 들어온 두 번째 요청을 진행 중인 스트림에 바로 붙여버린다. 원본 서버로 향하는 중복 호출을 근본적으로 차단하는 셈이다.
응답을 합칠 때 데이터가 꼬이지 않도록 안전장치도 채웠다. 원본 서버가 보내온 응답의 바이트 범위와 전체 파일 크기, 개별 엔터티 태그(ETag)가 명확히 일치하는지 먼저 검증한다. 조건이 맞으면 '206 Partial Content' 상태 코드로 필요한 부분만 내보내고, 범위를 벗어난 잘못된 요청에는 '416 Range Not Satisfiable'을 넘긴다. 데이터 손상 우려가 있어 안전한 부분 처리가 불가능하다고 판단되면 파일 전체를 그대로 전달한다.
효과는 수치로 확인됐다. 클라우드플레어 내부에서 가장 큰 데이터 전송량을 차지하는 객체 스토리지 서비스 'R2'에 이 새 시스템을 먼저 이식해 테스트를 거쳤다. 그 결과 캐시 적중(Hit)과 미적중(Miss) 상황 모두에서 상위 99%(p99) 기준 첫 바이트 응답 시간(TTFB)이 기존 대비 절반 수준으로 줄어들었다.
이미 디스크에 남은 바이트 조각과 상위 서버에서 실시간으로 가져온 스트림을 하나의 응답으로 깔끔하게 결합하는 기술이 들어가면서, R2와 비슷한 성격의 워크로드에서 발생하던 계층형 캐시(Tiered Cache) 트래픽도 일주일 만에 약 6% 감소했다.
이번 기능은 고화질 동영상 스트리밍 플랫폼, 이어받기를 지원하는 대용량 소프트웨어 배포 서버, 대형 아카이브 파일 제공 업체는 물론 최근 용량이 급증하고 있는 생성형 AI 모델 파라미터 파일 전송 인프라에 유용하게 쓰일 것으로 보인다.
