etcd (엣시디) - 쿠버네티스의 불멸을 보장하는 뇌(Brain)와 분산 Key-Value 스토리지

핵심 인사이트 (3줄 요약)

본질: etcd(엣시디)는 쿠버네티스(K8s) 클러스터의 마스터 노드(Control Plane) 안에서 작동하는 유일무이한 고가용성 분산 Key-Value(키-값) 데이터베이스로, 클러스터에 배포된 모든 파드(Pod), 노드, 시크릿(Secret), 네트워크 상태 등 K8s의 "어제와 오늘과 미래의 모든 영구적 기억(상태 정보)"을 저장하는 뇌(Brain)의 핵심 장기다.

가치: K8s 클러스터의 API 서버나 스케줄러가 터지더라도 재부팅하면 살아나지만, etcd 디스크 데이터가 날아가거나 깨지면 수천 대의 워커 노드 위에서 쌩쌩하게 돌아가던 수만 개의 컨테이너 클러스터 자체가 1초 만에 영원히 뇌사(좀비) 상태로 멸망해 버리는, 절대 죽어서는 안 되는(SPOF 방어 0순위) K8s 백엔드의 궁극적 단일 진실 원천(SSOT)이다.

융합: 절대 죽지 않는 불멸성을 쟁취하기 위해, etcd는 홀수 대수(3대, 5대)의 클러스터로 다중화(HA)되어 구성되며, 자기들끼리 0.1초 단위로 투표하여 리더(Leader)를 뽑고 데이터를 완벽히 똑같이 복제하는 분산 합의 알고리즘의 제왕 **'뗏목(Raft) 알고리즘'**과 아키텍처 레벨에서 융합되어 있다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 영어 /etc(리눅스 설정 파일 폴더)와 d(분산, Distributed)의 합성어다. K8s의 대장인 API Server가 "웹 서버 5개 띄워"라는 명령을 받으면, 묻지도 따지지도 않고 etcd 데이터베이스 금고에 달려가 {"desired_pods": 5, "current_pods": 2} 라는 JSON 형태의 키-값을 하드디스크에 영구 박제(Commit)해 둔다. 오직 API 서버만이 이 금고에 접근할 권한을 가진다.
필요성: 쿠버네티스 클러스터 위에는 로봇(Controller) 수백 마리가 1초 단위로 워커 노드의 상태를 쳐다보고 있다. 그런데 만약 "웹 서버를 5개 유지해라"라는 사용자의 야믈(yaml) 계약서 원본이 저장된 중앙 DB가 갑자기 정전으로 죽는다면? 로봇들은 패닉에 빠진다. "어? 내가 5개를 유지해야 하나? 3개였나? 100개였나?" 상태 정보(State)를 잃어버린 로봇들은 아무 짓도 하지 못하고 통제력을 상실한다. 클라우드 전체가 혼돈의 카오스에 빠지는 것을 막기 위해, **서버에 불이 나고 벼락이 쳐도 절대 데이터가 날아가지 않고 다른 서버에 100% 일치된 복사본이 살아 숨 쉬는 '불사조 저장소'**가 K8s의 심장부에 절대적으로 이식되어야 했다.
💡 비유: 초대형 건축 현장의 **'금고 속 유일한 마스터 설계도 원본'**과 같습니다.
- K8s의 작업 반장들(Controller)은 1분마다 공사장 중앙 금고(etcd)에 뛰어와서 설계도 원본을 쳐다봅니다. "아, 설계도(etcd)에 기둥을 5개 박으라고 쓰여 있네? 근데 현장엔 3개뿐이군. 2개 더 짓자!"
- 만약 불이 나서 금고 안의 설계도(etcd)가 재가 되어버리면? 반장들은 현장에 기둥이 3개가 있든 10개가 무너지든, 설계도가 없으니 어찌할 바를 모르고 멍하니 서서 공사장을 통째로 마비시켜 버립니다. 그래서 이 설계도를 무조건 3개의 튼튼한 금고(다중화)에 똑같이 복사해 나눠 보관하는 것입니다.
등장 배경 및 발전 과정:
1. 분산 합의 시스템의 태동: 클라우드 시대가 열리며 1대의 DB 서버로는 신뢰성이 떨어져, 구글 츄비(Chubby), 아파치 주키퍼(Zookeeper) 등 리더(Leader)를 뽑아 복제하는 분산 코디네이터 저장소가 탄생했다.
2. CoreOS의 etcd 개발 (2013년): 주키퍼는 기능이 너무 무겁고 세팅이 지옥 같았다. CoreOS(현 레드햇)가 뗏목(Raft) 알고리즘을 차용해 훨씬 가볍고 빠르며 Go 언어로 짠 etcd를 내놓으며 반란을 일으켰다.
3. K8s의 공식 심장 채택 (2015년~): 구글이 쿠버네티스를 만들 때 무겁고 복잡한 주키퍼를 버리고 직관적이고 빠른 etcd를 마스터 노드의 메인 데이터 저장소로 공식 채택하며 클라우드 제국의 유일한 황실 DB로 등극했다.
📢 섹션 요약 비유: 수만 대의 컴퓨터가 각자의 기억 상실증에 걸리지 않도록 1초도 안 쉬고 "지금 클러스터의 상태는 이래! 넌 이걸 해야 해!"라고 팩트(Fact)를 읊어주는 단 하나의 완벽한 중앙 기억 뇌세포입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

