Snowflake

가상 웨어하우스 정의와 탄력성

가상 웨어하우스(Virtual Warehouse)는 SQL 쿼리와 DML 작업을 실행하는 컴퓨트 자원(CPU, 메모리, SSD)의 클러스터를 추상화한 것이다. 사용자는 X-Small부터 시작해 필요에 따라 웨어하우스를 재사이징(Scale Up)하거나, 더 많은 동시 사용자를 처리하기 위해 클러스터 수를 늘릴(Scale Out) 수 있다.

하나의 쿼리는 정확히 하나의 가상 웨어하우스에서 실행되며, 서로 다른 웨어하우스는 컴퓨트 자원을 전혀 공유하지 않는다. 이 덕분에 무거운 배치 변환 작업을 처리하는 웨어하우스와 대시보드 조회를 처리하는 웨어하우스를 분리해두면, 한쪽의 부하가 다른 쪽 성능에 영향을 주지 않는다.

결정적으로, 웨어하우스는 유휴 상태가 되면 자동으로 정지(Auto-Suspend)되도록 설정할 수 있고, 새 쿼리가 들어오면 자동으로 재개(Auto-Resume)된다. 과금은 실제로 웨어하우스가 가동된 정확한 초 단위로만 이루어지므로, 쓰지 않는 동안에는 비용이 발생하지 않는다.

Scale Up vs Scale Out

Scale Up은 웨어하우스의 크기 자체를 키우는 것이다(예: Small → Medium). 크기를 한 단계 올릴 때마다 컴퓨트 자원이 대략 두 배가 되며, 이는 '하나의 복잡한 쿼리'를 더 빠르게 만드는 데 적합하다.

Scale Out은 멀티클러스터 웨어하우스에 클러스터를 추가하는 것이다. 각 클러스터의 크기는 그대로 유지되지만, 클러스터 수가 늘어나 더 많은 동시 쿼리를 병렬로 처리할 수 있게 된다. 즉 Scale Out은 '한 쿼리를 더 빠르게'가 아니라 '더 많은 사용자의 쿼리를 동시에' 처리하기 위한 확장이다.

두 방식을 혼동하면 잘못된 튜닝으로 이어진다. 단일 쿼리가 느린데 클러스터 수만 늘리면 그 쿼리 자체의 속도는 그대로이고, 반대로 동시 사용자가 많아 대기열이 생기는데 웨어하우스 크기만 키우면 동시성 문제는 해결되지 않는다.

멀티클러스터 웨어하우스로 동시성 해결하기

멀티클러스터 웨어하우스는 동일한 크기의 클러스터 여러 개로 구성된다. 단일 클러스터가 100개의 쿼리를 동시에 처리하려 하면 큐잉(대기열)이 발생하지만, 멀티클러스터 웨어하우스는 트래픽이 몰릴 때 추가 클러스터를 자동으로 띄워(Scale Out) 부하를 분산하고, 트래픽이 줄어들면 다시 클러스터 수를 줄인다(Scale In).

이 워크로드 격리와 동시성 모델은 Snowflake가 자주 '중간 지점'으로 평가받는 이유이기도 하다 — BigQuery처럼 완전히 컴퓨트를 숨기지도 않고(사용자가 웨어하우스 크기를 직접 고른다), Redshift처럼 노드 타입·개수까지 세세히 관리하지도 않는다(웨어하우스는 정해진 크기 단위로만 조절). 문제가 생겼을 때 원인을 특정 웨어하우스로 좁혀 진단할 수 있다는 점이 Snowflake의 예측 가능성으로 자주 언급된다(세 플랫폼 비교는 모듈 10에서 더 다룬다).