본문으로 바로가기 본문 바로가기
WIKI 기술 지식 베이스

Cloudflare R2 Sippy

원문 보기 위키 갱신

Sippy는 데이터가 요청될 때 다른 클라우드 프로바이더에서 R2로 데이터를 복사하는 데이터 마이그레이션 서비스예요. 대량의 데이터를 옮길 때 흔히 발생하는 불필요한 클라우드 이그레스 요금을 내지 않아도 돼요.

출처: 문서

본문

이미 이그레스 요금을 지불하고 있는 애플리케이션 흐름 안의 요청을 활용해 동시에 객체를 R2로 복사함으로써, 마이그레이션 전용 이그레스 요금을 줄여요.

동작 원리

R2 버킷에 활성화되면 Sippy는 Workers, S3 API, public buckets 전반에 걸쳐 다음 마이그레이션 전략을 구현해요:

  • 객체가 요청되면 R2 버킷에서 찾으면 그 객체를 제공해요.
  • R2에서 객체를 찾지 못하면, 소스 스토리지 버킷에서 객체를 반환하는 동시에 R2로 복사해요.
  • put과 delete를 포함한 다른 모든 작업은 평소처럼 동작해요.

Sippy가 유용한 때

마이그레이션 전략의 일부로 Sippy를 쓰면 좋은 경우는 이럴 때예요:

  • 데이터 마이그레이션을 시작하고 싶은데, 한 번에 모든 데이터를 옮기기 위한 선불 이그레스 요금을 피하고 싶을 때.
  • 데이터 마이그레이션에 시간을 투자하지 않고 이그레스 요금을 없애기 위해 자주 접근하는 객체를 R2에서 제공해 실험해 보고 싶을 때.
  • 자주 변하는 데이터가 있고 다운타임을 피하면서 마이그레이션을 진행하려 할 때. Sippy로 요청을 처리하면서 나머지 데이터는 Super Slurper로 마이그레이션할 수 있어요.

기존 클라우드 프로바이더에서 R2로 모든 데이터를 한 번에 옮기려 한다면 Super Slurper를 권장해요.

Sippy 시작하기

시작 전에 필요한 것:

  • 기존 R2 버킷. 아직 없다면 Create buckets을 참고해요.
  • 소스 객체 스토리지 버킷의 API 자격 증명.
  • (Wrangler만 해당) 읽기·쓰기 권한이 있는 Cloudflare R2 Access Key ID와 Secret Access Key. 자세한 내용은 Authentication을 참고해요.

Dashboard로 Sippy 활성화하기

  1. Cloudflare dashboard의 R2 object storage 페이지로 이동해요. Overview로 이동
  2. 객체를 마이그레이션할 버킷을 선택해요.
  3. Settings 탭으로 전환한 뒤 On Demand Migration 카드까지 스크롤해요.
  4. Enable을 선택하고 객체를 마이그레이션할 버킷의 세부 정보를 입력해요. 입력한 자격 증명은 이 버킷에서 읽을 권한이 있어야 해요. Cloudflare는 자격 증명을 이 버킷에서 읽기만 가능하도록 범위를 좁히는 것도 권장해요.
  5. Enable을 선택해요.

Wrangler로 Sippy 활성화하기

Wrangler 설정

시작하려면 npm을 설치해요. 그다음 Wrangler, Developer Platform CLI를 설치해요.

R2 버킷에서 Sippy 활성화

wrangler login 명령으로 Wrangler에 로그인해요. 그다음 r2 bucket sippy enable 명령을 실행해요:

npx wrangler r2 bucket sippy enable "<BUCKET_NAME>"

지원하는 객체 스토리지 프로바이더 중 하나를 선택하라는 프롬프트가 뜨고, 설정 과정이 안내돼요.

API로 Sippy 활성화하기

필요한 매개변수와 Sippy 활성화 예시는 API documentation을 참고해요. Cloudflare API 시작 방법은 Make API calls을 참고해요.

참고

버킷이 jurisdictional restrictions으로 설정됐다면, 해당 관할권과 함께 cf-r2-jurisdiction 요청 헤더를 전달해야 해요. 예를 들어 cf-r2-jurisdiction: eu처럼요.

마이그레이션 지표 보기

활성화되면 Sippy는 진행 중인 마이그레이션의 진행 상황을 이해하는 데 도움이 되는 지표를 제공해요.

