[Snowflake 101] Day 2: 비용의 핵심, Virtual Warehouse 사이징 전략

어제 살펴본 아키텍처에서 Snowflake의 핵심은 Storage와 Compute의 분리였다. 스토리지는 저렴하다(S3 비용과 거의 유사). 하지만 컴퓨팅은 비싸다. Snowflake 청구서의 90% 이상은 Virtual Warehouse(가상 웨어하우스) 구동 비용에서 나온다.

오늘은 쿼리를 실행하는 엔진인 Virtual Warehouse의 크기를 어떻게 산정(Sizing)해야 하는지, 그리고 비용 효율적으로 운영하기 위한 전략인 Scale Up과 Scale Out에 대해 다룬다.

1. T-Shirt Sizing 모델과 Credit

Snowflake는 서버의 사양을 CPU 코어 수나 RAM 용량으로 표기하지 않는다. 대신 옷 사이즈처럼 X-Small부터 6X-Large까지의 사이즈(T-Shirt Sizing)를 제공한다.

각 사이즈는 Credit(크레딧)이라는 단위로 과금된다. 사이즈가 한 단계 커질 때마다 성능과 소모 크레딧은 정확히 2배씩 늘어난다.

Size	Credits / Hour	비고
X-Small	1	기본 단위. 단일 클러스터
Small	2	XS의 2배 성능
Medium	4	XS의 4배 성능
Large	8	XS의 8배 성능
…	…	…
X-Large	16

• 과금 방식: 초(Second) 단위 과금이다. (단, 웨어하우스가 시작된 후 최초 60초는 최소 과금된다.)
• 성능 특성: 사이즈를 2배로 늘리면(XS -> S), 쿼리 처리 속도도 대략 2배 빨라진다(선형적 성능 향상). 단, 복잡한 연산이 필요한 쿼리일 경우에 한하며, 단순 조회는 큰 차이가 없다.

2. 느린 쿼리 해결: Scale Up vs Scale Out

“쿼리가 느리다”는 불만이 들어왔을 때, 무작정 사이즈를 올리면 돈 낭비다. 병목(Bottleneck)의 원인에 따라 대응 방식이 달라야 한다.

2.1. Scale Up (Resizing)

• 상황: 쿼리 하나 자체가 복잡하고 무거워서 오래 걸리는 경우.
• 해결: 웨어하우스의 사이즈를 키운다 (예: XS -> M).
• 명령어: ```sql ALTER WAREHOUSE my_wh SET WAREHOUSE_SIZE = ‘MEDIUM’;

* **효과:** 단일 쿼리의 수행 시간이 단축된다.

### 2.2. Scale Out (Multi-cluster Warehouses)

* **상황:** 쿼리 자체는 가벼운데, 동시에 많은 사용자가 몰려 **대기열(Queue)**이 발생하는 경우. (월요일 아침 9시 대시보드 새로고침 등)
* **해결:** 사이즈는 그대로 두고, 동일한 웨어하우스를 여러 개 띄운다 (클러스터 추가).
* **설정:** `Min_Cluster_Count`와 `Max_Cluster_Count`를 설정하면, 트래픽에 따라 자동으로 늘어났다 줄어든다(Auto-scaling).
* **효과:** 동시성(Concurrency) 처리 능력이 향상된다.

## 3. 비용 절감의 핵심: Auto-suspend

Snowflake를 처음 도입한 기업이 가장 많이 겪는 실수는 웨어하우스를 24시간 켜두는 것이다. Snowflake는 쿼리가 없으면 자동으로 꺼지는 **Auto-suspend(자동 일시 중단)** 기능을 제공한다.

```sql
CREATE OR REPLACE WAREHOUSE analytics_wh
  WITH WAREHOUSE_SIZE = 'X-SMALL'
  AUTO_SUSPEND = 300  -- 300초(5분) 동안 쿼리 없으면 중단
  AUTO_RESUME = TRUE; -- 쿼리 들어오면 자동 재시작

• 권장 설정: 개발(Dev) 환경이나 Ad-hoc 쿼리용은 60초~300초 정도로 짧게 설정한다.
• Auto-resume: 반드시 TRUE로 설정해야 한다. 그래야 사용자가 쿼리를 날렸을 때 자동으로 깨어나서 실행한다. (약간의 초기 구동 지연이 있을 수 있다.)

4. 워크로드 분리 (Workload Isolation)

모든 팀이 하나의 웨어하우스를 공유하면 ‘옆 팀 때문에 내 쿼리가 느려지는’ 상황이 발생한다. 아키텍처의 이점을 살려 용도별로 웨어하우스를 쪼개는 것이 좋다.

1. Loading Warehouse: 데이터 적재(Airflow, Fivetran 등) 전용. 보통 XS나 S면 충분하다.
2. Transform Warehouse: dbt 배치 작업용. 데이터 양에 따라 L 이상이 필요할 수도 있다.
3. BI Warehouse: 태블로(Tableau), 리대시(Redash) 등 시각화 도구 연결용. 동시 접속이 많으므로 Scale Out 설정을 해둔다.
4. Analyst Warehouse: 데이터 분석가들의 Ad-hoc 쿼리용.

이렇게 분리하면 비용 추적(Cost Attribution)도 명확해진다. “이번 달은 마케팅 팀 분석 쿼리 비용이 많이 나왔습니다”라고 근거를 댈 수 있다.

Summary

Virtual Warehouse는 Snowflake의 성능과 비용을 결정하는 레버(Lever)다.

• 쿼리가 복잡하면 사이즈를 키우고 (Scale Up), 사람이 많으면 클러스터 수를 늘린다 (Scale Out).
• 사용하지 않을 때는 반드시 꺼지도록 Auto-suspend를 설정한다.