일관성

이 페이지에서는 strong consistency와 eventual consistency를 가지는 Cloud Storage 작업을 설명합니다. 캐시 가능하고 공개적으로 읽을 수 있는 객체의 경우, 객체에 대한 작업의 일관성 정도를 제어할 수 있습니다.

strong consistency를 가지는 작업

Cloud Storage는 데이터와 메타데이터를 모두 포함하여 다음 작업에 전역 strong consistency를 제공합니다.

  • 쓰기 후 읽기
  • 메타데이터 업데이트 후 읽기
  • 삭제 후 읽기
  • 버킷 나열
  • 객체 나열

Cloud Storage에 객체를 업로드하고 성공 응답을 받으면 Google이 서비스를 제공하는 모든 위치에서 객체를 즉시 다운로드하고 메타데이터 작업에 사용할 수 있습니다. 새로운 객체를 만들거나 기존 객체를 대체할 때도 마찬가지입니다. 업로드는 strong consistency를 가지므로, 쓰기 후 읽기 또는 메타데이터 업데이트 후 읽기 작업에 대해 404 Not Found 응답이나 비활성 데이터가 절대 발생하지 않습니다.

강력한 전역 일관성은 객체에서의 삭제 작업까지도 이어집니다. 삭제 요청이 성공한 경우 즉시 객체 또는 객체의 메타데이터를 다운로드하려고 시도하면 404 Not Found 상태 코드가 반환됩니다. 삭제 작업이 성공한 후에는 객체가 더 이상 존재하지 않으므로 404 오류가 발생합니다.

버킷 나열과 객체 나열은 strong consistency를 가집니다. 버킷이나 객체를 만든 후 즉시 관련 list 작업을 수행하면 새로 생성된 버킷이나 객체가 반환된 목록에 나타납니다.

버킷의 경우 메타데이터 업데이트가 메타데이터 업데이트 후 읽기 작업에 대한 strong consistency를 가지지만 그에 따른 구성 변경사항을 전파하는 데는 시간이 오래 걸릴 수 있습니다. 예를 들어 버킷에 객체 버전 관리를 사용하면 객체를 삭제하거나 대체하기 전에 30초 이상 기다려야 합니다.

HMAC 키의 경우에도 키 상태 변경을 요청하는 시점과 상태 변경이 적용되는 시점 사이에 최대 3분이 지연됩니다. 예를 들어 HMAC 키를 사용 중지하면 처음 3분 동안은 키 삭제를 요청해도 실패하므로 키 삭제를 요청하기 전에 3분 이상 기다려야 합니다.

eventual consistency를 가지는 작업

다음 작업은 eventual consistency를 가집니다.

  • 리소스에 대한 액세스 권한 부여 또는 취소

일반적으로 이러한 작업이 적용되는 데 약 1분 정도 소요됩니다. 경우에 따라 몇 분 더 걸릴 수 있습니다.

eventual consistency로 인해 발생할 수 있는 동작의 예시를 들어보겠습니다. 버킷에 대한 사용자의 액세스 권한을 삭제하면 이 변경사항이 버킷의 메타데이터에 즉시 반영됩니다. 그러나 사용자가 잠시 동안 버킷에 계속 액세스할 수 있습니다.

캐시 제어 및 일관성

공개적으로 읽을 수 있는 캐시된 객체는 강력한 일관성을 나타내지 않을 수 있습니다. 객체를 캐시할 수 있도록 허용하고 객체가 업데이트 또는 삭제 시 캐시에 있으면 캐시 수명이 만료될 때까지 캐시된 객체가 업데이트 또는 삭제되지 않습니다.

객체의 캐시 수명은 객체와 연결된 Cache-Control 메타데이터로 정의됩니다. 객체 최초 업로드 또는 객체의 메타데이터에 후속 업데이트에 포함된 Cache-Control 요청 헤더를 사용하여 Cache-Control 메타데이터를 설정할 수 있습니다. Cache-Control 메타데이터를 제어하므로, 캐시된 객체의 일관성 정도도 제어할 수 있습니다. 또한 객체에 대한 요청에 자체 Cache-Control 헤더를 포함할 수 있지만 캐시된 콘텐츠를 차단하도록 설정된 경우 이러한 헤더는 Cloud Storage에 의해 무시됩니다.