Raft(뗏목) 알고리즘을 통한 etcd 클러스터 합의 아키텍처

etcd 서버 1대(단일)는 언제든 죽을 수 있으므로 실무에선 절대 안 쓴다. 무조건 3대, 5대를 띄운다. 이 3대가 어떻게 싸우지 않고 똑같은 데이터를 유지하는지 뜯어보자.

  ┌───────────────────────────────────────────────────────────────┐
  │         Raft (뗏목) 알고리즘 기반의 etcd 다중화(HA) 분산 합의 아키텍처   │
  ├───────────────────────────────────────────────────────────────┤
  │                                                               │
  │   [ 1. 리더(Leader) 선출 - 투표의 마술 ]                         │
  │     - etcd 3대(A, B, C 노드)가 클러스터로 묶여 켜진다.                 │
  │     - 자기들끼리 "누가 대장 할래?" 타이머를 돌려 투표를 한다.             │
  │     - 👑 A노드가 과반수(Quorum, 3대 중 2대) 동의를 얻어 리더가 됨!       │
  │                                                               │
  │   [ 2. 쓰기(Write) 데이터 복제 - 엄격한 일관성 (Strong Consistency) ]│
  │     ① K8s API 서버 ─▶ "야, 팟(Pod) 5개 띄우는 걸로 DB에 적어!"       │
  │                       (명령은 무조건 리더 A노드에게만 날아간다)          │
  │     ② 리더 A노드는 지 혼자 디스크에 적지 않고, 쫄따구 B, C 노드에게        │
  │        "야! 팟 5개로 장부 써!" 라고 일제히 복사본 패킷을 날린다.          │
  │     ③ B노드가 "저도 똑같이 5개 적었습니다(ACK)!"라고 대답함.            │
  │     ④ 💡 (핵심!): 리더 A, 쫄따구 B. 과반수(Quorum)가 동의(Commit)했다!│
  │        리더 A는 그제야 맘 놓고 자기 디스크에 확정 빵! 때리고 API 서버에    │
  │        "DB 기록 완벽하게 성공했습니다!"라고 응답해 줌.                  │
  │                                                               │
  │   [ 3. 자가 치유 및 쿠오럼(Quorum) 유지 ]                        │
  │     - 벼락이 쳐서 👑리더 A노드가 통째로 불타 사라짐! (장애 발생)           │
  │     - 남은 쫄따구 B, C노드가 0.1초 만에 "어라? 리더 형님 죽었네?" 눈치챔.  │
  │     - 둘이서 다시 투표해서 과반수 찬성으로 B노드가 새 리더 👑 로 즉각 승격됨!│
  │     - 죽었던 A노드의 빈자리를 채워 무중단 K8s 서비스 100% 지속 생존 보장!   │
  └───────────────────────────────────────────────────────────────┘

[다이어그램 해설] 클라우드 인프라 엔지니어 면접 1순위 단골 질문: "왜 etcd 클러스터는 2대, 4대 짝수가 아니라 3대, 5대 홀수로만 구성하나요?" 정답은 **Quorum(과반수 정족수)**의 수학적 생존 공식에 있다. 과반수 공식은 (N/2)+1이다.

3대를 띄우면 과반수는 2대다. 서버 1대가 죽어도 2대가 살아있으니 K8s는 정상 작동(생존)한다.
만약 돈 아낀다고 4대를 띄우면? 과반수는 3대다. 똑같이 서버 1대 죽으면 3대가 살아남아 생존한다. 똑같이 장애 허용 대수가 1대인데 굳이 서버 값 비싸게 돈 낭비하며 4대를 띄울 이유가 전혀 없다! (심지어 4대일 때 네트워크가 반으로 갈라지면 2:2 동점이 되어 투표가 무한 멈추는 Split-brain 치명적 버그가 터진다) 따라서 etcd는 무조건 3대, 5대, 7대의 홀수(Odd number) 구조로 아키텍처를 잡는 것이 우주의 절대 진리다.

