저장소 수명 주기 정책¶
참고
:doc:`저장소 수명 주기 정책</user-guide/storage-management/storage-lifecycle-policies>`은 현재 정부 리전에서 사용할 수 없습니다.
저장소 수명 주기 정책은 표준 Snowflake 테이블의 데이터 수명 주기를 자동으로 관리하는 스키마 수준 오브젝트입니다. 이러한 정책을 사용하여 데이터 보존 기간 또는 기타 기준과 같이 정의한 조건에 따라 특정 테이블 행을 보관하거나 만료할 수 있습니다. Snowflake는 공유 컴퓨팅 리소스를 사용하여 이러한 정책을 매일 자동으로 실행합니다.
저장소 수명 주기 정책의 작동 방식¶
저장소 수명 주기 정책을 시작하려면 다음 단계를 따릅니다.
보관하거나 만료할 행을 식별하는 식을 사용하여 :ref:`정책을 생성<label-slp_create>`합니다.
:ref:`하나 이상의 테이블에 정책을 연결<label-slp_attach_to_table>`합니다.
저장소 수명 주기 정책을 테이블에 연결한 다음 Snowflake는 약 24시간을 기다린 후 정책을 처음 실행합니다. 이러한 초기 지연 이후, Snowflake는 공유 컴퓨팅 리소스를 통해 정책을 매일 자동으로 실행하여 정의된 조건을 충족하는 행을 식별하고 처리합니다.
정책이 실행되면 식과 비교하여 각 행을 확인하고 데이터를 COOL 또는 COLD 저장소 명령을 사용하여 보관된 데이터를 검색할 수 있습니다. Snowflake는 지정된 보관 기간이 경과할 때까지 기다린 후 아카이브 저장소에서 데이터를 만료합니다.
주요 기능¶
저장소 수명 주기 정책은 Snowflake 데이터 관리에 다음과 같은 이점을 제공합니다.
- 저장소 비용 절감
저장소 수명 주기 정책은 오래된 데이터를 보다 비용 효율적인 :ref:`아카이브 계층<label-slp_archive_tiers>`으로 자동 이동하여 비용을 최적화하는 데 도움이 됩니다. 장기간 보존해야 하지만 자주 액세스하지 않는 데이터의 경우, 아카이브 저장소를 사용하면 표준 저장소 계층에 비해 저장소 비용을 크게 줄일 수 있습니다.
- 규정 준수
규정 표준에 따라 데이터를 보관하거나 만료하는 정책을 구성하여 규정 준수 요구 사항을 자동으로 충족합니다. 만료 전 특정 시간 동안 데이터를 보관하거나 보관하지 않고 직접 만료할 수 있습니다. 이를 통해 데이터 관리가 조직의 거버넌스 표준을 준수할 수 있습니다.
- 간단한 데이터 관리
저장소 수명 주기 정책을 사용하면 보관 및 만료 규칙을 자동으로 실행하여 수동 데이터 관리 작업을 수행할 필요가 없습니다. 자세한 내용은 저장소 수명 주기 정책 모니터링 섹션을 참조하십시오.
- 유연한 데이터 검색
필요한 행만 포함하는 새 테이블을 생성하여 :doc:`보관된 데이터 검색 </user-guide/storage-management/storage-lifecycle-policies-retrieving-archived-data>`을 정확하게 수행합니다. WHERE 절이 있는 간단한 명령을 사용하여 복원할 보관된 데이터를 정확하게 지정합니다.
아카이브 저장소 계층¶
Snowflake는 다음 저장소 계층에서 데이터 보관을 지원합니다.
아카이브 계층 |
설명 |
|---|---|
COOL |
빠른 검색 시간을 제공하므로 데이터를 쉽게 사용할 수 있습니다. 최소 보관 기간은 90일입니다. |
COLD |
COOL 계층보다 큰 비용 절감 효과를 제공합니다(4배 더 저렴). 최소 보관 기간은 180일입니다. COOL 계층에 비해 COLD의 데이터 검색 시간이 더 깁니다(최대 48시간). COLD 저장소 계층에서의 데이터 검색 작업은 복원 작업당 최대 100만 개의 파일을 지원합니다. |
아카이브 계층 선택하기¶
아카이브 계층을 선택할 때 다음 사항을 고려하세요.
보관 비용: 데이터를 보관하는 일회성 비용은 두 계층에서 동일합니다.
저장소 비용: COLD 계층 저장소가 COOL 계층 저장소보다 더 저렴합니다.
검색 비용: COLD 계층 데이터 검색이 COOL 계층 검색보다 더 저렴합니다.
검색 시간: COOL 저장소 계층은 즉각적인 데이터 검색을 제공하는 반면, COLD 계층 검색에는 최대 48시간이 걸릴 수 있습니다.
자세한 가격 정보는 `Snowflake Service Consumption Table`_의 테이블 3(e) 및 4(f)를 참조하세요.
데이터 보관에 대한 자세한 내용은 저장소 수명 주기 정책 생성 및 아카이브 저장소 고려 사항 섹션을 참조하세요.
고려 사항¶
저장소 수명 주기 정책으로 작업할 때 다음 사항을 고려하세요.
클라우드 공급자 지원¶
만료 정책: 모든 클라우드 공급자(AWS, Azure, Google Cloud)에서 호스팅되는 계정에 대해 지원됩니다.
아카이브 정책: 현재 AWS에서 호스팅되는 계정에만 사용 가능합니다.
지원되는 테이블 및 기능¶
지원되는 테이블: 저장소 수명 주기 정책은 표준 Snowflake 테이블에 대해 지원됩니다. 저장소 수명 주기 정책 식을 평가하고 적용하기 위해 Snowflake는 테이블에 대한 모든 거버넌스 정책을 내부적으로 일시적으로 우회합니다.
복제
Snowflake는 저장소 수명 주기 정책 및 테이블과의 연결을 대상 계정에 복제하지만 정책을 실행하지는 않습니다.
대상 계정으로 장애 조치한 후 Snowflake는 원래 기본 계정에서 저장소 수명 주기 정책 실행을 일시 중지합니다. 원래 기본 계정으로 장애 복구한 후 Snowflake는 정책 실행을 재개합니다.
Snowflake는 장애 조치 후에도 보조 테이블에서 보조 저장소 수명 주기 정책을 자동으로 실행하지 않습니다. 그러나 새 테이블에 보조 정책을 연결하여 대상 계정에서 보조 정책을 사용할 수 있습니다. 이러한 새 테이블에 대해 Snowflake는 정책을 실행합니다.
복제: Snowflake는 복제된 테이블에 저장소 수명 주기 정책을 자동으로 적용하지 않습니다. 복제본 그룹의 테이블에 저장소 수명 주기 정책을 적용하는 경우 Snowflake는 해당 특정 테이블의 행만 보관합니다. 이 정책은 복제본에 영향을 주지 않습니다. 이를 통해 표준 및 아카이브 저장소 계층 모두에 데이터 복사본이 생성되며 각 계층의 저장소 비용을 지불합니다. 비용 정보는 저장소 수명 주기 정책에 대한 요금 청구 섹션을 참조하세요.
지원되지 않는 기능
저장소 수명 주기 정책은 다음에 대해 지원되지 않습니다.
일반 Snowflake 테이블 및 동적 테이블을 제외한 모든 오브젝트 유형.
한 번 쓰고 여러 번 읽기(WORM) 스냅샷(생성 후에는 수정할 수 없는 변경 불가능한 스냅샷).
Snowflake 데이터 공유를 통해 공유되는 테이블(공급자 및 컨슈머 테이블 모두).
기본 앱.
사용자 정의 함수(UDFs) 및 외부 액세스와 외부 함수.
Python, Java 또는 Scala UDFs.
정책 동작 및 실행¶
저장소 수명 주기 정책은 :ref:`행 수준 액세스 정책에 대한 지침<label-security_row_performance>`과 유사한 성능 지침을 사용하며 다음과 같은 특성으로 자동 작동합니다.
테이블에 저장소 수명 주기 정책을 연결하는 경우 Snowflake는 약 24시간을 기다린 후 처음으로 실행합니다.
Snowflake는 공유 컴퓨팅 리소스를 사용하여 저장소 수명 주기 정책을 매일 실행합니다. 저장소 수명 주기 정책 비용에 대한 자세한 내용은 저장소 수명 주기 정책에 대한 요금 청구 섹션을 참조하세요.
매우 장기간의 보관 또는 만료 실행을 방지하기 위해 Snowflake는 대규모 데이터 작업을 더 작은 청크로 증분 방식으로 처리합니다. 대규모 작업은 일일 1회의 실행으로 완료되지 않으며 대신 여러 일일 실행에 걸쳐 완료될 수 있습니다.
저장소 수명 주기 정책이 테이블에서 실행 중인 경우 Snowflake는 UPDATE, DELETE, MERGE 작업을 잠급니다. 이때 INSERT 및 COPY 작업은 계속 수행할 수 있습니다. 자세한 내용은 리소스 잠금 섹션을 참조하세요.
아카이브 저장소 정책¶
아카이브 저장소 수명 주기 정책이 연결된 테이블로 작업하는 경우:
보관된 데이터에 액세스하기: Snowflake가 행을 보관한 후에는 직접 쿼리할 수 없습니다. 액세스하려면 CREATE TABLE … FROM ARCHIVE OF 명령을 사용하여 보관된 데이터의 복사본으로 새 테이블을 생성합니다. 자세한 내용은 보관된 데이터 검색하기 섹션을 참조하세요.
보안: |tri-secret-secure|(TSS)를 사용하여 정기적인 키 순환으로 보관된 데이터를 보호합니다.
키 재생성: Snowflake는 보관된 데이터의 키를 재생성하지 않습니다. 키 손상이 의심되는 경우 다음 해결 방법을 사용하세요.
CREATE TABLE … FROM ARCHIVE OF 명령을 사용하여 보관된 데이터를 새 테이블로 검색합니다.
필요한 경우 새 테이블에 데이터를 보관합니다. 각 테이블에는 자체 암호화 키가 있으므로 새 테이블은 새 키를 효과적으로 사용합니다.
키가 손상된 원본 테이블의 아카이브를 삭제합니다.
아카이브 계층 제한 사항:
정책의 아카이브 계층<label-slp_archive_tiers>`은 COOL에서 COLD로(또는 그 반대로) 변경할 수 없습니다. 대신 새 정책을 만듭니다(:ref:`label-slp_recreate 참조).
테이블은 하나의 아카이브 계층만 사용할 수 있습니다. COOL 아카이브를 이미 사용하는 테이블에 COLD 정책을 연결할 수 없습니다.
정책 제거: 테이블에서 정책을 제거하면 보관된 데이터는 아카이브 저장소에 남아 있으며 계속 검색할 수 있습니다.
테이블 삭제 또는 자르기:
테이블을 잘라도 해당 테이블의 보관된 데이터에는 영향을 주지 않습니다. 테이블을 자른 후에도 아카이브 저장소에서 데이터를 계속 검색할 수 있습니다.
:doc:`/sql-reference/sql/undrop-table`을 사용하여 해당 :ref:`Time Travel 데이터 보존 기간<label-time_travel_data_retention_period>`에 테이블을 복원하는 경우 Snowflake는 아카이브 저장소의 모든 데이터도 복원합니다.
테이블이 Fail-safe 기간 내에 있는 경우 Snowflake 지원을 통해 Fail-safe 데이터 복구 단계를 사용하여 아카이브 저장소의 데이터를 복구할 수 있습니다.
ARCHIVE_FOR_DAYS 기간이 경과하기 전에 삭제한 아카이브 저장소의 테이블 데이터에는 저장 비용이 부과됩니다. 자세한 내용은 최소 저장 기간 요금 섹션을 참조하십시오.