object-storage

R2 로컬 업로드로 글로벌 (새 탭에서 열림)

Cloudflare는 전 세계 어디에서나 R2 객체 스토리지의 업로드 성능을 극대화할 수 있는 'Local Uploads' 기능을 오픈 베타로 출시했습니다. 이 기능은 클라이언트와 가장 가까운 위치에 데이터를 먼저 기록한 뒤 버킷이 위치한 지역으로 비동기 복제하는 방식을 통해, 지리적 거리로 인한 업로드 지연 시간을 최대 75%까지 단축합니다. 특히 데이터의 즉각적인 접근성과 강력한 일관성을 유지하면서도 글로벌 서비스의 쓰기 성능을 획기적으로 개선한 것이 핵심입니다. ### 전 세계 업로드 성능의 비약적 향상 * **TTLB(Time to Last Byte) 감축**: 내부 테스트 결과, 클라이언트와 버킷의 지역이 다를 때 업로드 완료까지 걸리는 시간이 최대 75% 감소했습니다. * **성능 벤치마크**: 북미 서부에서 아시아 태평양 지역 버킷으로 5MB 크기의 객체를 업로드할 때, 기존 약 2초 소요되던 시간이 Local Uploads 적용 후 약 500ms 수준으로 단축되었습니다. * **글로벌 사용자 경험 최적화**: 전 세계에 분산된 사용자로부터 미디어 콘텐츠를 수집하거나 IoT 장치의 로그 및 텔레메트리 데이터를 전송받는 애플리케이션에 이상적입니다. ### 데이터 처리 메커니즘과 거리 문제 해결 * **기존 방식의 한계**: 기존에는 사용자가 어디에 있든 데이터가 버킷이 지정된 지역의 스토리지까지 물리적으로 이동해야 했으므로, 거리가 멀수록 대기 시간과 불안정성이 증가했습니다. * **로컬 우선 쓰기**: 클라이언트가 버킷과 다른 지역에 있을 경우, R2 게이트웨이는 데이터를 클라이언트 인근 스토리지 인프라에 즉시 기록하고 메타데이터만 버킷 지역에 게시합니다. * **즉각적인 가용성**: 로컬에 쓰기가 완료되는 즉시 객체에 접근할 수 있으며, 배경에서 복제 작업이 진행되는 중에도 데이터 읽기가 가능해 대기 시간이 전혀 없습니다. ### 아키텍처 및 내부 구현 기술 * **Cloudflare Queues 활용**: 복제 작업(Replication Task)을 비동기적으로 처리하기 위해 Cloudflare Queues를 도입했습니다. 이를 통해 실패 시 재시도 처리와 부하 조절(Rate limiting)을 효율적으로 관리합니다. * **원자적 작업 처리**: 메타데이터 저장 시 객체 메타데이터 저장, 보류 중인 복제 키 생성, 복제 작업 마커 생성을 원자적(Atomic)으로 수행하여 데이터 무결성을 보장합니다. * **구성 요소**: 인증과 라우팅을 담당하는 'R2 Gateway Worker', 메타데이터를 관리하는 'Durable Object Metadata Service', 그리고 실제 암호화된 데이터를 저장하는 분산 스토리지 인프라가 협업합니다. ### 사용 환경 및 권장 사항 * **적용 방법**: Cloudflare 대시보드 설정이나 Wrangler 명령(`npx wrangler r2 bucket local-uploads enable [BUCKET]`)을 통해 기존 버킷에서 즉시 활성화할 수 있습니다. * **제한 사항**: 데이터 주권 준수가 필요한 지역 제한(Jurisdiction restriction, 예: EU 전용) 버킷에서는 이 기능을 사용할 수 없습니다. * **활용 팁**: 대시보드의 R2 버킷 메트릭 페이지에서 '지역별 요청 분포'를 확인하여, 읽기/쓰기 요청이 전 세계적으로 분산되어 있다면 Local Uploads를 활성화하는 것이 성능 최적화에 큰 도움이 됩니다.

Husky: Datadog 규모의 효율적인 컴팩션 (새 탭에서 열림)

