etcd 심층 분석: 쿠버네티스의 모든 상태 데이터는 어떻게 저장되는가?

etcd 심층 분석: 쿠버네티스의 모든 상태 데이터는 어떻게 저장되는가?

쿠버네티스 아키텍처를 하나의 거대한 유기체로 비유할 때, 컨트롤 플레인의 중심에서 모든 기억과 상태를 관장하는 심장부이자 중추 신경망 역할을 하는 것이 바로 etcd입니다. etcd는 단순한 데이터베이스가 아닙니다. 고가용성을 보장하고 강력한 일관성(Strong Consistency)을 유지하는 분산 키-값(Key-Value) 저장소로, 쿠버네티스 클러스터의 '단일 진실의 공급원(Single Source of Truth)'입니다. 클러스터 내에 존재하는 파드의 개수, 노드의 상태, 시크릿(Secret) 데이터, 그리고 서비스 라우팅 정보 등 모든 선언적 명세와 런타임 상태 데이터는 오직 etcd에만 영구적으로 기록됩니다. 이 가이드에서는 etcd가 내부적으로 데이터를 어떻게 관리하고, 분산 환경에서 어떻게 일관성을 유지하는지 심층적으로 분석합니다.

1. Raft 합의 알고리즘 (Raft Consensus Algorithm)

etcd가 단일 장애점(SPOF)을 극복하고 고가용성을 유지할 수 있는 핵심 비결은 Raft 합의 알고리즘에 있습니다. 분산 시스템에서는 네트워크 단절이나 노드 장애가 필연적으로 발생합니다. etcd는 클러스터를 구성하는 여러 노드(일반적으로 3, 5, 7대의 홀수) 중 하나를 리더(Leader)로 선출하고, 나머지 노드들을 팔로워(Follower)로 지정합니다.

클라이언트(Kube-apiserver)의 모든 쓰기(Write) 요청은 오직 리더 노드만이 처리할 수 있습니다. 리더는 데이터를 즉시 자신의 디스크에 확정(Commit)하지 않고, 먼저 팔로워 노드들에게 로그(Log) 형태로 복제(Replication)를 요청합니다. 전체 노드의 과반수(Quorum, 정족수) 이상이 로그를 성공적으로 수신했다고 응답(ACK)해야만 비로소 데이터를 최종적으로 저장소에 커밋하고 클라이언트에게 성공 응답을 반환합니다.

이러한 정족수 기반의 합의 메커니즘 덕분에 클러스터에 네트워크 파티션(네트워크 단절로 클러스터가 둘로 나뉘는 현상)이 발생하더라도, 과반수를 확보하지 못한 그룹은 새로운 리더를 선출할 수 없어 쓰기 작업이 차단됩니다. 이를 통해 분산 환경의 치명적인 문제인 스플릿 브레인(Split-Brain, 두 개의 노드가 서로 자신이 리더라고 주장하며 데이터가 엇갈리는 현상)을 완벽하게 방지하고 데이터의 무결성을 엄격하게 지켜냅니다.

2. 다중 버전 동시성 제어 (MVCC, Multi-Version Concurrency Control)

etcd v3 아키텍처의 가장 큰 특징 중 하나는 데이터를 덮어쓰지 않는다는 점입니다. etcd는 내부적으로 다중 버전 동시성 제어(MVCC)를 사용하여 데이터의 모든 변경 이력을 보존합니다.

특정 키(Key)에 대한 수정(Update)이나 삭제(Delete) 요청이 들어오면, etcd는 기존 데이터를 지우는 대신 내부적으로 리비전(Revision)이라는 전역적인 논리적 시계를 1씩 증가시키며 새로운 버전의 데이터를 추가로 생성합니다. 즉, 동일한 키에 대해 여러 버전의 데이터가 동시에 존재하게 됩니다. 이 리비전 값은 쿠버네티스 리소스 메타데이터의 resourceVersion 필드에 1대1로 매핑됩니다.

MVCC 아키텍처는 쿠버네티스 환경에 두 가지 결정적인 이점을 제공합니다. 첫째, 데이터의 과거 상태를 조회할 수 있어, API 서버가 일시적인 네트워크 지연 등으로 놓친 이벤트를 특정 시점(Revision)부터 다시 재생(Replay)하여 동기화할 수 있습니다. 둘째, 잠금(Lock) 없이 읽기 작업을 수행할 수 있으므로, 초당 수만 건씩 쏟아지는 컨트롤러들의 상태 조회(List/Get) 요청을 쓰기 작업의 지연 없이 초고속으로 처리할 수 있습니다.

3. 스토리지 백엔드 (bbolt)와 디스크 I/O 메커니즘

