리소스 추정
다음은 예상 수집 볼륨을 기준으로 ClickStack 배포에 필요한 컴퓨팅 및 스토리지 리소스를 추정하기 위한 모델입니다. 산출되는 값은 추정치일 뿐이며 초기 기준선으로 사용해야 합니다. 이는 규범적인 정답이 아닙니다. 실제 요구 사항은 쿼리 복잡도, 동시성, 보존 정책, 수집 처리량의 변동성에 따라 달라집니다. 항상 리소스 사용량을 모니터링하고 필요에 따라 스케일링하십시오.
이 페이지의 모든 수치(처리량(MB/s, TB/월), CPU 산정, 스토리지)는 압축되지 않은 원시 수집 볼륨, 즉 애플리케이션에서 생성되어 압축이 적용되기 전에 OpenTelemetry collector로 전송되는 데이터 크기를 기준으로 표시됩니다.
기존 로그, 트레이스, 메트릭 파이프라인을 바탕으로 추정해야 하는 값이 바로 이 수치입니다. 아래 표의 스토리지 수치에는 이 원시 볼륨에 대해 가정한 10배 압축률이 이미 적용되어 있습니다.
ClickStack을 배포할 때는 수집과 쿼리라는 두 개의 독립적인 워크로드를 처리할 수 있도록 컴퓨팅 리소스를 프로비저닝하십시오.
| Workload | Estimated resources |
|---|---|
| Ingest | 지속적인 수집 처리량 10 MB/s당 1 vCPU |
| Query | 1 QPS당 1 vCPU, 그리고 지속적인 수집 처리량 10 MB/s당 1 vCPU |
대부분의 자가 관리형 배포에서는 수집과 쿼리가 동일한 노드를 공유합니다. 이 경우 Total CPUs를 기준선으로 사용하십시오. 수집과 쿼리 컴퓨팅을 독립적으로 프로비저닝하는 격리형 스케일링은 ClickHouse Cloud에서 별도의 compute pool(즉, Warehouse)을 통해 지원됩니다.
가정
- 스토리지의 경우 10배 압축률을 가정하며, 이는 일반적으로 로그와 트레이스에서 보수적인 수치입니다.
- 쿼리 SLA는 P50 1.5초, P99 5초를 가정합니다.
- 대부분의 쿼리는 최근 데이터에 대해 발생하며, 약 1시간 부근에서 정점을 찍고 약 6시간까지 꼬리가 이어지는 로그 정규 분포를 따른다고 가정합니다. 오래된 데이터를 쿼리하기 위해 전용 컴퓨팅을 프로비저닝할 수도 있습니다. ClickHouse Cloud에서는 사용하지 않을 때 이를 idle 상태로 둘 수 있으므로(따라서 비용이 발생하지 않음) 효율적으로 운영할 수 있습니다.
- 쿼리 컴퓨팅은 수집 컴퓨팅과 독립적으로 스케일링할 수 있지만, 본질적으로는 여전히 수집 볼륨과 연결되어 있습니다. 수집이 증가하면 데이터 밀도도 높아져 쿼리 시 스캔 볼륨이 커지고, 그 결과 더 많은 쿼리 컴퓨팅이 필요하다고 가정합니다.
다음 표는 초당 메가바이트 단위의 수집 처리량이 증가할 때의 예시 산정값과, 이에 대응하는 월간 테라바이트 단위 데이터 볼륨을 보여줍니다. 이는 모든 쿼리 유형(검색, 대시보드, 알림) 전반에서 ClickStack의 1 QPS 지속 평균을 가정합니다.
| MB/s | TB/month | Ingest CPUs | Query CPUs | Total CPUs | Total Storage (per month) (GB) |
|---|---|---|---|---|---|
| 10 | 25.92 | 1 | 3 | 4 | 2,592 |
| 20 | 51.84 | 2 | 6 | 8 | 5,184 |
| 50 | 129.6 | 5 | 15 | 20 | 12,960 |
| 100 | 259.2 | 10 | 30 | 40 | 25,920 |
| 200 | 518.4 | 20 | 60 | 80 | 51,840 |
| 500 | 1,296 | 50 | 150 | 200 | 129,600 |
| 1000 | 2,592 | 100 | 300 | 400 | 259,200 |
환경에 맞게 용량 산정 가정 조정하기
이 모델은 검색, 대시보드, 알림을 포함한 모든 쿼리 유형을 합산했을 때 ClickStack에서 평균 1 QPS가 지속적으로 발생한다고 가정합니다.
쿼리 볼륨이 더 높다면 목표 QPS에 맞춰 CPU 요구량을 선형적으로 늘리십시오. 즉, CPU 요구량에 목표 QPS를 곱하면 됩니다. 예를 들어 100 MB/s로 수집하는 배포에서 목표가 9 QPS라면, 기준 10개가 아니라 90개의 쿼리 CPU(10 × 9)가 필요합니다. 이 경우 총 CPU는 100개(수집 10개 + 쿼리 90개)로 다시 산정됩니다.
스토리지 추정치는 보수적으로 10배 압축률을 가정합니다. 실제로는 로그, 트레이스, 메트릭이 이보다 더 높은 압축률을 보이는 경우가 많습니다. 프로덕션에 앞서 데이터 샘플로 테스트하여 압축률과 스토리지 요구량을 미리 산정할 것을 권장합니다. 더 긴 보관 기간에 필요한 스토리지를 계산하려면 월별 스토리지에 보관할 개월 수를 곱하십시오.
이는 쿼리 분포가 비교적 고르게 분산되어 있다고 가정한 것입니다. 더 무거운 과거 데이터 조회나 아카이브 쿼리에 치우친 워크로드는 컴퓨트 요구량이 크게 달라질 수 있으므로 부하 테스트를 통해 검증해야 합니다. 향후에는 다양한 쿼리 분포 패턴에 따라 쿼리 컴퓨트 요구량을 추정할 수 있도록 더 유연한 용량 산정 모델을 도입할 계획입니다.
계산 예시
요구 사항: 월 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
수집 컴퓨트
지속 수집 10 MB/s당 1 vCPU를 기준으로 하면 다음과 같습니다.
579 ÷ 10 = 수집에 약 58 vCPU
쿼리 컴퓨트
쿼리 컴퓨트는 수집 처리량과 QPS에 따라 함께 증가합니다. 5 QPS 기준:
(579 ÷ 10) × 5 = 58 × 5 = 쿼리에 290 vCPU
스토리지
30일 동안 579 MB/s를 지속하면 원시 수집량은 월 1,500 TB입니다. 가정한 10배 압축률을 적용하면 다음과 같습니다.
- 월 압축 후 용량: 1,500 TB ÷ 10 = 150 TB/월
- 3개월 보관 시: 150 TB × 3 = 총 450 TB
요약
| 리소스 | 값 |
|---|---|
| 수집 컴퓨트 | 58 vCPU |
| 쿼리 컴퓨트 | 290 vCPU |
| 총 컴퓨트 | 348 vCPU |
| 월별 스토리지(압축 후) | 150 TB |
| 3개월 보관용 스토리지 | 450 TB |
관측성 워크로드 격리
실시간 애플리케이션 분석과 같은 다른 워크로드를 이미 지원하는 기존 ClickHouse Cloud 서비스에 ClickStack을 추가하는 경우, 관측성 트래픽을 격리하는 것을 강력히 권장합니다.
ClickStack 전용 하위 서비스를 생성하려면 관리형 웨어하우스를 사용하십시오. 이 절을 사용하면 다음이 가능합니다:
- 기존 애플리케이션의 수집 및 쿼리 부하를 격리
- 관측성 워크로드를 독립적으로 확장
- 관측성 쿼리가 프로덕션 분석에 영향을 주지 않도록 방지
- 필요할 때 서비스 전반에서 동일한 기본 데이터세트를 공유
이 접근 방식은 관측성 데이터가 증가하더라도 기존 워크로드에 영향을 주지 않으면서 ClickStack을 독립적으로 확장할 수 있도록 합니다.
더 큰 규모의 배포 또는 사용자 지정 크기 조정 지침이 필요하면, 보다 정확한 견적을 위해 지원팀에 문의하십시오.
