Split View: etcd 클러스터 운영: 장애 복구와 성능 튜닝
etcd 클러스터 운영: 장애 복구와 성능 튜닝
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 메커니즘을 분석합니다.
etcd Cluster Operations: Disaster Recovery and Performance Tuning
etcd Cluster Operations: Disaster Recovery and Performance Tuning
This post covers essential knowledge for reliable etcd cluster operations, including member management, snapshot backup/restore, disaster recovery, and performance tuning.
1. Member Management
1.1 Cluster Size Recommendations
etcd clusters should use an odd number of nodes:
| Cluster Size | Majority | Tolerated Failures |
|---|---|---|
| 1 | 1 | 0 |
| 3 | 2 | 1 |
| 5 | 3 | 2 |
| 7 | 4 | 3 |
3-node or 5-node configurations are most common. More nodes increase fault tolerance but also increase write latency.
1.2 Adding Members
# 1. Register new member with existing cluster
etcdctl member add new-node \
--peer-urls=https://10.0.0.4:2380
# 2. Start etcd on the new node (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 Members
In etcd 3.4+, adding as a Learner first is recommended:
# Add as Learner
etcdctl member add new-node \
--peer-urls=https://10.0.0.4:2380 \
--learner
# Promote to voting member after catching up
etcdctl member promote MEMBER_ID
1.4 Removing Members
etcdctl member list
etcdctl member remove MEMBER_ID
2. Snapshots and Backup
2.1 Saving Snapshots
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
2.2 Data Directory Structure
/var/lib/etcd/
member/
snap/ # Snapshot files
db # BoltDB data file
wal/ # Write-Ahead Log files
2.3 Snapshot Restore
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
2.4 Backup Strategy
- Regular snapshots (e.g., every 30 minutes)
- Copy snapshots to remote storage (S3, GCS)
- Backup verification: periodically test restores
- Separate WAL and data on different disks
3. Disaster Recovery
3.1 Single Node Failure
In a 3-node cluster with 1 node failure, quorum (2/3) is maintained and the cluster operates normally. Recover or replace the failed node.
3.2 Quorum Loss Recovery
When majority nodes fail:
# Save snapshot from surviving node
etcdctl snapshot save /backup/emergency.db
# Restore as single-node cluster
etcdutl snapshot restore /backup/emergency.db \
--name node1 \
--data-dir /var/lib/etcd-new \
--initial-cluster 'node1=https://10.0.0.1:2380'
# Add remaining members one by one
3.3 Data Corruption
Signs of data corruption: startup failures, consistency check failures, CORRUPT alarms.
Recovery: remove the node, delete data directory, re-add as new member (automatic data replication), or restore from snapshot.
3.4 Network Partition
During network partitions, only the partition containing the majority can perform reads/writes. After recovery, minority partition nodes automatically sync to the latest state.
4. Performance Tuning
4.1 Disk Performance
Disk is the most critical factor for etcd performance:
- SSD required: HDDs are not suitable
- Dedicated WAL disk: Separate WAL and data on different disks
- fio benchmark: Ensure 99th percentile fsync latency is below 10ms
fio --rw=write --ioengine=sync --fdatasync=1 \
--directory=/var/lib/etcd --size=22m \
--bs=2300 --name=etcd-fsync-test
4.2 Network Configuration
- Lower RTT between members is better
- Deploy within the same data center
- Adjust heartbeat-interval and election-timeout based on network latency
4.3 Snapshot Count
--snapshot-count controls snapshot creation frequency (default: 100000).
4.4 Resource Recommendations
CPU: 2-4 dedicated cores
Memory: 8GB minimum
Disk: SSD, 50GB minimum
Network: 1Gbps minimum
5. Monitoring and Alerting
5.1 Key Metrics
| Metric | Description | Threshold |
|---|---|---|
| etcd_server_has_leader | Leader existence | 0 is critical |
| etcd_server_leader_changes_seen_total | Leader changes | Spike needs attention |
| etcd_disk_wal_fsync_duration_seconds | WAL fsync latency | p99 > 10ms warning |
| etcd_disk_backend_commit_duration_seconds | Backend commit latency | p99 > 25ms warning |
5.2 Alert Rule Examples
- alert: EtcdNoLeader
expr: etcd_server_has_leader == 0
for: 1m
labels:
severity: critical
- alert: EtcdHighFsyncDuration
expr: histogram_quantile(0.99, etcd_disk_wal_fsync_duration_seconds_bucket) > 0.01
for: 5m
labels:
severity: warning
6. Summary
The keys to etcd cluster operations are regular backups, proper monitoring, and disk performance optimization. Understanding safe member management with Learner nodes and quorum loss recovery procedures is essential. The next post analyzes etcd's Watch and Lease mechanisms.