Ⅲ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — SSD 미장착과 과도한 IOPS로 인한 K8s 뇌사 상태: 스타트업 개발자가 AWS에서 EC2 서버 3대를 빌려 마스터 노드를 설치했다. 싸게 해보려고 하드디스크를 아주 느린 기본 마그네틱 HDD로 물려두었다. 오픈 날 이벤트 트래픽이 터지며 K8s 위에서 파드(Pod) 10,000개가 미친 듯이 생성되고 지워지기를 반복했다. 갑자기 kubectl 명령어가 30초 넘게 Time Out으로 뻗더니 클러스터 전체가 멈춰버렸다.
- 판단: API 서버 탓이 아니다. etcd의 스토리지 디스크 I/O 병목에 의한 심장 마비다. etcd는 데이터를 복제하고 합의(Raft)할 때, 그 내용이 메모리에서 날아가지 않게 무조건 디스크(하드)에 강제로 동기화 쾅쾅 찍어 넣는다(fsync). 하드가 느려서 이 쾅쾅 찍는 게 밀리면 리더 노드가 시간 초과(Timeout) 에러를 뿜고 파업해 버린다.
- 해결책: K8s 클러스터 튜닝의 제1원칙은 **"마스터 노드의 etcd 데이터 저장 경로는 무조건 분리된 초고속 NVMe SSD (AWS io2/gp3) 볼륨에 따로 꽂아 줘라"**이다. 아무리 싼 서버를 쓰더라도 etcd가 돌아가는 디스크의 IOPS(초당 쓰기 속도)만큼은 최상급으로 보장해 주어야 K8s의 두뇌가 질식하지 않고 수만 개의 컨테이너 변경 엑셀 장부를 1밀리초 만에 처리할 수 있다.
시나리오 — Etcd 스냅샷 백업 누락이 부른 100억짜리 데이터 센터 멸망: 한 회사의 온프레미스(사내 전산실) K8s 환경. 초보 인프라 직원이 명령어 kubectl delete namespace prod를 칠 때 실수로 --all 옵션을 잘못 쳤다. 1년 동안 세팅해 놓은 수백 개의 배포 파일, 서비스 IP, 비밀번호 시크릿(Secret) 리소스들이 1초 만에 K8s 상에서 영원히 증발해 버렸다. 직원은 사색이 되어 etcd를 열어 롤백(Rollback)을 시도하려 했으나 백업 파일이 하나도 없었다.
- 판단: 백업이 없는 etcd는 목숨줄(Life-line)이 끊어진 인프라다. 마스터 다중화(HA 3대)를 해놨더라도, 사용자가 쳐버린 '삭제' 명령은 0.1초 만에 3대의 etcd 노드에 똑같이 완벽하게 복제(합의)되어 3대의 데이터가 일제히 다 지워져 버린다(동기화의 함정).
- 해결책: 다중화(HA)와 백업(Backup)을 착각하면 안 된다. 무조건 리눅스의 크론탭(Cron)이나 자동화 스크립트를 써서 etcdctl snapshot save 명령어를 하루에 한 번 또는 매시간 주기적으로 실행해, etcd의 과거 스냅샷 파일을 S3 클라우드 같은 안전한 곳으로 물리적으로 빼돌려 놓아야(Archiving) 한다. 나중에 인턴이 클러스터를 통째로 폭파시키는 대형 참사가 나더라도, 어젯밤 떠놓은 이 스냅샷 파일 1개만 etcdctl snapshot restore로 밀어 넣으면 K8s는 마치 타임머신을 탄 것처럼 어젯밤의 화려하고 완벽했던 수백 개 컨테이너 상태로 1분 만에 100% 롤백되어 기적처럼 부활한다.

도입 체크리스트

Managed K8s (EKS, GKE)의 축복: 당신의 조직에 분산 시스템(Raft 알고리즘) 장애 났을 때 원인을 뜯어보고 디스크를 복구할 만한 초고수 클라우드 인프라 엔지니어가 있는가? 없다면 온프레미스로 K8s 마스터 노드를 직접 설치하고 etcd 3중화를 직접 셋팅하는 오만(Hubris)을 당장 버려라. AWS EKS나 GCP GKE 같은 완전 관리형 쿠버네티스를 돈 주고 사서 써라. 클라우드 벤더들이 보이지 않는 뒤쪽 은밀한 곳에서 etcd 노드 3대 다중화, 디스크 튜닝, 매시간 스냅샷 백업, 버전 업그레이드까지 다 대신 해주고 회사의 목숨을 살려준다. "etcd를 내 눈에 보이지 않게 감추는 것"이 스타트업 아키텍처의 제일 똑똑한 승리 공식이다.

