일관성 모델
R2의 일관성 모델이 어떤지, R2가 어디에서 강력한 전역 일관성(strongly, globally consistent)을 가지며 어떤 작업에 적용되는지 자세히 배워 보아요.
출처: 문서
본문
이 페이지는 R2의 일관성 모델을 자세히 설명해요. R2가 어디에서 강력한 전역 일관성을 가지는지, 그리고 어떤 작업에 이 일관성이 적용되는지를 다루죠.
R2는 특히 다른 분산 객체 스토리지 시스템과 비교하면 "강력한 일관성(strongly consistent)"을 가진다고 설명할 수 있어요. 이러한 강력한 일관성 덕분에 R2에 대한 작업은 항상 최신(정확한) 상태를 보장해요. 즉, 클라이언트는 어떤 쓰기(write), 업데이트(update), 삭제(delete) 작업의 효과를 전역에서 즉시 관찰할 수 있어야 해요.
용어
R2에서 강한 일관성과 결과적(eventual) 일관성은 다음과 같은 의미를 가져요.
- 강력한 일관성(Strongly consistent) - 작업의 효과가 전역에서 모든 클라이언트에게 즉시 관찰돼요. 클라이언트는 '오래된(stale, 일관되지 않은)' 상태를 관찰하지 않아요.
- 결과적 일관성(Eventually consistent) - 클라이언트가 작업의 효과를 즉시 보지 못할 수 있어요. 상태가 전역으로 전파되는 데 시간(보통 몇 초에서 1분)이 걸릴 수 있어요.
작업과 일관성
R2 버킷과 객체에 대한 작업은 다음과 같은 일관성 보장을 따르는 거예요.
| 작업 | 일관성 |
|---|---|
| 쓰기 후 읽기(Read-after-write): 객체를 쓰기(업로드)한 뒤 읽기 | 강력한 일관성: 읽는 사람이 전역에서 최신 객체를 즉시 볼 수 있어요 |
| 메타데이터: 객체의 메타데이터 업데이트 | 강력한 일관성: 읽는 사람이 전역에서 업데이트된 메타데이터를 즉시 볼 수 있어요 |
| 삭제(Deletion): 객체 삭제 | 강력한 일관성: 해당 객체에 대한 읽기는 즉시 "존재하지 않음" 오류를 반환해요 |
| 객체 나열(Object listing): 버킷의 객체 나열 | 강력한 일관성: 나열 작업은 그 시점의 모든 객체를 나열해요 |
| IAM: R2 Storage 권한 추가/제거 | 결과적 일관성: 새로 만들었거나 업데이트한 API 키가 권한을 전역에 반영하는 데 최대 1분이 걸릴 수 있어요 |
추가 참고 사항:
- 두 클라이언트가 같은 키에 대해 쓰기(
PUT또는DELETE)를 수행하는 경우, 쓰기를 마지막으로 완료한 쪽이 "이기는(wins)" 거예요. - 멀티파트 업로드를 수행할 때, 모든 파트가 성공적으로 업로드되면 쓰기 후 읽기 일관성이 계속 적용돼요. 같은 파트를 (실수로) 여러 작성자가 업로드하는 경우 마지막 쓰기가 이겨요.
- 같은 버킷 내에서 객체를 복사하는 것도 새 객체를 쓰는 것과 동일한 쓰기 후 읽기 일관성을 따르는 거예요. 복사 작업이 완료되면 "복사된" 객체는 모든 클라이언트가 즉시 읽을 수 있어요.
- R2 버킷을 삭제하려면 삭제 전에 버킷이 완전히 비어 있어야 해요. 객체가 아직 들어 있는 버킷을 삭제하려 하면
The bucket you tried to delete (X) is not empty (account Y)또는Bucket X cannot be deleted because it isn’t empty.같은 오류를 받게 돼요. 버킷을 비우고 삭제하는 방법은 Delete buckets 문서를 참고해요.
캐싱
참고
기본적으로 Cloudflare의 캐시는 캐시 문서에 따라 일반적이고 캐시 가능한 상태 코드를 자동으로 캐시해요.
R2 버킷에 커스텀 도메인을 연결하고 해당 버킷에서 제공되는 객체에 캐싱을 활성화하면, 캐싱이 활성화된 도메인을 통해 콘텐츠에 접근할 때 일관성 모델이 필연적으로 완화되게 돼요.
구체적으로 다음과 같은 것을 예상해야 해요.
- R2에서 삭제했지만 여전히 캐시에 남아 있는 객체는 계속 이용 가능해요. 삭제를 반영해야 한다면 객체를 삭제한 뒤 캐시를 제거(purge)해야 해요.
- 기본적으로 Cloudflare의 캐시는 HTTP 404(Not Found) 응답을 자동으로 캐시해요. 같은 경로에 객체를 업로드해도 캐시 TTL(Time to Live)이 만료되어 새 객체를 R2에서 가져오거나 캐시가 제거될 때까지 캐시가 계속 HTTP 404를 반환할 수 있어요.
- 특정 키의 객체가 새 객체로 덮어써지면, 캐시 TTL이 만료되거나(또는 객체가 축출되거나) 캐시가 제거될 때까지 이전 객체가 계속 클라이언트에 제공돼요.
캐시는 Worker API 바인딩이나 S3 API를 통한 접근에는 영향을 주지 않아요. 이러한 작업은 캐시를 통하지 않고 버킷에 직접 수행되기 때문이에요.