etcd 클러스터 운영: 장애 복구와 성능 튜닝

etcd 클러스터의 안정적인 운영을 위한 핵심 지식을 다룹니다. 멤버 관리, 스냅샷 백업/복원, 재해 복구, 성능 튜닝 등 운영에 필수적인 내용을 설명합니다.

1. 멤버 관리

1.1 클러스터 구성 권장 사항

etcd 클러스터는 홀수 노드로 구성하는 것이 권장됩니다:

클러스터 크기	과반수	허용 장애 노드
1	1	0
3	2	1
5	3	2
7	4	3

3노드 또는 5노드 구성이 가장 일반적입니다. 노드가 많을수록 내결함성은 높아지지만 쓰기 지연이 증가합니다.

1.2 멤버 추가

새 멤버를 추가하는 과정:

# 1. 기존 클러스터에 새 멤버 등록
etcdctl member add new-node \
  --peer-urls=https://10.0.0.4:2380

# 2. 새 노드에서 etcd 시작 (initial-cluster-state=existing)
etcd --name new-node \
  --initial-cluster 'node1=https://10.0.0.1:2380,...,new-node=https://10.0.0.4:2380' \
  --initial-cluster-state existing

1.3 Learner 멤버

etcd 3.4+에서는 Learner로 먼저 추가하는 것을 권장합니다:

# Learner로 추가
etcdctl member add new-node \
  --peer-urls=https://10.0.0.4:2380 \
  --learner

# Learner가 로그를 따라잡은 후 투표 멤버로 승격
etcdctl member promote MEMBER_ID

Learner의 장점:

투표에 참여하지 않으므로 쿼럼에 영향 없음
로그를 따라잡는 동안 클러스터 안정성 유지
네트워크 문제 시 클러스터가 영향받지 않음

1.4 멤버 제거

# 멤버 목록 확인
etcdctl member list

# 멤버 제거
etcdctl member remove MEMBER_ID

주의사항:

리더를 제거하면 자동으로 새 리더가 선출됨
제거 후 해당 노드의 데이터 디렉토리 정리 권장
3노드에서 1노드를 제거하면 2노드가 되어 1노드 장애도 허용 불가

2. 스냅샷과 백업

2.1 스냅샷 저장

# 스냅샷 저장
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/etcd/ca.crt \
  --cert=/etc/etcd/server.crt \
  --key=/etc/etcd/server.key

# 스냅샷 상태 확인
etcdctl snapshot status /backup/etcd-snapshot.db --write-out=table

2.2 데이터 디렉토리 구조

/var/lib/etcd/
  member/
    snap/       # 스냅샷 파일
      db        # BoltDB 데이터 파일
    wal/        # Write-Ahead Log 파일
      0000000000000000-0000000000000000.wal
      0000000000000001-0000000000001000.wal

WAL: 모든 변경사항을 순차적으로 기록. 장애 복구에 사용
Snap: 특정 시점의 전체 상태 스냅샷. WAL 재생 범위를 줄여 시작 시간 단축

2.3 스냅샷 복원

# 스냅샷 복원 (새 data-dir에)
etcdutl snapshot restore /backup/etcd-snapshot.db \
  --name node1 \
  --data-dir /var/lib/etcd-restored \
  --initial-cluster 'node1=https://10.0.0.1:2380,...' \
  --initial-advertise-peer-urls https://10.0.0.1:2380

# etcd 설정에서 data-dir을 새 경로로 변경 후 재시작

2.4 백업 전략

권장 백업 전략:

정기적 스냅샷 (예: 30분마다)
스냅샷을 원격 저장소에 복사 (S3, GCS 등)
백업 검증: 정기적으로 복원 테스트 수행
WAL과 스냅샷을 별도 디스크에 저장하여 I/O 분리

3. 재해 복구

3.1 단일 노드 장애

3노드 클러스터에서 1노드 장애 시:

쿼럼(2/3)이 유지되므로 정상 동작
장애 노드 복구 또는 교체
새 노드를 Learner로 추가하여 안전하게 복구

3.2 쿼럼 손실 복구

과반수 노드가 장애인 경우:

# 남은 노드에서 스냅샷 저장 (가능한 경우)
etcdctl snapshot save /backup/emergency.db

