데이터 가용성 및 내구성

이 페이지에서는 Cloud Storage가 데이터를 중복 저장하는 방법, 이중 리전 및 멀티 리전의 기본 복제 동작, 이중 리전의 터보 복제 기능, 교차 버킷 복제 기능을 포함하여 Cloud Storage의 데이터 가용성 및 내구성과 관련된 개념을 설명합니다.

주요 개념

  • Cloud Storage는 연간 내구성 99.999999999%(9 11개)를 위해 설계되었습니다.

    • 이를 달성하기 위해 Cloud Storage는 삭제 코딩을 사용하고 여러 가용성 영역에 있는 여러 기기에 데이터 조각을 중복해서 저장합니다.

    • Cloud Storage는 스토리지에 기록된 객체를 최소 2개 이상의 서로 다른 가용성 영역에 중복해서 저장한 후에야 쓰기 작업이 성공한 것으로 간주합니다.

    • 체크섬을 저장하고 정기적으로 재평가하여 모든 저장 데이터의 무결성을 사전에 확인하고 전송 중인 데이터의 손상을 감지합니다. 필요한 경우 중복 데이터를 사용하여 수정을 자동으로 수행합니다.

  • Cloud Storage에 저장된 데이터의 월간 가용성은 데이터의 스토리지 클래스 및 버킷의 위치 유형에 따라 달라집니다. 자세한 내용은 사용 가능한 스토리지 클래스를 참조하세요.

  • 이중 리전 또는 멀티 리전 버킷에 저장된 객체는 최소 두 곳 이상의 지리적 장소에 중복 저장됩니다.

    • 이중 리전의 경우 객체가 저장되는 특정 리전을 선택합니다.

    • 멀티 리전의 경우 데이터를 저장하는 데 사용되는 특정 데이터 센터는 필요에 따라 Cloud Storage에 의해 결정되지만 멀티 리전의 지리적 경계 내에 위치하며, 최소 161km(100마일) 이상 떨어져 있습니다. 이렇게 하면 이중 리전보다 스토리지 비용이 낮은 리전 간에 중복성을 제공합니다.

    • 자연 재해 등으로 인한 리전 전체의 서비스 중단이 발생하는 경우에도 스토리지 경로를 변경하지 않고 이중 리전 및 멀티 리전 버킷을 계속 사용할 수 있습니다.

  • 이중 리전 및 멀티 리전 버킷에 저장된 객체는 일반적으로 기본 복제를 사용해서 여러 지리적 장소에 복제됩니다.

    • 객체가 업로드된 후 두 번째 위치에 복제되기 전에 객체가 저장된 위치 중 하나를 사용할 수 없게 되면 Cloud Storage의 strong consistency에 따라 객체의 이전 버전이 제공되지 않고 리전을 다시 사용할 수 있게 되었을 때 이후에 발생한 덮어쓰기 작업이 취소되지 않습니다.

    • 이중 리전에 저장된 객체는 선택적으로 터보 복제를 사용해서 더 빠르고 더 예측 가능한 리전 간 복제를 달성할 수 있습니다.

  • 이중 리전으로 사용할 수 없는 리전 쌍 간에 중복성을 달성하려면 각 리전에 별도의 버킷을 만들고 Storage Transfer Service 이벤트 기반 전송 또는 교차 버킷 복제를 사용하여 버킷을 동기화된 상태로 유지합니다.

리전 간 중복성

기존 스토리지 모델은 종종 '기본' 및 '보조' 지리적 위치에 활성-수동 방식을 사용하지만 Cloud Storage는 리전 간에 중복성이 있는 단일 버킷을 기반으로 활성-활성 아키텍처를 제공합니다. 이렇게 하면 기본 리전 다운타임이 발생할 경우 사용자가 한 버킷에서 다른 버킷으로 데이터를 복제하거나 수동으로 보조 버킷으로 장애 조치할 필요가 없으므로 재해 복구 프로세스가 간소화됩니다.

Cloud Storage는 항상 버킷의 현재 상태를 이해하고 필요에 따라 사용 가능한 리전에서 객체를 투명하게 제공합니다. 따라서 이중 리전 및 멀티 리전 버킷은 복구 시간 목표(RTO)가 0이 되도록 설계되었으며 일시적인 리전 장애는 일반적으로 사용자에게 표시되지 않습니다. 리전 서비스 중단이 발생한 경우 이중 리전 및 멀티 리전 버킷은 리전 간에 복제된 모든 데이터를 자동으로 계속 제공합니다.

그러나 리전 간 중복성은 비동기적으로 발생하며 리전이 사용 불가능 상태가 되기 전에 리전 간 복제가 완료되지 않은 데이터는 작동 중지된 리전이 다시 온라인으로 전환될 때까지 액세스할 수 없습니다. 가능성이 거의 없지만 리전이 물리적으로 파기될 경우 데이터가 손실될 수 있습니다.

Cloud Storage에서 기본 복제는 1시간의 목표 내에 새로 작성된 객체의 99.9%와 12시간 목표 내에 새로 작성된 객체의 100%에 대해 리전 간 중복성을 제공하도록 설계되었습니다. 새로 작성된 객체에는 업로드, 재작성, 복사, 조합이 포함됩니다.

터보 복제

터보 복제는 이중 리전 버킷의 데이터에 대한 리전 간 빠른 중복을 제공하여 데이터 손실 노출 위험을 줄이고 리전 서비스 중단 후 중단 없는 서비스 지원을 돕습니다. 터보 복제를 사용 설정하면 객체 크기와 관계없이 복구 지점 목표 15분 내에서 이중 리전을 구성하는 두 리전에 새로 작성된 객체를 100% 복제하도록 설계되었습니다.

