일관성

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

strong consistency를 가지는 작업

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

  • 쓰기 후 읽기
  • 메타데이터 업데이트 후 읽기
  • 삭제 후 읽기
  • 버킷 나열
  • 객체 나열
  • ACL을 사용하여 리소스에 대한 액세스 권한 부여

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

또한 업로드 요청이 성공하면 데이터가 여러 데이터 센터에 복제되었음을 의미합니다. Cloud Storage의 전역 일관성이 있는 복제된 저장소에 대한 쓰기 지연 시간은 복제되지 않거나 커밋되지 않은 저장소에 대한 지연 시간보다 약간 길 수 있습니다. 쓰기가 한 개가 아닌 여러 개가 완료된 경우에만 성공 응답이 반환되기 때문입니다.

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

버킷 나열은 strong consistency를 가집니다. 예를 들어 버킷을 만든 직후에 list buckets 작업을 수행하면 새 버킷이 반환된 버킷 목록에 나타납니다.

객체 나열도 strong consistency를 가집니다. 예를 들어 객체를 버킷에 업로드한 직후에 list objects 작업을 수행하면 새 객체가 반환된 객체 목록에 나타납니다.

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

최종 일관성 작업

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

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

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

캐시 제어 및 일관성

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

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