관리형 모드의 동작 방식
실행기는 스크레이퍼, troubleshooter와 동일한clicklink 바이너리에 포함된 데몬입니다. 엔드포인트로 향하는 아웃바운드 WebSocket 채널을 유지하면서 ClickHouse Cloud로부터 수명 주기 명령어를 수신합니다. 실행기는 자신이 구성된 단일 Kubernetes 클러스터에 각 명령어를 적용하고, 해당 채널을 통해 결과를 보고합니다. 다른 구성 요소와 마찬가지로 아웃바운드 연결만 생성합니다. 즉, ClickHouse Cloud가 사용자 클러스터로 접속하는 일은 없으며, 실행기의 로컬 API는 루프백에 바인딩됩니다.
관리형 모드는 비공개 프리뷰 기간 동안 S3 storage를 사용하는 Amazon EKS에서 제공됩니다. 환경을 등록할 때 계정 담당 팀이 이를 활성화합니다. init은 EKS 클러스터를 가리키지 않는 kube context를 거부합니다.
각 서비스에는 사용자가 소유한 세 가지 cloud resources가 필요합니다. 데이터 버킷, 백업 버킷, 그리고 ClickHouse 파드가 이들에 접근하기 위해 assume하는 IAM role입니다. 이들은 서비스가 생성되기 전에 사용자의 자격 증명으로 직접 생성하고, 서비스가 제거된 후에 삭제합니다. 실행기는 사용자의 버킷이나 IAM에 대한 자격 증명을 보유하지 않으며, 데이터를 삭제하지도 않습니다. 실행기의 클라우드 호출은 Amazon ECR과 STS로만 향합니다. 플랫폼 동기화나 생성 작업이 차트를 가져올 때 registry에 로그인하며, 플랫폼 업데이트 중에는 읽기 전용 pull role로 이미지를 확인합니다. S3나 IAM 호출은 수행하지 않습니다. 각 서비스에 대해 LoadBalancer 타입의 Kubernetes Service를 생성하며, 이는 클러스터의 load-balancer controller에 의해 사용자 계정 내 내부 NLB로 구현됩니다.
VM에서 실행기는 나머지 두 구성 요소와 함께 clicklink-executor systemd unit으로 실행됩니다. Kubernetes에서는 커넥터 네임스페이스 내 단일 레플리카 배포로 동작합니다. 포트 8086으로 상태 확인과 메트릭을 제공하고, 127.0.0.1:9999로 로컬 API를 제공합니다.
관리형 모드 활성화
관리형 모드는 등록할 때 선택합니다.clicklink clctl init에 --managed를 전달하거나, 터미널에 표시되는 프롬프트에 응답하십시오. VM에서 init은 해당 호스트의 kubeconfig에서 클러스터를 가져오며(EKS cluster가 두 개 이상 있는 경우 --cluster-name으로 지정), 실행기에 클러스터 전역 액세스 권한을 인라인으로 부여합니다. Kubernetes에서는 커넥터 엔드포인트의 CIDR을 --egress-cidrs로 전달하여 차트가 기본 거부(default-deny) NetworkPolicy를 활성화된 상태로 배치하도록 하십시오.
설치 과정 자체는 달라지지 않습니다. 전체 흐름은 온보딩을, 플래그는 CLI 참고를 확인하십시오.
서비스 생성
엔드포인트를 통한 서비스 생성은 환경별로 활성화되므로, 시작하기 전에 계정 담당 팀에 문의하십시오. 서비스를 생성하려면 두 개의 명령어가 필요합니다.prepare는 사용자 측에 필요한 모든 것을 생성하고, instances create는 엔드포인트를 통해 ClickHouse Cloud에 생성 요청을 제출합니다. ClickHouse Cloud는 서비스 정의를 렌더링한 뒤 아웃바운드 채널을 통해 실행기로 생성 요청을 전달합니다. 실행기는 이를 클러스터에 적용하고 결과를 보고합니다.
AWS 자격 증명이 필요한 명령어는 prepare뿐이며, 이 명령어는 S3 버킷과 IAM role을 생성합니다. instances create는 커넥터의 구성과 자격 증명이 필요하고, --wait를 사용할 때만 실행기의 로컬 API에 접근합니다. VM에서는 두 명령어 모두 커넥터 호스트에서 root로 실행하십시오. Kubernetes에서는 관리형 클러스터의 kube 컨텍스트가 설정된 작업 머신에서 두 명령어를 모두 실행하십시오.
prepare에는 커넥터 구성 사본(--config), 실행기의 로컬 API로 연결되는kubectl port-forward, 그리고 쓰기 가능한--output-dir가 필요합니다. 이 명령어는 실행기를 통해 서비스 이름을 확인하며, 실행기에 연결할 수 없으면 실행을 거부합니다.- 현재 호스트에 구성에 지정된 자격 증명 파일이 없으면,
instances create는 이를clicklink-hmac및clicklink-mtls시크릿에서 읽어오며 읽을 때마다 이를 알립니다. 커넥터 네임스페이스가clicklink가 아니면--connector-namespace를 추가하십시오. 이 폴백 동작은instances create에만 적용됩니다.
1
서비스 준비
- Kubernetes
- Linux VM
instances create와 모든 retry가 읽어 들이는 create body와 name 레코드가 이 디렉터리에 보관됩니다.- Name. service name을 선택하거나
--instance <name>으로 전달한 이름을 검사합니다. 생성된 이름은<output-dir>/_prepare/<eks-cluster-name>.name에 기록되어 다음 실행에서 이어서 사용되므로, retry 시에는 첫 실행의 버킷과 역할을 재사용합니다.--new-name을 사용하면 다른 이름을 선택합니다. executor가 아직 보유 중인 이름이거나 해당 네임스페이스에 이미 ClickHouse 클러스터가 있는 이름은 거부됩니다. - Storage. 데이터 및 backup 버킷과 IAM role
CH-S3-<name>-<region>-00-Role을 생성합니다. 기본 버킷 이름은<cluster>-clickhouse-data-<rand>와<cluster>-clickhouse-backup-<rand>이며,--data-bucket과--backup-bucket으로 재정의할 수 있습니다.--role-arn을 지정하면 사용자가 제공한 역할을 검증하며 IAM은 작성하지 않습니다. - Grant and apply. VM에서는 service 네임스페이스(
ns-<name>)에 대한 executor의 access bundle을 렌더링하고, 해당 RBAC를 적용한 뒤 executor의 registry에 service를 등록합니다. Kubernetes에서는 이 단계가 생략됩니다. executor가 자신의 파드 ServiceAccount로 실행되며, create 요청이 도착하면 직접 service를 등록합니다. - Summary.
defaultUSER의 password를 발급하고 create body를<output-dir>/_prepare/<name>.create.json에 작성합니다(mode0600, password의 해시만 포함). 그리고 다음에 실행할 명령을Next:줄에 출력합니다.
--context <name>을 전달하십시오. 이때 Context는 구성의 executor.cluster에 지정된 EKS cluster를 가리켜야 합니다. --dry-run은 아무것도 생성하거나 작성하지 않고 모든 단계를 실행합니다. 해싱 단계는 SHA-1을 사용하는데, Go는 GODEBUG=fips140=only 설정에서 이를 거부합니다. 따라서 해당 설정이 적용되지 않은 호스트에서 prepare를 실행하십시오.2
생성 요청을 제출합니다
- Kubernetes
- Linux VM
prepare에서 실행한 포트 포워딩은 그대로 열어 두십시오. --wait가 이 연결을 통해 실행기를 폴링합니다.created <spoken-name> (state provisioning)과 watch: hint가 출력됩니다. <spoken-name>은 ClickHouse Cloud가 할당한 이름(예: amberaws-kq-42)이며, 준비 단계에서 지정한 service name이 아닙니다. watch: hint와 모든 clctl 명령은 사용자가 지정한 service name을 사용합니다.동일한 입력으로 재시도해도 안전합니다. 멱등성 key는 기본적으로 환경과 service name에서 파생되므로, 다시 제출하면 최초 생성 결과가 반환됩니다.--wait는 service가 running 상태가 될 때까지 10초마다 실행기의 로컬 API를 폴링하며, 최대 --wait-timeout(기본값 30m)까지 대기합니다. 실행기가 해당 이름에 대한 생성 실패를 기록하거나 service가 terminating, terminated, stale 상태로 전환되면 기록된 오류와 함께 즉시 실패 처리합니다.3
확인
status가 running이 되면 사용할 준비가 된 것입니다. 해당 서비스의 default 사용자는 prepare에서 출력된 비밀번호를 사용합니다. --cluster는 CLCTL_CLUSTER 환경 변수로도 지정할 수 있습니다.상태
실행기는 로컬 API를 통해 상태 조회에 응답하며, 이 API는127.0.0.1:9999에 바인딩되고 자체 인증(authentication) 기능은 제공하지 않습니다. VM에서는 해당 호스트에서 명령어를 실행하십시오. Kubernetes에서는 먼저 포트 포워딩을 설정한 뒤, 명령어가 이를 바라보도록 지정하십시오:
clicklink clctl instances list는 실행기가 알고 있는 모든 서비스를 JSON으로 출력합니다. clicklink clctl instances get --name <name> --cluster <eks-cluster-name>는 특정 서비스 하나를 생성 당시 사용된 저장소 정보와 함께 출력합니다. 실행기는 서비스의 ClickHouseCluster 리소스(준비된 서버 레플리카 수 대 예상 서버 레플리카 수)를 기준으로 상태를 판단하며, sync_interval(기본값 30초)마다 이를 갱신합니다:
provisioning: 아직 준비된 서버 레플리카가 없거나,ClickHouseCluster가 아직 존재하지 않음running: 예상된 모든 서버 레플리카가 준비됨degraded: 일부 서버 레플리카만 준비되고 전부는 준비되지 않음terminating: 실행기가 서비스를 제거하는 중terminated: 서비스의 네임스페이스가 사라짐stale: 삭제 절차 없이 서비스가 실행기의 registry에서 제거됨.--wait와teardown은 이를terminated와 동일하게 취급합니다
clicklink clctl commands list로 이를 출력할 수 있으며, --status(pending, running, completed, failed), --action(예: create_instance), --cluster로 필터링할 수 있습니다. clicklink clctl commands get <id>는 명령어 하나를 해당 stage 및 결과와 함께 출력합니다. 실패한 명령어의 result에는 오류 내용이 담겨 있어, 생성이 수렴하지 못한 이유나 어떤 플랫폼 업데이트가 승인을 기다리고 있는지를 확인할 수 있습니다.
서비스 수명 주기
서비스가 생성되고 나면 ClickHouse Cloud는 실행기를 통해 해당 서비스를 운영합니다. ClickHouse Cloud가 전송하는 명령어는 다음과 같습니다:- Scale. ClickHouse Cloud가 고정된 레플리카 수를 지정하며, 그 상한은 ClickHouse Cloud 설정으로 결정됩니다(기본 구성에서는 20). 자동 스케일링은 지원되지 않습니다.
- Stop 및 start. 중지하면 서버가 0으로 스케일되고 Keeper는 유지됩니다. 시작하면 레플리카 수가 복원됩니다. 이 과정 내내 데이터는 사용자의 버킷에 그대로 남아 있습니다.
- Restart. 전체 서비스, 해당 Keeper, 또는 단일 파드를 재시작합니다.
- Backups. ClickHouse Cloud가 백업을 트리거하며, 백업은 백업 버킷에 저장되고 백업을 삭제하면 제거됩니다.
- 버전 업그레이드 및 구성 변경. ClickHouse Cloud는 새 버전이나 설정을 반영해 서비스 정의를 다시 렌더링합니다. 이는
create_instance명령어로 전달되므로commands list --action create_instance에서도 업그레이드를 확인할 수 있습니다. 실행기는 이를 적용한 뒤 레플리카가 다시 준비 상태가 될 때까지 대기합니다. - Delete. 서비스 삭제에서 설명합니다.
running 상태로 전환합니다.
instances scale, instances patch, instances delete 하위 명령어는 ClickHouse Cloud를 거치지 않고 실행기의 로컬 API에 직접 명령어를 전송합니다. 계정 담당 팀이 요청하는 경우에만 실행하십시오. 각 명령어의 동작은 CLI 참고에 설명되어 있습니다.
관리형 서비스의 지원 세션
실행기는 자신이 생성하는 각 서비스에 스크레이퍼를 연결합니다. 다만 Troubleshooter는 프로비저닝하지 않으므로, 직접 프로비저닝하기 전까지는 지원 세션에서 관리형 서비스에 대한 진단을 실행할 수 없습니다. 직접 등록한 instance와 동일한 방식으로, 서비스 네임스페이스ns-<name>을 지정하여 서비스마다 한 번씩 프로비저닝하십시오.
- Kubernetes
- Linux VM
$CH_DEFAULT_PASSWORD는 prepare가 출력한 default 사용자의 password입니다. 이 command는 SQL 권한 부여를 적용하기 위해 해당 값으로 인증하며, 별도로 입력을 요청하지 않습니다. 그런 다음 ClickHouse instance 추가에 설명된 대로 시크릿과 ServiceAccount 쌍을 troubleshooter.accessBundles에 추가하고 helm upgrade를 실행하십시오.--ch-user-via cr로 추가한 사용자는 유지되지 않습니다. 서비스 정의는 ClickHouse Cloud가 소유하며 이를 반복해서 다시 적용하기 때문입니다. 서비스가 삭제되면 실행기는 VM에서 Troubleshooter의 bundle을 제거합니다. Kubernetes에서는 제거에 나열된 대로 직접 삭제하기 전까지 bundle 시크릿과 ServiceAccount가 그대로 남아 있습니다.
서비스 삭제
커넥터 엔드포인트를 통한 고객용 삭제 명령은 제공되지 않습니다. 서비스 삭제는 계정 담당 팀에 요청하십시오. ClickHouse Cloud가 서비스를 종료하면 실행기가 해당 워크로드와 네임스페이스를 삭제합니다(terminating을 거쳐 terminated). AWS 측에는 아무런 변경도 가해지지 않습니다. 버킷, 그 안의 데이터, IAM role은 직접 제거하기 전까지 그대로 유지됩니다.
서비스 상태가 terminated로 보고되면 prepare가 생성한 리소스를 정리하십시오. teardown은 prepare를 실행했던 곳에서 동일한 AWS 자격 증명으로 실행해야 합니다. Kubernetes에서는 동일한 workstation, 동일한 구성 사본과 출력 디렉터리, 그리고 실행기로 연결된 포트 포워딩이 필요합니다.
- Kubernetes
- Linux VM
prepare가 생성한 IAM role을 삭제하고, 실행기가 해당 서비스를 잊도록 하여 이름을 해제합니다. VM에서는 서비스의 클러스터 전체 RBAC 객체, 로컬 액세스 bundle, registry entry도 함께 제거합니다.
기본적으로 서비스의 데이터와 백업은 유지됩니다. 유지되는 버킷의 태그는 clicklink:deployed-name에서 clicklink:retained-from=<name>으로 변경되므로, 동일한 이름으로 다시 생성된 서비스가 이를 상속하는 일은 없으며, 요약에 데이터 위치가 표시됩니다. 이를 삭제하려면 같은 명령에 --delete-data --delete-backups --yes를 추가하십시오.
--yes가 없으면 기록 단계 이후 실행이 중단되며, 비우게 될 버킷의 이름을 알려 줍니다. --dry-run은 모든 정보를 읽기만 하고 아무것도 쓰지 않습니다. --role-arn으로 직접 지정한 역할이나 prepare가 생성하지 않은 버킷은 유지 대상으로 보고되며 전혀 건드리지 않습니다. 서비스의 네임스페이스에 아직 ClickHouse 클러스터가 남아 있으면 실행이 거부됩니다. 무엇이든 삭제하기 전에 모든 정보를 먼저 읽으므로, 거부된 실행은 아무것도 변경하지 않습니다.
커넥터가 오프라인일 때
실행 중인 서비스는 실행기에 의존하지 않습니다. 클러스터의 ClickHouse Operator가 서비스를 계속 실행 상태로 유지하므로, 커넥터 연결이 끊기더라도 이미 쿼리를 처리 중인 서비스는 전혀 영향을 받지 않습니다. 실행기가 연결되어 있지 않은 동안에는 ClickHouse Cloud가 새 작업을 전달할 수 없습니다. 이미 수락된 생성, 삭제, 플랫폼 동기화 작업은 보관되었다가 재시도됩니다. 생성은 마지막 진행 상황 보고 시점부터 30분 동안, 삭제는 2시간 동안, 플랫폼 동기화는 최대 10회까지 재시도됩니다. 이 한도를 초과하면 커넥터 엔드포인트가 해당 명령어를 실패로 표시합니다. 그 외 모든 수명 주기 명령어(scale, stop, start, restart, backup, backup 삭제)는 큐에 대기되지 않고 거부됩니다. 실행기가 연결되어 있지 않은 상태에서 제출한 생성 또는 삭제 명령어도 동일하게 거부되며, 이미 수락된 명령어만 재시도됩니다. 실행기가 이미 수락한 명령어는 완료될 때까지 실행되며, 보고하지 못한 결과는 다음 연결 시 전송됩니다.instances create는 명령어를 실행하는 호스트에서 커넥터 엔드포인트에 연결할 수 있어야 합니다. --wait, instances list, instances get, commands list는 실행기의 로컬 API를 사용하므로 실행기가 실행 중이어야 합니다. 플랫폼 승인 토큰은 연결 상태와 관계없이 자체 시간에 따라 만료됩니다. 승인 윈도우를 참조하십시오.