etcd의 논리적인 데이터가 물리적인 디스크에 저장될 때는 bbolt라는 Go 언어 기반의 B+Tree 임베디드 데이터베이스 엔진을 거칩니다. 메모리 상의 MVCC 인덱스 구조와 디스크의 bbolt 트리가 결합하여 최적의 읽기/쓰기 성능을 냅니다.

etcd의 성능을 좌우하는 가장 치명적인 요소는 디스크 I/O 대기 시간(Latency), 특히 fsync 속도입니다. 쓰기 요청이 들어오면 etcd는 데이터를 잃지 않기 위해 메모리에만 올리는 것이 아니라 미리 쓰기 로그(WAL, Write-Ahead Log) 파일에 기록하고, 이 변경 사항을 물리 디스크에 안전하게 동기화(fsync)해야 합니다. Raft 알고리즘 특성상 과반수 노드의 fsync가 완료되어야 합의가 이루어지므로, 일반적인 HDD나 성능이 낮은 클라우드 스토리지(EBS 등)를 사용하면 fsync 지연으로 인해 전체 Kube-apiserver의 응답 속도가 치명적으로 느려집니다. 따라서 프로덕션 환경의 etcd 노드는 반드시 고성능 NVMe SSD를 전용 디스크로 사용하여 구성해야 합니다.

4. gRPC 기반의 Watch 이벤트 스트리밍

쿠버네티스의 민첩한 상태 조정 루프(Reconciliation Loop)를 가능하게 하는 원동력은 etcd의 Watch API입니다. 과거 etcd v2 시절에는 클라이언트가 데이터의 변경을 확인하기 위해 주기적으로 요청을 보내는 폴링(Polling) 방식이나 무거운 HTTP/1.1 연결을 사용했습니다.

하지만 etcd v3부터는 통신 프로토콜을 HTTP/2 기반의 gRPC로 전면 개편했습니다. gRPC의 양방향 스트리밍(Bi-directional Streaming)과 멀티플렉싱(Multiplexing) 기술을 활용하여, Kube-apiserver는 단일 TCP 연결만으로 수만 개의 키(Key) 변화를 동시에 감시(Watch)할 수 있습니다.

etcd 내부의 Watcher는 특정 키나 디렉토리의 리비전 변화를 실시간으로 모니터링하다가, 변경이 발생하는 즉시 이벤트(생성, 수정, 삭제)를 gRPC 스트림을 통해 Kube-apiserver로 푸시(Push)합니다. 이 이벤트는 다시 API 서버를 거쳐 Kubelet이나 Scheduler로 전달되며, 파드의 생성이나 삭제 같은 실제 인프라의 물리적 변화를 지연 없이 즉각적으로 촉발합니다.

5. 운영을 위한 필수 메커니즘: Compaction과 Defragmentation

MVCC 기반의 아키텍처는 변경 이력을 계속 누적하므로, 방치할 경우 디스크 사용량이 무한정 증가하여 장애를 유발합니다. etcd는 기본적으로 데이터베이스 크기를 2GB(최대 8GB 설정 가능)로 엄격하게 제한하고 있습니다. 저장 공간 고갈(Quota Exceeded) 상태에 빠지면 클러스터는 즉시 읽기 전용(Read-only) 모드로 전환되며, 새로운 파드 배포가 전면 중단됩니다.

이를 방지하기 위해 두 가지 핵심 유지보수 작업이 백그라운드에서 주기적으로 실행되어야 합니다.

• 컴팩션 (Compaction): 보존할 필요가 없는 오래된 리비전의 데이터 이력을 논리적으로 삭제하여 최신 상태만 남기는 작업입니다. API 서버가 주기적으로 컴팩션을 트리거하여 과거 데이터를 정리합니다.
• 조각 모음 (Defragmentation): 컴팩션으로 인해 논리적으로 삭제된 빈 공간(Free Page)을 물리적인 디스크 용량으로 반환하는 작업입니다. 단, 조각 모음 작업 중에는 해당 etcd 노드의 읽기/쓰기가 일시적으로 차단되므로(Lock), 클러스터 운영 중에는 리더 노드를 피해 팔로워 노드부터 순차적으로 실행해야 하는 세심한 운영 전략이 요구됩니다.

etcd는 쿠버네티스의 심장입니다. 컨트롤 플레의 모든 컴포넌트가 다운되더라도 etcd의 스냅샷 데이터만 무사하다면 클러스터를 이전 상태로 완벽하게 복원할 수 있습니다. 반대로 다른 모든 것이 정상이더라도 etcd 데이터가 손상되거나 합의를 잃으면 클러스터는 통제 불능 상태에 빠집니다. 따라서 etcd의 아키텍처를 정확히 이해하고 스토리지 성능 확보, 주기적인 스냅샷 백업(Snapshot Save), 그리고 조각 모음을 자동화하는 것은 엔터프라이즈 쿠버네티스 운영에 있어 타협할 수 없는 최우선 과제입니다.