> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-3a82795f.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 리소스 산정

> Managed ClickStack 배포를 위한 리소스 산정 가이드

다음은 예상 수집 볼륨을 기준으로 ClickStack 배포에 필요한 컴퓨트 및 스토리지 리소스를 추정하는 모델입니다. 여기서 산출되는 값은 **추정치일 뿐**이며 **초기 기준선**으로 활용해야 합니다. 정해진 답으로 받아들여서는 안 됩니다. 실제 요구 사항은 쿼리 복잡도, 동시성, 보관 정책, 수집 처리량의 변동성에 따라 달라집니다. 항상 리소스 사용량을 모니터링하고 필요에 따라 스케일링하십시오.

<Warning>
  **모든 수치는 압축되지 않은 원시 수집량을 기준으로 합니다**

  이 페이지의 모든 수치(처리량(MB/s, TB/월), CPU 산정, 스토리지)는 **압축되지 않은 원시 수집 볼륨** 기준으로 표시됩니다. 즉, 애플리케이션에서 생성되어 압축이 적용되기 전에 OpenTelemetry collector로 전송되는 데이터 크기입니다.

  기존 로그, 트레이스, 메트릭 파이프라인을 기준으로 추정해야 하는 값이 바로 이 수치입니다. 아래 표의 스토리지 수치에는 이 원시 볼륨에 대해 가정한 **10배 압축률**이 이미 적용되어 있습니다.
</Warning>

ClickStack을 배포할 때는 **수집**과 **쿼리**라는 두 개의 독립적인 워크로드를 감당할 수 있도록 컴퓨트를 프로비저닝해야 합니다.

| Workload   | Estimated resources                            |
| ---------- | ---------------------------------------------- |
| **Ingest** | 지속적인 수집 처리량 10 MB/s당 1 vCPU                    |
| **Query**  | 1 QPS당 1 vCPU, 그리고 지속적인 수집 처리량 10 MB/s당 1 vCPU |

<Info>
  **쿼리와 수집의 분리**

  대부분의 자가 관리형 배포에서는 수집과 쿼리가 동일한 노드를 공유합니다. 이 경우 **Total CPUs**를 기준선으로 사용하십시오. 수집 컴퓨트와 쿼리 컴퓨트를 각각 독립적으로 프로비저닝하는 분리형 스케일링은 ClickHouse Cloud에서 [별도의 컴퓨트 풀(즉, Warehouses)](/ko/products/cloud/features/infrastructure/warehouses)을 통해 지원됩니다.
</Info>

<Accordion title="가정">
  * 스토리지에는 **10배 압축률**을 가정합니다. 일반적으로 로그와 트레이스 기준으로는 보수적인 수치입니다.
  * 쿼리 SLA는 P50 1.5초, P99 5초를 가정합니다.
  * 대부분의 쿼리는 최신 데이터에 대해 발생한다고 가정하며, 약 1시간 부근에서 정점을 찍고 약 6시간까지 꼬리가 이어지는 로그 정규 분포를 따른다고 봅니다. 오래된 데이터를 조회하려면 별도의 전용 컴퓨트를 프로비저닝하는 것이 좋을 수 있습니다. ClickHouse Cloud에서는 사용하지 않을 때 유휴 상태로 둘 수 있으므로(따라서 비용이 발생하지 않음) 필요할 때만 사용할 수 있습니다.
  * 쿼리 컴퓨트는 수집 컴퓨트와 독립적으로 스케일링할 수 있지만, 본질적으로는 여전히 수집 볼륨과 연결되어 있습니다. 수집량이 증가하면 데이터 밀도가 높아지고, 그 결과 쿼리 시점의 스캔 볼륨이 커지며, 이에 따라 더 많은 쿼리 컴퓨트가 필요해진다고 가정합니다.
</Accordion>

다음 표는 초당 메가바이트 단위의 수집 처리량이 증가할 때의 예시 산정값과, 이에 대응하는 월간 테라바이트 단위 데이터 볼륨을 보여줍니다. 이는 모든 쿼리 유형(search, dashboards, alerting)에 걸쳐 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 |

