요약

  • Snowflake 영구 테이블은 Time Travel 보존 기간이 끝나면 변경할 수 없는 7일의 Fail-safe를 거친다. 이때도 이력 데이터의 저장 비용이 발생한다.
  • 보존 기간 단축, transient 테이블 선택, 클론 정리는 서로 다른 보관 원인에 작용한다. 삭제한 테이블에 연결된 청구 대상 바이트까지 살펴야 절감 효과를 알 수 있다.

데이터팀이 삭제 작업을 끝내도 저장소의 계산서는 아직 퇴근하지 않을 수 있다. Snowflake 영구 테이블은 Time Travel을 거친 뒤 7일간 Fail-safe에 들어간다. 일상적인 작업에서 사라진 데이터가 복구 가능성을 위해 남고, 그 공간에는 계속 비용이 붙는다.

클라우드 구매 담당자가 따져야 할 대상은 이 보관의 꼬리다. 테이블을 얼마나 많이 없앴는지와 청구 대상 용량이 얼마나 줄었는지는 서로 다른 결과가 될 수 있다. 복구할 기회를 남기는 설계가 삭제 이후의 비용도 만든다.

저장 비용 안내는 활성 데이터와 Time Travel·Fail-safe의 이력을 청구 범위에 넣는다. 클론이 참조해 남겨 둔 데이터에도 저장 비용이 붙으며, Snowflake는 테이블을 압축한 뒤 그 크기로 저장량을 계산한다.

고객의 조회가 끝난 뒤 공급자가 맡는 7일

Fail-safe 설명에 따르면 7일이라는 기간은 설정으로 바꿀 수 없고 Time Travel이 끝난 다음 시작된다. 이 단계에서는 고객이 통상적인 방식으로 과거 데이터를 조회할 수 없다. 복구 요청은 Snowflake 지원팀을 거쳐야 한다.

Fail-safe는 다른 복구 수단을 시도한 뒤 심각한 운영 장애 등에 대응하는 최선 노력 방식의 서비스다. Snowflake는 복구에 수시간에서 수일이 걸릴 수 있다고 안내하며, 작업에 쓰는 서버리스 컴퓨팅에도 요금을 매긴다. 고객은 복구할 데이터를 보관하는 비용과 실제로 복구를 요청했을 때의 처리 비용을 각각 부담한다.

다시 만들기 어려운 데이터에는 이 추가 기회가 값질 수 있다. 다만 기회를 유지하려면 사고가 나기 전부터 데이터를 남겨야 한다. 정상 운영 중에도 복구 가능성을 위해 유료 공간을 사용하는 이유다.

이력 저장 비용 문서는 기본 선택지를 다음과 같이 제시한다.

테이블 유형 Time Travel 이후 Fail-safe
Standard Edition 영구 테이블 0일 또는 1일 7일
Enterprise Edition 이상 영구 테이블 0~90일 7일
transient 0일 또는 1일 없음
temporary 0일 또는 1일, 삭제나 세션 종료까지 없음

영구 테이블의 Time Travel을 0일로 정해도 다음 7일은 남는다. Time Travel 쿼리가 오래 실행되면 Snowflake는 그 쿼리가 끝날 때까지 Fail-safe 전환을 미룬다. 전환 작업은 백그라운드에서 진행된다. 따라서 비용을 예상할 때는 설정된 기간뿐 아니라 실행 중인 쿼리와 전환 처리 상황도 살펴야 한다.

보존 기간을 줄이면 오래된 데이터가 먼저 이동한다

Time Travel 문서는 기간을 10일에서 1일로 줄이는 사례를 든다. 최근 하루의 이력은 Time Travel에 남고, 2~10일 전 이력은 Fail-safe로 이동한다. 고객이 직접 과거를 사용할 수 있는 창은 짧아지고, 오래된 데이터는 다음 보호 단계로 넘어간다.

이미 삭제한 테이블에는 정책 변경 순서가 중요하다. 공식 사례에서 테이블은 상위 스키마의 90일을 물려받은 뒤 삭제된다. 나중에 스키마를 1일로 바꿔도 그 테이블의 90일은 유지된다. 해당 객체 자체의 보존 기간을 바꾸려면 먼저 복원하고 나서 설정을 변경해야 한다.

새로운 상위 정책은 활성 객체에 적용된다. 이전에 삭제한 객체는 앞서 정해진 조건으로 계속 보관된다. 계정 관리자가 설정한 최소 기간이 개별 객체의 값보다 긴 실효 보존 기간을 만들 수도 있다. 0이라는 숫자는 적용되는 상위 규칙과 함께 읽어야 한다.

클론의 수명은 원본과 따로 간다

저장 구조 설명에 따르면 제로카피 클론은 생성 시점의 마이크로파티션을 공유한다. 이후 변경은 각 객체가 소유하는 새로운 파티션을 만들고, 각 객체는 독립된 수명주기를 갖는다. 개발용 사본이 원래 테이블에서 필요 없어진 데이터를 계속 참조할 수 있는 구조다.

TABLE_STORAGE_METRICS는 활성 바이트, Time Travel 바이트, Fail-safe 바이트, 클론을 위해 남긴 바이트를 구분한다. 마지막 항목에는 테이블 데이터를 보관하는 WORM 백업도 포함되므로, 이 값을 설명하려면 클론과 WORM 백업을 함께 확인해야 한다.

저장 비용이 발생하는 동안 삭제한 테이블도 이 뷰에 나타난다. 같은 이름으로 다시 만들면 각자의 이력을 가진 여러 버전이 남을 수 있다. 사용자가 아는 테이블 이름과 실제 객체 식별자를 연결해야 어느 버전의 바이트에 비용이 붙는지 설명할 수 있다.

Account Usage 반영은 최대 90분 늦을 수 있다. 오래된 행이 남더라도 네 가지 주요 바이트 수치가 모두 0이면 저장 비용은 발생하지 않는다. 특정 계정의 잔여 비용을 계산하려면 압축된 보관 바이트, 실효 보존 정책, 적용 단가가 필요하다.

하루의 이력과 테이블의 수명은 다르다

transient 테이블에는 Fail-safe가 없고 Time Travel은 최대 하루다. 이 하루는 추가 이력 보호의 한도다. 활성 데이터는 테이블이 존재하는 동안 계속 청구되므로 몇 주간 남긴 transient 테이블은 몇 주간 활성 저장소를 차지한다.

원본에서 다시 만드는 작업 데이터라면 짧은 이력 보관과 재실행 비용을 비교해 transient 사용 여부를 정할 수 있다. 이력이 만료되면 Snowflake의 Fail-safe 복구 경로가 사라지고, 고객이 다시 만드는 시간과 컴퓨팅 자원, 작업 중단을 부담한다. 재구축하기 어려운 중요 데이터는 저장 단가와 함께 복구 가능성의 가치를 평가해야 한다.

temporary 테이블은 삭제되거나 세션이 끝날 때 이력 보관도 종료된다. 연결을 끊는 것만으로는 세션이 종료되지 않으므로, 정리 담당자는 테이블을 삭제하거나 해당 세션이 실제로 끝났는지 확인해야 한다.

데이터팀은 삭제 계획에 유효 보존 기간과 남길 클론·백업을 함께 정하고, 재무팀은 해당 객체의 저장 바이트가 실제로 줄어드는 시점을 비용 계획에 반영해야 한다.