읽기 및 쓰기 워크로드 격리

​

읽기와 쓰기를 분리해야 하는 이유

• 쓰기가 읽기 성능을 떨어뜨리지 않습니다. 지속적인 OpenTelemetry 수집(삽입 작업 자체와 그 뒤를 잇는 백그라운드 머지)은 대시보드 및 검색 쿼리와 CPU 및 메모리를 두고 경쟁합니다. 수집이 실행되는 동안 읽기 지연 시간이 눈에 띄게 나빠졌다가 수집이 멈추면 회복될 수 있습니다.
• 읽기가 쓰기를 방해하지 않습니다. 경합은 양방향으로 발생합니다. 무거운 애드혹 쿼리나 비용이 큰 대시보드 렌더링은 service의 메모리를 소진시켜 삽입을 단순히 느리게 만드는 정도가 아니라 아예 실패시킬 수 있습니다.
• 읽기 전용 컴퓨트는 전적으로 쿼리에만 사용됩니다. 읽기 전용 service는 system tables를 제외하면 백그라운드 머지를 수행하지 않습니다. 또한 머지 때문에 깨어 있는 상태가 유지될 수 있는 읽기-쓰기 service와 달리, 지연 없이 유휴 상태로 전환됩니다.
• 양쪽 용량을 각각 산정합니다. 용량 산정 모델은 수집 컴퓨트와 쿼리 컴퓨트를 별도로 추정하며, warehouse를 사용하면 각각을 독립적인 service로 프로비저닝할 수 있습니다. 모델의 1 QPS 기준선을 넘어서면 쿼리 컴퓨트가 대부분을 차지합니다. 5 QPS를 가정한 실제 예시에서는 수집에 58 vCPU, 쿼리에 290 vCPU가 산출되므로, 작은 쓰기 service가 훨씬 큰 읽기 service에 데이터를 공급하는 구성이 가능합니다.
• 유휴 상태 전환과 자동 스케일링은 service별로 설정합니다. 각 service는 자체 레플리카 수, 자동 스케일링 및 자동 유휴 상태 전환 설정을 가지므로, 쓰기 service는 지속적인 수집을 위해 항상 켜 두고 읽기 service는 업무 시간 외에 유휴 상태로 전환되도록 할 수 있습니다.
• 스토리지는 중복되지 않습니다. warehouse 내의 service들은 동일한 객체 스토리지 폴더와 동일한 테이블을 공유하며, 스토리지 요금은 한 번만 청구됩니다.
• 엔드포인트별로 액세스를 제한할 수 있습니다. IP 액세스 목록은 service별로 적용되므로, 쓰기 엔드포인트는 collector에서만, 읽기 엔드포인트는 ClickStack 배포에서만 연결할 수 있도록 제한할 수 있습니다. 네트워크 액세스 제어 가이드를 참조하십시오.

​

아키텍처

• warehouse의 첫 번째 서비스는 항상 읽기-쓰기이며, 서비스 유형은 생성 시점에 고정됩니다. 읽기 전용과 읽기-쓰기를 전환하려면 warehouse에 새 서비스를 생성하십시오.
• warehouse 내 모든 서비스는 동일한 클라우드 제공업체, 리전, ClickHouse 버전 및 Keeper를 공유하며, 기본 서비스의 upgrade schedule을 따릅니다.
• 수집에는 읽기-쓰기 서비스를 하나만 사용하십시오. 머지는 스토리지를 공유하는 모든 읽기-쓰기 서비스에 분배되므로, 한 서비스에서 발생한 삽입에 대한 머지가 다른 서비스에서 실행될 수 있습니다. 그 다른 서비스가 부하가 큰 쿼리까지 처리하고 있다면, 해당 쿼리와 머지가 같은 서비스의 CPU 및 메모리를 두고 경합하게 되어 첫 번째 서비스의 삽입에 대한 머지가 느려지고, 결과적으로 삽입 performance도 함께 저하됩니다. 쿼리 워크로드는 읽기 전용 서비스에서 처리하고, 머지를 수집과 분리해야 하는 경우에만 두 번째 읽기-쓰기 서비스를 추가하십시오.

​

격리된 배포 환경 설정하기

CREATE DATABASE otel;
CREATE USER hyperdx_ingest IDENTIFIED WITH sha256_password BY '<strong-password>';
GRANT SELECT, INSERT, CREATE DATABASE, CREATE TABLE, CREATE VIEW ON otel.* TO hyperdx_ingest;

CLICKHOUSE_ENDPOINT=https://<read-write-service>.clickhouse.cloud:8443
CLICKHOUSE_USER=hyperdx_ingest
CLICKHOUSE_PASSWORD=<strong-password>
HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE=otel

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;

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;

​

머지와 수집 분리

• 두 읽기-쓰기 서비스 모두 auto-idling에 의존하지 마십시오. 머지가 비활성화된 서비스라도 warehouse 내 다른 곳에서 발생한 삽입으로 생성된 파트 다운로드 및 삭제 이벤트를 처리하며, 머지되지 않은 파트 수가 많으면 그 자체만으로도 유휴 상태 전환이 차단될 수 있습니다. 두 읽기-쓰기 서비스가 모두 상시 가동된다고 가정하여 계획하십시오.
• 두 읽기-쓰기 서비스에서는 쿼리를 실행하지 마십시오. 읽기-쓰기 서비스에서 무거운 SELECT 쿼리를 실행하면 머지 작업과 CPU 및 메모리를 두고 경쟁하게 되며, 이는 바로 이 토폴로지가 방지하려는 장애 유형입니다. 위에서 설명한 대로 ClickStack이 읽기 전용 서비스를 바라보도록 설정하십시오.
• 뮤테이션이 있는 경우, 이를 실행하는 서비스에서 추적됩니다. 관측성 환경에서 뮤테이션은 드뭅니다. ClickStack의 스키마는 ttl_only_drop_parts = 1을 설정하므로, 일반적인 보존 정책은 TTL 머지 과정에서 만료된 파트 전체를 삭제하며 행을 뮤테이션으로 제거하지 않습니다. 뮤테이션을 발생시키는 ALTER를 수집 서비스에 제출하더라도 해당 작업은 머지 서비스에서 수행되며, 그 진행 상황도 수집 서비스가 아닌 머지 서비스의 system.mutations에 나타납니다.

​

관리 및 DDL

• 테이블 생성 - 최초 수집 시 ClickStack collector가 자동으로 수행
• 보존 기간 변경을 위한 TTL 수정
• 쿼리 가속을 위한 materialized view 생성
• 스킵 인덱스, 프로젝션 및 기타 성능 최적화 추가

CREATE DATABASE otel
SETTINGS distributed_ddl_task_timeout=0

​

에이전트형 워크로드 분리

claude mcp add --transport http clickstack https://mcp.clickhouse.cloud/clickstack \
  --header "x-service-id: <read-only-agent-service-id>"

​

알림

​

알림 평가 격리

• 공용 알림과 이에 딸린 dashboards는 알림 service에만 존재하며, 쿼리 service에서 작업하는 사용자에게는 보이지 않습니다. 알림은 어느 쪽이든 동일한 대상으로 전달되므로, 사용자가 잃는 것은 정의에 대한 가시성일 뿐 알림 기능 자체는 아닙니다.
• 알림 service의 sources는 별개의 객체입니다. 기본 OpenTelemetry schema를 사용하는 source는 자동으로 감지되지만, 사용자 정의 source는 알림이 참조할 수 있도록 해당 service에서도 구성해야 합니다.

​

추가 고려 사항