Skip to main content

​
FAQ

​
온보딩 및 프로비저닝

문의 양식을 통해 ClickHouse에 문의하면 ClickHouse 팀에서 조직에 BYOC를 활성화합니다. 그런 다음 전용 클라우드 계정(AWS 계정, GCP 프로젝트 또는 Azure subscription)을 준비하고 표준 온보딩 가이드를 따르십시오. BYOC 전용 계정, 프로젝트 또는 subscription을 사용하는 것을 강력히 권장합니다.
전체 과정은 약 45~90분이 소요됩니다. 이처럼 범위가 넓은 이유는 대부분의 시간이 클라우드 제공업체에서 리소스(Kubernetes 클러스터, 로드 밸런서, 네트워크 구성 요소)를 프로비저닝하는 데 걸리기 때문입니다. 이 작업의 소요 시간은 실행할 때마다 다르며 ClickHouse가 제어할 수 없습니다. 프로비저닝이 중단되는 가장 일반적인 원인은 계정 측에 있습니다.
  • 적용하기 전에 CloudFormation template 또는 Terraform 모듈을 수정한 경우입니다. 예를 들어 PermissionsBoundary를 추가하거나 명명 규칙을 충족하기 위해 IAM 역할 이름을 변경한 경우입니다(AWS에서는 ClickHouse가 다른 이름을 명시적으로 승인하지 않는 한 기본 이름인 ClickHouseManagementRole을 유지하십시오). 제공된 아티팩트를 그대로 적용하십시오. 지원되는 사용자 지정은 매개변수로 제공되며, 그 밖의 변경 사항은 사전에 ClickHouse의 승인을 받아야 합니다.
  • 역할 수임 또는 IAM 바인딩을 차단하는 조직 수준 정책(AWS SCP, iam.allowedPolicyMemberDomains 등의 GCP 조직 정책 또는 역할 할당을 제한하는 Azure 정책)입니다.
  • 온보딩 역할의 external ID가 일치하지 않는 경우입니다(아래 external ID 관련 질문 참조).
  • 계정 할당량 제한(예: AWS의 Elastic IP 또는 VPC)입니다.
프로비저닝은 자동으로 재시도되며 근본 원인이 해결되면 자동으로 복구됩니다. 인프라가 몇 시간 이상 계속 중단된 상태라면 지원팀에 문의하십시오.
ClickHouse Cloud 콘솔은 온보딩을 시작할 때 AWS 계정용 external ID를 생성하고 CloudFormation 링크의 ExternalID 매개변수에 미리 채웁니다. Terraform을 사용하는 경우 동일한 값을 external_id로 전달하십시오. 동일한 AWS 계정의 모든 BYOC 인프라는 동일한 external ID를 공유합니다. 임의의 값을 선택하지 마십시오. 이 값은 ClickHouse 자동화가 예상하는 값과 일치해야 합니다. 그렇지 않으면 교차 계정 역할을 수임할 수 없어 프로비저닝이 실패합니다. 자세한 내용은 AWS external ID를 참조하십시오.
external ID가 도입되기 전에 온보딩된 BYOC 인프라는 이전 버전과의 호환성을 위해 자리 표시자 값 emptyid를 사용합니다. 기존 레거시 배포가 있는 AWS 계정에 새 인프라를 추가하면 콘솔은 계정의 모든 인프라가 일관된 신뢰 구성을 유지하도록 이 자리 표시자를 재사용합니다. 고유한 external ID로 전환하려면 ClickHouse 지원팀에 문의하십시오.
AWS 및 GCP에서는 BYOC 인프라와 동일한 계정 또는 프로젝트에 있는 기존 VPC에 배포할 수 있습니다. AWS 및 GCP 사용자 지정 가이드를 참조하십시오. GCP에서는 별도의 호스트 프로젝트에 있는 Shared VPC도 지원합니다. onboarding module은 호스트 프로젝트와 서브넷을 직접 지정할 수 있도록 지원합니다. 설정 및 사전 요구 사항은 해당 모듈의 “Shared VPC” 섹션을 참조하십시오. Azure에서 자체 VNet을 사용하는 기능은 곧 제공될 예정입니다.AWS에서는 다른 계정에서 공유된 서브넷(AWS RAM)을 지원하지 않습니다. 대신 VPC peering 또는 PrivateLink를 통해 기존 네트워크에 연결된 전용 계정을 사용하십시오. 고객 관리형 VPC에서는 기본적으로 프라이빗 로드 밸런서만 활성화됩니다(구성 참조).
아니요. Kubernetes 클러스터(EKS, GKE 또는 AKS)는 ClickHouse가 생성하고 완전히 관리합니다. 이는 ClickHouse가 플랫폼을 안정적으로 운영하고 최신 상태로 유지하기 위해 필요합니다.
클라우드 계정에서는 가능하지만, 함께 배치된 리소스는 항상 어느 정도 ClickHouse의 권한 범위에 속합니다. AWS에서는 대부분의 쓰기 권한이 태그 및 prefix 범위로 제한되며(ClickHouse가 프로비저닝한 리소스에는 clickhouse-byoc=true가 지정됨), 일부 EC2 작업은 태그 범위로 제한할 수 없습니다. GCP 및 Azure에서는 온보딩 ID에 프로젝트 또는 subscription 범위의 권한이 부여됩니다. 리소스를 ClickHouse가 프로비저닝한 리소스와 분리하고, 모든 cloud에서 전용 account, 프로젝트 또는 subscription을 사용하는 것을 권장합니다. 이는 여전히 강력히 권장되는 방식입니다.Kubernetes 클러스터에서는 몇 가지 제약 조건을 준수하면 가능합니다. taint 및 toleration을 적용한 자체 노드 그룹을 사용하고, ClickHouse가 관리하는 네임스페이스를 피하며, ClickHouse 구성 요소의 리컨실리에이션을 차단할 수 있는 cluster-wide admission controller 또는 policy engine을 설치하지 마십시오. 충돌이 없는지 확인할 수 있도록 지원팀에 계획을 설명하십시오.

