Cloud Storage 소프트 삭제 소개

소프트 삭제는 선택한 보관 기간(기본 7일, 최대 90일까지 연장하거나 아예 중지할 수 있음) 동안 최근에 삭제된 객체를 보관하여 실수로 또는 악의적 삭제에 대한 버킷 수준 보호 기능을 제공합니다. 셀프서비스 복원 기능을 사용하면 삭제 후에 객체를 복구할 수 있습니다.

일반적으로 객체 삭제를 실행 취소할 수 없습니다. 그러나 소프트 삭제를 사용 설정하면 삭제된 객체가 소프트 삭제된 상태로 전환되므로 객체를 계속 복원할 수 있습니다. 삭제 API에 의해 객체가 삭제되었는지, 삽입/복사/다시 쓰기 API에 의해 객체를 덮어썼는지, UI를 통해 객체가 삭제되었는지 또는 객체 수명 주기 관리 정책에 의해 객체가 삭제되었는지 등 삭제 이유에 관계없이 복원할 수 있습니다.

소프트 삭제된 객체는 읽을 수 없는 특수 객체로, 특정 옵션이 지정되지 않는 한 객체 목록에 표시되지 않습니다. 소프트 삭제된 객체는 지정된 소프트 삭제 보관 기간 동안 보관된 후 영구 삭제되며 객체가 소프트 삭제된 상태로 전환되면 보관 기간을 재정의할 수 없습니다(소프트 삭제된 객체를 조기에 영구 삭제할 수 없음). 따라서 실수로 인한 삭제 및 악의적인 삭제 이벤트에 대한 강력한 보호 수준을 제공합니다.

소프트 삭제된 객체 하나 이상을 삭제된 객체에서 같은 버킷으로 다시 복원하여 실시간 객체로 다시 액세스할 수 있습니다. 특정 객체 목록을 제공하여 동기 복원을 수행하거나 두 타임스탬프 사이에 삭제된 모든 객체를 복원하는 장기 실행 비동기 작업을 실행할 수 있습니다. 새로 생성된 객체이므로 복원된 객체에는 새 생성 날짜가 포함됩니다. 자동 클래스를 사용하면 복원된 모든 객체 수명이 Standard 스토리지 클래스에서 다시 시작됩니다. 그렇지 않으면 복원된 객체는 삭제되었을 때와 동일한 스토리지 클래스에 생성됩니다.

잘못 삭제한 경우 복원을 감지하고 완료할 수 있도록 소프트 삭제 보관 기간을 충분히 길게 설정하는 것이 중요합니다. 대략적으로 시간당 객체 1,000만 개를 복원하는 속도 객체 10억 개를 복원하는 데 4일이 걸릴 수 있으므로 대규모 버킷의 경우 보관 기간을 7일 이상으로 늘리는 것이 좋습니다.

또한 소프트 삭제는 버킷 수준 삭제 이벤트로부터 보호합니다. 버킷 수준 삭제의 경우 먼저 Google에 삭제된 버킷을 다시 만드는 데 필요한 도움을 요청하세요. 그런 다음 복원 기능을 사용하여 해당 버킷의 객체를 복원할 수 있습니다.

2024년 3월 출시부터 2024년 8월 31일까지 소프트 삭제 프로모션 기간이며,데이터를 소프트 삭제한 후 첫 7일 동안 저장에 대한 추가 요금은 청구되지 않습니다. 2024년 9월 1일부터 객체가 삭제된 이후 소프트 삭제된 상태로 소비되는 모든 기간에 대한 기존 스토리지 SKU 사용량 요금이 기존 가격으로 청구됩니다. 소프트 삭제는 기본적으로 7일 동안 데이터를 보관하므로 요금이 청구되지 않도록 하려면 2024년 8월 25일 전에 소프트 삭제를 중지하세요.

복원을 수행하거나 버킷의 소프트 삭제 보관 기간을 늘리지 않는 한 2024년 9월 1일 이전에는 소프트 삭제로 인해 요금이 청구되지 않습니다. 이는 소프트 삭제 기능이 향후 청구에 미치는 영향을 평가하고 예산 및 비즈니스 니즈에 따라 버킷에서 사용할 수 있는 최적의 소프트 삭제 설정에 대해 정보에 입각한 결정을 내릴 수 있는 적절한 시간을 제공하기 위함입니다.

모든 소프트 삭제 사용량 요금은 기존 SKU에 청구되므로 기존 할인은 소프트 삭제 기능에서 발생하는 모든 요금에 계속 적용됩니다.