참고로 기본 복제의 경우에도 대부분의 객체는 몇 분 안에 복제를 완료합니다.

리전간 중복 및 터보 복제는 비즈니스 연속성 및 재해 복구(BCDR) 작업을 지원하는 데 도움이 되지만 관리자는 워크로드에 적합한 완전한 BCDR 아키텍처를 계획하고 구현해야 합니다.

자세한 내용은 Google Cloud 애플리케이션의 재해 복구 설계에 대한 단계별 안내를 참조하세요.

제한사항

  • 터보 복제는 이중 리전의 버킷에만 사용할 수 있습니다.

  • 터보 복제가 사용 설정된 새 버킷 생성을 포함하여 XML API를 통해 Turbo 복제를 관리할 수 없습니다.

  • 버킷에서 터보 복제를 사용 설정하면 새로 작성된 객체에 적용되기 전에 최대 10초가 걸릴 수 있습니다.

  • 버킷에 터보 복제를 사용 설정하기 전에 시작된 객체 쓰기는 기본 복제 속도로 리전에서 복제됩니다.

    • 이전 12시간 동안 기본 복제를 사용해서 기록된 소스 객체를 사용하는 객체 구성은 기본 복제도 사용되는 복합 객체를 만듭니다.

버킷 간 복제

경우에 따라 두 번째 버킷에 데이터 사본을 유지하려고 할 수 있습니다. 버킷 간 복제는 소스 버킷에서 대상 버킷으로 신규 객체와 업데이트된 객체를 비동기식으로 복사합니다.

버킷 간 복제는 데이터가 스토리지 위치, 암호화, 액세스, 스토리지 클래스와 같은 자체 구성이 있는 두 개의 버킷에 존재한다는 점에서 기본 복제 및 터보 복제와 다릅니다. 따라서 데이터 복구 및 가용성을 제공할 뿐만 아니라 다음에도 적합합니다.

  • 데이터 주권: 지리적으로 먼 지역에서 데이터를 유지합니다.
  • 개발 및 프로덕션 버전을 별도로 유지: 개발이 프로덕션 워크로드에 영향을 미치지 않도록 별도의 버킷과 네임스페이스를 만듭니다.
  • 데이터 공유: 공급업체 또는 파트너가 소유한 버킷에 데이터를 복제합니다.
  • 데이터 집계: 여러 버킷의 데이터를 단일 버킷으로 결합하여 분석 워크로드를 실행합니다.
  • 비용, 보안, 규정 준수 관리: 다양한 소유권, 스토리지 클래스, 보관 기간에 따라 데이터를 유지합니다.

버킷 간 복제는 Storage Transfer Service를 사용하여 객체를 복제하고 Pub/Sub를 사용하여 소스 및 대상 버킷의 변경사항에 대한 알림을 수신합니다. 버킷 간 복제는 새로 만드는 새 버킷과 기존 버킷에서 사용 설정할 수 있습니다. 대부분의 객체는 몇 분 내에 복제할 수 있지만 1GiB를 초과하는 객체는 몇 시간이 걸릴 수 있습니다.

버킷 간 복제 사용에 관한 자세한 내용은 버킷 간 복제 사용을 참고하세요.

제한사항

  • 소스 버킷의 객체 삭제는 대상 버킷에 복제되지 않습니다.

  • 객체 수명 주기 구성은 복제되지 않습니다.

  • 객체가 복제되면 타임스탬프 메타데이터 (예: timeCreated 및 timeUpdated)는 보존되지 않습니다. 메타데이터 보존에 관한 자세한 내용은 Cloud Storage 버킷 간 전송을 참고하세요.

성능 모니터링

Cloud Storage는 복제되지 않은 가장 오래된 객체를 모니터링합니다. 객체가 RPO(복구 지점 목표) 시간보다 오랫동안 복제되지 않는 상태로 유지되면 RPO에서 벗어난 것으로 간주됩니다. 하나 이상의 객체가 RPO에서 벗어나는 각 시간(분 단위)은 '불량' 시간(분)으로 계산됩니다.

예를 들어, 한 객체에 오전 9시~9시 20분 동안 20분의 불량 시간(분)이 발생하였고, 다른 객체에 오전 9시 15분~9시 25분 동안 10분의 불량 시간(분)이 발생한 경우 해당 월에 2개의 객체가 RPO를 벗어난 것입니다. 해당 월의 총 잘못된 시간은 25분입니다. 오전 9시부터 오전 9시 25분까지 RPO가 누락된 객체가 하나 이상 있었기 때문입니다.

  • 터보 복제를 사용하는 버킷의 경우 객체의 RPO는 15분입니다.

  • 기본 복제를 사용하는 버킷의 경우 객체의 RPO는 12시간입니다.

    • 기본 복제를 사용하는 버킷의 경우 객체는 일반적으로 1시간 이내에 복제됩니다.

  • 버킷 간 복제는 RPO를 제공하지 않습니다.

Google Cloud 콘솔 내에서 RPO를 초과한 시간(분) 비율 그래프를 통해 버킷의 지난 30일 동안의 불량 시간(분) 비율을 모니터링할 수 있습니다. 이 서비스 수준 지표를 사용하여 버킷의 월간 복제 시간 적합성을 모니터링할 수 있습니다. 마찬가지로 목표에서 벗어난 객체의 비율은 RPO 내에서 발생하지 않은 객체 복제를 추적합니다. 이 서비스 수준 지표를 사용하여 버킷의 월간 복제 볼륨 적합성을 모니터링할 수 있습니다. 자세한 내용은 Cloud Storage 모니터링 및 Cloud Storage SLA를 참조하세요.

다음 단계