Snowflake 아키텍처 (스토리지, 컴퓨트, 클라우드 서비스 세 계층)

세 계층 한눈에 보기

Snowflake 는 "공유 디스크" 와 "공유 없음(shared nothing)" 구조를 섞은 형태입니다. 데이터는 한 벌만 클라우드 오브젝트 스토리지에 두고, 쿼리는 서로 독립된 컴퓨트 묶음(가상 웨어하우스)이 각자 읽습니다. 그 위에서 인증, 메타데이터, 최적화를 맡는 클라우드 서비스 계층이 항상 돌고 있습니다.

이 분리 덕분에 다음 세 가지가 가능합니다.

• 워크로드 격리: ETL 과 BI 가 같은 테이블을 읽어도 웨어하우스가 다르면 서로 CPU 와 메모리를 뺏지 않습니다.
• 즉시 확장: 웨어하우스 크기를 바꾸면 다음 쿼리부터 새 크기로 돌고, 데이터 이동은 없습니다.
• 쓰는 만큼 과금: 웨어하우스는 꺼 두면 크레딧이 들지 않습니다. 저장 요금은 따로 계속 나옵니다.

스토리지 계층

• 테이블 데이터는 마이크로 파티션이라는 불변 파일로 저장됩니다. 압축 전 50~500 MB 정도의 행 묶음이 열 단위로 압축되어 들어가고, Snowflake 가 파티션마다 열별 최솟값, 최댓값, 고유값 수 같은 메타데이터를 따로 들고 있습니다. 자세한 동작은 마이크로 파티션과 클러스터링 에 있습니다.
• 파일은 바꾸지 않고 새로 씁니다. UPDATE 나 DELETE 는 영향받은 파티션을 새로 만들고 옛 파티션을 Time Travel 보관으로 넘깁니다. 그래서 변경이 잦은 테이블은 실제 저장량이 보이는 테이블 크기보다 커질 수 있습니다.
• 저장 요금은 활성 데이터, Time Travel 데이터, Fail-safe 데이터, 스테이지 파일을 모두 더한 월평균 TB 기준입니다.

컴퓨트 계층 (가상 웨어하우스)

웨어하우스는 크기(XS 부터 6XL)와 종류(표준, Snowpark-optimized, Adaptive, Interactive)를 고르는 컴퓨트 묶음입니다. 크기가 한 단계 올라가면 시간당 크레딧이 두 배가 됩니다. 2026-10 기준 새 표준 웨어하우스는 기본으로 Gen2 로 만들어지고, Gen2 는 같은 크기에서 크레딧을 더 쓰지만 대부분의 쿼리가 더 빨리 끝납니다. 크기 고르는 법과 크레딧 표는 웨어하우스와 크레딧 에 정리했습니다.

CREATE WAREHOUSE IF NOT EXISTS etl_wh
  WAREHOUSE_SIZE = 'LARGE'
  AUTO_SUSPEND = 60          -- 기본값은 600초
  AUTO_RESUME = TRUE
  INITIALLY_SUSPENDED = TRUE;

클라우드 서비스 계층

• 로그인과 세션, 역할 확인, 메타데이터 관리, 쿼리 컴파일과 프루닝, 트랜잭션, 결과 캐시를 맡습니다.
• SELECT COUNT(*) 나 MIN, MAX 처럼 메타데이터만으로 답할 수 있는 쿼리는 웨어하우스 없이도 끝납니다.
• 과금 규칙: 하루 단위로 클라우드 서비스 크레딧이 같은 날 웨어하우스 크레딧의 10% 이하면 청구되지 않습니다. 서버리스 기능이 쓰는 클라우드 서비스는 이 계산에 들어가지 않습니다.

주의 아주 작은 쿼리를 초당 수천 번 날리거나, 거대한 SHOW 와 INFORMATION_SCHEMA 조회를 반복하면 클라우드 서비스 비율이 10% 를 넘어 청구서에 따로 찍힙니다. METERING_DAILY_HISTORY 의 CREDITS_ADJUSTMENT_CLOUD_SERVICES 열로 확인합니다.

에디션

크레딧 단가는 에디션마다 다릅니다. 2026-10-15 시행 Service Consumption Table 의 On Demand 기준으로 AWS 미국 동부는 Standard $2.00, Enterprise $3.00, Business Critical $4.00, AWS 서울은 각각 $2.75, $4.05, $5.50 입니다. 2026년 5월부터는 ALTER ACCOUNT 로 에디션을 바꾸는 기능이 GA 입니다.

조직, 계정, 객체 계층

조직(Organization)
  계정(Account)  예: myorg-prod, 클라우드와 리전이 계정마다 하나
    웨어하우스, 사용자, 역할, 통합(Integration), 네트워크 정책   (계정 수준 객체)
    데이터베이스
      스키마
        테이블, 뷰, 스테이지, 파이프, 스트림, 태스크, 함수, 프로시저 ...

• 계정은 특정 클라우드와 리전에 고정됩니다. 다른 리전에 데이터를 두려면 계정을 하나 더 만들고 복제나 공유를 씁니다.
• 계정 식별자는 <조직 이름>-<계정 이름> 형식을 권장합니다. 예전 로케이터(xy12345.ap-northeast-2.aws)도 여전히 동작합니다.
• 객체 이름은 데이터베이스.스키마.객체 로 완전히 지정하는 습관이 사고를 줄입니다. 세션의 현재 데이터베이스와 스키마에 기대면 배포 환경마다 다른 객체를 건드릴 수 있습니다.

테이블 종류 요약

Interactive Table 과 Interactive Warehouse 는 2025-12-11 에 GA 가 되었습니다. Iceberg 는 Iceberg 와 카탈로그, 보존 기간은 Time Travel 과 Fail-safe 에서 다룹니다.

설계할 때 기억할 것

1. 웨어하우스는 워크로드별로 나눕니다. 적재, 변환, BI, 데이터 과학을 한 웨어하우스에 몰면 큐잉과 비용 추적이 모두 어려워집니다.
2. 데이터는 하나, 환경은 클론으로 만듭니다. 개발 데이터베이스는 운영의 제로 카피 클론으로 만들면 저장 비용이 거의 늘지 않습니다.
3. 계정은 리전과 규제 경계로 나눕니다. 같은 리전 안에서 팀을 나누는 데는 데이터베이스와 역할이면 충분합니다.
4. 클라우드 서비스 비용이 튀면 대개 작은 쿼리 폭주나 메타데이터 조회 반복입니다. 비용 모니터링 의 쿼리로 찾습니다.

공식 문서

• Key concepts and architecture
• Overview of warehouses
• Snowflake editions
• Snowflake Service Consumption Table (PDF)