​
컴퓨트 및 스케일링

예. 인프라(Kubernetes 클러스터 포함)는 클라우드 계정/프로젝트/구독 및 리전 조합별로 한 번만 프로비저닝하면 되며, 해당 리전에서 생성하는 모든 서비스가 이를 공유합니다.
지원 리전 문서에 나열된 모든 퍼블릭 리전에서 BYOC를 배포할 수 있습니다. BYOC는 3개의 가용 영역에 걸쳐 프로비저닝되므로, 가용 영역이 3개 미만인 리전과 AWS Local Zones는 지원되지 않습니다. 필요한 리전이 목록에 없으면 ClickHouse 담당자에게 문의하여 사용 가능 여부를 논의하십시오.
ClickHouse 인스턴스 자체(ClickHouse 서버 및 ClickHouse Keeper) 외에도 clickhouse-operator, 클러스터 오토스케일러, Istio, 모니터링 스택 등의 지원 서비스를 실행합니다.이러한 공유 구성 요소의 리소스 사용량은 비교적 안정적이며 ClickHouse 서비스의 수나 크기에 비례해 증가하지 않습니다. 대략적인 기준으로, 이러한 워크로드를 위한 전용 시스템 노드 그룹에는 총 약 48 vCPU와 192GB의 메모리가 필요하며, AWS에서는 약 6개의 2xlarge 인스턴스에 해당합니다. 또한 각 웨어하우스에서는 해당 웨어하우스의 모든 서비스가 공유하는 전용 3노드 ClickHouse Keeper 앙상블을 실행합니다. 자세한 내용은 비용 모델을 참조하십시오.
서비스 수준의 수직 자동 스케일링은 로드맵에 포함되어 있습니다. 현재는 콘솔을 통한 수동 수직 및 수평 스케일링, 예측 가능한 부하 패턴을 위한 예약 스케일링, 간헐적인 워크로드를 위한 자동 유휴 전환 및 재시작, 인프라 수준의 자동 노드 그룹 스케일링을 사용할 수 있습니다. 노드를 직접 관리할 필요는 없습니다. ClickHouse Keeper는 ClickHouse에서 모니터링하고 스케일링합니다.
BYOC는 임의의 인스턴스 유형이 아닌 선별된 노드 그룹에서 실행됩니다. 워크로드 노드 그룹(ClickHouse 서버 및 Keeper)은 기본적으로 ARM 기반 메모리 최적화 인스턴스(AWS의 Graviton)에서 실행되며, 시스템 노드 그룹은 일반적으로 x86 인스턴스를 사용합니다. 다른 인스턴스 패밀리, CPU 대 메모리 비율 또는 아키텍처는 지원을 통해 요청 시 프로비저닝할 수 있으며, 스팟 인스턴스는 지원되지 않습니다. 구성을 참조하십시오.
각 레플리카는 자체 노드에서 하나의 pod로 실행됩니다. 노드 크기는 레플리카 크기에 맞춰지며, 노드는 필요에 따라 프로비저닝되고 여러 레플리카가 하나의 노드에 함께 배치되는 일은 없습니다. 따라서 매우 작은 레플리카는 비효율적입니다. 하드웨어 리소스 중 오버헤드가 차지하는 비중이 커지고, 네트워크 및 디스크 대역폭은 인스턴스 크기에 따라 달라집니다. 콘솔에서 제공하는 크기보다 작은 크기는 지원을 통해 사용자 지정으로 요청할 수 있습니다.
예. BYOC에서는 웨어하우스(컴퓨트-컴퓨트 분리)를 지원합니다. 여러 서비스가 동일한 데이터를 공유하므로 일부 서비스는 수집에, 다른 서비스는 쿼리에 전용으로 할당할 수 있습니다.

