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 알람
대응 절차:
1. 해당 노드를 클러스터에서 제거
2. 데이터 디렉토리 삭제
3. 새 멤버로 다시 추가 (자동으로 데이터 복제)
4. 또는 스냅샷에서 복원
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 메커니즘을 분석합니다.
현재 단락 (1/122)
etcd 클러스터의 안정적인 운영을 위한 핵심 지식을 다룹니다. 멤버 관리, 스냅샷 백업/복원, 재해 복구, 성능 튜닝 등 운영에 필수적인 내용을 설명합니다.