객체 버전 관리와 마찬가지로 2024년 9월 1일부터 기간 조건만 있는 삭제를 설명하는 객체 수명 주기 관리 청구 예외는 더 이상 소프트 삭제가 사용 설정된 버킷에 적용되지 않습니다.

소프트 삭제로 인한 요금 청구에 미치는 주된 영향은 소프트 삭제된 데이터와 관련된 사용량에 대한 월별 스토리지 요금이 추가로 청구된다는 점입니다. 객체가 소프트 삭제되면 소프트 삭제 보관 기간이 종료될 때까지 위치와 스토리지 클래스를 기준으로 기존 스토리지 SKU에 대해 사용 요금이 계속 청구됩니다. 예를 들어 us-east4의 Standard 스토리지 클래스 객체는 라이브 객체 상태에서는 us-east4 Standard 스토리지 클래스 SKU에 요금이 청구되며 소프트 삭제된 후에는 소프트 삭제 보관 기간이 종료될 때까지(기본적으로 7일) 동일한 SKU에 같은 요금이 계속 청구됩니다.

위에서 언급한 바와 같이 출시 시점부터 2024년 8월 31일까지의 프로모션 기간 동안에는 데이터가 소프트 삭제된 후 첫 7일 간 저장에 대한 추가 요금은 청구되지 않습니다.

소프트 삭제된 상태에서 객체가 소비한 시간은 스토리지 클래스와 자동 클래스 상태에 따라 적용 가능한 최소 스토리지 기간에 포함됩니다. 이로 인해 소프트 삭제가 사용 설정되면 최소 스토리지 기간을 충족하고 조기 삭제 요금 청구를 방지하기가 더 쉬워집니다. 예를 들어 Nearline 스토리지 클래스의 경우 자동 클래스를 사용하지 않는 버킷의 최소 스토리지 기간은 30일입니다. 소프트 삭제 없이 23일 후에 객체를 삭제하면 7일 동안의 조기 삭제 요금이 청구됩니다. 기본 7일 동안 소프트 삭제를 사용 설정하면 소프트 삭제 기간을 포함하여 객체에 30일 스토리지 요금이 청구되므로 조기 삭제 요금이 적용되지 않습니다.

복원을 수행할 때에는 GiB당 처리 요금이 청구되지 없습니다. 여기에는 Nearline, Coldline 또는 Archive 객체를 복원할 때 검색 수수료를 청구하지 않는 것도 포함됩니다.

복원과 관련된 작업에 대한 기본 요금은 버킷의 위치 유형과 관련된 A 클래스 작업입니다. 복원할 특정 객체 목록을 제공하는 동기 복원의 경우 복원된 객체마다 A 클래스 작업 하나가 측정됩니다. 사용률이 낮은 객체의 복원에 페널티를 주지 않기 위해 객체의 실제 스토리지 클래스와 관계없이 항상 표준 A 클래스 작업으로 요금이 청구됩니다. 먼저 복원할 객체를 결정해야 하는 비동기 복원의 경우 복원을 시작하기 전에 스캔한 객체 1,000개당 표준 A 클래스 작업 하나에 대한 요금이 청구됩니다.

복원 시 버킷에 새 만든 날짜가 포함된 새 라이브 객체가 생성되므로 복원 프로세스에서 생성된 새 객체에는 정상적으로 요금이 청구되며 모든 일반 가격 책정 및 스토리지 기간 요구사항이 새 객체에 적용됩니다. 복원된 객체의 소프트 삭제된 버전에 대한 요금이 계속 청구되지만 일반적으로 기본 소프트 삭제 보관 기간(7일)을 기준으로 겹치는 기간은 며칠에 불과합니다.

Google은 기본적으로 소프트 삭제를 사용하기로 결정했습니다. 소프트 삭제가 대부분의 고객에게 이점을 주고 대부분의 경우에 요금 청구에 큰 영향을 미치지 않는 매우 유용한 기능이라고 판단했기 때문입니다. 하지만 사용자는 Cloud Storage 버킷의 일부 또는 전체에 7일 소프트 삭제 보관 정책이 적합하지 않다고 판단할 수 있습니다. 2024년 8월 25일 이전에 이러한 보호 기능이 필요하지 않은 모든 버킷(예: 대량의 단기 임시 데이터가 포함된 버킷)에서 소프트 삭제를 중지해야 합니다. 반대로 비즈니스에 중요한 데이터를 더 안전하게 보호해야 하는 버킷의 경우 7일 보관 기간을 최대 90일까지 늘릴 수도 있습니다.