​
네트워크 및 보안

AWS와 GCP에서는 처음부터 권한 부여 범위를 줄일 수 있습니다. 온보딩 아티팩트는 매개변수화되어 있으므로 자체 VPC를 사용할 때 VPC 네트워크 토폴로지 관리 권한을 제외할 수 있습니다(CloudFormation의 IncludeVPCWritePermissions, Terraform 모듈의 include_vpc_write_permissions). GCP에서는 이 설정으로 토폴로지 관리 권한만 제한됩니다. ClickHouse는 Private Service Connect NAT 서브넷, 서비스 연결, 수신 주소 등 VPC 내에서 소유한 네트워킹 리소스에 대한 쓰기 액세스는 유지합니다. AWS에서는 지원팀을 통해 활성화되는 비공개 프리뷰에서 IAM 역할을 직접 관리할 수도 있으며(IncludeIAMWritePermissions=false, 고객 관리형 IAM 역할 참조), 교차 계정 역할은 혼동된 대리인(confused deputy) 액세스를 방지하기 위해 외부 ID로 보호됩니다. Azure에서는 현재 온보딩 모듈이 범위 지정 매개변수 없이 subscription 범위의 고정 역할을 부여합니다. 모든 클라우드에서 일부 권한은 특정 기능에만 필요하므로 해당 기능을 사용하지 않을 예정이라면 제거할 수 있습니다. 아티팩트에서 제공하는 범위보다 더 권한을 제한해야 한다면 지원팀에 문의하십시오.프로비저닝 후 관리 아이덴티티의 권한을 임의로 제거하지 마십시오. ClickHouse는 인프라를 지속적으로 조정하므로 권한이 누락되면 프로비저닝, 업그레이드 및 지원에 문제가 발생합니다. 부여된 권한을 변경하거나 완전히 오프보딩하려면 지원팀과 협의하십시오(아래의 서비스 해제 관련 질문 참조).
권한 참고 자료에서는 AWS, GCP, Azure의 모든 역할과 아이덴티티 및 그 용도를 개괄적으로 설명합니다. 온보딩(부트스트랩) 아이덴티티의 정확한 정책 범위는 게시된 아티팩트인 CloudFormation template 및 Terraform modules로 정의되며, 보안 팀에서 직접 감사할 수 있습니다. 온보딩 후 ClickHouse가 생성하는 추가 아이덴티티(컨트롤러 역할, 서비스 계정, 관리형 아이덴티티)는 권한 참고 자료에 공급자별로 설명되어 있습니다. 이러한 아이덴티티는 계정 내에 있으므로 클라우드 콘솔에서 실제 정책을 검사하고 CloudTrail 또는 GCP/Azure의 해당 서비스에서 생성 및 사용 내역을 확인할 수 있습니다. AWS에서는 관리 역할의 대부분의 쓰기 권한이 clickhouse-cloud-* 등의 리소스 태그와 이름 접두사로 범위가 지정되므로 일반적으로 생성하지 않은 리소스를 수정할 수 없습니다(일부 EC2 작업은 태그로 범위를 지정할 수 없음). 또한 데이터 버킷에 대한 객체 수준 액세스 권한이 없습니다. 객체 액세스는 ClickHouse 워크로드로 범위가 지정된 클러스터 내 아이덴티티로 제한됩니다. GCP와 Azure에서는 온보딩 아이덴티티가 대신 프로젝트 또는 subscription 범위의 권한을 보유합니다. 전용 프로젝트 또는 subscription을 강력히 권장하는 이유 중 하나입니다. 읽기 권한은 지속적인 조정에 필요하므로 더 넓은 범위를 가집니다.
기본적으로 데이터에 대한 액세스 권한은 없습니다. 문제 해결을 위해 엔지니어는 내부 적시 에스컬레이션 절차를 거쳐야 합니다. 액세스는 시간 제한 및 인증서 기반이며, system.* 테이블(고객 데이터 테이블 제외)로 제한됩니다. 또한 모든 액세스는 기록되고 보안 팀의 감사를 받습니다. ClickHouse 엔지니어가 실행한 모든 쿼리는 자체 system.query_log에서 확인할 수 있습니다. 인프라 진단을 위해 동일한 승인 기반 에스컬레이션을 통해 Tailscale로 Kubernetes API server 및 클러스터 내 모니터링 스택에 대한 시간 제한 액세스를 부여할 수도 있습니다. 데이터 액세스 모델은 ClickHouse data access를, 연결 모델은 네트워크 보안을 참조하십시오.
예. 고객이 엔지니어의 클러스터 액세스를 승인할 수 있는 고객 제어 메커니즘을 구현하는 방안이 로드맵에 있습니다. 현재 엔지니어는 클러스터에 대한 적시 액세스 권한을 얻으려면 내부 에스컬레이션 절차를 거쳐야 합니다. 이 과정은 기록되고 보안 팀의 감사를 받습니다.
서비스 및 백업 상태 이벤트, 청구용 사용량 메트릭, 알림 알림 등 운영 메타데이터만 전송됩니다. 데이터, 백업, 로그 및 모니터링 데이터는 계정 내에 유지됩니다. 전체 아웃바운드 흐름 목록은 네트워크 보안을 참조하십시오.
기본적으로 Kubernetes API 엔드포인트는 공개되어 있지만 ClickHouse의 NAT IP 주소로만 접근이 제한됩니다. 이 기본 설정을 사용하는 동안에는 컨트롤 플레인이 클러스터를 관리하는 데 필요하므로 ClickHouse 허용 목록 항목을 제거하지 마십시오. ClickHouse 팀과 협의하여 엔드포인트를 비공개 전용 접근으로 전환할 수도 있습니다. Tailscale(아웃바운드 전용이며 문제 해결 접근에도 사용됨) 또는 AWS에서는 VPC Lattice(비공개 프리뷰)를 사용할 수 있습니다. 자세한 내용은 구성을 참조하십시오. 이는 Kubernetes API에만 적용됩니다. 클라우드 제공업체 API 호출(예: AWS의 EKS 및 EC2)은 교차 계정 역할 수임을 통해 ClickHouse Cloud 네트워크에서 시작되며, Tailscale을 통해 라우팅할 수 없습니다. 자세한 내용은 클라우드 제공업체 API와 Kubernetes API 비교를 참조하십시오.
AWS에서는 Customer BYOC VPC와 S3 간의 테이블 데이터, 백업 및 로그 트래픽이 AWS S3 API를 통해 HTTPS(포트 443)를 사용합니다. 이 트래픽은 S3 gateway VPC endpoint를 통해 전송되므로 AWS 네트워크 내에 유지되고, 공용 인터넷을 거치지 않으며 NAT gateway 요금도 발생하지 않습니다. GCP에서도 Google API 접근에 Private Google Access를 사용합니다. Azure에서는 데이터가 구독 내 Azure Blob Storage 계정에 저장됩니다.
아니요. 테이블 데이터 blob은 테이블별 경로가 없는 공유 레이아웃에 저장되므로 객체를 특정 테이블에 연결할 수 없으며, 직접 수정하면 서비스가 손상될 위험이 있습니다. 버킷 콘텐츠를 직접 수정하지 마십시오. 문제가 의심되면 지원 티켓을 제출하십시오.
클라이언트 연결은 TLS 포트에서 로드 밸런서로 종료됩니다. 8443(HTTPS 인터페이스) 및 9440(TLS를 통한 네이티브 프로토콜)이 사용되며, 포트 443도 HTTPS 인터페이스로 라우팅됩니다. MySQL 인터페이스(포트 3306)는 현재 BYOC에서 노출되지 않으며 로드맵에 포함되어 있습니다(개요 참조).네트워크 내부에서 클러스터 내 통신은 포트 9000의 네이티브 프로토콜, 포트 8123의 HTTP, 복제 및 분산 쿼리를 위한 포트 9009의 서버 간 통신을 사용합니다. 이러한 내부 포트와 ClickHouse Keeper 포트는 어떤 로드 밸런서에도 노출되지 않습니다.
ClickHouse 관리형 VPC에서는 각 서비스에 기본적으로 IP 접근 목록으로 보호되는 퍼블릭 로드 밸런서가 제공됩니다. 네트워크 및 피어링된 네트워크에서 접근할 수 있는 프라이빗 로드 밸런서는 ClickHouse Cloud 콘솔에서 추가로 활성화할 수 있습니다(Load Balancers 참조). 고객 관리형 VPC에서는 기본값이 반대이며 프라이빗 로드 밸런서만 활성화됩니다. IP 필터링은 인그레스 프록시 계층에서 적용되므로 스캔 시 로드 밸런서 포트가 열려 있는 것처럼 보일 수 있지만, 목록에 없는 소스의 연결은 거부됩니다. 더 이상 이에 의존하는 항목이 없으면 퍼블릭 엔드포인트를 완전히 비활성화할 수 있습니다. 콘솔의 Connection via 선택기에는 서비스에 활성화된 각 연결 경로의 엔드포인트가 표시됩니다. 자세한 내용은 연결을 참조하십시오.
현재는 지원하지 않습니다. 서비스 엔드포인트는 ClickHouse 관리형 인증서와 함께 clickhouse-byoc.com 도메인 아래에 프로비저닝됩니다.
공개된 단일 엔드포인트 목록은 없습니다. 클러스터에는 클라우드 제공업체 API에 대한 프라이빗 액세스뿐 아니라 작동하는 아웃바운드 인터넷 액세스(직접 또는 NAT를 통해)도 필요합니다. 네트워크 연결 요구 사항을 참조하십시오. 네트워크 정책상 명시적인 목록이 필요하다면 지원팀에 문의하여 설정을 검토하십시오.
EBS CSI 드라이버, 노드 구성 작업, Prometheus node exporter(/proc 및 /sys를 읽음) 등 일부 플랫폼 구성 요소에는 정당하게 상승된 권한이나 호스트 파일 시스템 액세스가 필요합니다. 스캐너에서 항목을 발견하면 지원팀에 공유하십시오. 각 항목이 의도된 설계인지 조치가 필요한지 확인해 드립니다.
현재 BYOC에서는 지원하지 않습니다. 저장된 데이터는 클라우드 제공업체 관리형 키로 암호화됩니다. 현재 계획된 기능 목록은 개요를 참조하십시오.

