[Snowflake 101] Day 4: 데이터 복제의 혁명, Zero-Copy Cloning

운영(Production) 환경의 데이터를 개발(Dev) 환경으로 가져오는 일은 데이터 엔지니어에게 늘 부담스러운 작업이다.

수 테라바이트(TB)에 달하는 운영 데이터를 덤프(Dump) 떠서 개발 DB에 적재하려면 수 시간이 걸린다. 더 큰 문제는 비용이다. 데이터를 복제하는 순간 스토리지 비용은 두 배가 된다. 그래서 보통은 데이터를 샘플링(Sampling)해서 개발 서버에 넣는데, 이 경우 운영 환경의 버그를 재현하기 어렵다.

Snowflake의 Zero-Copy Cloning(무복제 클로닝)은 이 딜레마를 해결한다. 10TB의 테이블을 복제하는 데 1초도 걸리지 않으며, 추가적인 스토리지 비용도 발생하지 않는다.

1. 메타데이터만 복사한다

원리는 간단하다. Snowflake가 데이터를 복제할 때, 실제 물리적인 데이터 파일(Micro-partitions)을 복사하지 않기 때문이다. 대신 원본 데이터를 가리키는 메타데이터(Metadata) 포인터만 복제한다.

• 속도: 데이터의 크기와 상관없이 메타데이터만 생성하므로 거의 즉시 완료된다.
• 비용: 물리적인 파일이 늘어나지 않았으므로, 클론 생성 직후의 추가 스토리지 비용은 ‘0원’이다.

CLONE 구문

문법은 매우 직관적이다. CLONE 키워드를 사용한다.

-- 운영 DB의 orders 테이블을 개발 스키마로 복제
CREATE TABLE dev.public.orders CLONE prod.public.orders;

-- 스키마 전체 복제도 가능하다
CREATE SCHEMA dev.testing CLONE prod.public;

-- 데이터베이스 전체 복제
CREATE DATABASE dev_db CLONE prod_db;

2. 변경이 발생했을 때 (Copy-on-Write)

“복제본(Clone)에서 데이터를 수정하면 원본(Source)도 바뀌나요?”

아니오. 클론은 완전히 독립적인 개체다. 클론 생성 시점에는 원본과 클론이 동일한 마이크로 파티션(저장소 블록)을 공유한다. 하지만 클론 테이블에서 UPDATE, DELETE, INSERT가 발생하는 순간, Snowflake는 변경된 데이터에 대해 새로운 마이크로 파티션을 생성하고 클론이 이를 가리키도록 한다.

즉, 변경된 부분에 대해서만 추가적인 스토리지를 사용한다. 원본 데이터는 아무런 영향을 받지 않는다.

3. 활용 패턴 (Use Cases)

이 기능은 단순한 백업 이상의 가치를 지닌다. 데이터 팀의 작업 방식(Workflow)을 바꿀 수 있다.

3.1. 개발/테스트 환경의 즉각적인 구성 (Instant Dev Environment)

신규 기능을 개발하기 위해 실제 운영 데이터가 필요할 때, 기다릴 필요 없이 운영 DB를 통째로 클론(Clone)하면 된다. 민감 정보가 있다면 클론 생성 후 마스킹(Masking) 처리를 하고 개발자에게 권한을 부여하면 된다.

3.2. 대규모 변경 전 스냅샷 (Snapshot before Deployment)

복잡한 마이그레이션 쿼리를 운영 환경에 배포하기 직전, 혹시 모를 사태에 대비해 클론을 따둔다. 문제가 생기면 클론을 원본으로 교체(Swap)하면 된다.

-- 배포 전 백업
CREATE TABLE orders_backup CLONE orders;

-- (문제 발생 시) 백업본으로 원상 복구
ALTER TABLE orders SWAP WITH orders_backup;

3.3. Ad-hoc 분석을 위한 샌드박스

데이터 분석가가 “이 데이터를 마음대로 주무르면서 실험해보고 싶다”고 할 때, 운영 테이블 권한을 주는 대신 개인 스키마에 클론을 만들어주면 된다. 분석가가 데이터를 지우건 덮어쓰건 운영 환경에는 영향이 없다.

Summary

Zero-Copy Cloning은 물리적 데이터 복사 없이 메타데이터 연산만으로 데이터를 복제하는 Snowflake의 핵심 기능이다. 이를 통해 스토리지 비용 증가 없이 운영 데이터를 개발/테스트 환경에서 자유롭게 활용할 수 있다.