온프레미스 환경의 데이터 웨어하우스(DW)는 스토리지 용량이 찰 때마다 하드웨어를 증설해야 하는 CapEx(자본 지출) 문제와, 피크 타임의 트래픽을 처리하기 위해 평상시 유휴 자원을 유지해야 하는 비효율성을 안고 있습니다. 물리적 장비에 종속된 오라클(Oracle) Exadata나 Teradata 환경에서 벗어나 클라우드 네이티브 DW로 전환하는 것은 단순한 플랫폼 변경이 아닌, 컴퓨팅과 스토리지의 분리(Decoupling Compute and Storage)라는 아키텍처적 패러다임의 전환을 의미합니다. 본 글에서는 현재 시장을 주도하는 3대 클라우드 DW인 Snowflake, Google BigQuery, AWS Redshift의 내부 아키텍처와 트레이드오프를 엔지니어링 관점에서 분석합니다.
1. 아키텍처 접근 방식: Shared-Nothing vs Multi-Cluster
세 플랫폼 모두 MPP(Massively Parallel Processing) 아키텍처를 기반으로 하지만, 구현 방식에는 명확한 차이가 존재합니다. 이 차이는 성능 확장성(Scalability)과 동시성(Concurrency) 처리 능력에 직접적인 영향을 미칩니다.
Snowflake: Multi-Cluster Shared Data
Snowflake는 스토리지 계층(S3, Blob, GCS) 위에 독자적인 'Virtual Warehouse'라는 컴퓨팅 클러스터를 올리는 구조입니다. 가장 큰 특징은 컴퓨팅 자원이 서로 완전히 격리되어 있다는 점입니다. 즉, ETL 작업을 수행하는 웨어하우스와 BI 대시보드 조회를 수행하는 웨어하우스가 물리적으로 분리되어 있어, 무거운 배치 작업이 분석가들의 쿼리 속도에 영향을 주지 않습니다.
Google BigQuery: Serverless & Dremel
BigQuery는 인프라 프로비저닝 개념 자체를 추상화했습니다. 사용자는 노드나 클러스터를 생성하지 않습니다. 구글의 내부 분산 파일 시스템인 Colossus에 데이터를 저장하고, 쿼리 실행 시 Borg 클러스터에서 수천 개의 슬롯(Slot, vCPU 단위)을 동적으로 할당받아 Dremel 엔진으로 처리합니다. 이는 트래픽 변동이 극심한 서비스에 유리합니다.
AWS Redshift: Coupled to RA3
전통적인 Redshift는 컴퓨팅과 스토리지가 결합된 형태였으나, RA3 인스턴스 출시 이후 Managed Storage for Redshift를 통해 컴퓨팅과 스토리지를 분리했습니다. 하지만 Snowflake나 BigQuery에 비해 여전히 '클러스터'라는 물리적 개념이 강하며, 진정한 의미의 Elastic Scaling보다는 예약된 인스턴스 기반의 안정적인 성능에 초점을 맞춥니다.
2. 성능 최적화 및 유지보수성
각 플랫폼은 성능을 최적화하기 위해 서로 다른 전략을 취합니다. 엔지니어는 각 DB가 데이터를 어떻게 물리적으로 저장하고 인덱싱하는지 이해해야 쿼리 튜닝이 가능합니다.
Snowflake: Micro-partitions
Snowflake는 데이터를 '마이크로 파티션(Micro-partitions)'이라는 50MB~500MB 단위의 불변(Immutable) 파일로 자동 분할 저장합니다. 별도의 인덱스 생성 없이, 각 파티션의 메타데이터(Min/Max 값 등)를 활용하여 쿼리 시 불필요한 파티션을 스캔 대상에서 제외하는 Pruning 기법을 사용합니다.
-- Snowflake의 클러스터링 키 지정 (대용량 테이블 최적화 시 필수)
-- 데이터가 입력될 때 해당 키 기준으로 정렬되어 마이크로 파티션 효율 극대화
CREATE OR REPLACE TABLE events (
event_id STRING,
event_date DATE,
user_id STRING,
data VARIANT
)
CLUSTER BY (event_date, user_id);
BigQuery: Partitioning & Clustering
BigQuery는 풀 스캔(Full Scan)이 기본 동작 방식이므로, 비용 통제를 위해 파티셔닝(Partitioning)과 클러스터링(Clustering)이 필수적입니다. 파티셔닝은 데이터를 물리적으로 분리하고, 클러스터링은 파티션 내부에서 데이터를 정렬하여 스캔 비용을 줄입니다.
SELECT * 쿼리는 테이블 전체 용량만큼 비용을 청구합니다. 반드시 LIMIT가 아닌 WHERE 절을 통해 파티션을 필터링해야 스캔 용량이 줄어듭니다.
# BigQuery 파티셔닝 및 클러스터링 테이블 생성 예시
CREATE TABLE mydataset.logs (
log_id INT64,
timestamp TIMESTAMP,
category STRING
)
PARTITION BY DATE(timestamp) -- 일자별 파티셔닝
CLUSTER BY category -- 카테고리별 정렬 (Block Pruning 유도)
OPTIONS(
require_partition_filter = TRUE -- 파티션 필터 누락 시 쿼리 에러 발생 강제
);
3. 비용 모델과 트레이드오프
비용 구조는 도입 결정 시 가장 중요한 요소 중 하나입니다. 단순한 단가 비교보다는 워크로드 패턴에 따른 총소유비용(TCO)을 계산해야 합니다.
| 구분 | Snowflake | BigQuery | Redshift |
|---|---|---|---|
| 컴퓨팅 비용 | Credit 기반 (초 단위 과금, 최소 1분) | 스캔 용량(On-demand) 또는 슬롯 할당(Flat-rate) | 노드 시간당 과금 (RI 구매 시 대폭 할인) |
| 스토리지 비용 | 압축 후 월평균 용량 ($23/TB/Month 수준) | Active/Long-term 구분 과금 | RA3 사용 시 S3 비용과 유사, 구형 노드는 비쌈 |
| 유휴 자원 | Auto-suspend로 비용 절감 용이 | 완전 Serverless (유휴 비용 0) | 클러스터 실행 중 계속 과금 (Pause 기능 존재) |
| 적합한 패턴 | 예측 불가능한 다중 워크로드, 데이터 공유 | 간헐적이고 폭발적인 분석 쿼리 | 예측 가능한 정형화된 ETL/리포팅 |
Redshift의 비용 효율성
Redshift는 24/7 가동되는 정형화된 워크로드(예: 매시간 도는 ETL, 상시 대시보드)에서 예약 인스턴스(Reserved Instance)를 활용할 경우 타 솔루션 대비 50% 이상 저렴할 수 있습니다. 반면, 사용하지 않는 새벽 시간대에도 비용이 발생하므로 Pause/Resume 자동화가 필요합니다.
BigQuery의 예측 불가능성
BigQuery의 On-demand 모델(TB당 $5)은 진입 장벽이 낮지만, 쿼리 효율화를 하지 않은 주니어 개발자의 실수 하나로 수백 달러가 청구될 수 있습니다. 엔터프라이즈 환경에서는 'Slot' 단위의 정액제(Editions)를 고려해야 비용 폭탄을 막을 수 있습니다.
4. 데이터 거버넌스와 생태계 통합
단순 쿼리 엔진을 넘어 데이터 플랫폼으로서의 기능도 중요합니다.
- Snowflake: 클라우드 벤더 중립적(Cloud Agnostic)입니다. AWS, Azure, GCP 어디서든 동일한 경험을 제공하며, 'Data Sharing' 기능을 통해 데이터를 복제(Copy)하지 않고도 다른 계정이나 조직에 실시간으로 공유할 수 있습니다. 이는 B2B 데이터 비즈니스에 매우 유리합니다.
- BigQuery: Google Analytics(GA4), Firebase, YouTube 등 구글 마케팅 데이터와의 통합이 버튼 클릭 몇 번으로 이루어집니다. ML 모델을 SQL로 생성하는 BigQuery ML 기능은 데이터 사이언티스트 없이도 예측 모델을 만들 수 있게 해줍니다.
- Redshift: AWS 생태계(S3, Glue, Kinesis, Lambda)와의 결합도가 강력합니다. Redshift Spectrum을 사용하면 S3에 있는 데이터를 로딩 없이 바로 쿼리할 수 있어 데이터 레이크하우스(Lakehouse) 구축에 유리합니다.
결론: 어떤 DW를 선택해야 하는가?
세 솔루션 모두 성능과 안정성 면에서 엔터프라이즈 요구사항을 충족합니다. 결정은 기술적 우위보다는 현재 조직의 인프라 상황과 워크로드 특성에 따라 달라져야 합니다.
Snowflake는 관리 인력이 부족하고 여러 클라우드를 동시에 사용하거나, 데이터 공유가 잦은 조직에 적합합니다. BigQuery는 트래픽 변동이 심하고 구글 데이터 소스(GA4 등) 활용도가 높은 마케팅/커머스 조직에 최적입니다. Redshift는 이미 AWS 생태계에 깊이 종속되어 있고, 정해진 패턴의 대규모 ETL 작업을 가장 저렴하게 처리하고 싶은 조직에 가장 합리적인 선택이 될 것입니다.
Post a Comment