​
업그레이드 및 유지 관리

업그레이드는 ClickHouse Cloud와 동일한 방식으로 진행됩니다. 서비스는 릴리스 채널(빠름, 일반, 느림)에 등록되며, 예약된 유지 관리 기간을 따릅니다. 설정하려면 지원팀에 문의하십시오. 업데이트는 최소 주 1회 일정으로 진행됩니다. 업그레이드는 레플리카별로 순차적으로(make-before-break) 진행되므로 서비스 전체의 다운타임은 발생하지 않습니다. 운영을 참조하십시오.
ClickHouse가 제공업체의 지원 종료일 전에 Kubernetes 업그레이드를 선제적으로 수행하고, 지원팀을 통해 유지 관리 기간을 조율합니다. 제어 플레인 업그레이드는 사용자에게 영향을 주지 않습니다. 노드 그룹 업그레이드는 make-before-break 방식으로 노드를 하나씩 순차적으로 진행되므로, 파드 재시작 시 짧은 연결 재설정이 발생할 수 있지만 데이터 손실은 없습니다. 운영을 참조하십시오.

​
백업 및 재해 복구

백업은 자체 클라우드 계정의 객체 스토리지에 저장되며, 환경 외부로 반출되지 않습니다. 백업 일정과 보존 기간은 구성할 수 있으며, 조정하려면 지원팀에 문의하십시오.
사용자가 생성한 모든 데이터베이스, 테이블, 객체와 액세스 엔터티(사용자, 역할, 설정 프로필, 행 정책, 쿼터), 사용자 정의 함수가 포함됩니다. system.query_log와 같은 시스템 로그 테이블은 포함되지 않습니다.
백업은 체인을 이룹니다. 즉, 전체 백업 뒤에 이에 종속된 증분 백업이 이어집니다. 체인에 속한 증분 백업을 복원하려면 기본 전체 백업이 필요하므로, 종속된 모든 증분 백업의 보존 기간이 만료될 때까지 기본 전체 백업이 보존 및 저장됩니다.
방법은 두 가지입니다. ClickHouse Cloud API의 백업 엔드포인트를 사용하거나 클러스터 내 모니터링 스택에서 노출하는 백업 메트릭(시작, 완료, 실패 카운터)을 사용할 수 있습니다. 자체 모니터링 환경에서 실패 알림을 설정하는 것이 좋습니다. 관측성을 참조하십시오.
BYOC는 3개의 가용 영역에 걸쳐 배포되며, 객체 스토리지가 쓰기를 확인한 후에만 쓰기가 승인됩니다. 현재 리전 간 복제는 제공되지 않으므로 리전 재해 복구는 백업을 기반으로 하며, 달성 가능한 RPO는 백업 빈도에 따라 제한됩니다. 다른 리전의 버킷에 백업하는 것을 포함해 목표에 맞게 백업 빈도와 대상을 구성할 수 있습니다. 이를 설정하려면 지원팀에 문의하십시오.