# 새 단일 노드 클러스터로 복원
etcdutl snapshot restore /backup/emergency.db \
  --name node1 \
  --data-dir /var/lib/etcd-new \
  --initial-cluster 'node1=https://10.0.0.1:2380' \
  --initial-advertise-peer-urls https://10.0.0.1:2380

# 나머지 멤버를 하나씩 추가

3.3 데이터 손상 대응

etcd 데이터 손상 징후:

etcd 시작 실패 (WAL 또는 스냅샷 오류)
일관성 확인 실패
CORRUPT 알람

대응 절차:

해당 노드를 클러스터에서 제거
데이터 디렉토리 삭제
새 멤버로 다시 추가 (자동으로 데이터 복제)
또는 스냅샷에서 복원

3.4 네트워크 파티션 대응

네트워크 파티션 시 Raft는 다음과 같이 동작합니다:

과반수를 포함하는 파티션에서만 읽기/쓰기 가능
소수 파티션의 리더는 heartbeat 실패 후 리더십 포기
파티션 복구 후 소수 파티션의 노드가 자동으로 최신 상태로 동기화

4. 성능 튜닝

4.1 디스크 성능

etcd 성능에 가장 큰 영향을 미치는 요소는 디스크입니다:

SSD 필수: 회전 디스크(HDD)는 적합하지 않음
WAL 전용 디스크: WAL과 데이터를 별도 디스크에 분리
fio 벤치마크: 99th percentile fsync 지연이 10ms 이하인지 확인

# 디스크 fsync 성능 테스트
fio --rw=write --ioengine=sync --fdatasync=1 \
  --directory=/var/lib/etcd --size=22m \
  --bs=2300 --name=etcd-fsync-test

4.2 네트워크 설정

멤버 간 RTT(Round Trip Time)가 낮을수록 좋음
같은 데이터센터 내 배치 권장
heartbeat-interval과 election-timeout 조정

# 네트워크 지연에 따른 권장 설정
RTT < 1ms:  heartbeat-interval=100ms,  election-timeout=1000ms (기본)
RTT < 10ms: heartbeat-interval=200ms,  election-timeout=2000ms
RTT < 50ms: heartbeat-interval=500ms,  election-timeout=5000ms

4.3 스냅샷 카운트

--snapshot-count는 스냅샷 생성 빈도를 제어합니다:

기본값: 100000 (10만 트랜잭션마다 스냅샷)
값을 줄이면: 스냅샷 빈도 증가, 시작 시간 단축, 디스크 I/O 증가
값을 늘리면: 스냅샷 빈도 감소, 시작 시간 증가, 디스크 I/O 감소

4.4 클라이언트 관련 튜닝

--max-request-bytes: 최대 요청 크기 (기본 1.5MB)
--max-concurrent-streams: gRPC 스트림 동시성 제한
클라이언트에서 연결 풀링 사용
불필요한 Watch 수 최소화

4.5 리소스 제한

# 권장 리소스
CPU: 2-4 cores (전용)
Memory: 8GB 이상
Disk: SSD, 50GB 이상
Network: 1Gbps 이상

5. 모니터링과 알림

5.1 핵심 메트릭

메트릭	설명	임계값
etcd_server_has_leader	리더 존재 여부	0이면 위험
etcd_server_leader_changes_seen_total	리더 변경 횟수	급증 시 주의
etcd_disk_wal_fsync_duration_seconds	WAL fsync 지연	p99 > 10ms 경고
etcd_disk_backend_commit_duration_seconds	백엔드 커밋 지연	p99 > 25ms 경고
etcd_server_proposals_failed_total	실패한 제안 수	증가 시 주의

5.2 알림 규칙 예시

# etcd 리더 없음 알림
- alert: EtcdNoLeader
  expr: etcd_server_has_leader == 0
  for: 1m
  labels:
    severity: critical

# etcd 높은 fsync 지연
- alert: EtcdHighFsyncDuration
  expr: histogram_quantile(0.99, etcd_disk_wal_fsync_duration_seconds_bucket) > 0.01
  for: 5m
  labels:
    severity: warning

6. 정리

etcd 클러스터 운영의 핵심은 정기적인 백업, 적절한 모니터링, 디스크 성능 최적화입니다. Learner 노드를 활용한 안전한 멤버 관리, 쿼럼 손실 시 복구 절차를 숙지하는 것이 중요합니다. 다음 글에서는 etcd의 Watch와 Lease 메커니즘을 분석합니다.