본 콘텐츠는 사용자의 편의를 고려해 자동 기계 번역 서비스를 사용하였습니다. 영어 원문과 다른 오류, 누락 또는 해석상의 미묘한 차이가 포함될 수 있습니다. 필요하시다면 영어 원문을 참조하시기를 바랍니다.
오늘, R2용 로컬 업로드 를 오픈 베타로 출시합니다. 로컬 업로드 를 활성화하면 개체 데이터가 클라이언트와 가까운 스토리지 위치에 자동으로 먼저 작성된 다음, 버킷이 있는 곳에 비동기적으로 복사됩니다. 데이터에 즉시 액세스할 수 있으며 강력한 일관성을 유지합니다. 업로드는 더 빨라지고, 데이터는 전 세계를 대상으로 합니다.
많은 애플리케이션의 경우 성능이 글로벌해야 합니다. 예를 들어, 미디어 콘텐츠를 업로드하는 사용자가 다양한 지역에서 미디어 콘텐츠를 업로드하거나 전 세계 로그와 원격 측정을 전송하는 장치를 예로 들 수 있습니다. 하지만 데이터는 어딘가에 있어야 하고, 즉 업로드한 데이터가 버킷에 도달하려면 먼 거리를 이동해야 한다는 뜻입니다.
R2는 Cloudflare의 전역 네트워크에 구축된 개체 스토리지입니다. 즉시 사용 가능하므로 개체 데이터를 자동으로 전역적으로 캐시하여 어디에서나 빠르게 읽을 수 있도록 하지만, 동시에 강력한 일관성을 유지하고 송신료를 부과하지 않습니다. 이는 S3 API, Workers 바인딩, 일반 HTTP 중 어떤 것을 사용하든 백그라운드에서 발생합니다. 이제 Local Upload를 통해 전 세계 어디에서나 읽기 및 쓰기 속도를 높일 수 있습니다.
이 데모에서 직접 사용해 보고 로컬 업로드의 이점을 확인해 보세요.
사용할 준비가 되셨나요? Cloudflare 대시보드의 버킷 설정 아래에서, 또는 기존 버킷에 대해 단일 Wrangler 명령으로 로컬 업로드를 활성화할 수 있습니다.
npx wrangler r2 bucket local-uploads enable [BUCKET]
로컬 업로드 에서 업로드 요청(예: (PutObject, UploadPart)보다 더 빨라집니다. 고객을 대상으로 한 비공개 베타 테스트와 종합 벤치마크 모두에서 버킷이 아닌 지역에서 업로드 요청이 이루어질 때 TTLB(Time to Last Byte)가 최대 75%까지 감소했습니다. 이 결과에서 TTLB는 R2가 업로드 요청을 수신한 시점부터 R2가 200 응답을 반환한 시점까지를 측정했습니다.
신세틱 테스트에서 저희는 가상 워크로드를 사용하여 교차 지역 업로드 워크플로우를 시뮬레이션하는 방식으로 로컬 업로드의 영향을 측정했습니다. 저희는 북미 서부에 테스트 클라이언트를 배포하고 아시아 태평양 지역에 대한 위치 힌트 로 R2 버킷을 구성했습니다. 클라이언트는 5MB 크기의 개체를 업로드하기 위해 30분 동안 초당 약 20건의 PutObject 요청을 수행했습니다.
다음 그래프는 이러한 요청에 대한 p50(또는 중앙값) TTLB 지표를 비교하여 업로드 요청 지속 시간의 차이를 보여줍니다. 로컬 업로드가 없는 경우(TTLB가 약 2초), 로컬 업로드가 활성화된 상태(TTLB가 약 500ms)입니다.
로컬 업로드가 업로드 요청을 개선하는 방법을 이해하려면 먼저 R2가 어떻게 작동하는지 살펴보겠습니다. R2의 아키텍처는 다음을 포함한 여러 구성 요소로 구성됩니다.
R2 Gateway Worker: 인증 및 라우팅 로직을 처리하는 모든 API 요청의 진입점입니다. SASE는 Cloudflare Workers를 통해 Cloudflare의 전역 네트워크에 배포됩니다.
Durable Object Metadata Service: Durable Objects 에 구축된 분산형 계층으로, 개체 메타데이터(예: 개체 키, 체크섬)을 통해 제어할 수 있습니다.
분산 스토리지 인프라: 암호화된 개체 데이터를 지속적으로 저장하는 기본 인프라입니다.
Local Uploads를 사용하지 않을 때 버킷에 개체를 업로드할 때 다음과 같은 일이 발생합니다. 그런 다음 클라이언트가 개체 데이터의 바이트를 스트리밍함에 따라 데이터가 암호화되고 버킷이 배치된 지역의 스토리지 인프라에 씁니다. 이 작업이 완료되면 게이트웨이는 메타데이터 서비스에 연결하여 개체 메타데이터를 게시하고, 커밋된 후에는 클라이언트에 성공 응답을 반환합니다.
클라이언트와 버킷이 별도의 지역에 있는 경우 요청이 이동해야 하는 거리가 더 길기 때문에 개체 데이터의 바이트를 업로드하는 과정에서 더 많은 변동성이 발생할 수 있습니다. 따라서 업로드 속도가 느려지거나 안정성이 떨어질 수 있습니다.
로컬 업로드를 활성화하지 않고 북미 동부에서 동유럽 버킷으로 업로드하는 클라이언트.
이제 로컬 업로드를 활성화한 상태에서 버킷에 업로드 요청을 하면 다음 두 가지 케이스가 처리됩니다.
클라이언트와 버킷 지역이 동일한 지역에 있습니다.
클라이언트와 버킷 지역이 다른 지역에 있습니다.
첫 번째 경우에서 R2는 개체 데이터가 버킷의 스토리지 인프라에 작성되는 일반적인 흐름을 따릅니다. 두 번째 경우에서 R2는 버킷 지역의 메타데이터를 개체에 게시하는 동안 클라이언트 지역에 있는 스토리지 인프라에 쓰기 작업을 합니다.
중요한 것은 초기 쓰기가 완료된 후 즉시 개체에 액세스할 수 있다는 점입니다. 전체 복제 프로세스 동안 액세스할 수 있습니다. 개체를 읽을 수 있기 전에 백그라운드 복제가 완료될 때까지 기다릴 필요가 없습니다.
로컬 업로드를 활성화하여 북미 동부에서 동유럽 버킷으로 업로드하는 클라이언트.
이는 관할권이 제한되지 않은 버킷용이며, 관할권 제한이 있는 버킷(예: EU, FedRAMP)를 지원합니다.
로컬 업로드는 버킷이 위치한 곳과 다른 지리적 지역에서 많은 업로드 요청을 받는 워크로드를 위해 구축되었습니다. 이 기능은 다음과 같은 경우에 적합합니다.
읽기 및 쓰기 요청이 시작된 위치의 지리적 분포를 알아보려면 Cloudflare 대시보드를 방문하여 R2 버킷의 지표 페이지로 이동한 다음 지역별 요청 분포 그래프를 보십시오.
Cloudflare에서 로컬 업로드를 구축한 방법
로컬 업로드를 사용하면 개체 데이터가 클라이언트와 가까운 곳에 기록된 다음 백그라운드에서 버킷의 지역에 복사됩니다. 이 복사 작업을 복제 작업이라고 합니다.
이러한 복제 작업을 감안할 때, 비동기 처리 구성 요소가 필요했는데, 이는 Cloudflare Queues를 잘 활용한 사례입니다. Queues를 통해 복제 작업을 처리하는 속도를 제어할 수 있으며, 재시도 및 배달 못한 편지 대기열과 같은 기본 제공되는 장애 처리 기능이 있습니다. 이 경우 R2는 스토리지 지역별로 여러 대기열에 복제 작업을 분할합니다.
로컬 업로드를 활성화한 상태에서 개체의 메타데이터를 게시하면 Cloudflare에서는 세 가지 작업을 원자 단위로 수행합니다.
개체 메타데이터 저장
아직 수행해야 하는 복제를 추적하는 보류 복제본 키 생성
타임스탬프로 작동되는 복제 작업 표시를 생성하여 작업을 대기열로 보내는 시기를 제어합니다
보류 중인 복제 키에는 전체 복제 계획이 포함되어 있습니다. 여기에는 복제 작업 수, 읽을 소스 위치, 쓸 대상 위치, 복제 모드 및 우선순위, 그리고 복제가 성공적으로 완료된 후 소스를 삭제해야 하는지 여부가 포함됩니다.
따라서 개체의 데이터를 이동시키는 방식에 유연성이 생깁니다. 예를 들어 지리적으로 멀리 데이터를 이동시키는 데 비용이 많이 듭니다. 모든 복제본을 병렬로 처리하여 모든 복제본을 최대한 빠르게 이동시킬 수는 있지만, 이는 비용 증가와 네트워크 인프라에 부담을 줄 수 있습니다. 대신 먼저 대상 버킷 지역에 하나의 복제본을 생성하여 지역 간 데이터 이동의 수를 최소화한 다음, 이 로컬 사본을 이용하여 버킷 지역 내에 추가 복제본을 생성합니다.
백그라운드 프로세스는 복제 작업 마커를 주기적으로 스캔하여 대상 스토리지 영역과 관련된 대기열 중 하나로 전송합니다. 마커는 최소 한 번은 대기열로 전달하도록 보장하며, 대기열에 넣기가 실패하거나 프로세스가 충돌하는 경우 마커가 유지되고 다음 스캔에서 작업이 다시 시도됩니다. 또한 이를 통해 상이한 시간에 복제를 처리하고 유효한 작업만 대기열에 넣을 수 있습니다. 복제 작업이 대기열에 도달하면, 처리 준비가 완료됩니다.
대기열 소비자의 경우, 중앙 집중식 폴링 서비스가 지역 대기열의 작업을 소비하고 실행을 위해 Gateway Worker로 보내는 풀 모델을 선택했습니다.
작동 방식은 다음과 같습니다.
폴링 서비스는 지역 대기열에서 가져옵니다. 소비자 서비스는 복제 작업을 위해 지역 대기열을 폴링합니다. 그런 다음 이동할 데이터의 양에 따라 균일한 배치 크기를 생성하도록 작업을 일괄 처리합니다.
폴링 서비스를 게이트웨이 작업자로 디스패치: 소비자 서비스가 복제 작업을 게이트웨이 작업자로 보냅니다.
Gateway Worker가 복제를 실행합니다. 작업자는 소스 위치에서 개체 데이터를 읽고, 대상에 쓰고, Durable Object의 메타데이터를 업데이트하고, 선택적으로 소스 위치를 가비지 수집 대상으로 표시합니다.
Gateway Worker가 결과를 보고합니다. 완료되면 작업자는 결과를 폴러에 반환하고, 폴러는 대기열에 작업을 완료된 것으로 확인합니다.
이러한 풀 모델 접근 방식을 사용함으로써 복제 프로세스가 안정적이고 효율적으로 유지되도록 합니다. 이 서비스는 실시간 시스템 상태에 따라 속도를 동적으로 조정하여 데이터가 지역 간에 안전하게 복제되도록 보장할 수 있습니다.
로컬 업로드는 현재 오픈 베타로 이용 가능합니다. 로컬 업로드를 활성화하는 데 추가 비용은 없습니다. 이 기능을 활성화한 상태에서 업로드 요청을 하면, 로컬 업로드를 이용하지 않고 업로드 요청을 할 때와 마찬가지로 표준 클래스 A 작업 비용이 발생합니다.
시작하려면 버킷 설정에서 Cloudflare 대시보드 를 방문하여 로컬 업로드 카드를 찾아 활성화하거나, Wrangler를 사용하여 다음 명령을 실행하여 버킷에서 로컬 업로드를 활성화하세요.
npx wrangler r2 bucket local-uploads enable [BUCKET]
버킷에 로컬 업로드를 사용하면 원활하게 진행할 수 있습니다. 기존 업로드가 예상대로 완료되고 트래픽이 중단되지 않습니다.
자세한 내용은 Local Uploads 문서를 참조하세요. 질문이 있거나 피드백을 공유하고 싶다면 개발자 Discord의 토론에 참여하세요.