카카오 DKOS, Kubernetes Live Upgrade를 위한 etcd Raft 알고리즘과 유지보수 전략 공개

카카오의 Kubernetes as a Service인 DKOS는 애플리케이션 무중단 업그레이드를 위해 마스터 노드를 순차적으로 교체하는 Kubernetes Live Upgrade 방식을 채택하고 있다. 이 과정에서 etcd 서버의 추가와 삭제가 반복되므로, 안정적인 운영을 위해 etcd의 핵심인 Raft 알고리즘과 유지보수 원리를 이해하는 것이 필수적이다.

Raft 알고리즘과 Consensus 확보

etcd는 분산 환경에서 데이터 일관성을 보장하기 위해 Replicated State Machine(RSM) 구조를 사용하며, 이를 위해 Raft 알고리즘을 구현했다. Raft는 서버가 다운되더라도 응답하는 가용성(Available)과 올바른 결과를 보장하는 안전성(Safety)을 확보한다.

• 리더 선출(Leader Election): 서버는 Leader, Follower, Candidate 상태 중 하나를 가지며, Leader가 Heartbeat를 보내지 않으면 Election timeout 후 새로운 Leader를 선출한다.
• 로그 복제(Log Replication): Write 요청 시 Leader는 로그를 복제하고, Quorum(정족수, 예: 3대 서버 중 2대)만큼 복제가 완료되면 Commit을 수행한다.
• Learner 상태: 멤버 추가 시 기존 서버의 부하를 줄이고 가용성을 유지하기 위해, 새 서버는 쿼럼 계산에서 제외되는 Learner 상태로 초기화되어 로그를 동기화한 후 Follower로 승격된다.

런타임 재구성과 가용성 관리

etcd 클러스터 운영 중 서버를 추가하거나 삭제하는 Runtime Reconfiguration은 기존 로그 복제 메커니즘을 통해 이루어진다.

• 멤버 추가: 새 서버는 Snapshot과 로그를 받아 기존 서버와 동기화된다. 이 과정에서 쿼럼 숫자가 변경되며, Learner를 통해 동기화 지연으로 인한 가용성 저하를 방지한다.
• 멤버 삭제: Leader가 자신을 삭제하는 요청을 받으면, 자기 자신을 제외한 Quorum 수만큼 로그 복제를 확인한 후 Step Down하여 리더 자리를 내려놓는다. 이는 새로운 Leader 선출을 보장하기 위함이다.
• Restriction: Raft는 한 번에 하나의 멤버 변경만 허용하며, 미커밋된 Config 로그가 존재하면 새로운 변경 요청을 거절하여 일관성을 유지한다.

etcd 유지보수 및 백업 전략

etcd의 성능과 디스크 공간 관리를 위해 로그 리텐션, 컴팩션, 단편화 제거 등의 유지보수 작업이 필요하다.

• 로그 리텐션: 메모리 오버플로우를 방지하기 위해 주기적으로 Snapshot을 생성하고 메모리 로그를 Truncate한다. 기본 Snapshot 생성 주기는 100,000 로그 단위이다.
• 컴팩션(Compaction): 키의 변경 이력(Revision)을 정리하여 디스크 공간을 확보한다. Auto Compaction은 Revision 모드나 Periodic 모드로 설정할 수 있다.
• 단편화 제거(Defragmentation): Compaction으로 삭제된 공간은 실제 디스크에서 확보되지 않으므로, Defragmentation을 수행해야 한다. 이 작업 중에는 Read/Write가 차단되므로 주의가 필요하다.
• 백업 및 복구: etcdctl snapshot save 명령을 통해 무결성 해시가 포함된 백업 파일을 생성한다. 카카오 DKOS는 MetaKage 스토리지에 하루 1회 백업하며, 최근 5일간의 데이터를 보관하는 CronJob을 배포한다.