etcd

https://excalidraw.com/ 에서 그렸습니다.

etcd 란?

etcd 는 kubernetes 에서 클러스터의 핵심 데이터 저장소로, 모든 상태 정보와 리소스를 영구적으로 저장 및 관리하는 분산형 Key-Value 저장소 입니다.

CoreOS가 2013년 개발을 시작했으며, 2018년 CNCF(Cloud Native Computing Foundation) 에서 졸업 프로젝트로 승격되어 관리하고 있습니다.

이름의 유래는 Linux 시스템 설정 디렉토리 /etc + 분산 시스템을 의미하는 'd'에서 비롯되었습니다.

etcd 아키텍처

1. Raft 합의 알고리즘

분산 시스템 환경에서 모든 노드가 동일한 상태를 유지하도록 하고, 일부 노드에 결합이 생기더라도 전체 시스템이 문제 없이 동작하도록 만들기 위해 고안된 합의 알고리즘 이며, 아마존 DynamoDB, Redis 클러스터에서도 채택된 검증된 기술입니다.

 

동작 원리:

1-1. 리더 선출:

• 홀수 노드 구성(3/5/7)에서 과반수 투표 진행합니다.
  • etcd 의 과반수 투표 방식 과 리소스 효율성 때문에 홀수로 노드를 구성하는 것이 좋습니다.
  • 4개일 경우, 장애 허용 노드(1개)를 가지지만 2+1 추가로 노드 하나를 더 운영해야 함에 리소스 낭비가 발생합니다.

전체 노드 수	필요 과반 수	허용 가능한 장애 노드 수
3	2	1
4	3	1
5	3	2

 

1-2. 로그 복제:

• 리더가 쓰기 요청을 WAL(Write Ahead Log)에 기록합니다.
  • WAL(Write-Ahead Logging) 은 데이터의 안정성과 성능을 위해 변경 사항을 먼저 로그에 기록하는 시스템입니다.
• 팔로워들에게 병렬로 전파 → 과반수 승인 시 커밋합니다.

2. 클러스터 구성의 실제

# 3노드 클러스터 설정 예시 (노드1 기준)
etcd --name node1 \
--listen-client-urls https://10.0.0.1:2379 \
--advertise-client-urls https://10.0.0.1:2379 \
--cert-file=/etc/etcd/server.crt \
--key-file=/etc/etcd/server.key \
--initial-cluster-token my-etcd-cluster \
--initial-cluster node1=https://10.0.0.1:2380,node2=https://10.0.0.2:2380,node3=https://10.0.0.3:2380

노드 유형:

• 리더 노드 : 모든 클라이언트 요청을 처리하고 데이터를 복제합니다.
• 팔로워 노드 : 리더의 데이터를 복제하며, 리더가 다운되면 새로운 리더를 선출합니다.

라이프사이클

사용자가 kubectl apply를 실행할 때 발생하는 내부 프로세스:

1. 쓰기 요청:
   • API 서버 → etcd 리더 노드로 PUT 요청 전송
   • 리더가 Raft ID 생성 후 팔로워들에게 전파
2. 커밋 조건:
   • (N/2)+1 노드 승인 필요 (3노드 클러스터 = 2노드 승인)
     • 쿼럼(Quorum) 이라 합니다. 분산 시스템에서 시스템의 안정성과 일관성을 보장하기 위한 최소한의 노드 수 라고 합니다.
     • 동작 예시 (3 노드 클러스터)

       정상 : 2노드 생존 -> 읽기/쓰기 가능
       위험 : 1노드 생존 -> 읽기만 가능(쓰기 불가)

   • 커밋된 데이터는 모든 노드에 영구 저장
3. 변경 알림:
   • Watch 기능이 활성화된 컴포넌트(kubelet, scheduler)에 실시간 통지합니다.

# 특정 키 감시 명령어
etcdctl watch /registry/pods/default --prefix

단계	설명	참여 노드	소요 시간	시간 복잡도
리더 선출	Raft 알고리즘 기반 선출	모든 노드	200 ms	O(1)
로그 복제	팔로워 노드 동기화	팔로워들	50 ms / 노드	O(n)
커밋 실행	실제 데이터 저장	리더만	10 ms	O(1)

 

4대 핵심 기능

1. MVCC(Multi-Version Concurrency Control)

• 모든 변경 이력을 리비전(revision) 번호로 관리합니다.
  • 리비전(revision) 번호는 파일이나 변경 사항을 순차적으로 추적하는 식별자로, 변경 이력 추적에 용이합니다.
• 특정 시점 스냅샷 조회 가능 → 디버깅/복구에 필수입니다.

# 1234 리비전 데이터 조회
etcdctl get /registry/services --rev=1234

2. 자동 장애 복구 시스템

• 리더 다운 → 0.3초 내 신규 리더 선출합니다.
• 네트워크 분할 시 쿼럼(과반수) 유지 노드만 서비스 계속 합니다.

3. 강화된 보안 계층

• TLS 1.3 암호화 통신합니다.
• 클라이언트 인증서 기반 RBAC

# 보안 설정 예시 (etcd.yaml)
client-transport-security:
  cert-file: /etc/etcd/peer.crt
  client-cert-auth: true

4. 효율적 저장소 관리

• 주기적 컴팩션(compaction)으로 오래된 리비전 삭제합니다.
• 백그라운드 조각 모집(defrag) 수행합니다.

장애 유형별 진단 및 복구 매뉴얼

Case 1: 디스크 포화 상태

• 증상: mvcc: database space exceeded 에러
• 긴급 조치:

# 저장소 확보
etcdctl compact 10000  # 10000 리비전 이전 데이터 삭제
etcdctl defrag --cluster  # 모든 노드 조각 모음

• 예방:
  • 주기적 스냅샷(etcdutl snapshot save)
  • 모니터링: etcd_mvcc_db_total_size_in_bytes 지표 추적

etcd 는 클러스터의 한 구성원이라도 quota 용량을 초과하면 모든 클러스터 구성원들에게 'alarm:NOSPACE' 알람을 발생시키기 때문에 모든 마스터 노드에서 오류를 확인할 수 있습니다.

- 예제 로그

"etcdserver: mvcc: database space exceeded"

"applying raft message exceeded backend quota"

"compact.go:124] etcd: endpoint compact failed: etcdserver: mvcc: database space exceeded"

Case 2: 네트워크 분할

• 진단:

etcdctl endpoint health --cluster
# 출력 예시: 10.0.0.1 is unhealthy (15s timeout)

• 해결:
  • 쿼럼 유지 노드만으로 클러스터 재구성
  • 장애 노드 재가입 시 etcdctl member add 사용

Case 3: 리더 과부하

• 증상: 높은 쓰기 지연(>500ms), CPU 90% 이상
• 대응:
  • API 서버의 --max-requests-inflight 값 조정
  • etcd 노드 증설(3 → 5노드) 및 스케일 아웃

 

감사합니다.