Husky는 대규모 관측(observability) 데이터를 처리하기 위해 객체 스토리지 위에 구축된 분산 저장 시스템으로, 매일 수조 개의 이벤트를 효율적으로 관리하는 데 최적화되어 있습니다. 이 시스템은 데이터를 '조각(fragment)' 단위로 저장하고 컴팩션(compaction) 과정을 통해 쿼리 성능과 스토리지 비용 사이의 최적의 균형을 맞추는 것을 핵심 전략으로 삼습니다. 특히 파운데이션DB(FoundationDB)를 활용한 원자적 메타데이터 관리와 병렬 워커 기반의 스캔 구조를 통해 데이터 가용성을 유지하면서도 대규모 분석 쿼리를 신속하게 처리합니다. ## Husky의 쿼리 실행 및 조각화 구조 * Husky는 유입된 이벤트를 조각(fragment)이라 불리는 파일로 묶어 객체 스토리지(S3, GCS 등)에 저장하며, 각 조각에 대한 메타데이터를 별도로 관리합니다. * 쿼리 실행 시 시스템은 메타데이터를 검색하여 관련 있는 조각들을 식별하고, 이를 워커(worker) 풀에 분산하여 병렬로 스캔합니다. * 전체 쿼리 비용은 객체 스토리지에서 가져와야 하는 조각의 수와 해당 파일 내에서 스캔해야 하는 이벤트 수에 비례합니다. * 따라서 효율적인 조회를 위해 파일 수를 제어하는 '스트리밍 머지' 방식의 컴팩션과 쿼리당 스캔 이벤트를 줄이는 데이터 조직화 전략을 사용합니다. ## 컴팩션의 "골디락스(Goldilocks)" 문제 컴팩션은 여러 작은 조각을 하나의 큰 조각으로 병합하는 과정으로, 시스템의 효율성을 결정하는 핵심 요소입니다. Husky는 다음 요소들 사이에서 최적의 균형점(Goldilocks)을 찾습니다. * **파일 크기의 상충 관계:** 파일이 너무 작으면 객체 스토리지 접근 지연 시간과 메타데이터 부하가 커지며, 반대로 너무 크면 쿼리 워커 간의 병렬 처리가 제한되어 대규모 쿼리 속도가 느려집니다. * **컴팩션 비용과 성능:** 컴팩션 작업 자체도 CPU와 객체 스토리지 I/O 비용을 발생시키므로, 작업을 최소화하면서도 쿼리 성능을 높일 수 있는 적정 수준의 병합이 필요합니다. * **데이터 레이아웃 최적화:** 컴팩션 시 시간적 혹은 공간적(태그 등) 유사성에 따라 데이터를 재배치하면 압축률이 향상되고 쿼리 시 스캔해야 할 데이터 범위를 좁힐 수 있습니다. * **벡터화 실행:** Husky 워커는 많은 행을 빠르게 스캔하기 위해 벡터화된 실행(vectorized execution) 방식을 사용하며, 이는 적절한 크기의 조각에서 가장 효율적으로 작동합니다. ## FoundationDB를 통한 원자적 상태 관리 * 데이터 유입이 빈번한 환경에서 사용자가 즉시 데이터를 조회할 수 있도록, Husky는 유입 경로에서 짧은 버퍼링 후 작은 조각들을 빠르게 생성합니다. * 수많은 조각의 메타데이터를 관리하기 위해 트랜잭션 보장이 강력한 FoundationDB를 메타데이터 저장소로 사용합니다. * 컴팩션이 완료되면 FoundationDB의 트랜잭션 기능을 이용해 이전 조각들을 새 조각으로 '원자적(atomic)으로 교체'합니다. * 이를 통해 쿼리 시스템은 컴팩션 진행 중에도 데이터 중복이나 누락 없이 항상 일관된 상태의 테이블을 조회할 수 있습니다. 대규모 시계열 및 관측 데이터를 다루는 시스템을 설계할 때는 무조건적인 데이터 병합보다는 쿼리 패턴과 객체 스토리지의 특성을 고려한 컴팩션 정책이 중요합니다. 특히 메타데이터 계층에서 원자성을 확보하여 데이터 일관성을 유지하고, 병렬 스캔의 이점을 극대화할 수 있는 '적정 크기'의 데이터 블록을 유지하는 설계가 권장됩니다.