<div id="refining-sizing-assumptions">
  ## 환경에 맞게 용량 산정 가정 조정하기
</div>

이 모델은 검색, 대시보드, 알림을 포함한 모든 쿼리 유형을 합산했을 때 ClickStack에서 평균 1 QPS가 지속적으로 발생한다고 가정합니다.

쿼리 볼륨이 더 높다면 CPU 요구량에 목표 QPS를 곱해 CPU 요구량을 선형적으로 늘리십시오. 예를 들어, 100 MB/s로 수집하는 배포에서 목표가 9 QPS라면 기준값 10이 아니라 90개의 쿼리 CPU(10 × 9)가 필요하므로, 총 CPU 수는 100개(수집 10개 + 쿼리 90개)로 조정됩니다.

스토리지 추정치는 보수적으로 10배의 압축률을 가정합니다. 실제로는 로그, 트레이스, 메트릭이 이보다 더 높은 압축률을 보이는 경우가 많습니다. 운영(production) 전에 데이터 샘플로 테스트하여 압축률과 스토리지 요구량을 미리 파악할 것을 권장합니다. 더 긴 보존 기간에 필요한 스토리지를 계산하려면 월별 스토리지 용량에 보존해야 하는 개월 수를 곱하십시오.

또한 이는 쿼리 분포가 비교적 고르게 균형을 이룬다고 가정합니다. 더 무거운 과거 데이터 쿼리나 아카이브 쿼리에 치우친 워크로드는 필요한 컴퓨트가 크게 달라질 수 있으므로 부하 테스트를 통해 검증해야 합니다. 향후에는 다양한 쿼리 분포 패턴에 따라 필요한 쿼리 컴퓨트를 추정할 수 있는 더 유연한 용량 산정 모델을 도입할 계획입니다.

<div id="worked-example">
  ### 계산 예시
</div>

**요구 사항:** 월 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**의 쿼리 컴퓨트

**스토리지**

579 MB/s를 30일 동안 지속한다고 가정하면 원시 수집량은 월 1,500 TB입니다. 여기에 가정한 10배 압축률을 적용하면:

* 월간 압축 후 용량: 1,500 TB ÷ 10 = **150 TB/월**
* 3개월 보존 시: 150 TB × 3 = **총 450 TB**

**요약**

| 리소스           | 값         |
| ------------- | --------- |
| 수집 컴퓨트        | 58 vCPUs  |
| 쿼리 컴퓨트        | 290 vCPUs |
| 총 컴퓨트         | 348 vCPUs |
| 월간 스토리지(압축 후) | 150 TB    |
| 3개월 보존용 스토리지  | 450 TB    |

<div id="isolating-workloads">
  ## 관측성 워크로드 격리
</div>

이미 실시간 애플리케이션 분석과 같은 다른 워크로드를 지원하고 있는 **기존 ClickHouse Cloud 서비스**에 ClickStack을 추가하는 경우, 관측성 트래픽을 격리하는 것을 강력히 권장합니다.

[**Managed Warehouses**](/ko/products/cloud/features/infrastructure/warehouses)를 사용하여 ClickStack 전용 **하위 서비스**를 만드십시오. 이렇게 하면 다음과 같은 이점이 있습니다.

* 기존 애플리케이션의 수집 트래픽과 쿼리 부하를 격리
* 관측성 워크로드를 독립적으로 확장
* 관측성 쿼리가 운영 분석에 영향을 주지 않도록 방지
* 필요할 때 서비스 간에 동일한 기본 데이터셋을 공유

이 접근 방식을 사용하면 기존 워크로드에는 영향을 주지 않으면서, 관측성 데이터가 증가함에 따라 ClickStack을 독립적으로 확장할 수 있습니다.

더 큰 규모의 배포 또는 맞춤형 용량 산정 지침이 필요한 경우, 보다 정확한 추정을 위해 지원팀에 문의하십시오.