Snowflake에서 ClickHouse로 마이그레이션하기
Snowflake에서 ClickHouse로 마이그레이션하기
이 문서는 Snowflake에서 ClickHouse로 데이터를 마이그레이션하는 방법을 소개해요. Snowflake는 대규모 장기 실행 리포트에 최적화된 클라우드 데이터 웨어하우스이고, ClickHouse는 실시간 분석 애플리케이션을 구동하는 데 최적화된 데이터베이스예요. 두 시스템의 유사점과 차이점을 정리했어요.
본문
이 문서는 Snowflake에서 ClickHouse로 데이터를 마이그레이션하는 방법을 소개해요.
Snowflake는 주로 레거시 온프레미스 데이터 웨어하우스 워크로드를 클라우드로 옮기는 데 초점을 둔 클라우드 데이터 웨어하우스예요. 대규모 장기 실행 리포트를 실행하는 데 잘 최적화되어 있어요. 데이터셋이 클라우드로 옮겨가면서 데이터 소유자들은 이 데이터에서 어떻게 추가 가치를 추출할지 고민하기 시작해요. 여기에는 이 데이터셋으로 내부·외부 사용 사례의 실시간 애플리케이션을 구동하는 것도 포함되죠. 이때쯤 되면 ClickHouse처럼 실시간 분석을 구동하는 데 최적화된 데이터베이스가 필요하다는 걸 깨닫는 경우가 많아요.
비교 (Comparison)
이 섹션에서는 ClickHouse와 Snowflake의 핵심 기능을 비교할게요.
유사점 (Similarities)
Snowflake는 대량의 데이터를 저장·처리·분석하기 위한 확장 가능하고 효율적인 솔루션을 제공하는 클라우드 기반 데이터 웨어하우징 플랫폼이에요. ClickHouse처럼 Snowflake는 기존 기술 위에 구축되지 않고 자체 SQL 쿼리 엔진과 맞춤 아키텍처에 의존해요. Snowflake의 아키텍처는 공유 스토리지(shared-storage, shared-disk) 아키텍처와 shared-nothing 아키텍처의 하이브리드로 설명돼요.
shared-storage 아키텍처는 S3 같은 오브젝트 스토어를 사용해 모든 컴퓨트 노드에서 데이터에 접근할 수 있는 구조예요. shared-nothing 아키텍처는 각 컴퓨트 노드가 전체 데이터셋의 일부를 로컬에 저장해서 쿼리에 응답하는 구조예요. 이론적으로 이는 두 모델의 최상을 제공해요: shared-disk 아키텍처의 단순성과 shared-nothing 아키텍처의 확장성. 이 설계는 근본적으로 오브젝트 스토리지를 기본 저장 매체로 삼는데, 오브젝트 스토리지는 동시 접근 하에서 거의 무한히 확장되면서 높은 복원력과 확장 가능한 처리량 보장을 제공해요. 아래 docs.snowflake.com의 이미지가 이 아키텍처를 보여줘요.
반대로 ClickHouse는 오픈소스이자 클라우드 호스팅 제품으로, shared-disk와 shared-nothing 아키텍처 양쪽에 배포할 수 있어요. 후자는 self-managed 배포에 일반적이에요. CPU와 메모리를 쉽게 확장할 수 있게 해 주지만, shared-nothing 구성은 데이터 복제의 전통적인 데이터 관리 과제와 오버헤드, 특히 멤버십 변경 중의 오버헤드를 도입해요. 그래서 ClickHouse Cloud는 Snowflake와 개념적으로 유사한 shared-storage 아키텍처를 사용해요. 데이터는 S3나 GCS 같은 오브젝트 스토어에 한 번(단일 복사본) 저장되어, 강력한 중복 보장과 함께 사실상 무한한 스토리지를 제공해요. 각 노드는 이 단일 데이터 복사본과 캐시용 자체 로컬 SSD에 접근해요. 노드는 차례로 확장되어 필요에 따라 추가 CPU와 메모리 리소스를 제공할 수 있어요.
차이점 (Differences)
기본 저장 포맷과 쿼리 엔진을 제외하면, 이 아키텍처들은 몇 가지 미묘한 면에서 달라요:
- Snowflake의 컴퓨트 리소스는 warehouses라는 개념으로 제공돼요. 이들은 각각 고정 크기인 여러 노드로 구성돼요. Snowflake는 웨어하우스의 구체적 아키텍처를 공개하지 않지만, 일반적으로 각 노드는 8 vCPU, 16 GiB, 200GB 로컬 스토리지(캐시용)로 구성된다고 알려져 있어요. 노드 수는 티셔츠 사이즈에 따라 달라져요 — 예를 들어 x-small은 1개, small 2, medium 4, large 8 등. 이 웨어하우스들은 데이터와 독립적이며 오브젝트 스토리지에 있는 어떤 데이터베이스든 쿼리하는 데 사용할 수 있어요. 유휴 상태이고 쿼리 부하가 없으면 웨어하우스는 일시 중지되고, 쿼리를 받으면 재개돼요. 스토리지 비용은 항상 청구에 반영되지만 웨어하우스는 활성 상태일 때만 과금돼요.
- ClickHouse Cloud는 로컬 캐시 스토리지를 가진 유사한 노드 원리를 사용해요. 티셔츠 사이즈 대신 사용자는 총 컴퓨트 양과 사용 가능한 RAM으로 서비스를 배포해요. 그리고 이는 쿼리 부하에 따라 (정의된 한도 내에서) 투명하게 자동 확장돼요 — 각 노드의 리소스를 늘리거나(또는 줄이거나) 하는 수직 확장이거나, 전체 노드 수를 올리거나 내리는 수평 확장이죠. ClickHouse Cloud 노드는 Snowflake와 달리 1 CPU 대 메모리 비율을 가져요. 더 느슨한 결합이 가능하지만, 서비스는 Snowflake 웨어하우스와 달리 데이터에 결합돼요. 노드는 유휴 상태면 일시 중지되고 쿼리가 있으면 재개되기도 해요. 필요하면 서비스를 수동으로 크기 조정할 수도 있어요.
- ClickHouse Cloud의 쿼리 캐시는 노드 전용이에요. 반면 Snowflake는 웨어하우스와 독립적인 서비스 레이어에서 전달돼요. 벤치마크에 따르면 ClickHouse Cloud의 노드 캐시가 Snowflake보다 우수해요.
- Snowflake와 ClickHouse Cloud는 쿼리 동시성을 높이기 위해 확장하는 방식이 달라요. Snowflake는 multi-cluster warehouses라는 기능으로 이에 대응해요. 이 기능은 웨어하우스에 클러스터를 추가할 수 있게 해 줘요. 쿼리 지연 시간을 개선하지는 않지만, 추가 병렬화를 제공하고 더 높은 쿼리 동시성을 허용해요. ClickHouse는 수직 또는 수평 확장으로 서비스에 메모리와 CPU를 추가해 이에 대응해요. 이 블로그에서는 동시성을 더 높게 확장하는 능력은 탐구하지 않고 지연 시간에 집중하지만, 완전한 비교를 위해 이 작업도 해야 한다는 점을 인지하고 있어요. 하지만 어떤 동시성 테스트에서도 ClickHouse가 잘 수행할 것으로 예상해요. Snowflake는 웨어하우스당 허용 동시 쿼리 수를 기본 8로 명시적으로 제한하거든요. 비교해 보면 ClickHouse Cloud는 노드당 최대 1000개 쿼리 실행을 허용해요.
- 데이터셋에서 컴퓨트 크기를 전환할 수 있는 Snowflake의 능력과 웨어하우스의 빠른 재개 시간은 임시(ad hoc) 쿼리에 훌륭한 경험을 제공해요. 데이터 웨어하우스와 데이터 레이크 사용 사례에서 이는 다른 시스템에 비해 이점을 제공해요.
실시간 분석 (Real-time analytics)
공개 벤치마크 데이터에 따르면, ClickHouse는 실시간 분석 애플리케이션에서 다음 영역에 대해 Snowflake를 능가해요:
- 쿼리 지연 시간: 성능을 최적화하기 위해 테이블에 클러스터링을 적용해도 Snowflake 쿼리 지연 시간은 더 높아요. 테스트에서 Snowflake는 Snowflake clustering 키 또는 ClickHouse primary key의 일부인 필터가 적용된 쿼리에서 ClickHouse와 동등한 성능을 얻으려면 두 배 이상의 컴퓨트가 필요해요. Snowflake의 persistent query cache는 이러한 지연 문제 중 일부를 상쇄하지만, 필터 조건이 더 다양해지는 경우에는 비효율적이에요. 이 쿼리 캐시 효율은 기반 데이터의 변경에 의해 더 영향을 받을 수 있는데, 테이블이 바뀌면 캐시 항목이 무효화되기 때문이에요. ClickHouse의 쿼리 캐시는 노드 전용이고 트랜잭션적으로 일관되지 않아서 실시간 분석에 더 적합해요. 사용자는 쿼리별로 사용을 제어하고, 정확한 크기, 쿼리가 캐시되는지 여부 (지속 시간 또는 필요한 실행 횟수 제한), 수동적으로만 사용되는지에 대한 세밀한 제어도 할 수 있어요.
- 더 낮은 비용: Snowflake 웨어하우스는 쿼리 비활성 기간 후 일시 중지되도록 구성할 수 있어요. 일시 중지되면 비용이 발생하지 않아요. 실질적으로 이 비활성 검사는 60초로만 낮출 수 있어요. 쿼리를 받으면 웨어하우스는 몇 초 내에 자동으로 재개돼요. Snowflake는 웨어하우스가 사용 중일 때만 리소스에 대해 과금하므로 이 동작은 임시 쿼리처럼 자주 유휴 상태인 워크로드에 맞춰져 있어요. 그러나 많은 실시간 분석 워크로드는 지속적인 실시간 데이터 수집과 빈번한 쿼리(고객 대상 대시보드 같은)를 필요로 하며 유휴 상태의 이점이 없어요. 이는 웨어하우스가 자주 완전 활성 상태여야 하고 비용이 발생한다는 뜻이에요. 이는 유휴 상태의 비용 이점과 Snowflake가 대안보다 빠르게 응답 상태로 재개하는 능력과 연관된 성능 이점을 모두 무효화해요. 이 활성 상태 요구사항은 ClickHouse Cloud의 활성 상태 초당 비용이 더 낮은 것과 결합되어, 이런 종류의 워크로드에서 ClickHouse Cloud가 총 비용을 크게 낮춰요.
- 기능의 예측 가능한 가격: 매터리얼라이즈드 뷰와 클러스터링(ClickHouse의
ORDER BY에 해당) 같은 기능은 실시간 분석 사용 사례에서 최고 수준의 성능을 달성하는 데 필요해요. 이 기능들은 Snowflake에서 추가 비용이 발생해요 — 더 높은 티어가 필요해서 1.5배의 크레딧당 비용이 들 뿐 아니라, 예측 불가능한 백그라운드 비용도 수반돼요. 예를 들어 매터리얼라이즈드 뷰는 백그라운드 유지보수 비용이 들고, 클러스터링도 사용 전에 예측하기 어려운 비용이 들어요. 반면 ClickHouse Cloud에서는 이 기능들에 추가 비용이 없어요. 삽입 시 추가 CPU·메모리 사용을 제외하고, 이는 높은 삽입 워크로드 사용 사례 외에는 보통 무시할 만해요. 벤치마크에서 이러한 차이와 더 낮은 쿼리 지연 시간, 더 높은 압축이 결합되어 ClickHouse로 훨씬 더 낮은 비용을 제공하는 것을 관찰했어요.