etcd 고가용성(HA) 클러스터 구성과 백업/복구 베스트 프랙티스

etcd 고가용성(HA) 클러스터 구성과 백업/복구 베스트 프랙티스

1. etcd 고가용성(HA) 클러스터 아키텍처 토폴로지

쿠버네티스 컨트롤 플레인 고가용성의 핵심은 etcd 클러스터의 안정성에 있습니다. etcd는 뗏목(Raft) 합의 알고리즘을 사용하므로, 네트워크 파티션 발생 시 스플릿 브레인(Split-Brain)을 방지하기 위해 반드시 홀수(3, 5, 7 등)로 노드를 구성하여 과반수(Quorum)를 확보해야 합니다.

• Stacked etcd 토폴로지: Kube-apiserver와 etcd가 동일한 마스터 노드에 공존하는 구조입니다. 인프라 구축 및 관리가 단순하여 Kubeadm 기본 설정으로 널리 사용됩니다. 하지만 하나의 마스터 노드에 장애가 발생하면 컨트롤 플레인과 etcd 멤버를 동시에 잃게 되므로 장애 발생 시 클러스터 전체에 미치는 영향도가 상대적으로 큽니다.
• External etcd 토폴로지: Kube-apiserver가 구동되는 컨트롤 플레인 노드와 etcd가 구동되는 노드를 물리적으로 완전히 분리하는 구조입니다. 노드 장애 시 영향도가 분산되어 프로덕션 환경에서 가장 권장되는 방식입니다. 다만 별도의 etcd 전용 서버가 필요하므로 인프라 비용이 증가하고, API 서버와 etcd 간의 네트워크 인증서 관리가 더 복잡해집니다.

2. 프로덕션 환경의 인프라 구성 베스트 프랙티스

• 고성능 SSD(NVMe) 전용 할당: etcd 성능의 병목은 대부분 디스크의 쓰기 지연 시간(fsync latency)에서 발생합니다. WAL(Write-Ahead Log)을 물리적 디스크에 안전하게 기록해야만 다음 합의 작업을 수행할 수 있으므로, 반드시 고성능 SSD를 사용해야 합니다. 또한 I/O 경합을 막기 위해 etcd 데이터 디렉토리(/var/lib/etcd)를 OS나 컨테이너 런타임이 사용하는 디스크와 별도의 물리적 파티션으로 분리해야 합니다.
• 네트워크 지연 시간(RTT) 최소화: 멤버 노드 간의 하트비트(Heartbeat)와 데이터 복제는 네트워크 속도에 크게 의존합니다. 멤버 간 네트워크 지연이 발생하면 잦은 리더 선출(Leader Election)이 발생하여 클러스터가 극도로 불안정해집니다. 고가용성을 위해 가용 영역(AZ)을 분리하더라도, 노드 간 네트워크 RTT는 가급적 10ms 이내로 유지되도록 인프라를 설계해야 합니다.
• 리소스 격리 및 보호: OOM(Out of Memory) 킬러에 의해 etcd 프로세스가 강제 종료되는 것을 방지하기 위해, etcd 파드의 리소스 요청(Requests)과 제한(Limits)을 충분히 넉넉하게 설정해야 합니다. 또한 쿠버네티스 스케줄러에 의해 축출되지 않도록 우선순위 클래스(PriorityClass)를 시스템 최고 수준으로 할당하는 것이 필수적입니다.

3. 무중단 운영을 위한 etcd 백업(Snapshot) 전략

etcd 데이터는 쿠버네티스의 모든 것입니다. 노드 장애, 디스크 손상, 또는 휴먼 에러로 인한 치명적인 데이터 손실에 대비해 견고한 주기적 백업 체계가 필수적입니다.

