요약

  • 소프트 삭제를 지원하는 Google Cloud Storage 버킷의 기본 보존 기간은 7일이다. 삭제한 객체도 이 기간에는 저장 비용이 계속 발생한다.
  • 정책을 나중에 꺼도 이미 소프트 삭제한 객체는 원래 기간을 채운다. 지속적인 삭제량이 하루 1 TiB라면, 7일 보존은 정상 상태에서 약 7 TiB의 삭제 재고를 만든다.

비용 절감 버튼에 붙은 대기실

저장 비용이 늘자 팀이 소프트 삭제를 껐다고 하자. 앞으로 버리는 데이터는 새 정책이 적용되지만, 어제 버린 데이터의 청구 시계는 그대로 간다. Google Cloud Storage의 복구 창은 지난 결정을 소급해서 지워 주지 않는다.

공식 문서는 이를 명확히 설명한다. 소프트 삭제 상태의 객체는 보존 기간이 끝날 때까지 저장 비용을 낸다. 정책 변경은 새 정책이 발효된 뒤 삭제하는 자원에 적용된다. 이미 삭제된 자원은 삭제 당시의 기간을 유지한다. 0일째에 7일 정책으로 지운 객체는 1일째 정책을 꺼도 원래 7일의 일정을 따른다.

삭제를 비용의 종점으로 생각했다면 장부가 어긋난다. 여기서는 삭제가 복구 대기실의 입장권이다.

살아 있는 데이터가 그대로인데 재고가 늘어난다

이 기능을 지원하는 버킷에는 기본 7일 정책이 붙는다. 보존 기간은 7~90일로 정할 수 있고, 비활성화도 가능하다. 기본값을 따로 바꿀 수도 있으므로 실제 버킷 정책을 확인해야 한다.

경제적 효과는 삭제 속도에서 나온다. 조건을 단순하게 고정해 보자. 같은 위치의 Standard 저장 클래스를 쓰고, 객체 버전 관리는 꺼져 있다. 활성 데이터는 늘 1 TiB다. 하루 1 TiB를 일정한 속도로 삭제하고, 이 흐름이 7일 이상 이어진다. 추가 복구 사본은 없다.

정상 상태에서 소프트 삭제 데이터는 대략 하루 1 TiB에 7일을 곱한 7 TiB다. 활성 1 TiB를 더하면 저장 요금이 쌓이는 내용 데이터는 약 8 TiB가 된다. 활성 공간은 성장하지 않았는데 삭제 대기 재고가 일곱 배의 공간을 더 차지한다.

이는 조건을 둔 저장량 계산이다. 전체 클라우드 청구액이 여덟 배라는 관측 결과가 아니다. 실제 금액에는 해당 버킷의 삭제량, 객체 저장 클래스, 위치와 계약 단가가 필요하다. 요청·네트워크 비용과 할인도 이 단순 저장량 계산 밖에 있다.

임시 데이터가 장기 손님이 되는 순간

Google은 단명하는 임시 객체에 소프트 삭제를 켜면 저장 비용이 크게 늘 수 있다고 직접 설명한다. 쿼리 결과, 스테이징 파일, 삭제 빈도가 높은 작업이 예다. 잠깐 쓰려고 만든 데이터가 복구 창에서는 일주일 숙박객이 된다.

가격 문서는 활성 객체, 비현재 버전, 소프트 삭제 객체에 저장 요금이 같은 방식으로 적용된다고 명시한다. 요금은 객체의 저장 클래스와 위치에 따라 달라진다. 따라서 활성 객체 목록만 보고 비용을 추정하면, 청구 대상의 상당 부분을 놓칠 수 있다.

수명주기 규칙으로 지운 객체도 소프트 삭제 상태로 들어갈 수 있다. 이미 그 상태가 된 객체를 수명주기 규칙으로 일찍 영구 삭제하거나 다른 저장 클래스로 옮길 수는 없다. 버전 관리까지 사용하면 삭제 경로가 더 달라지므로 위 계산에서는 이를 껐다고 가정했다.

“매일 정리한다”는 설명은 충분하지 않다. 무엇을 어느 상태로 이동시키는 정리인지가 비용을 결정한다.

복구할 가치도 데이터마다 다르다

실수나 악의적인 삭제 뒤 복원할 수 있는 시간은 유용한 상품이다. 다시 만들 수 없는 원본과 재실행하면 나오는 중간 결과가 그 시간을 똑같이 필요로 하지는 않는다.

의사결정은 작업 시작 전에 이뤄져야 한다. 어떤 데이터가 손실되면 사업이 멈추는지, 재생성에 얼마나 걸리는지, 어느 복구 창을 사는지 정해야 한다. 나중에 정책을 끄면 새로운 유입은 바꿀 수 있어도 기존 대기실을 즉시 비울 수 없다.

삭제 자동화는 실행을 빠르게 한다. 비용을 낮추는지는 그 뒤에 남는 재고가 결정한다. 임시 파일에도 숙박비를 내기로 했다면, 적어도 누가 예약했는지는 알고 있어야 한다.

출처