지표 설명
Requests served by Sippy 일정 기간 동안 R2가 제공한 전체 요청의 비율. 비율이 높을수록 소스 버킷으로 보내야 할 요청이 적다는 뜻이에요.
Data migrated by Sippy 일정 기간 동안 소스 버킷에서 R2로 복사된 데이터의 양. 바이트 단위로 보고돼요.

현재 및 과거 지표를 보려면:

  1. Cloudflare dashboard의 R2 object storage 페이지로 이동해요. Overview로 이동
  2. 버킷을 선택해요.
  3. Metrics 탭을 선택해요.

선택적으로 조회할 시간 창을 고를 수 있어요. 기본값은 지난 24시간이에요.

R2 버킷에서 Sippy 비활성화하기

Dashboard

  1. Cloudflare dashboard의 R2 object storage 페이지로 이동해요. Overview로 이동
  2. Sippy를 비활성화할 버킷을 선택해요.
  3. Settings 탭으로 전환하고 On Demand Migration 카드까지 스크롤해요.
  4. Disable을 눌러요.

Wrangler

Sippy를 비활성화하려면 r2 bucket sippy disable 명령을 실행해요:

npx wrangler r2 bucket sippy disable "<BUCKET_NAME>"

API

비활성화에 필요한 매개변수와 예시는 API documentation을 참고해요.

지원되는 클라우드 스토리지 프로바이더

Cloudflare는 현재 다음 클라우드 객체 스토리지 프로바이더에서 R2로 데이터를 복사하는 것을 지원해요:

  • Amazon S3
  • Google Cloud Storage (GCS)
  • Azure Blob Storage
  • S3 호환 스토리지 프로바이더

R2 API 상호작용

Sippy가 활성화되면 Workers, S3 API, public buckets 전반에서 R2 버킷의 특정 작업 동작이 바뀌어요.

작업 새 동작
GetObject GetObject 호출은 먼저 R2 버킷에서 객체를 가져오려 해요. 객체가 없으면 소스 스토리지 버킷에서 객체를 제공하는 동시에 요청된 R2 버킷에 업로드해요.

추가 고려 사항:
  • 소스 버킷에서 객체를 수정해도 최초 복사 이후에는 R2에 반영되지 않아요. 객체가 R2에 저장되면 다시 가져와서 업데이트하지 않아요.
  • HTTP 응답에서 x-amz-meta-로 시작하는 사용자 정의 메타데이터만 마이그레이션돼요. 나머지 메타데이터는 생략돼요.
  • 더 큰 객체(199 MiB 초과)는 R2로 완전히 복사하는 데 여러 GET 요청이 필요할 수 있어요.
  • R2에 아직 완전히 복사되지 않은 객체에 동시 GET 요청이 여러 개 있으면, Sippy는 그 요청들을 처리하기 위해 소스 스토리지 버킷에서 객체를 여러 번 가져올 수 있어요.
HeadObject GetObject와 비슷하게 동작하지만 객체 메타데이터만 가져와요. 요청된 R2 버킷에는 객체를 복사하지 않아요.
PutObject 동작 변화 없음. PutObject 호출은 객체를 요청된 R2 버킷에 추가해요.
DeleteObject 동작 변화 없음. DeleteObject 호출은 요청된 R2 버킷에서 객체를 삭제해요.

추가 고려 사항:
  • R2에서 객체를 삭제하면서 소스 스토리지 버킷에서도 삭제하지 않으면, 이후 GetObject 요청에서 소스 버킷에서 객체를 가져와 R2로 복사하게 돼요.

위에 나열되지 않은 작업은 동작 변화가 없어요. 자세한 내용은 Workers API reference 또는 S3 API compatibility를 참고해요.

스토리지 프로바이더용 자격 증명 만들기

Amazon S3

Amazon S3에서 객체를 복사하려면 Sippy에 버킷에 대한 접근 권한이 필요해요. 올바른 권한이 있는 AWS Identity and Access Management(IAM) 사용자 자격 증명이면 무엇이든 쓸 수 있지만, Cloudflare는 좁은 권한 집합을 가진 사용자 만들기를 권장해요.

올바른 권한의 자격 증명을 만들려면:

  1. AWS IAM 계정에 로그인해요.

  2. 다음 형식의 정책을 만들고 접근 권한을 부여할 버킷으로 <BUCKET_NAME>을 바꿔요:

    {
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": ["s3:ListBucket*", "s3:GetObject*"],
			"Resource": [
				"arn:aws:s3:::<BUCKET_NAME>",
				"arn:aws:s3:::<BUCKET_NAME>/*"
			]
		}
	]
}

  3. 새 사용자를 만들고 만든 정책을 그 사용자에게 연결해요.

