용량 산정과 하드웨어 권장사항

이 가이드에서는 오픈소스 사용자를 위한 하드웨어, 컴퓨팅, 메모리, 디스크 구성에 대한 일반적인 권장사항을 다뤄요. 설정을 단순화하고 싶다면 인프라 관리 비용을 최소화하면서 워크로드에 자동으로 확장·적응하는 ClickHouse Cloud 사용을 권장해요. ClickHouse 클러스터 구성은 애플리케이션의 사용 사례와 워크로드 패턴에 크게 의존해요. 아키텍처를 계획할 때 다음 요소를 고려해야 해요:

동시성 (초당 요청 수)
처리량 (초당 처리되는 행 수)
데이터 양
데이터 보존 정책
하드웨어 비용
유지보수 비용

출처: 문서

본문

디스크 (Disk)

ClickHouse와 함께 사용해야 할 디스크 종류는 데이터 양, 지연 시간, 처리량 요구에 따라 달라져요.

성능 최적화

성능을 최대화하려면 IO에 최적화된 AWS의 provisioned IOPS SSD 볼륨 또는 클라우드 제공자의 동급 제품을 직접 연결할 것을 권장해요.

저장 비용 최적화

비용을 낮추려면 general purpose SSD EBS 볼륨을 사용할 수 있어요. hot/warm/cold 아키텍처에서 SSD와 HDD를 사용하는 계층형 저장소를 구현할 수도 있어요. 대안으로 AWS S3를 저장소로 사용해 컴퓨팅과 저장을 분리할 수도 있어요. 컴퓨팅·저장 분리와 함께 오픈소스 ClickHouse를 사용하는 가이드는 여기를 참고하세요. 컴퓨팅·저장 분리는 ClickHouse Cloud에서 기본으로 제공돼요.

CPU

어떤 CPU를 사용해야 하나요?

사용해야 할 CPU 종류는 사용 패턴에 따라 달라져요. 일반적으로 빈번한 동시 쿼리가 많고 더 많은 데이터를 처리하거나 계산 집약적인 UDF를 사용하는 애플리케이션은 더 많은 CPU 코어가 필요해요.

낮은 지연 또는 고객 대면 애플리케이션 고객 대면 워크로드처럼 수십 밀리초의 지연 요구가 있다면 IO에 최적화된 AWS의 EC2 i3 계열이나 i4i 계열, 또는 클라우드 제공자의 동급 제품을 권장해요.

높은 동시성 애플리케이션 동시성(초당 100+ 쿼리)에 최적화해야 하는 워크로드에는 AWS의 compute-optimized C 시리즈나 클라우드 제공자의 동급 제품을 권장해요.

데이터 웨어하우징 사용 사례 데이터 웨어하우징 워크로드와 임시 분석 쿼리에는 메모리에 최적화된 AWS의 R-type 시리즈나 클라우드 제공자의 동급 제품을 권장해요.

CPU 사용률은 얼마여야 하나요?

ClickHouse에 표준 CPU 사용률 목표는 없어요. iostat 같은 도구로 평균 CPU 사용량을 측정하고, 예상치 못한 트래픽 급증을 관리하도록 서버 크기를 그에 맞게 조정해요. 하지만 임시 쿼리가 있는 분석·데이터 웨어하우징 사용 사례에서는 10-20% CPU 사용률을 목표로 해야 해요.

몇 개의 CPU 코어를 사용해야 하나요?

사용해야 할 CPU 수는 워크로드에 따라 달라져요. 하지만 일반적으로 CPU 유형에 따라 다음 메모리-대-CPU 코어 비율을 권장해요:

M-type (범용 사용 사례): 4 GB:1 메모리-대-CPU 코어 비율
R-type (데이터 웨어하우징 사용 사례): 8 GB:1 메모리-대-CPU 코어 비율
C-type (계산 최적화 사용 사례): 2 GB:1 메모리-대-CPU 코어 비율

예를 들어 M-type CPU를 사용할 때 25개의 CPU 코어당 100GB의 메모리를 프로비저닝할 것을 권장해요. 애플리케이션에 적절한 메모리 양을 결정하려면 메모리 사용량 프로파일링이 필요해요. 메모리 문제 디버깅 가이드를 읽거나 기본 제공 관찰성 대시보드로 ClickHouse를 모니터링할 수 있어요.

