TL;DR

  • 모든 Cloud Storage 소프트웨어 개발 키트(SDK) 최신 버전은 애플리케이션이 체크섬을 제공하지 않아도 업로드 데이터의 체크섬을 계산해 전달하고, 다운로드 데이터 검증도 지원하는 방식임.
  • Cloud Storage는 수신 데이터의 순환 중복 검사(CRC) 32비트 값을 계산해 디스크 저장 데이터와 비교하며, 클라이언트 체크섬이 있으면 그 값도 대조함.
  • 클라이언트 체크섬이 없는 업로드는 서버 측 계산 전 전송 중 비트 오류에 취약했으며, SDK의 기본 체크섬 기능이 이 공백을 보완함.
  • Google Cloud는 암호화와 복호화 검증, 청크·샤드·블록별 체크섬, CRC 연결 특성을 활용해 데이터가 저장 계층을 거치는 동안 무결성 추적을 유지함.
  • gRPC 범위 읽기는 내장된 종단 간 범위 체크섬을 이용해 SDK에서 데이터를 검증하며, Google Cloud는 최신 SDK 버전으로의 업데이트를 권장함.

Cloud Storage SDK의 종단 간 체크섬

  • Google Cloud는 저장 중인 데이터와 전송 중인 데이터의 내구성과 무결성을 유지하기 위해 모든 Cloud Storage SDK에서 기본적으로 종단 간 체크섬을 활성화함.
  • 디스크 기반 저장 시스템에서는 애플리케이션부터 디스크에 이르는 어느 단계에서든 비트가 바뀔 수 있음. Cloud Storage는 이전부터 클라이언트가 업로드 데이터의 체크섬을 전달하고 다운로드 데이터의 체크섬을 받을 수 있도록 했으며, 객체가 어떤 방식으로 업로드되든 모든 객체의 체크섬을 메타데이터에 저장함.
  • Cloud Storage는 수신한 데이터의 CRC32(32비트 순환 중복 검사)를 계산하고, 디스크에 저장된 데이터가 해당 체크섬과 일치하는지 확인함. 요청에 객체 체크섬이 포함되면 해당 값도 비교함.
  • 업로드 요청에 체크섬이 없으면 서버 측 체크섬 계산 전에 데이터가 전송 중 비트 오류를 겪을 수 있음. 모든 고객과 클라이언트가 클라이언트 측 체크섬을 기본으로 활성화하지는 않아, 그 구간의 데이터가 보호되지 않는 경우가 있었음.
  • 모든 Cloud Storage SDK 최신 버전은 애플리케이션이 체크섬을 제공하지 않으면 업로드 데이터를 내부적으로 체크섬 처리해 Cloud Storage에 전달함. 객체 다운로드 시 체크섬 검증도 지원함.
  • 애플리케이션이 전체 객체 대신 특정 범위를 선택해 내려받는 경우, Cloud Storage SDK와 gRPC API를 함께 사용하면 gRPC에 내장된 종단 간 범위 체크섬으로 수신 데이터를 검증함.
  • 이러한 무결성 기능을 활용하려면 최신 SDK 버전으로 업데이트하는 것이 권장됨.

내부 데이터 보호 과정

  • 애플리케이션에서 디스크까지 데이터와 관련 체크섬 사이의 연속적인 ‘관리 연속성(chain of custody)’을 유지하고, 비트 오류가 감지되지 않는 공백을 없애는 일은 어려운 과제임. Cloud Storage 프런트엔드가 수십만 개에 이르는 현재 규모에서는 비트 오류가 이론적인 문제가 아니며 때때로 발생함.
  • Cloud Storage 프런트엔드가 데이터를 받으면 객체별 암호화 키로 암호화함. 이 과정에서 평문 데이터가 암호화기를 거쳐 암호문을 담은 새 메모리 버퍼로 복사됨. 매우 드물게 이 과정에서 원본 또는 대상 메모리 버퍼의 비트가 바뀔 수 있으며, 운영 규모가 크면 매우 드문 일도 반복적으로 발생함.
  • 이를 감지하기 위해 암호화 후 암호문의 체크섬을 계산하고, 암호문을 다시 복호화함. 결과 평문이 원본과 다르면 처리 결과를 모두 폐기하고 다시 시작함. 이 과정은 암호화와 체크섬 계산에 추가 CPU 시간을 사용하지만 데이터 무결성을 보장하는 데 필요한 단계임.
  • 데이터는 저장 스택의 여러 계층을 지나며 나뉘고 다시 합쳐짐. 업로드 데이터는 각각 자체 체크섬을 가진 청크로 분할되며, Cloud Storage는 수천 개의 청크를 샤드 파일이라는 저장 단위로 묶음.
  • 기가바이트 크기의 샤드 파일은 Cloud Storage가 클러스터 수준 저장 시스템인 Colossus에 전달하는 단위임. Colossus는 리드-솔로몬(Reed-Solomon) 인코딩으로 데이터를 여러 디스크에 분산해 개별 디스크·머신·랙 장애를 방어하며, 이 과정에서 샤드 파일 데이터는 다시 블록으로 나뉘고 각 블록에 체크섬이 적용됨.
  • 데이터 변환 과정의 관리 연속성을 위해 순환 중복 검사(CRC)의 연결 특성을 활용함. 각각 자체 CRC를 가진 두 데이터 버퍼는 데이터를 다시 검사하지 않고도 두 버퍼를 연결한 결과의 CRC를 효율적으로 계산할 수 있음.
  • 청크를 샤드 파일로 연결할 때 Colossus는 구성 청크의 CRC를 이용해 전체 샤드 파일의 CRC를 효율적으로 계산하고 이를 메타데이터에 저장함.

디스크 저장과 읽기 검증

  • 데이터는 최종적으로 네트워크 연결 디스크를 관리하는 ‘D’ 파일 서버의 디스크에 저장됨. D는 Colossus 블록 안의 각 데이터 범위에 인라인 체크섬을 저장함.
  • 디스크에서 데이터를 읽을 때 여러 계층에서 검증이 수행됨. Colossus 클라이언트는 읽은 데이터를 D의 인라인 체크섬과 비교하고, Cloud Storage 프런트엔드는 데이터를 청크별로 읽으며 각 청크의 체크섬을 확인한 뒤 클라이언트에 전송함.
  • 청크 수준 체크섬을 통해 gRPC 프로토콜은 범위 읽기의 체크섬을 제공하며, SDK는 관리 연속성을 유지한 채 이를 검증함.

체크섬 계층 요약

  • 클라이언트가 전체 객체 체크섬을 Cloud Storage 프런트엔드에 전달함.
  • 데이터가 청크로 분할되고 각 청크의 체크섬이 계산됨.
  • 청크 수준 CRC를 연결해 샤드 수준 체크섬을 계산함.
  • 샤드가 디스크 블록에 저장되며, 블록 수준 인라인 체크섬이 추가됨.
  • Cloud Storage는 SDK의 기본 종단 간 체크섬과 내부 저장 스택 전반의 관리 연속성을 통해 업로드 순간부터 최종 다운로드까지 데이터가 의도한 상태를 유지하도록 함. 해당 보호 기능을 충분히 활용하려면 최신 SDK 버전으로 업데이트하는 것이 권장됨.