이제 Sippy를 활성화할 때 Access Key ID와 Secret Access Key를 모두 사용할 수 있어요.

Google Cloud Storage

Google Cloud Storage(GCS)에서 객체를 복사하려면 Sippy에 버킷에 대한 접근 권한이 필요해요. Cloudflare는 Google Cloud 사전 정의 Storage Object Viewer 역할 사용을 권장해요.

올바른 권한의 자격 증명을 만들려면:

  1. Google Cloud 콘솔에 로그인해요.
  2. IAM & Admin > Service Accounts로 이동해요.
  3. 사전 정의된 Storage Object Viewer 역할로 서비스 계정을 만들어요.
  4. 만든 서비스 계정의 Keys 탭으로 이동해요.
  5. Add Key > Create a new key를 선택하고 JSON 키 파일을 다운로드해요.

이제 Wrangler 또는 API로 Sippy를 활성화할 때 이 JSON 키 파일을 사용할 수 있어요.

Azure Blob Storage

Azure Blob Storage에서 객체를 복사하려면 Sippy에 Azure Storage 계정 이름, 복사할 컨테이너, 그리고 계정 키(account key) 또는 공유 액세스 서명(SAS) 토큰 중 하나가 필요해요. 두 자격 증명 유형 중 정확히 하나만 제공해요. Sippy는 컨테이너에 대한 읽기 및 나열 권한이 필요해요.

계정 키를 사용하려면:

  1. Azure 포털에 로그인해 스토리지 계정으로 이동해요.
  2. Security + networking 아래에서 Access keys를 선택해요.
  3. 스토리지 계정 이름과 나열된 키 중 하나를 복사해요.

대신 SAS 토큰을 사용한다면 Cloudflare는 마이그레이션할 컨테이너로만 범위를 한정할 것을 권장해요:

  1. Azure 포털에 로그인해 스토리지 계정으로 이동해요.
  2. Data storage 아래에서 Containers를 선택하고 마이그레이션할 컨테이너를 열어요.
  3. Shared access tokens을 선택하고 Read와 List 권한을 부여한 뒤 Generate SAS token and URL을 선택해요.
  4. 생성된 SAS 토큰을 복사해요.

이제 계정 이름, 컨테이너 이름, 그리고 계정 키 또는 SAS 토큰 중 하나를 Sippy 활성화에 사용할 수 있어요.

S3 호환 스토리지

S3 호환 스토리지 프로바이더에서 객체를 복사하려면 Sippy에 버킷의 S3 API 엔드포인트 URL과, 그 버킷에서 읽을 수 있는 Access Key ID 및 Secret Access Key가 필요해요. Cloudflare는 이 자격 증명을 마이그레이션할 버킷에서 읽기만 가능하도록 범위를 한정할 것을 권장해요.

버킷의 S3 API 엔드포인트를 찾고 읽기 전용 접근 자격 증명을 만들려면 스토리지 프로바이더의 문서를 참고해요.

이제 버킷 URL, Access Key ID, Secret Access Key를 Sippy 활성화에 사용할 수 있어요.

주의 사항

ETag

정상적인 운영 중에는 R2의 ETag 생성이 S3와 호환되지만, Sippy로 객체를 마이그레이션할 때 ETag가 같다는 보장은 없어요. Sippy는 성능과 네트워크 사용을 최적화하기 위해 객체를 마이그레이션할 때 사용할 작업을 자율적으로 결정해요. 객체를 여러 부분으로 마이그레이션하기로 선택할 수 있는데, 이는 ETag 계산에 영향을 줘요.

예를 들어 원래 S3에서 단일 PutObject 작업으로 업로드된 320 MiB 객체가 멀티파트 작업을 통해 R2로 마이그레이션될 수 있어요. 이 경우 R2의 ETag는 S3의 ETag와 같지 않아요. 마찬가지로 원래 S3에서 멀티파트 작업으로 업로드된 객체도, Sippy가 마이그레이션에 선택한 파트 크기가 원래 업로드 시 파트 크기와 다르면 R2에서 ETag가 달라질 수 있어요.

따라서 마이그레이션 전후 ETag가 일치할 것이라고 기대하는 것은 권장되지 않아요.

더 알아보기 (Learn more)

  • Super Slurper — 대량 데이터를 한 번에 옮기는 일회성 마이그레이션 도구
  • Migration Strategies — Sippy와 Super Slurper를 조합해 효과적으로 마이그레이션하는 전략