일관성

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

strong consistency를 가지는 작업

Cloud Storage는 다음 작업에 전역적 strong consistency를 제공합니다.

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

Cloud Storage에 객체를 쓰거나(예: 객체를 업로드, 구성, 복사) 쓰기 요청에 대한 성공 응답을 받는 즉시 객체를 읽기 및 메타데이터 작업에 즉시 사용할 수 있습니다. 모든 버킷과 모든 스토리지 클래스에 해당되며, 이는 새 객체 만들기와 기존 객체 바꾸기에 모두 적용됩니다.

이중 리전 또는 멀티 리전에 위치한 버킷이더라도 쓰기는 strong consistency를 가지므로, 쓰기 후 읽기 또는 메타데이터 업데이트 후 읽기 작업에 대해 404 Not Found 응답이나 비활성 데이터가 절대 발생하지 않습니다. 드물지만 데이터가 아직 리전에 복제되지 않았는데 객체를 처음 쓴 위치를 사용할 수 없게 될 경우 해당 객체에 액세스를 시도하면 재시도 가능한 500 오류 응답이 반환됩니다.

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

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

버킷의 경우, 메타데이터 업데이트 후 읽기 작업에 대해 메타데이터 업데이트의 일관성은 강력하지만, 그에 따른 구성 변경 사항을 전파하는 데는 시간이 오래 걸릴 수 있습니다. 예를 들어 버킷에 객체 버전 관리를 사용하면 객체를 삭제하거나 대체하기 전에 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에서 무시합니다.

원자적 작업

Cloud Storage는 객체 업로드 (기존 객체 덮어쓰기 포함), 객체 메타데이터 업데이트, 객체 교체, 객체 삭제와 같은 개별 객체와 관련된 대부분의 작업에 대한 원자성 보장을 제공합니다.

일괄 요청은 원자적 성격을 보장하지 않습니다. 일괄 요청 내의 단일 작업은 원자적일 수 있지만 일괄 요청 내의 모든 작업이 그룹으로서 원자적일 수는 없습니다. 일부 작업은 성공하고 다른 작업은 실패할 수 있기 때문입니다.

캐시된 데이터가 비활성화되거나 가져올 객체가 덮어쓰이는 세대 번호를 지정하지 않고 범위 읽기를 실행하는 경우와 같이 이전 버전의 객체가 가져와지는 경우도 있습니다. 가장 좋은 방법은 사전 조건을 사용하여 올바른 객체 버전을 가져오는지 확인하는 것입니다.

다음 단계