클라우드플레어, 원본 구간 요청 기능 전 요금제에 셀프서비스 제공

대용량 파일의 일부만 요청하는 서비스를 운영한다면, 클라이언트가 받는 양과 원본 서버에서 가져오는 양을 구분해 볼 필요가 있다. 클라우드플레어는 10월 23일 원본 구간 요청 기능을 모든 요금제에서 고객이 직접 활성화할 수 있게 했다고 발표했다. 국내 운영자가 도입을 검토할 때도 요금제뿐 아니라 원본의 지원 여부와 실제 요청 크기가 판단 기준이 된다.

회사 설명에 따르면 새 구현은 요청된 구간이 캐시에 있는지 확인하고, 부족한 데이터를 내부 저장 청크의 경계에 맞춰 원본에서 가져온다. 클라이언트에는 요청한 바이트 구간만 반환한다. 따라서 사용자가 받는 범위와 캐시를 채우려고 가져오는 범위는 다를 수 있다. 특히 청크보다 작은 요청에는 추가 가져오기가 발생할 수 있다는 제약이 있다.

설정은 캐시 규칙에서 적용할 트래픽을 지정한 뒤 Origin Range Requests를 On으로 바꾸는 방식이다. API에서는 origin_range_requests 항목의 mode를 on으로 설정한다. 다만 기능을 켜도 기존 캐시 적격 조건이 바뀌지는 않는다. 부분 원본 가져오기를 활용하려면 원본 서버가 바이트 범위 요청을 지원해야 한다는 것이 회사 안내다.

클라우드플레어는 자사 객체 저장 서비스 R2에 새 구현을 적용한 결과도 공개했다. 저장 리전 전반에서 캐시 적중 요청과 미적중 요청의 p99 첫 바이트 도착 시간이 각각 대략 절반으로 줄었다고 밝혔다. 이는 회사 내부 운영 결과다. 제공된 자료에는 외부 재현 결과가 없어, 다른 서비스에서도 같은 폭의 개선이 나타난다고 해석할 근거는 부족하다.

회사는 디스크에 있는 데이터와 상위 계층에서 가져온 데이터를 한 응답으로 합치는 후속 변경도 R2에 적용했다고 설명했다. 이후 R2와 유사 작업 부하의 계층형 캐시 트래픽이 전주 대비 약 6% 감소했다고 보고했다. 이 수치는 해당 작업 부하의 결과이며 클라우드플레어 전체 트래픽 감소율을 뜻하지 않는다.

관련 배경으로 깃허브는 10월 21일 객체 저장소를 활용해 읽기와 쓰기의 처리 자원을 별도로 확장하는 구조를 소개했다. 초기 가상 읽기 복제본은 백그라운드에서 상태를 맞추므로 일부 읽기에 적합하며, 모든 종류의 읽기를 처리하려면 요청 처리 경로에 동기화를 포함하는 후속 작업이 필요하다고 밝혔다. 별도 시스템에 관한 발표로, 클라우드플레어의 성능 수치를 검증하는 자료는 아니다.