다음 정보 외에도 대규모 Cloud Storage 소프트 삭제 관리 블로그 게시물을 검토하여 버킷에 대한 소프트 삭제의 적합성을 평가하고 설정을 자동화하는 데 도움이 되는 권장사항과 샘플 스크립트를 확인할 수 있습니다. 이 게시물에는 Terraform 템플릿에서 소프트 삭제 설정을 수정하는 방법도 수록되어 있습니다.

Google은 개발자가 모든 버킷의 현재 바이트, 이전 바이트 및 소프트 삭제된 바이트의 양을 검사할 수 있도록 Cloud Monitoring 스토리지 측정항목을 개선하고 있습니다.

소프트 삭제가 이미 사용 설정된 버킷의 경우 소프트 삭제 기능이 요금 청구에 미치는 영향을 검사하는 가장 쉬운 방법은 storage/v2/total_bytes 측정항목을 검사하는 방법입니다. 이 측정항목은 마지막 사용 날짜가 종료될 때 스토리지 클래스와 객체 유형(라이브, 이전 버전, 소프트 삭제)별로 그룹화된 버킷에 있는 모든 객체의 총 크기를 제공합니다. 총계 대비 소프트 삭제된 바이트의 비율을 비교하면 월별 스토리지 요금에서 소프트 삭제가 미치는 요금 청구 영향을 상당히 정확하게 예측할 수 있습니다(이 측정항목에서 포착하도록 삭제가 비교적 일정한 속도로 수행되는 경우).

버킷당 삭제된 바이트의 델타 수를 스토리지 클래스별로 그룹화하여 제공하는 새로운 storage/v2/deleted_bytes 측정항목도 추가됩니다. 소프트 삭제가 중지된 경우에도 이 측정항목을 사용하여 삭제 속도와 total_bytes 측정항목을 비교하여 특정 버킷에서 소프트 삭제가 요금 청구에 미치는 영향을 예측할 수 있습니다.

예:

• 소프트 삭제가 요금 청구에 절대적으로 미치는 영향을 계산하려면 시간 경과에 따라 삭제된 바이트 수를 측정하는 storage/v2/deleted_bytes 측정항목을 사용하면 됩니다. 소프트 삭제의 절대 비용은 소프트 삭제 보관 기간 × 삭제된 바이트 × 월간 $/GiB 가격으로 계산됩니다. 예를 들어 Standard 스토리지의 us-central1에 위치한 버킷에 7일 소프트 삭제 정책을 정가로 사용 설정하고 한 해 동안 100,000GB를 삭제한 경우의 비용은 7 / 30.4375 × 100,000 × $0.02 = $459.96입니다. 여기서 30.4375는 월간 평균 일수입니다.
• 소프트 삭제의 상대적 비용을 계산하려면 storage/v2/deleted_bytes 측정항목을 storage/v2/total_byte_seconds 측정항목과 결합하면 됩니다(소프트 삭제 보관 기간 × 삭제된 바이트 수 / 총 바이트 수). 위 예시에서 계속하여 한 해 동안 월간 스토리지 1,000,000GB를 제공하는 경우 소프트 삭제를 사용 설정하는 상대적 비용은 7 / 30.4375 × 100,000 / 1,000,000 = 최대 2% 영향입니다.

객체 버전 관리를 사용하는 경우 새로운 측정항목의 일부로 라이브 및 이전 바이트와 객체 수를 공개합니다. 이는 소프트 삭제 기능을 선택 해제한 사용자에게도 유용할 수 있는 새로운 가시성입니다.

향상된 측정항목에 대한 자세한 내용은 새 측정항목이 출시되는 즉시 스토리지 측정항목 문서에서 확인할 수 있습니다.

버킷마다 개별적으로 소프트 삭제 보관 기간을 조정할 수 있습니다. 소프트 삭제를 중지하시려면 보관 기간을 0으로 변경하세요. Google은 모든 버킷에 대한 소프트 삭제 적합성을 평가하고 수백만 개에 달하는 버킷에서도 설정 업데이트를 자동화하는 데 도움이 되는 샘플 스크립트를 제공할 예정입니다. 새 버킷이 비즈니스 니즈에 맞는 설정에 따라 생성되도록 Terraform 또는 KCC 스크립트 및 기타 버킷 만들기 워크플로의 소프트 삭제 설정을 맞춤설정할 수도 있습니다. 

마지막으로 조직 정책 제약조건을 만들어 새로 생성된 버킷에 소프트 삭제의 특정 설정을 적용할 수 있습니다.