​
관측성

모니터링 스택(Prometheus, Grafana, AlertManager)은 계정 내에서 실행되며, 프라이빗 연결을 통해 직접 사용할 수 있습니다. PromQL API를 통해 쿼리하거나 자체 Prometheus로 페더레이션하거나, 서비스별 ClickHouse /metrics_all 엔드포인트를 스크레이프할 수 있습니다. 현재 Datadog과 같은 타사 플랫폼용 기본 통합은 제공되지 않습니다. 해당 플랫폼의 Prometheus 호환 수집 기능을 통해 통합하십시오. 엔드포인트와 설정은 관측성을 참조하십시오.

​
비용

청구서는 두 건으로 나뉩니다. ClickHouse Cloud는 서비스에 할당된 메모리를 기준으로 요금을 청구하고, 클라우드 제공업체는 기본 인프라 비용을 별도의 가산 없이 원가로 직접 청구합니다. 현재 상세 비용 참고 페이지는 AWS만 다룹니다. 비용 모델, 청구 대상 AWS 서비스, AWS 서비스 한도를 참조하십시오.

​
가용성 및 수명 주기

AWS, GCP, Azure는 모두 일반 제공됩니다. 각 클라우드에서 지원되는 기능과 리전은 개요를 참조하십시오.
ClickHouse 콘솔에서 서비스와 BYOC 인프라를 종료하십시오. 클라우드 제공업체 콘솔에서 리소스를 삭제하거나 권한을 취소하는 작업부터 시작하면 안 됩니다. 이렇게 하면 진행 중인 컨트롤 플레인 연결이 끊어져 수동으로 정리해야 합니다. 콘솔을 통한 종료가 완료되면 온보딩 스택(CloudFormation 스택 또는 Terraform 모듈)과 남아 있는 모든 리소스를 제거하십시오. AWS에서는 ClickHouse가 생성한 모든 리소스에 clickhouse-byoc=true 태그가 지정되므로, 이후 이를 나열하여 남은 항목이 없는지 확인할 수 있습니다. GCP와 Azure에서는 온보딩한 전용 프로젝트 또는 subscription이 검토할 범위를 한정합니다.

​
업타임 SLA

아니요. 데이터 플레인은 고객의 클라우드 환경에서 호스팅되므로 서비스 가용성은 ClickHouse가 통제할 수 없는 리소스에 따라 달라집니다. 따라서 ClickHouse는 BYOC 배포에 대해 공식적인 업타임 SLA를 제공하지 않습니다. 실행 중인 서비스는 ClickHouse 컨트롤 플레인과 독립적으로 작동합니다. 즉, 컨트롤 플레인 장애가 발생해도 계정에서 실행 중인 서비스는 중단되지 않습니다. 추가로 궁금한 사항이 있으면 support@clickhouse.com으로 문의하십시오.
마지막 수정일 2026년 8월 14일