쿼리와 수집의 분리대부분의 자가 관리형 배포에서는 수집과 쿼리가 동일한 노드를 공유합니다. 이 경우 Total CPUs를 기준선으로 사용하십시오. 수집 컴퓨트와 쿼리 컴퓨트를 각각 독립적으로 프로비저닝하는 분리형 스케일링은 ClickHouse Cloud에서 별도의 컴퓨트 풀(즉, Warehouses)을 통해 지원됩니다.
가정
가정
- 스토리지에는 10배 압축률을 가정합니다. 일반적으로 로그와 트레이스 기준으로는 보수적인 수치입니다.
- 쿼리 SLA는 P50 1.5초, P99 5초를 가정합니다.
- 대부분의 쿼리는 최신 데이터에 대해 발생한다고 가정하며, 약 1시간 부근에서 정점을 찍고 약 6시간까지 꼬리가 이어지는 로그 정규 분포를 따른다고 봅니다. 오래된 데이터를 조회하려면 별도의 전용 컴퓨트를 프로비저닝하는 것이 좋을 수 있습니다. ClickHouse Cloud에서는 사용하지 않을 때 유휴 상태로 둘 수 있으므로(따라서 비용이 발생하지 않음) 필요할 때만 사용할 수 있습니다.
- 쿼리 컴퓨트는 수집 컴퓨트와 독립적으로 스케일링할 수 있지만, 본질적으로는 여전히 수집 볼륨과 연결되어 있습니다. 수집량이 증가하면 데이터 밀도가 높아지고, 그 결과 쿼리 시점의 스캔 볼륨이 커지며, 이에 따라 더 많은 쿼리 컴퓨트가 필요해진다고 가정합니다.
환경에 맞게 용량 산정 가정 조정하기
이 모델은 검색, 대시보드, 알림을 포함한 모든 쿼리 유형을 합산했을 때 ClickStack에서 평균 1 QPS가 지속적으로 발생한다고 가정합니다. 쿼리 볼륨이 더 높다면 CPU 요구량에 목표 QPS를 곱해 CPU 요구량을 선형적으로 늘리십시오. 예를 들어, 100 MB/s로 수집하는 배포에서 목표가 9 QPS라면 기준값 10이 아니라 90개의 쿼리 CPU(10 × 9)가 필요하므로, 총 CPU 수는 100개(수집 10개 + 쿼리 90개)로 조정됩니다. 스토리지 추정치는 보수적으로 10배의 압축률을 가정합니다. 실제로는 로그, 트레이스, 메트릭이 이보다 더 높은 압축률을 보이는 경우가 많습니다. 운영(production) 전에 데이터 샘플로 테스트하여 압축률과 스토리지 요구량을 미리 파악할 것을 권장합니다. 더 긴 보존 기간에 필요한 스토리지를 계산하려면 월별 스토리지 용량에 보존해야 하는 개월 수를 곱하십시오. 또한 이는 쿼리 분포가 비교적 고르게 균형을 이룬다고 가정합니다. 더 무거운 과거 데이터 쿼리나 아카이브 쿼리에 치우친 워크로드는 필요한 컴퓨트가 크게 달라질 수 있으므로 부하 테스트를 통해 검증해야 합니다. 향후에는 다양한 쿼리 분포 패턴에 따라 필요한 쿼리 컴퓨트를 추정할 수 있는 더 유연한 용량 산정 모델을 도입할 계획입니다.계산 예시
요구 사항: 월 1.5 PB 수집, 5 QPS, 3개월 보존. MB/s로 환산 용량 산정 모델은 MB/s 단위로 표현됩니다. 월 1.5 PB(1,500 TB)를 지속 처리량으로 환산하면 다음과 같습니다.- 1,500 TB = 1,500,000,000 MB
- 월간 초 수(30일 기준): 30 × 24 × 60 × 60 = 2,592,000
- MB/s = 1,500,000,000 ÷ 2,592,000 ≈ 579 MB/s
- 월간 압축 후 용량: 1,500 TB ÷ 10 = 150 TB/월
- 3개월 보존 시: 150 TB × 3 = 총 450 TB
관측성 워크로드 격리
이미 실시간 애플리케이션 분석과 같은 다른 워크로드를 지원하고 있는 기존 ClickHouse Cloud 서비스에 ClickStack을 추가하는 경우, 관측성 트래픽을 격리하는 것을 강력히 권장합니다. Managed Warehouses를 사용하여 ClickStack 전용 하위 서비스를 만드십시오. 이렇게 하면 다음과 같은 이점이 있습니다.- 기존 애플리케이션의 수집 트래픽과 쿼리 부하를 격리
- 관측성 워크로드를 독립적으로 확장
- 관측성 쿼리가 운영 분석에 영향을 주지 않도록 방지
- 필요할 때 서비스 간에 동일한 기본 데이터셋을 공유