메모리 (Memory)

CPU 선택과 마찬가지로 메모리-대-저장 비율과 메모리-대-CPU 비율 선택은 사용 사례에 따라 달라져요. 필요한 RAM 용량은 일반적으로 다음에 의존해요:

쿼리의 복잡도.
쿼리에서 처리되는 데이터 양.

일반적으로 메모리가 많을수록 쿼리가 더 빨리 실행돼요. 사용 사례가 가격에 민감하면 더 낮은 메모리 양도 작동해요. (max_bytes_before_external_group_by](/docs/reference/settings/session-settings/max-bytes#max_bytes_before_external_group_by)와 max_bytes_before_external_sort 설정을 활성화해 데이터를 디스크로 넘칠(spill) 수 있지만, 이는 쿼리 성능에 크게 영향을 줄 수 있음을 유의하세요.)

메모리-대-저장 비율은 얼마여야 하나요?

낮은 데이터 양에서는 1:1 메모리-대-저장 비율이 허용되지만 총 메모리는 8GB 미만이어서는 안 돼요. 데이터 보존 기간이 길거나 데이터 양이 많은 사용 사례에서는 1:100에서 1:130 메모리-대-저장 비율을 권장해요. 예를 들어 10TB의 데이터를 저장한다면 레플리카당 100GB의 RAM이에요. 고객 대면 워크로드처럼 자주 접근하는 사용 사례에서는 1:30에서 1:50 메모리-대-저장 비율로 더 많은 메모리를 사용할 것을 권장해요.

레플리카 (Replicas)

샤드당 최소 세 개의 레플리카(또는 Amazon EBS를 사용하면 두 개)를 권장해요. 또한 추가 레플리카를 더하기(수평 확장) 전에 모든 레플리카를 수직 확장할 것을 제안해요. ClickHouse는 자동으로 샤딩하지 않으며, 데이터셋을 다시 샤딩하려면 상당한 컴퓨팅 리소스가 필요해요. 따라서 미래에 데이터를 다시 샤딩하지 않도록 사용 가능한 가장 큰 서버를 사용할 것을 일반적으로 권장해요. 자동으로 확장하고 사용 사례에 맞게 레플리카 수를 쉽게 제어할 수 있는 ClickHouse Cloud를 고려해보세요.

대규모 워크로드를 위한 예제 구성

ClickHouse 구성은 특정 애플리케이션 요구에 크게 의존해요. 비용과 성능을 위해 아키텍처 최적화를 도와주길 원하면 영업팀에 문의하세요. 지침을 제공하기 위해(권장이 아니라) 다음은 프로덕션의 ClickHouse 사용자 구성 예시예요:

Fortune 500 B2B SaaS

저장 (Storage)

월간 신규 데이터 양| 30TB 총 저장 (압축)| 540TB 데이터 보존| 18개월 노드당 디스크| 25TB

CPU 동시성| 200+ 동시 쿼리 레플리카 수 (HA 쌍 포함)| 44 노드당 vCPU| 62 총 vCPU| 2700

메모리 총 RAM| 11TB 레플리카당 RAM| 256GB RAM-대-vCPU 비율| 4 GB:1 RAM-대-디스크 비율| 1:50

로깅 사용 사례의 Fortune 500 통신 사업자

저장 (Storage)

월간 로그 데이터 양| 4860TB 총 저장 (압축)| 608TB 데이터 보존| 30일 노드당 디스크| 13TB

CPU 레플리카 수 (HA 쌍 포함)| 38 노드당 vCPU| 42 총 vCPU| 1600

메모리 총 RAM| 10TB 레플리카당 RAM| 256GB RAM-대-vCPU 비율| 6 GB:1 RAM-대-디스크 비율| 1:60

추가 자료 (Further reading)

오픈소스 ClickHouse를 사용하는 회사들의 아키텍처에 대한 게시된 블로그 게시물은 다음과 같아요:

용량 산정과 하드웨어 권장사항