• 자동화된 스냅샷 체계 구축: CronJob 시스템이나 etcd-backup-operator를 활용하여 정기적으로 스냅샷을 생성해야 합니다. ETCDCTL_API=3 etcdctl snapshot save <파일명> 명령어를 사용하여 특정 시점 복구(PITR)를 위한 데이터를 지속적으로 확보합니다.
• 오프사이트(Off-site) 백업: 생성된 스냅샷 파일을 해당 노드의 로컬 디스크에만 보관하면 물리적 노드 장애 시 데이터를 영영 잃게 됩니다. AWS S3, Google Cloud Storage와 같은 외부 오브젝트 스토리지 네트워크로 즉각 복제(Sync)하는 파이프라인을 반드시 구축해야 합니다.
• PKI 인증서 백업: 스냅샷 파일만으로는 클러스터를 완벽히 복원할 수 없습니다. /etc/kubernetes/pki/etcd 디렉토리에 위치한 etcd CA 인증서, 클라이언트/서버 인증서 및 개인 키들을 반드시 안전한 외부 금고(Vault 등)에 스냅샷과 함께 백업해야 합니다.

4. 장애 유형별 etcd 복구(Restore) 가이드

복구 프로세스는 장애의 규모와 과반수(Quorum) 생존 여부에 따라 완전히 다르게 접근해야 합니다.

• 시나리오 A: 소수 노드 장애 (과반수 생존, Quorum 유지)
  클러스터는 계속해서 정상적으로 동작하며 읽기/쓰기 작업이 가능한 상태입니다. 이 경우 스냅샷을 사용할 필요가 없습니다. 먼저 생존한 노드에서 etcdctl member remove 명령으로 장애가 발생한 기존 노드를 클러스터 목록에서 완전히 퇴출시킵니다. 이후 새로운 컴퓨팅 노드를 프로비저닝하고, 비어있는 데이터 디렉토리 상태에서 etcdctl member add 명령을 통해 기존 클러스터에 새 멤버로 가입(Join)시킵니다. 가입 직후 생존 노드들의 리더로부터 최신 데이터를 자동으로 동기화받아 복구가 완료됩니다.
• 시나리오 B: 과반수 노드 장애 (Quorum 상실)
  과반수를 잃으면 새로운 리더를 선출할 수 없어 클러스터는 즉시 읽기 전용 상태가 되며 전체 컨트롤 플레인 기능이 마비됩니다. 이 때는 기존 클러스터를 파기하고 백업된 스냅샷을 통해 완전히 새로운 클러스터를 재구성해야 합니다.

1. 모든 Kube-apiserver 인스턴스를 중지시켜 etcd로의 유입 트래픽을 원천 차단합니다.
2. 모든 생존한 etcd 프로세스를 강제 종료하고, 기존의 손상된 데이터 디렉토리(/var/lib/etcd)를 완전히 삭제하거나 다른 경로로 백업합니다.
3. 백업해 둔 스냅샷 파일을 복구할 각 노드에 위치시킵니다.
4. 각 노드에서 etcdctl snapshot restore 명령어를 실행합니다. 이때 --initial-cluster, --initial-cluster-token, --name 파라미터를 정확히 명시하여 이전 데이터의 잔재를 지우고 각 노드가 완전히 새로운 클러스터의 멤버로 인식되도록 초기화합니다.
5. 복원된 데이터 디렉토리를 바탕으로 etcd 프로세스를 일제히 재시작하고, 멤버 간 동기화가 완료되어 성공적으로 새 리더가 선출되는지 확인합니다.
6. Kube-apiserver를 다시 시작하여 정상적인 클러스터 상태로 복귀시킵니다.

5. 운영 유지보수: 공간 단편화 및 조각 모음 (Defragmentation)

다중 버전 동시성 제어(MVCC) 구조를 사용하는 etcd는 데이터 수정/삭제 시 이전 리비전을 유지하므로 필연적으로 공간 단편화가 발생합니다. 할당된 데이터베이스 공간(Quota)이 꽉 차면 클러스터가 쓰기 불가 상태에 빠지므로, 주기적으로 etcdctl defrag 명령을 실행하여 물리적 디스크 공간을 회수해야 합니다.
단, 조각 모음 작업 중에는 해당 노드의 I/O 처리가 일시적으로 완전히 중단됩니다. 따라서 리더 노드에 영향을 주어 리더 재선출이 일어나지 않도록, 반드시 팔로워 노드들을 순차적으로 먼저 디프래그먼트하고, 마지막에 리더 권한을 다른 노드로 수동 이전(Transfer)한 뒤 기존 리더였던 노드를 작업하는 것이 가장 안전한 무중단 운영 방식입니다.