셀프 호스팅 배포의 재해 복구(Disaster Recovery for Self-Hosted Deployments)

셀프 호스팅 배포는 일상적인 장애(파드 하나, 노드 하나, 가용영역 하나)는 개입 없이 견디고, 더 큰 장애는 여러분이 통제하는 영구 복사본으로 복구하도록 설계됐어요. 기본적으로 무엇이 탄력적인지, 각 계층을 어떻게 복구하는지 이 페이지에서 다룰게요.

출처: 문서

본문

ClickHouse (트레이스와 스팬)

기본적으로 복제되고 고가용성. 차트는 3노드 Keeper 쿼럼이 조율하는 2개 레플리카의 복제 ClickHouse 클러스터(clusterType: replicated)를 실행해요. 레플리카 파드나 그 노드가 실패하면 다른 레플리카가 계속 서빙하고, 복구된 레플리카는 Keeper를 통해 스스로 재동기화해요.
데이터는 파드와 노드 손실에도 생존해요. 각 레플리카와 Keeper 노드는 영구 볼륨(AWS는 EBS, GCP는 Persistent Disk, Azure는 관리 디스크)에 데이터를 저장해요. 볼륨은 파드와 독립적이라, 파드가 재예약되면 Kubernetes가 같은 볼륨을 다시 연결해요. 재시작이나 노드 장애로 데이터가 사라지지 않죠. 객체 스토리지로의 예약 백업 (프로덕션 권장). 실수 삭제나 전체 클러스터 손실에서 복구하려면 매일 밤 백업 CronJob을 활성화해요. Terraform이 프로비저닝한 버킷으로 BACKUP DATABASE를 실행해요: confident_clickhouse_backup_bucket_enabled = true로 설정·적용하고, terraform output clickhouse_backup_bucket에서 이름을 읽어요. 클라우드별로 구성하세요:

AWS (S3)

백업 파드는 Pod Identity로 S3에 쓰므로 작업에 키가 없어요. serviceAccountName을 IAM 역할이 백업 버킷에 쓸 수 있는 서비스 계정으로 지정해요 (앱 서비스 계정 confident, 그 역할이 버킷을 커버한다면).

clickhouse:
  backup:
    enabled: true
    provider: s3
    schedule: "0 2 * * *"      # nightly at 02:00 UTC
    serviceAccountName: confident
    s3:
      bucket: <clickhouse_backup_bucket>
      region: <region>

GCP (GCS)

GCS는 S3 호환 엔드포인트로 접근하므로 작업에 HMAC 키가 필요해요. 버킷에 쓰기 접근이 있는 서비스 계정용으로 키를 만들고 Secret에 저장해요:

BUCKET=$(terraform output -raw clickhouse_backup_bucket)
SA=<app-service-account-email>

gcloud storage buckets add-iam-policy-binding gs://$BUCKET \
  --member="serviceAccount:$SA" --role=roles/storage.objectAdmin
gcloud storage hmac create "$SA"      # prints accessId + secret

kubectl create secret generic clickhouse-backup-creds -n confident-ai \
  --from-literal=GCS_HMAC_KEY='<accessId>' \
  --from-literal=GCS_HMAC_SECRET='<secret>'

clickhouse:
  backup:
    enabled: true
    provider: gcs
    schedule: "0 2 * * *"
    gcs:
      bucket: <clickhouse_backup_bucket>
    credentialsSecret: clickhouse-backup-creds

Azure (Blob)

작업은 스토리지 연결 문자열로 인증해요. 기본적으로 앱 시크릿을 사용하므로 AZURE_STORAGE_CONNECTION_STRING이 이미 거기에 있다면 재사용하고, 그렇지 않으면 credentialsSecret을 그 키를 담은 Secret으로 지정해요.

clickhouse:
  backup:
    enabled: true
    provider: azure
    schedule: "0 2 * * *"
    azure:
      container: <clickhouse_backup_container>

각 실행은 backups/<timestamp>에 쓰고 이전 복사본을 정리하지 않으므로, 보존을 제한하려면 버킷 수명주기 규칙(예: 30일 후 객체 만료)을 설정하세요. 일정을 기다리지 않고 즉시 하나를 실행하려면: kubectl create job --from=cronjob/confident-clickhouse-backup ch-backup-now -n confident-ai.

복구. 손실된 레플리카는 정상 레플리카에서 자동으로 재구축돼요. 전체 복원을 위해서는 버킷의 최신 백업에서 RESTORE DATABASE를 실행해요.

Kubernetes

관리형 컨트롤 플레인. EKS, GKE, AKS는 클라우드 제공자의 자체 HA와 백업으로 컨트롤 플레인을 운영해요. etcd를 관리할 일이 없죠.
자가 치유 워크로드. 모든 애플리케이션 서비스는 자동 확장과 함께 2개 이상의 레플리카를 실행하고, 노드와 가용영역에 걸쳐 분산돼요 (AWS는 2-AZ 노드 그룹, GCP는 리전 클러스터). 실패한 파드는 재예약되고, 실패한 노드의 파드는 정상 노드로 이동해요.
플랫폼은 재현 가능해요. 모든 것이 선언적이에요: 인프라는 Terraform, 앱은 Helm. 클러스터가 완전히 손실돼도 terraform apply가 재구축하고 helm install이 앱을 재배포하며, 아래의 데이터 계층은 다시 연결돼요. Terraform 상태를 원격 백엔드에, values 파일을 버전 관리에 두면 재구축이 몇 분 만에 끝나요. 고고학이 아니라요.

PostgreSQL

자동 장애 조치와 함께 관리형. 데이터베이스는 RDS (Multi-AZ), Cloud SQL (리전 HA), 또는 Flexible Server (zone-redundant HA)예요. 영역·인스턴스 장애 시 구성 변경 없이 스탠바이로 장애 조치해요.
자동 백업과 시점 복원(PITR). 각 클라우드가 예약 백업을 수행하고 보존 창 안의 어느 시점으로든 복원할 수 있게 해요. 프로덕션에서는 삭제 보호를 켜두세요 (AWS에서 confident_rds_deletion_protection = true).
복구. 클라우드 콘솔에서 시점 또는 스냅샷으로 복원하고, 엔드포인트가 바뀌었으면 DATABASE_URL을 업데이트해요.

객체 스토리지 (데이터셋과 페이로드)

클라우드가 내구성·복제를 제공. S3, GCS, Blob은 리전 전반에 객체를 중복 저장하므로 하드웨어 장애는 알아서 처리돼요.
실수 삭제를 위해 버전 관리 활성화. 버킷 버전 관리나 soft delete를 켜서 덮어쓰거나 삭제된 객체를 복원할 수 있게 해요. 더 강한 대비를 원하면 교차 리전 복제를 활성화해요.
복구. 이전 객체 버전을 복원하거나, 교차 리전 복제가 켜져 있다면 복제 버킷으로 장애 조치해요.

드릴을 실행해 보세요

이 중 무엇에든 의존하기 전에 한 번 실행해 봐요: ClickHouse 백업을 활성화하고 객체가 버킷에 들어오는지 확인하고, 데이터베이스 스냅샷을 떠서 임시 인스턴스에 복원하고, ClickHouse 레플리카 파드를 삭제해 재동기화되는 걸 지켜보세요. 실행해 본 복구 경로만이 믿을 수 있는 경로예요.

셀프 호스팅 배포의 재해 복구(Disaster Recovery for Self-Hosted Deployments)