해시 및 ETag: 권장사항

Cloud Storage에서는 CRC32c 또는 MD5 체크섬을 사용하여 버킷과 전송하는 데이터 유효성을 검사하는 것이 좋습니다. 이 섹션에서는 이러한 유효성 검사를 수행하는 권장사항을 설명합니다.

해시를 사용한 무결성 검사

Cloud에서 업로드 또는 다운로드하는 동안 데이터가 여러 가지 이유로 손상될 수 있습니다.

  • 트래픽이 많은 네트워크 링크
  • 클라이언트나 서버 컴퓨터, 또는 경로상에 있는 라우터에서의 메모리 오류
  • 소프트웨어 버그(예: 고객이 사용하는 라이브러리에서)

데이터 손상을 방지하기 위해 Cloud Storage는 CRC32C 및 MD5 등 두 가지 유형의 해시를 지원합니다(아래에서 설명). 고객은 아래 유효성 검사 섹션의 설명에 따라 모든 경우에 CRC32C를 사용하는 것이 좋습니다. MD5를 선호하는 고객은 해당 해시를 사용할 수 있지만, 복합 객체에 대해서는 지원되지 않습니다.

CRC32C

모든 Cloud Storage 객체에는 CRC32c 해시가 있습니다. CRC32C는 Castagnoli 다항식을 기반으로 하는 32비트 순환 중복 검사(CRC)입니다. 이 CRC는 SCTP의 IETF 규격으로 설명됩니다. CRC32c 계산용 라이브러리에는 Google의 CRC32C, C++용 Boost, Python용 crcmod, Ruby용 digest-crc가 포함됩니다. 자바 사용자는 GoogleCloudPlatform crc32c 자바 프로젝트에서 알고리즘 구현을 확인할 수 있습니다.

Base64 인코딩 CRC32c는 Big Endian 바이트 순서입니다.

MD5

Cloud Storage는 비 복합 객체에 대해 MD5 해시를 지원합니다. 이 해시는 전체 객체에만 적용되므로, 범위 GET에 의해 실행되는 부분 다운로드의 무결성 검사에는 사용될 수 없습니다.

ETag

이전부터 객체의 MD5는 ETag 헤더를 통해 표현되었습니다. 이 동작은 XML API의 비 복합 객체에 대해서는 계속되고 있지만 복합 객체는 MD5 해시를 지원하지 않으므로, 사용자는 규격에 따라 기본 데이터가 변경될 때마다 변경이 수행된다는 점만 제외하고 이러한 ETag에 대해 어떤 가정도 하지 않아야 합니다.

유효성 검사

다운로드한 데이터를 실시간으로 해싱하고 결과를 서버에서 제공한 해시와 비교하여 다운로드 무결성 검사를 수행할 수 있습니다. 잘못된 해시 값이 있는 다운로드 데이터를 삭제하고 잠재적으로 높은 비용을 초래하는 무한 루프를 방지하기 위해 재시도 로직을 사용해야 합니다.

Cloud Storage는 업로드에 대한 서버 측 유효성 검사를 지원하지만 클라이언트 측 유효성 검사도 일반적인 방법입니다. 애플리케이션이 업로드를 시작하기 전에 이미 객체의 MD5 또는 CRC32c를 계산한 경우, 업로드 요청으로 이를 제공할 수 있습니다. 그러면 사용자가 제공한 해시가 Google이 계산한 값과 일치하는 경우에만 Cloud Storage가 객체를 생성합니다.

또는, 사용자가 새로운 객체의 메타데이터에 대한 요청을 발행하고 보고된 해시 값을 비교한 후 일치하지 않으면 객체를 삭제하여 클라이언트 측 유효성 검사를 수행할 수 있습니다. 독립된 프로세스가 서로의 데이터를 삭제하거나 덮어쓰는 경합 상태를 방지하기 위해 객체 생성과 전제 조건을 사용하는 것도 좋습니다.

객체 구성을 사용하는 동시 업로드의 경우, 사용자는 각 구성요소 업로드에 대한 무결성 검사를 수행한 후 구성 요청과 함께 구성요소 전제 조건을 사용하여 경합 상태를 방지해야 합니다. 객체 구성은 서버 측 MD5 유효성 검사를 제공하지 않으므로, 엔드 투 엔드 무결성 검사를 수행할 사용자는 새로운 복합 객체에 클라이언트 측 유효성 검사를 적용해야 합니다.

각 복사 작업이 끝날 때마다 gsutil cprsync 명령어가 로컬 파일의 체크섬이 Cloud Storage에 저장된 객체의 체크섬과 일치하는지 확인합니다. 일치하지 않으면 gsutil이 잘못된 복사본을 삭제하고 경고 메시지를 인쇄합니다. 이러한 일은 매우 드뭅니다. 실제로 발생하는 경우, 작업을 다시 시도할 수 있습니다.

XML API

XML API에서는 base64 인코딩 MD5 및 CRC32c 해시가 x-goog-hash 헤더를 통해 노출되고 수용됩니다. 이전에는 MD5가 객체 ETag로 사용되었지만 사용자는 이러한 가정을 하지 않는 것이 좋습니다. 객체 변경 시 복합 객체는 변경 이외에는 어떤 보장도 하지 않는 불투명한 ETag 값을 사용하기 때문입니다.

서버 측 업로드 유효성 검사는 x-goog-hash 요청 헤더를 통해 로컬에서 계산된 해시를 제공하여 수행될 수 있습니다. 또한 표준 HTTP Content-MD5 헤더를 사용하여 MD5를 제공할 수 있습니다(규격 참조).

JSON API

JSON API의 경우 객체 리소스 md5Hashcrc32c 속성에는 각각 base64 인코딩 MD5 및 CRC32c 해시가 포함되어 있습니다. 메타데이터 속성 제공은 선택사항입니다. 객체 삽입에서 속성이 제공되지 않으면 Cloud Storage가 이 값을 계산하고 객체의 메타데이터에 씁니다. 삽입 요청을 통해 이러한 속성을 제공하면 새로운 객체의 서버 측 유효성 검사가 실행됩니다. Cloud Storage가 제공된 값과 일치하지 않는 속성 값을 계산하면 객체가 생성되지 않습니다. 다시 시작할 수 있으며 여러 부분으로 구성된 업로드의 경우, 단일 객체 삽입과 같은 방식으로 md5Hashcrc32c 속성을 사용합니다.

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

도움이 필요하시나요? 지원 페이지를 방문하세요.