> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-vortex-format.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# 읽기 및 쓰기 워크로드 격리
> ClickHouse Cloud warehouse로 ClickStack 수집 워크로드와 쿼리 워크로드 분리하기
export const ScalePlanFeatureBadge = ({feature = '이 기능', linking_verb_are = false}) => {
return
Scale 플랜 기능
{feature} Scale 및 Enterprise 플랜에서 제공됩니다. 업그레이드하려면 Cloud Console의 플랜 페이지를 방문하세요.
;
};
관측성 워크로드는 동일한 데이터에 대해 서로 성격이 매우 다른 두 가지 요구를 발생시킵니다. 수집은 지속적으로 이루어지는 쓰기 중심 작업이며, 삽입이 완료된 뒤에도 백그라운드 머지가 오랫동안 CPU와 메모리를 소모합니다. 반면 쿼리 부하는 고르지 않습니다. 대시보드와 검색은 장애 상황에서 최고조에 이르는데, 느린 응답을 가장 용납하기 어려운 시점이 바로 이때입니다.
ClickHouse Cloud [warehouses](/ko/products/cloud/features/infrastructure/warehouses)를 사용하면 동일한 데이터를 서로 분리된 컴퓨트로 두 워크로드에 제공할 수 있으므로, 어느 쪽도 CPU와 메모리를 두고 경쟁하지 않습니다.
warehouses는 ClickHouse Cloud 기능이므로, 여기서 설명하는 구성은 ClickHouse Cloud 기반으로 실행되는 ClickStack에 적용됩니다. 데이터는 단일 복사본만 유지하면서 분리된 양쪽을 각각 독립적으로 용량 산정, 확장, 유휴 전환할 수 있습니다.
**isolation이 유용한 경우**
isolation은 지속적인 수집이 이루어지는 대규모 배포를 대상으로 합니다. 저장 데이터가 월 약 100TB 미만이라면 일반적으로 하나의 읽기-쓰기 service가 두 워크로드를 모두 감당하므로 두 번째 service는 필요하지 않을 가능성이 높습니다. 월별 compressed 볼륨을 추정하려면 [용량 산정 모델](/ko/clickstack/managing/estimating-resources)을 사용하십시오.
읽기와 쓰기를 분리해야 하는 이유
* **쓰기가 읽기 성능을 떨어뜨리지 않습니다.** 지속적인 OpenTelemetry 수집(삽입 작업 자체와 그 뒤를 잇는 백그라운드 머지)은 대시보드 및 검색 쿼리와 CPU 및 메모리를 두고 경쟁합니다. 수집이 실행되는 동안 읽기 지연 시간이 눈에 띄게 나빠졌다가 수집이 멈추면 회복될 수 있습니다.
* **읽기가 쓰기를 방해하지 않습니다.** 경합은 양방향으로 발생합니다. 무거운 애드혹 쿼리나 비용이 큰 대시보드 렌더링은 service의 메모리를 소진시켜 삽입을 단순히 느리게 만드는 정도가 아니라 아예 실패시킬 수 있습니다.
* **읽기 전용 컴퓨트는 전적으로 쿼리에만 사용됩니다.** 읽기 전용 service는 system tables를 제외하면 백그라운드 머지를 수행하지 않습니다. 또한 머지 때문에 깨어 있는 상태가 유지될 수 있는 읽기-쓰기 service와 달리, 지연 없이 유휴 상태로 전환됩니다.
* **양쪽 용량을 각각 산정합니다.** [용량 산정 모델](/ko/clickstack/managing/estimating-resources)은 수집 컴퓨트와 쿼리 컴퓨트를 별도로 추정하며, warehouse를 사용하면 각각을 독립적인 service로 프로비저닝할 수 있습니다. 모델의 1 QPS 기준선을 넘어서면 쿼리 컴퓨트가 대부분을 차지합니다. 5 QPS를 가정한 [실제 예시](/ko/clickstack/managing/estimating-resources#worked-example)에서는 수집에 58 vCPU, 쿼리에 290 vCPU가 산출되므로, 작은 쓰기 service가 훨씬 큰 읽기 service에 데이터를 공급하는 구성이 가능합니다.
* **유휴 상태 전환과 자동 스케일링은 service별로 설정합니다.** 각 service는 자체 레플리카 수, 자동 스케일링 및 자동 유휴 상태 전환 설정을 가지므로, 쓰기 service는 지속적인 수집을 위해 항상 켜 두고 읽기 service는 업무 시간 외에 유휴 상태로 전환되도록 할 수 있습니다.
* **스토리지는 중복되지 않습니다.** warehouse 내의 service들은 동일한 객체 스토리지 폴더와 동일한 테이블을 공유하며, [스토리지 요금은 한 번만 청구됩니다](/ko/products/cloud/features/infrastructure/warehouses#pricing).
* **엔드포인트별로 액세스를 제한할 수 있습니다.** IP 액세스 목록은 service별로 적용되므로, 쓰기 엔드포인트는 collector에서만, 읽기 엔드포인트는 ClickStack 배포에서만 연결할 수 있도록 제한할 수 있습니다. [네트워크 액세스 제어](/ko/products/cloud/features/infrastructure/warehouses#network-access-control) 가이드를 참조하십시오.
아키텍처
권장 토폴로지는 수집용 읽기-쓰기 서비스 1개와 ClickStack용 읽기 전용 서비스 1개로 구성된 warehouse입니다:
| 서비스 | 유형 | 담당 역할 | 클라이언트 |
| - | - | - | - |
| Primary | 읽기-쓰기 | 수집, 백그라운드 머지, DDL(테이블 생성, TTL, materialized view) | OpenTelemetry collector, ClickPipes, Vector, 관리용 SQL 콘솔/클라이언트 |
| Secondary | 읽기 전용 | 검색, dashboards, notebooks, 알림 평가 | ClickStack UI(HyperDX) |
토폴로지를 계획할 때 다음 사항을 유념하십시오:
* warehouse의 첫 번째 서비스는 항상 읽기-쓰기이며, 서비스 유형은 **생성 시점에 고정**됩니다. 읽기 전용과 읽기-쓰기를 전환하려면 warehouse에 새 서비스를 생성하십시오.
* warehouse 내 모든 서비스는 동일한 클라우드 제공업체, 리전, ClickHouse 버전 및 Keeper를 공유하며, 기본 서비스의 upgrade schedule을 따릅니다.
* 수집에는 읽기-쓰기 서비스를 **하나만** 사용하십시오. 머지는 스토리지를 공유하는 모든 읽기-쓰기 서비스에 분배되므로, 한 서비스에서 발생한 삽입에 대한 머지가 다른 서비스에서 실행될 수 있습니다. 그 다른 서비스가 부하가 큰 쿼리까지 처리하고 있다면, 해당 쿼리와 머지가 같은 서비스의 CPU 및 메모리를 두고 경합하게 되어 첫 번째 서비스의 삽입에 대한 머지가 느려지고, 결과적으로 삽입 performance도 함께 저하됩니다. 쿼리 워크로드는 읽기 전용 서비스에서 처리하고, [머지를 수집과 분리](#separating-merges)해야 하는 경우에만 두 번째 읽기-쓰기 서비스를 추가하십시오.
격리된 배포 환경 설정하기
기존 서비스 또는 새 warehouse의 기본 서비스를 수집용으로 사용하고, [용량 산정 모델](/ko/clickstack/managing/estimating-resources)에서 산출한 수집 컴퓨트 규모에 맞게 크기를 지정하십시오.
이 서비스에 데이터베이스와 수집 전용 사용자를 생성하십시오. warehouse 내의 모든 서비스는 액세스 제어(access controls)를 공유하므로, 여기서 생성한 사용자는 warehouse의 모든 서비스에서 사용할 수 있습니다:
```sql theme={null}
CREATE DATABASE otel;
CREATE USER hyperdx_ingest IDENTIFIED WITH sha256_password BY '';
GRANT SELECT, INSERT, CREATE DATABASE, CREATE TABLE, CREATE VIEW ON otel.* TO hyperdx_ingest;
```
`openssl rand -base64 24`와 같은 도구로 비밀번호를 생성하고, 매니페스트나 셸 이력에 남기지 말고 시크릿 관리 도구에 저장하십시오. 자세한 내용은 [수집 사용자 생성](/ko/clickstack/ingesting-data/collector#creating-an-ingestion-user) 가이드를 참조하십시오.
이 서비스가 이미 웨어하우스에 속해 있다면, 같은 웨어하우스의 다른 서비스가 유휴(idled) 상태일 때 데이터베이스 수준 DDL이 멈출 수 있다는 점에 유의하십시오. [관리 및 DDL](#administration)을 참조하십시오.
ClickHouse Cloud 콘솔에서 방금 준비한 서비스의 더하기 기호를 클릭해 해당 데이터를 공유하는 두 번째 서비스를 생성하십시오. 서비스 유형으로 **읽기 전용**을 선택하고, 용량 산정 모델에서 산출된 쿼리 컴퓨트에 맞게 크기를 지정하십시오.
전체 절차는 [웨어하우스 설정 방법](/ko/products/cloud/features/infrastructure/warehouses#setup-warehouses) 가이드를 참조하십시오.
수집 사용자로 인증하여 **읽기-쓰기** 서비스 엔드포인트로 데이터를 내보내도록 collector를 구성하십시오:
```shell theme={null}
CLICKHOUSE_ENDPOINT=https://.clickhouse.cloud:8443
CLICKHOUSE_USER=hyperdx_ingest
CLICKHOUSE_PASSWORD=
HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE=otel
```
자세한 내용은 [collector 구성 옵션](/ko/clickstack/managing/config#otel-collector)을 참조하고, [Vector](/ko/clickstack/ingesting-data/vector) 및 기타 수집 경로에 대해서는 그에 상응하는 설정을 참조하십시오.
읽기 전용 엔드포인트로 전송된 쓰기 요청은 거부되므로, collector는 항상 읽기-쓰기 서비스를 대상으로 지정해야 합니다.
ClickStack UI는 항상 ClickHouse Cloud 콘솔에서 실행을 시작한 ClickHouse 서비스에 연결됩니다. 읽기 전용 컴퓨트에서 실행하려면 다음과 같이 하십시오:
1. ClickHouse Cloud 콘솔에서 읽기 전용 서비스를 선택합니다.
2. 왼쪽 탐색 메뉴에서 **ClickStack**을 선택합니다.
이후 UI에서 실행하는 모든 쿼리는 해당 읽기 전용 컴퓨트에서 수행됩니다. ClickStack 내부에서 별도로 구성할 사항은 없습니다. [읽기 전용 컴퓨트에서 ClickStack 사용하기](/ko/clickstack/deployment/managed#clickstack-read-only-compute) 가이드를 참조하십시오.
**ClickStack 상태는 서비스 단위로 한정됩니다**
대시보드, 저장된 검색, 알림, 소스는 ClickStack을 실행한 서비스에 속하며, 동일한 warehouse 내의 다른 서비스로는 이전되지 않습니다. 두 서비스가 동일한 데이터를 공유하더라도 마찬가지입니다. [기본 OpenTelemetry 스키마](/ko/clickstack/deployment/managed#adding-data-sources)를 사용하는 소스는 새 서비스에서 자동으로 감지되므로 해당 데이터에 대한 검색은 바로 사용할 수 있지만, 사용자 정의 소스나 수동으로 구성한 소스, 그리고 저장해 둔 나머지 모든 항목은 다시 만들어야 합니다.
대시보드를 구축하기 전에 ClickStack을 실행할 서비스를 먼저 결정하십시오. 이미 운영 중인 배포를 전환하는 경우, 이전 서비스에서 생성한 알림은 삭제할 때까지 해당 서비스의 컴퓨트에서 계속 평가된다는 점에 유의하십시오.
ClickStack에서 검색을 실행하거나 대시보드를 연 다음, 쿼리가 어느 노드에서 처리되었는지 확인하십시오. `system` 테이블은 쿼리를 실행한 노드에 기록되므로, 레플리카가 두 개 이상인 서비스에서는 모든 레플리카를 조회하기 위해 `default` 클러스터 이름과 함께 [`clusterAllReplicas`](/ko/reference/system-tables/overview#querying-across-nodes)를 사용해야 합니다. **읽기 전용** 서비스에서는 다음과 같이 ClickStack 쿼리가 표시됩니다:
```sql theme={null}
SELECT
user,
query_kind,
http_user_agent,
count()
FROM clusterAllReplicas('default', system.query_log)
WHERE event_time > now() - toIntervalMinute(10)
AND type = 'QueryFinish'
AND is_initial_query = 1
GROUP BY ALL
ORDER BY count() DESC;
```
여기서 결과가 비어 있다고 해서 그것만으로 쿼리가 다른 곳으로 갔다는 뜻은 아닙니다. `system.query_log`는 주기적으로(기본값은 7.5초마다) 플러시되므로, 검색 직후에 실행한 쿼리는 아직 보이지 않을 수 있습니다. 잠시 기다린 후 다시 실행하거나, 권한이 있다면 [`SYSTEM FLUSH LOGS`](/ko/reference/statements/system#flush-logs)로 플러시를 강제하십시오.
트래픽의 출처를 구분해 주는 것은 `user`와 `http_user_agent`를 기준으로 한 그룹화입니다. 소스가 어떤 테이블을 가리키든 관계없이 UI와 SQL 콘솔, 그리고 해당 엔드포인트에 연결하는 그 외 모든 것을 구분해 줍니다. `is_initial_query = 1`로 필터링하면 제출된 형태 그대로 쿼리당 한 행만 남습니다. 분산 실행에서 발생하는 보조 쿼리와 [materialized view](/ko/reference/system-tables/query_views_log)를 평가하는 내부 쿼리는 `is_initial_query = 0`으로 별도 기록됩니다.
**읽기-쓰기** 서비스에서 동일한 쿼리를 실행하면 수집 사용자의 삽입 작업만 표시되고 ClickStack 쿼리 트래픽은 나타나지 않아야 합니다.
각 서비스에서 차례로 쿼리를 실행하는 것이 확실한 확인 방법입니다. `default` 클러스터에는 현재 연결된 서비스의 레플리카만 포함되기 때문입니다. warehouse 전체를 집계해서 보려면 대신 `all_groups.default` 클러스터 이름을 사용하십시오:
```sql theme={null}
SELECT
hostName() AS host,
query_kind,
count()
FROM clusterAllReplicas('all_groups.default', system.query_log)
WHERE event_time > now() - toIntervalMinute(10)
AND type = 'QueryFinish'
AND is_initial_query = 1
GROUP BY ALL;
```
이 쿼리를 사용할 때 유의할 점이 두 가지 있습니다. 유휴 상태로 전환된 서비스는 행을 반환할 수 없으므로 완전한 결과가 필요하다면 먼저 해당 서비스를 깨워야 합니다. 또한 `hostName()`은 서비스가 아닌 레플리카를 식별하므로, 특정 서비스의 활동으로 구분하려면 해당 서비스에 직접 쿼리를 실행하십시오.
머지와 수집 분리
매우 높은 수집률이 지속되면 삽입 자체보다 머지가 수집 서비스의 주된 비용 요소가 됩니다. 머지는 스토리지를 공유하는 모든 읽기-쓰기 서비스에 걸쳐 할당되므로, 다른 용도로 의도한 서비스에 머지 작업이 배정될 수도 있습니다.
이러한 배포 환경에서는 머지를 수집 서비스에서 완전히 분리하여 다음과 같은 3개 서비스 토폴로지를 구성할 수 있습니다:
| 서비스 | 유형 | 역할 |
| - | - | - |
| 수집 | 읽기-쓰기, 머지 비활성화 | 삽입만 처리 |
| 머지 | 읽기-쓰기 | warehouse의 모든 백그라운드 머지 및 뮤테이션 실행 |
| 쿼리 | 읽기 전용 | ClickStack 서비스 제공 |
**지원 요청 필요**
읽기-쓰기 서비스에서 머지를 비활성화하는 설정은 Cloud console에서 변경할 수 없습니다. 특정 서비스에 적용하려면 [지원팀에 문의](https://clickhouse.com/support/program)하십시오.
이 토폴로지는 수집만으로 서비스가 포화되거나, 두 서비스 모두 쓰기를 수행해야 해서 읽기-쓰기 서비스가 두 개 필요한 경우에 고려할 만합니다. 쿼리 워크로드를 전적으로 ClickStack(읽기만 수행)이 처리한다면, 더 단순한 [읽기-쓰기 및 읽기 전용 분리](#architecture) 구성만으로 요구 사항을 충족할 수 있으며 지원 측면에서도 더 나은 선택입니다.
이 토폴로지를 운영할 때는 다음 사항에 유의하십시오:
* **두 읽기-쓰기 서비스 모두 auto-idling에 의존하지 마십시오.** 머지가 비활성화된 서비스라도 warehouse 내 다른 곳에서 발생한 삽입으로 생성된 파트 다운로드 및 삭제 이벤트를 처리하며, 머지되지 않은 파트 수가 많으면 그 자체만으로도 유휴 상태 전환이 차단될 수 있습니다. 두 읽기-쓰기 서비스가 모두 상시 가동된다고 가정하여 계획하십시오.
* **두 읽기-쓰기 서비스에서는 쿼리를 실행하지 마십시오.** 읽기-쓰기 서비스에서 무거운 `SELECT` 쿼리를 실행하면 머지 작업과 CPU 및 메모리를 두고 경쟁하게 되며, 이는 바로 이 토폴로지가 방지하려는 장애 유형입니다. [위](#point-clickstack)에서 설명한 대로 ClickStack이 읽기 전용 서비스를 바라보도록 설정하십시오.
* **뮤테이션이 있는 경우, 이를 실행하는 서비스에서 추적됩니다.** 관측성 환경에서 뮤테이션은 드뭅니다. ClickStack의 스키마는 [`ttl_only_drop_parts = 1`](/ko/clickstack/managing/ttl)을 설정하므로, 일반적인 보존 정책은 TTL 머지 과정에서 만료된 파트 전체를 삭제하며 행을 뮤테이션으로 제거하지 않습니다. 뮤테이션을 발생시키는 `ALTER`를 수집 서비스에 제출하더라도 해당 작업은 머지 서비스에서 수행되며, 그 진행 상황도 수집 서비스가 아닌 머지 서비스의 [`system.mutations`](/ko/reference/system-tables/mutations)에 나타납니다.
관리 및 DDL
다음을 포함한 모든 스키마 변경은 **읽기-쓰기** 서비스에서 실행해야 합니다:
* 테이블 생성 - 최초 수집 시 ClickStack collector가 자동으로 수행
* 보존 기간 변경을 위한 [TTL 수정](/ko/clickstack/managing/ttl#modifying-ttl)
* 쿼리 가속을 위한 [materialized view](/ko/clickstack/managing/materialized-views) 생성
* [스킵 인덱스, 프로젝션 및 기타 성능 최적화](/ko/clickstack/managing/performance-tuning) 추가
사용자, 역할, 권한 부여는 스키마 변경이 아닙니다. 이들은 warehouse 내 모든 서비스가 공유하므로 어느 서비스에서든 한 번만 생성하면 됩니다. 위의 [설정 단계](#prepare-read-write-service)에서 수집 사용자를 생성합니다. 읽기 전용 서비스에 연결하는 다른 클라이언트는 위에 표시된 수집 권한이 아니라, [ClickStack UI에서 요구하는 권한](/ko/clickstack/managing/production#user-permissions)을 가진 별도의 읽기 전용 쿼리 사용자로 인증해야 합니다.
[SQL 콘솔 또는 clickhouse client](/ko/clickstack/managing/admin)를 사용해 읽기-쓰기 서비스에 연결하십시오. warehouse는 스토리지와 access control을 공유하므로 변경 사항은 읽기 전용 서비스에 즉시 반영됩니다. [머지를 수집과 분리](#separating-merges)했다면 SQL 문을 어느 읽기-쓰기 서비스에든 제출할 수 있지만, 뮤테이션은 머지 서비스에서 실행되고 추적된다는 점에 유의하십시오.
**다른 서비스가 idle 상태일 때 데이터베이스 DDL이 멈출 수 있습니다**
`CREATE`, `RENAME`, `DROP DATABASE` SQL 문은 warehouse 내 idle 상태이거나 중지된 서비스에 의해 차단되어 멈출 수 있습니다. 읽기 전용 서비스는 지연 없이 idle 상태로 전환되므로 이 토폴로지에서는 쉽게 발생할 수 있습니다. 데이터베이스 수준의 SQL 문은 쿼리별 또는 세션 단위로 [`distributed_ddl_task_timeout=0`](/ko/reference/settings/session-settings/distributed-ddl#distributed_ddl_task_timeout)을 설정해 실행하십시오:
```sql theme={null}
CREATE DATABASE otel
SETTINGS distributed_ddl_task_timeout=0
```
수동으로 중지한 서비스는 다시 시작해야 해당 서비스에서 쿼리가 실행됩니다.
materialized view는 삽입에 의해 트리거되므로 읽기-쓰기 서비스에서 실행됩니다. 읽기 전용 서비스는 쿼리 가속을 위해 [ClickStack 소스에 등록된](/ko/clickstack/managing/config#materialized-views-settings) view를 포함하여, 그 target table을 다른 테이블과 동일하게 쿼리합니다.
에이전트형 워크로드 분리
[ClickStack MCP 서버](/ko/clickstack/mcp)를 통해 연결된 AI 어시스턴트도 대시보드와 마찬가지로 읽기 트래픽이지만, 부하 패턴이 다릅니다. 장애를 조사하는 에이전트는 사전에 정해두지 않은 범위에 대해 짧은 시간 안에 수많은 탐색적 쿼리를 실행합니다. 에이전트와 UI가 하나의 읽기 전용 서비스를 공유하면, 이러한 버스트가 같은 장애 상황에서 엔지니어가 보고 있는 대시보드보다 앞서 처리되게 됩니다.
여기에도 동일한 warehouse 패턴이 적용됩니다. 즉, 에이전트에 전용 읽기 전용 컴퓨트를 제공하십시오.
[위 설정](#add-read-only-service)과 동일한 방식으로 warehouse에 읽기 전용 서비스를 하나 더 생성하십시오. 이 서비스는 UI를 담당하는 서비스와 동일한 테이블을 읽으므로 복사할 데이터가 없습니다.
그다음 [ClickStack을 읽기 전용 서비스로 지정하기](#point-clickstack)에서 설명한 것처럼, Cloud Console에서 해당 서비스에 대해 ClickStack을 한 번 실행하십시오. Cloud MCP는 MCP 자체뿐 아니라 ClickStack이 활성화된 서비스도 필요로 합니다. [MCP 사전 요구 사항](/ko/clickstack/mcp#managed-prerequisites)을 참조하십시오.
용량 산정 모델의 대시보드 QPS가 아니라 에이전트에서 예상되는 쿼리 부하에 맞춰 크기를 산정하고, auto-idling은 활성화된 상태로 두십시오. 에이전트형 사용은 일반적으로 간헐적이므로, 조사 작업 사이에 서비스가 유휴 상태로 전환될 수 있습니다.
ClickHouse Cloud 콘솔에서 읽기 전용 서비스를 열고 **Connect**를 클릭한 후 **Connect with MCP**를 선택하여 활성화하십시오. [원격 MCP 서버 활성화](/ko/products/cloud/features/ai-ml/mcp/remote-mcp#enable-remote-mcp-server)를 참조하십시오.
Cloud MCP 엔드포인트는 모든 서비스에서 동일합니다. 요청은 `x-service-id` 헤더에 따라 라우팅되며, 이 헤더가 없으면 계정에서 처음 사용한 ClickStack 서비스로 전달됩니다. 기존 MCP 구성을 복사한 뒤 새 읽기 전용 서비스의 ID를 담은 헤더를 추가하십시오.
```shell theme={null}
claude mcp add --transport http clickstack https://mcp.clickhouse.cloud/clickstack \
--header "x-service-id: "
```
어떤 MCP 클라이언트든 이 헤더를 전달할 수 있습니다. Cursor, VS Code 등에서의 동등한 구성은 [특정 서비스 지정](/ko/clickstack/mcp#managed-service-override)을 참조하십시오.
**MCP는 대상 서비스에 상태를 기록합니다**
MCP 서버는 쿼리 실행뿐 아니라 대시보드, 알림, 저장된 검색도 생성할 수 있으며, 이 상태는 모든 [ClickStack 상태](#point-clickstack)와 마찬가지로 요청이 라우팅된 서비스로 한정됩니다. 에이전트가 에이전트 서비스에서 만든 대시보드는 엔지니어용 서비스에서 실행한 ClickStack UI에 나타나지 않으며, 거기서 생성한 알림은 해당 서비스의 컴퓨트에서 평가됩니다. [아래](#isolating-alerts)에서 설명하듯이, 유휴 상태로 전환된 에이전트 서비스에서는 이러한 평가가 지연되거나 누락됩니다. 지속적으로 유지되어야 하는 산출물을 생성할 것으로 예상되는 에이전트는 팀이 사용하는 서비스와 동일한 서비스로 라우팅하십시오.
알림
ClickStack은 알림이 생성된 서비스에서 해당 알림을 평가하므로, 알림은 UI와 동일한 컴퓨트, 즉 이 토폴로지에서는 읽기 전용 서비스에서 실행됩니다.
**관리형 ClickStack**
알림을 활성화하려면 **Service Admin** 권한을 가진 사용자가 최소 한 번은 ClickStack에 로그인해야 합니다. 이 과정에서 알림 쿼리를 실행하는 전용 데이터베이스 사용자가 프로비저닝되며, 해당 사용자는 warehouse 내 모든 서비스에서 공유됩니다. [관리형 ClickStack에 대한 액세스 부여](/ko/clickstack/deployment/managed#configure-access) 가이드를 참조하십시오.
알림 평가는 주기적으로 반복되는 쿼리 워크로드입니다. 읽기 전용 서비스의 용량을 산정할 때 사용하는 QPS에 이를 포함하십시오. [용량 산정 모델](/ko/clickstack/managing/estimating-resources#refining-sizing-assumptions)에서는 검색, dashboard, 알림 쿼리를 하나의 합산 수치로 취급합니다.
알림 평가 격리
알림 부하는 중앙에서 라우팅할 수 없습니다. 알림은 사용자가 직접 생성하기 때문입니다. ClickStack에서 알림을 추가하면 그 알림은 사용자가 작업 중인 service에 추가되고, 해당 service의 컴퓨트에서 평가됩니다. 특정 service의 알림을 다른 곳으로 옮기는 SETTING은 없습니다.
격리할 수 있는 것은 중앙에서 소유하는 알림, 즉 플랫폼 팀이 organization 전체를 위해 유지 관리하는 알림입니다. 이러한 알림은 보통 가장 자주 평가되는 알림이기도 합니다. 이런 알림에는 warehouse 내에 전용 읽기 전용 service를 할당하고, 그 service에서 실행한 ClickStack에서 알림을 생성하십시오.
| Service | 유형 | 제공 대상 |
| - | - | - |
| Ingest | 읽기-쓰기 | OpenTelemetry collector |
| Query | 읽기 전용 | ClickStack UI 및 사용자가 직접 생성한 알림 |
| Alerting | 읽기 전용 | 플랫폼 팀이 유지 관리하는 공용 알림 |
**알림 service에서 auto-idling 비활성화**
service에 알림이 구성되어 있다고 해서 해당 service가 깨어 있는 상태로 유지되지는 않습니다. idled 상태의 service에서 수행되어야 하는 알림 평가는 깨어나는 시간만큼 지연되거나 아예 실패하므로, auto-idling이 enabled 상태로 남아 있는 알림 service는 평가를 놓칠 수 있습니다. 해당 service에서는 auto-idling을 끄고 항상 켜져 있는 것을 전제로 계획하십시오. 이는 알림이 평가되는 모든 곳에 동일하게 적용됩니다. 즉, UI를 제공하는 service에서 알림이 실행된다면 그 service 역시 유휴 상태로 둘 수 없습니다.
남은 절충 관계는 state가 service 단위로 존재한다는 점에서 비롯됩니다.
* 공용 알림과 이에 딸린 dashboards는 알림 service에만 존재하며, 쿼리 service에서 작업하는 사용자에게는 보이지 않습니다. 알림은 어느 쪽이든 동일한 [대상](/ko/clickstack/features/alerts)으로 전달되므로, 사용자가 잃는 것은 정의에 대한 가시성일 뿐 알림 기능 자체는 아닙니다.
* 알림 service의 sources는 별개의 객체입니다. [기본 OpenTelemetry schema](/ko/clickstack/deployment/managed#adding-data-sources)를 사용하는 source는 자동으로 감지되지만, 사용자 정의 source는 알림이 참조할 수 있도록 해당 service에서도 구성해야 합니다.
단일 알림 집합이 충분히 작아 그 평가 부하가 dashboard 트래픽에 비해 무시할 수 있는 수준이라면, 모든 것을 하나의 읽기 전용 service에 두십시오. 정의를 두 곳에서 유지 관리하는 운영 비용이 둘 중 더 큰 비용입니다.
추가 고려 사항
**Auto-idling.** 유휴 상태로 전환된 읽기 전용 service에 처음 실행되는 쿼리는 service가 시작될 때까지 대기하므로, 간헐적으로 사용한다면 약간의 지연 시간을 감수하는 대신 비용을 절감할 수 있습니다. 유휴 상태 전환을 막는 수단으로 알림에 의존하지 마십시오. [위](#isolating-alerts)에서 설명한 것처럼, 알림 평가에 사용하는 service에서는 auto-idling을 비활성화하십시오. 지속적인 수집은 읽기-쓰기 service를 깨어 있는 상태로 유지하지만, 수집이 간헐적이거나 일정에 따라 실행된다면 유휴 기간 이후의 첫 배치도 마찬가지로 대기하게 되며, 이는 telemetry 지연으로 나타납니다.
**백업.** 백업은 기본 서비스에서만 수행되며, warehouse 전체의 데이터를 포함합니다. 백업을 복원하면 기존 warehouse와 연결되지 않은 완전히 새로운 service가 생성됩니다.
**Replica limits.** warehouse 내 모든 service의 레플리카 수 합계에는 기본적으로 상한이 적용됩니다. [usage limits](/ko/products/cloud/guides/best-practices/usagelimits)를 참조하십시오.
**ClickStack을 다른 워크로드와 격리하기.** 실시간 애플리케이션 analytics처럼 이미 다른 워크로드가 실행 중인 service에 ClickStack을 추가하는 경우에도, 동일한 warehouse 기능을 사용해 관측성에 전용 컴퓨트를 할당할 수 있습니다. [관측성 워크로드 격리](/ko/clickstack/managing/estimating-resources#isolating-workloads) 가이드를 참조하십시오.
warehouse의 전체 동작 방식과 제한 사항은 [Warehouses](/ko/products/cloud/features/infrastructure/warehouses) 가이드를 참조하십시오.