Ⅳ. 기대효과 및 결론

정량/정성 기대효과

구분	단일 DB (MySQL 등) 설정 저장	etcd 클러스터 (Raft 알고리즘) 다중화	클라우드 안정성 폭발적 개선 효과
정량 (장애 복구율)	서버 전원/디스크 사망 시 DB 데이터 유실 및 중단	노드 1대 폭파 시 0.1초 내 새 리더 선출 지속	K8s 컨트롤 플레인 다운타임(Downtime) 제로(0) 달성
정량 (초당 연산 속도)	무거운 RDBMS 락(Lock) 지연 병목 현상	메모리/디스크 경량 최적화로 초당 수만 건 처리	K8s 내부 초거대 팟(Pod) 10,000개 실시간 갱신 레이턴시 소멸
정성 (데이터 정합성)	스플릿 브레인(Split-brain) 시 양쪽 엉뚱한 값 쓰임	과반수(Quorum) 합의 없으면 쓰기 강제 거부	클러스터 분단 시 일어나는 상태 불일치 버그 100% 원천 방어

쿠버네티스의 우주에서 etcd는 단순한 데이터베이스 깡통이 아니다. 그것은 수천 대의 서버 위에 떠 있는 수만 개의 컨테이너들이 어제 무슨 약속을 했고 오늘 어떤 상태로 살아가야 하는지를 지켜주는 **'절대 깨지지 않는 진실의 석판(Single Source of Truth)'**이다. 아무리 화려한 웹 앱을 짜고 파드를 100개 띄워도, etcd의 3대 노드 중 2대가 죽어 과반수(Quorum)가 무너지는 순간 K8s는 즉각 뇌사 상태로 식물인간이 되어버린다. 기술사는 겉으로 돌아가는 컨테이너의 춤사위에 속지 말고, 그 밑바닥 가장 어둡고 은밀한 곳에서 1밀리초마다 투표를 날리며 데이터를 강박적으로 디스크에 찍어내고 있는 etcd의 뗏목(Raft) 분산 합의 아키텍처를 신주단지 모시듯 경건하게 튜닝하고 백업해야 한다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
Raft (뗏목) 알고리즘	etcd가 3대로 띄워졌을 때 서로 "내가 대장 할래!" 싸우지 않고, 가장 빠르고 효율적으로 과반수 투표를 거쳐 리더(Leader)를 선출하고 데이터를 복제하는 천재적인 분산 수학 알고리즘.
Quorum (쿼럼, 과반수)	분산 시스템이 생존하기 위한 최소한의 살아있는 서버 숫자. 총 3대면 쿼럼은 2대, 5대면 쿼럼은 3대다. 이 숫자 밑으로 살아남으면 투표를 못 해 시스템이 패닉을 일으키며 셧다운 된다.
Split-brain (스플릿 브레인)	4대짜리 클러스터를 잘못 짰을 때, 네트워크 선이 끊겨 2대 vs 2대로 나뉜 상황. 양쪽 다 "내가 리더야!"라며 뇌가 반으로 쪼개져 똑같은 데이터를 두 개로 중복 복제해 버리는 최악의 재앙.
Kube-API Server	etcd 금고의 유일한 비밀번호를 아는 수문장. K8s의 스케줄러나 큐블릿은 etcd를 절대 직접 건드리지 못하고 무조건 이 API 서버에게 "저기 금고에 5개 띄운다고 좀 적어줘"라고 굽신대야 한다.
Key-Value Store (키-값 저장소)	오라클 같은 무거운 표(Table) 형식이 아니라, 그냥 `{"Pod_Count": 5}` 처럼 이름표와 값만 포스트잇처럼 가볍게 붙여 넣는 NoSQL 구조. 속도가 우주에서 제일 빨라 설정 저장에 찰떡이다.

👶 어린이를 위한 3줄 비유 설명

100명의 로봇이 일하는 공사장에 '절대 잃어버리면 안 되는 황금 설계도(etcd)' 1장이 있어요. 불타 없어지면 공사가 완전히 마비된답니다.
그래서 똑똑한 소장님은 황금 설계도를 3장으로 똑같이 복사해서, A, B, C 금고(다중화 클러스터)에 나눠서 몰래 숨겨놨어요!
만약 도둑이 들어서 A 금고 하나를 훔쳐 가더라도, 여전히 2개의 금고(과반수)가 안전하게 남아있으니까 1초의 망설임도 없이 완벽한 설계도 복사본을 꺼내 공사를 문제없이 계속 진행하는 튼튼한 방어 마법이랍니다!