ClickHouse 컨트롤 플레인과 BYOC VPC 간 연결
ClickHouse Cloud 컨트롤 플레인은 BYOC 배포를 운영하고 지원하기 위해 여러 유형의 연결을 유지합니다:
| 목적 | 연결 유형 | 비고 |
|---|
| 일상 운영 — Kubernetes API server | IP 필터링이 적용된 공개 연결(기본값) 또는 Tailscale | 관리 서비스는 IP 허용 목록으로 제한된 공개 네트워크를 통해 API 서버와 통신합니다. 초기 배포 후에는 필요에 따라 이를 Tailscale을 통한 비공개 접근으로 전환할 수 있습니다. |
| 일상 운영 — AWS APIs | ClickHouse VPC → AWS | 관리 서비스는 ClickHouse Cloud 자체 VPC에서 AWS API(EKS, EC2 등)를 AWS에 호출합니다. 이 과정에는 사용자 VPC나 Tailscale이 관여하지 않습니다. |
| 문제 해결 — ClickHouse 서비스 | Tailscale | ClickHouse 엔지니어는 진단을 위해 Tailscale을 통해 ClickHouse 서비스(예: 시스템 테이블)에 접근합니다. |
| 문제 해결 — Kubernetes API server | Tailscale | ClickHouse 엔지니어는 클러스터 진단을 위해 Tailscale을 통해 API 서버에 접근합니다. |
다음 섹션에서는 Tailscale 비공개 네트워크가 문제 해결과 선택적 관리 접근에 어떻게 사용되는지 설명합니다.
Tailscale은 ClickHouse Cloud의 관리 서비스와 BYOC 배포 환경 간에 제로 트러스트 기반의 프라이빗 네트워크 연결을 제공합니다. 이 보안 채널을 통해 공개 인터넷에 액세스하거나 복잡한 VPN을 구성하지 않아도 ClickHouse 엔지니어가 문제 해결 및 관리 작업을 수행할 수 있습니다.
Tailscale은 ClickHouse 컨트롤 플레인(ClickHouse의 VPC 내)과 BYOC 데이터 플레인(사용자 VPC 내) 사이에 암호화된 프라이빗 네트워크 터널을 생성합니다. 이 연결은 다음 용도로만 사용됩니다.
- 관리 작업: ClickHouse 관리 서비스가 BYOC 인프라와 연동하여 수행하는 작업
- 문제 해결 접근: ClickHouse 엔지니어가 진단을 위해 Kubernetes API 서버와 ClickHouse 시스템 테이블에 접근
- 메트릭 접근: ClickHouse의 중앙 집중식 모니터링 대시보드가 BYOC VPC 내에 배포된 Prometheus 스택의 메트릭에 접근하여, ClickHouse 엔지니어가 해당 환경의 관측성을 확보할 수 있도록 합니다.
Tailscale은 관리 및 문제 해결 작업에만 사용됩니다. 쿼리 트래픽이나 고객 데이터 접근에는 절대 사용되지 않습니다. 모든 고객 데이터는 사용자 VPC 내에만 유지되며, Tailscale 연결을 통해 전송되지 않습니다.
BYOC에서 Tailscale이 작동하는 방식
Tailscale을 통해 액세스해야 하는 각 서비스 또는 엔드포인트에 대해 ClickHouse BYOC는 다음을 배포합니다:
-
Tailnet 주소 등록: 각 엔드포인트는 고유한 tailnet 주소를 등록합니다(예: Kubernetes API server의 경우
k8s.xxxx.us-east-1.aws.byoc.clickhouse-prd.com)
-
Tailscale agent 컨테이너: EKS 클러스터에서 Tailscale agent 컨테이너가 실행되며, 다음을 담당합니다:
- Tailscale coordination server에 연결
- 서비스를 등록해 검색할 수 있도록 함
- Nginx 파드와 네트워크 설정을 조정
-
Nginx 파드: 다음을 수행하는 Nginx 파드:
- Tailscale에서 들어오는 TLS 트래픽을 종료 처리
- EKS 클러스터 내의 적절한 IP로 트래픽을 라우팅
Tailscale 연결은 다음 단계로 이루어집니다:
-
초기 연결:
- 양쪽 끝의 Tailscale 에이전트(ClickHouse 엔지니어의 환경과 BYOC EKS 클러스터)가 Tailscale coordination server에 연결합니다
- EKS 클러스터 에이전트가 Kubernetes 서비스를 등록해 검색 가능하도록 합니다
- ClickHouse 엔지니어가 해당 서비스를 볼 수 있도록 하려면 내부 에스컬레이션이 필요합니다
-
연결 모드:
- 직접 모드: 에이전트가 NAT 트래버설 터널을 통해 직접 연결을 설정하려고 시도합니다
- 릴레이 모드: 직접 모드가 실패하면 통신은 Tailscale DERP(Distributed Encrypted Relay Protocol) 서버를 통한 릴레이 모드로 전환됩니다
-
암호화:
- 모든 통신은 종단 간 암호화됩니다
- 각 Tailscale 에이전트는 자체 공개 키-개인 키 쌍(PKI와 유사함)을 생성합니다
- 직접 모드와 릴레이 모드 중 어느 것을 사용하든 트래픽은 암호화된 상태로 유지됩니다
아웃바운드 전용 연결:
- EKS 클러스터의 Tailscale 에이전트가 Tailscale coordination/relay server로 아웃바운드 연결을 시작합니다
- 인바운드 연결은 필요하지 않습니다 — security group 규칙에서 Tailscale 에이전트에 대한 인바운드 트래픽을 허용할 필요가 없습니다
- 따라서 공격 표면이 줄어들고 네트워크 보안 구성이 단순해집니다
액세스 제어:
- 엔지니어가 Tailscale을 통해 고객 엔드포인트로 라우팅되기 전에 내부 승인 워크플로를 통해 액세스를 요청해야 합니다
- 액세스는 일정 시간 동안만 유효하며 자동으로 만료됩니다
- 모든 액세스는 감사되며 로그에 기록됩니다
전체 데이터 액세스 정책(엔지니어가 확인할 수 있는 항목, 인증서 기반 인증, 고객 측 감사 포함)은 ClickHouse data access에서 확인하십시오.
기본적으로 ClickHouse 관리 서비스는 ClickHouse의 NAT gateway IP 주소에서만 접근할 수 있도록 제한된 EKS API 서버의 공용 IP 주소를 통해 BYOC Kubernetes 클러스터에 액세스합니다.
선택적 Private Endpoint 구성:
- EKS API 서버가 Private Endpoint만 사용하도록 구성할 수 있습니다
- 이 경우 관리 서비스는 Tailscale을 통해 API 서버에 액세스합니다(사용자의 문제 해결 접근과 유사)
- 긴급 investigation 및 지원이 필요한 경우를 대비한 백업 메커니즘으로 공용 액세스가 유지됩니다
Tailscale 연결 흐름:
- EKS 클러스터의 Tailscale 에이전트 → Tailscale coordination server(아웃바운드)
- 엔지니어의 머신에 있는 Tailscale 에이전트 → Tailscale coordination server(아웃바운드)
- 에이전트 간에 직접 연결 또는 릴레이 연결이 설정됩니다
- 설정된 터널을 통해 암호화된 트래픽이 흐릅니다
- EKS의 Nginx 파드가 TLS 종료를 수행하고 내부 서비스로 라우팅합니다
고객 데이터 전송 없음:
- Tailscale 연결은 관리 및 문제 해결 목적으로만 사용됩니다
- 쿼리 트래픽과 고객 데이터는 Tailscale을 통해 전송되지 않습니다
- 모든 고객 데이터는 VPC 내부에 유지됩니다
BYOC에서 Tailscale이 구현되는 방식에 대한 더 자세한 기술적 내용은 Building ClickHouse BYOC on AWS blog post를 참조하십시오. 연결 후 ClickHouse 엔지니어가 읽을 수 있는 내용과 ClickHouse가 해당 접근을 어떻게 감사하는지는 ClickHouse data access를 참조하십시오.
이 섹션에서는 고객 BYOC VPC로 들어오고 나가는 여러 유형의 네트워크 트래픽을 설명합니다.
- Inbound: 고객 BYOC VPC로 들어오는 트래픽입니다.
- Outbound: 고객 BYOC VPC에서 시작되어 외부 대상으로 전송되는 트래픽입니다.
- Public: 공용 인터넷에서 접근할 수 있는 네트워크 엔드포인트입니다.
- Private: VPC peering, VPC Private Link 또는 Tailscale과 같은 프라이빗 연결을 통해서만 접근할 수 있는 네트워크 엔드포인트입니다.
ClickHouse client 트래픽을 수신하기 위해 Istio 인그레스가 AWS NLB 뒤에 배포됩니다.
Inbound, Public 또는 Private
Istio 인그레스 게이트웨이는 TLS 종료를 수행합니다. Let’s Encrypt를 사용해 CertManager가 프로비저닝한 인증서는 EKS 클러스터 내의 시크릿에 저장됩니다. Istio와 ClickHouse는 동일한 VPC 내에 있으므로, 이들 사이의 트래픽은 AWS에서 암호화됩니다.
기본적으로 인그레스는 IP 허용 목록 필터링을 통해 공개적으로 접근할 수 있습니다. 고객은 VPC peering을 구성하여 이를 프라이빗하게 전환하고 공용 연결을 비활성화할 수 있습니다. 접근을 제한하려면 IP 필터를 설정할 것을 강력히 권장합니다.
인바운드, 프라이빗
ClickHouse Cloud 엔지니어에게는 Tailscale을 통한 문제 해결 접근 권한이 필요합니다. BYOC 배포에서는 엔지니어에게 Just-in-Time 방식의 인증서 기반 인증이 제공됩니다. 전체 접근 정책은 ClickHouse data access를 참조하십시오.
아웃바운드, 프라이빗
청구 스크레이퍼는 ClickHouse의 청구 데이터를 수집하여 ClickHouse Cloud가 소유한 S3 버킷으로 전송합니다.
이 스크레이퍼는 ClickHouse 서버 컨테이너의 사이드카로 실행되며, CPU 및 메모리 메트릭을 주기적으로 스크레이프합니다. 동일한 리전 내 요청은 VPC gateway 서비스 엔드포인트를 통해 라우팅됩니다.
Outbound, Public
AlertManager는 고객의 ClickHouse 클러스터가 비정상 상태일 때 ClickHouse Cloud로 알림을 보내도록 구성되어 있습니다.
메트릭과 로그는 고객의 BYOC VPC 내에 저장됩니다. 로그는 현재 EBS에 로컬로 저장되고 있습니다. 향후 업데이트에서는 BYOC VPC 내의 ClickHouse 서비스인 LogHouse에 저장될 예정입니다. 메트릭은 Prometheus 및 Thanos 스택을 사용하며 BYOC VPC 내에 로컬로 저장됩니다.
Outbound, Public
State Exporter는 ClickHouse 서비스의 상태 정보를 ClickHouse Cloud 소유의 SQS로 전송합니다.