분산 락 (Distributed Lock)과 ZooKeeper 합의 동기화

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

본질: 분산 락(Distributed Lock)은 단일 서버의 메모리(RAM) 위에서 동작하던 전통적인 OS 락(Mutex)의 한계를 넘어, 수십 대의 물리적으로 떨어진 서버들이 네트워크를 통해 하나의 공유 자원에 순차적으로 접근할 수 있도록 통제하는 클러스터 동기화 메커니즘이다.

가치: 네트워크 단절(Split Brain), 서버 다운 등 예측 불가능한 분산 환경의 혼돈 속에서도, **"오직 단 하나의 클라이언트만이 락을 쥘 수 있다"는 상호 배제(Mutual Exclusion)**를 완벽하게 보장하여 데이터의 오염과 동시성 파괴를 막아낸다.

융합: 이를 구현하기 위해 Apache ZooKeeper는 ZAB(Zookeeper Atomic Broadcast)라는 뗏목(Raft/Paxos) 기반의 과반수 합의(Consensus) 알고리즘과, 순차적 임시 노드(Ephemeral Sequential Znode)라는 트리 구조의 파일 시스템 철학을 융합해 절대 무너지지 않는 코디네이터를 창조했다.

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

개념:
- 단일 락 (Local Lock): 한 대의 컴퓨터 안에서 여러 스레드가 싸울 때 OS 커널이 정리해 주는 자물쇠 (예: Java synchronized, pthread_mutex).
- 분산 락 (Distributed Lock): 컴퓨터 A, B, C가 각자 독립된 프로세스로 도는데, 셋이 동시에 데이터베이스의 같은 줄(Row)을 수정하려 할 때, 제3의 중앙 통제 서버(ZooKeeper, Redis)를 두고 먼저 락을 획득한 놈만 들어가게 해주는 원격 자물쇠.
필요성(문제의식):
- 1번 서버(결제망)와 2번 서버(결제망)가 있다. 둘 다 동시에 "홍길동의 잔액 100만 원"을 읽고, 각각 50만 원씩 빼서 50만 원으로 업데이트했다. 100만 원을 썼는데 잔액이 50만 원이 남는 대참사(Race Condition)가 발생한다.
- 1번 서버의 RAM에 락을 걸면 2번 서버는 그 락을 볼 수가 없다(메모리 고립).
- 해결책: "서버 밖에다가 자물쇠 보관함(분산 락 서버)을 따로 짓자. 1번이든 2번이든 돈을 빼기 전에 반드시 자물쇠 보관함에 가서 열쇠를 하나만 꺼내 오게 만들자!"
💡 비유:
- 단일 락: 한 가족이 화장실을 쓸 때, 문에 달린 걸쇠(Mutex) 하나만 잠그면 다른 가족이 못 들어온다.
- 분산 락: 아파트 전체가 공용 화장실을 하나 쓴다. 각자의 집에선 남이 화장실에 갔는지 알 수 없다. 그래서 아파트 1층 경비실(ZooKeeper)에 '화장실 열쇠'를 딱 하나 놔두고, 누구든 화장실을 가려면 경비실까지 내려와서 그 열쇠를 가져가야만(분산 락 획득) 쓸 수 있게 만든 철저한 관리 시스템.
등장 배경:
- Hadoop, Kafka 같은 거대 빅데이터 클러스터가 등장하면서, 수천 대의 노드 중 "누가 리더(마스터)를 할 것인가?"를 정하거나 설정값을 동기화하기 위한 100% 신뢰 가능한 제3의 중재자(Coordinator)가 필요해져 Yahoo! 에서 개발되었다.

  ┌─────────────────────────────────────────────────────────────┐
  │                 단일 서버 락(Local) vs 분산 락(Distributed)의 구조 차이 │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │  [ 전통적 Local Lock - RAM 내부 통제 ]                        │
  │   ┌─── Server A ──────────────────────┐                     │
  │   │  Thread 1 ─▶ [ Mutex (RAM) ] ◀─ Thread 2             │
  │   └───────────────────────────────────┘                     │
  │   ※ 문제: Server B가 켜지면 Server A의 Mutex를 볼 수 없음.          │
  │                                                             │
  │  [ 분산 락 (ZooKeeper 기반) - 네트워크 통제 ]                    │
  │                 ┌─── ZooKeeper Cluster ───┐                 │
  │                 │ ┌───┐   ┌───┐   ┌───┐ │                 │
  │                 │ │ZK1│   │ZK2│   │ZK3│ │                 │
  │                 │ └───┘   └───┘   └───┘ │                 │
  │                 └─────────▲───────────┘                 │
  │              "내가 먼저 락 만들었음!"│                            │
  │   ┌─── Server A ───┐          │          ┌─── Server B ───┐ │
  │   │   Process 1    │──────────┴──────────│   Process 2    │ │
  │   └────────────────┘      (네트워크)       └────────────────┘ │
  └─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 그림에서 가장 눈여겨볼 점은 주키퍼(ZooKeeper) 자체가 1대의 서버가 아니라 3대, 5대의 클러스터(홀수)로 구성되어 있다는 것이다. "자물쇠 보관함을 1개만 뒀다가 그 보관함에 불이 나면(SPOF, 단일 장애점) 아파트 화장실을 영원히 못 쓰게 되지 않을까?" 분산 시스템 아키텍트들은 이를 막기 위해 보관함 자체를 3개로 복제해 두고, 3명 중 2명(과반수, Quorum)이 "A가 열쇠를 가져갔어"라고 합의(Consensus)해야만 진짜로 열쇠를 내어주는 극강의 복원력(Fault Tolerance)을 부여했다.

📢 섹션 요약 비유: 경비원(단일 서버) 한 명에게 열쇠 관리를 맡겼다가 경비원이 기절하면 끝장입니다. 그래서 경비원 3명을 고용해서(ZooKeeper 클러스터), 항상 2명 이상(과반수)이 도장을 찍어야만 열쇠를 내어주는 안전장치를 마련한 것입니다. 1명이 기절해도 나머지 2명이 멀쩡히 업무를 이어갑니다.

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

ZooKeeper의 Znode 트리 파일 시스템 모델

주키퍼는 락(Lock) 전용 API가 따로 없다. 대신 유닉스의 파일 시스템처럼 폴더와 파일을 만들 수 있는 **Znode(지노드)**라는 트리를 제공하고, 그 특징을 조립하여 락을 만든다.

Ephemeral (임시 노드): 이 노드를 만든 클라이언트와 주키퍼 사이의 네트워크(세션)가 끊어지면, 주키퍼가 1초 만에 이 노드를 자동으로 삭제해 버린다. (클라이언트가 락을 쥐고 죽었을 때 무한 데드락에 빠지는 것을 막아주는 생명줄).
Sequential (순차 노드): 노드를 만들 때 이름 끝에 000001, 000002 처럼 증가하는 순번을 주키퍼가 원자적으로(Atomic) 붙여준다.

분산 락 획득 시퀀스 (Herd Effect 방어)

수천 대의 서버가 락을 잡기 위해 주키퍼에 몰려들 때 어떻게 부하를 막고 줄을 세우는가?

  ┌───────────────────────────────────────────────────────────────────┐
  │                 ZooKeeper 순차적 임시 노드 기반의 분산 락 시퀀스         │
  ├───────────────────────────────────────────────────────────────────┤
  │                                                                   │
  │   [ 락(Lock)을 획득하기 위한 대기열 폴더: `/mylock` ]                  │
  │                                                                   │
  │   1. Server A, B, C가 동시에 `/mylock/req-` 라는 노드를 생성 시도!      │
  │                                                                   │
  │   2. 주키퍼가 순번표(Sequential)를 원자적으로 발급함:                     │
  │      Server A: `/mylock/req-000001` 생성 성공!                       │
  │      Server B: `/mylock/req-000002` 생성 성공!                       │
  │      Server C: `/mylock/req-000003` 생성 성공!                       │
  │                                                                   │
  │   3. 락 획득 판단 👑:                                                │
  │      - 자기가 만든 번호가 `/mylock` 폴더 안에서 가장 작은 번호인가?           │
  │      - Server A: "내가 1번이네! 내가 Lock 획득!" ──▶ 작업 시작!         │
  │                                                                   │
  │   4. 줄 서기 (Watch 걸기) 👀:                                        │
  │      - Server B: "난 2번이네. 내 앞번호인 1번 노드에 알람(Watch) 걸고 자야지."│
  │      - Server C: "난 3번이네. 내 앞번호인 2번 노드에 알람(Watch) 걸고 자야지."│
  │                                                                   │
  │   5. 락 해제 (Unlock) 및 알람 발송 🔔:                               │
  │      - Server A가 작업을 끝내고 `000001` 노드를 삭제함.                 │
  │      - 주키퍼: "어? 1번 지워졌다!" -> 1번을 감시하던 Server B만 깨움!     │
  │      - Server B: "오예! 내 앞놈이 갔네! 이제 내가 1빠다! Lock 획득!"      │
  └───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 초창기 분산 락은 A가 락을 만들면, B~Z까지 1만 대의 서버가 전부 A만 감시(Watch)했다. A가 락을 풀고 죽는 순간, 1만 대의 서버가 동시에 "내가 락 잡을 거야!" 라며 주키퍼에게 1만 개의 트래픽 폭탄을 날리는 **허드 이펙트(Herd Effect, 소떼 현상)**가 터져 주키퍼가 뻗어버렸다. 위 다이어그램의 순차 노드 방식은 이 재앙을 막기 위해 "자기 바로 앞 번호의 뒷통수만 쳐다보고 기다려라"라고 줄을 세운 것이다. A가 빠지면 B만 깨어나고 C는 계속 잔다. 이 우아한 연결 리스트형 줄 서기 덕분에 주키퍼는 수만 대의 서버 트래픽을 평온하게 감당할 수 있다.

📢 섹션 요약 비유: 은행 창구에서 100명이 줄을 안 서고 눈치만 보다가, 1번 손님이 나가면 100명이 동시에 창구로 달려드는 아수라장(허드 이펙트)을 막기 위해, 은행 입구에 번호표 기계(순차 노드)를 두고 "자기 앞번호가 불릴 때만 일어나라"고 철저한 질서를 부여한 시스템입니다.

Ⅲ. 융합 비교 및 다각도 분석

3대 분산 락 솔루션의 아키텍처 비교 (ZooKeeper vs Redis vs DB)

인프라 아키텍트는 락의 중요도와 속도 요구사항에 따라 어떤 솔루션을 쓸지 정해야 한다.

비교 항목	RDBMS (MySQL)	Redis (Redlock)	ZooKeeper (CP/ZAB)
저장소	하드 디스크 (매우 느림)	메모리 (매우 빠름)	메모리 + 디스크 동기화 (보통)
일관성(Consistency) 수준	강한 일관성 (DB 락)	낮음. 비동기 복제라 마스터 죽을 때 락 정보가 유실되어 두 명이 락을 잡을 수 있음.	절대적 강한 일관성. 과반수가 투표(Commit)해야만 락이 생성되므로 무결점 100%.
장애 복구 (Deadlock 방지)	트랜잭션 타임아웃 롤백	TTL(초 단위 생존 시간)로 무조건 풀리게 함	임시 노드(Ephemeral) 기술. 세션(TCP) 끊어지면 즉시 삭제됨. (가장 우아함)
주 사용처	영세한 스타트업, 트래픽 적음	캐시, 선착순 이벤트 등 가벼운 중복 방어	금융망, 클러스터 리더 선출, 절대 무결성 보장

과목 융합 관점

네트워크 (스플릿 브레인, Split-Brain): 네트워크 스위치 고장으로 5대의 클러스터가 [A, B] 와 [C, D, E] 두 개의 섬으로 찢어졌다고 치자. A, B 쪽에 붙어있던 클라이언트가 "내가 락 잡을래!"라고 외쳐도, A, B는 5명 중 2명밖에 안 되어 과반수(3표 이상)를 못 채우므로 락 생성을 100% 거부(Reject)한다. 오직 3명이 살아남은 [C, D, E] 쪽만 락을 허용한다. 이 정족수(Quorum) 합의 융합 덕분에 네트워크가 찢어져도 락이 2개가 생성되는 스플릿 브레인(두 개의 뇌) 참사를 수학적으로 원천 봉쇄한다.
분산 데이터베이스 (PACELC 정리): CAP 정리에서 ZooKeeper는 명백한 CP (일관성과 분할 내성) 시스템이다. 만약 과반수의 서버가 죽으면, 주키퍼는 아예 응답을 멈추고 락을 못 걸게(Availability 포기) 해버린다. "잘못된 락을 두 명에게 줘서 데이터가 박살 나느니, 차라리 시스템 전체를 정지(Pause)시켜 데이터의 완벽한 무결성을 지키겠다"는 철학이다.
📢 섹션 요약 비유: Redis 락이 "대충 10초 빌려줄 테니 빨리 쓰고 반납해(타임아웃)" 라며 초고속으로 열쇠를 던져주는 패스트푸드점이라면, ZooKeeper는 "네가 살아있는지 1초마다 심장박동(세션)을 체크할 거고, 우리 직원 3명 중 2명이 동의해야만 열쇠를 주겠다"는 철통 보안의 스위스 은행 금고입니다.

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

실무 시나리오 및 트러블슈팅

시나리오 — Redis Redlock의 배신과 데이터 오염 사태: 수강 신청 선착순 10명 시스템을 Redis 분산 락으로 짰다. 대박이 나서 트래픽이 몰렸는데 12명이 수강 신청에 성공해 버렸다.
- 원인 분석: 스레드 A가 Redis에서 락을 5초 만기로 얻고 작업을 하다가, JVM의 거대한 Garbage Collection(Stop-the-world)이 터져 7초 동안 기절해버렸다. Redis는 5초 뒤에 락을 풀어버렸고, 스레드 B가 락을 잡고 수강 신청을 했다. 2초 뒤 깨어난 스레드 A는 자기가 아직도 락을 쥔 줄 알고 수강 신청 DB에 Insert를 때려버려 락의 상호 배제가 완전히 깨진 것이다.
- 아키텍트 판단 (Zookeeper + Fencing Token 도입): GC 멈춤(Pause) 같은 시간 지연 앞에 완벽한 분산 락은 없다. 아키텍트는 주키퍼의 락을 쓰되, 주키퍼가 락을 줄 때 순차 번호(Znode의 00001 같은 순번, Fencing Token)를 같이 주도록 설계한다. DB에 데이터를 쓸 때 "내가 들고 온 토큰 번호가 최신 번호일 때만 Insert 해라!"는 조건을 건다. 기절했다 깨어난 스레드 A가 구형 1번 토큰을 들고 DB에 가면, DB가 "아까 B가 2번 토큰 들고 이미 왔다 갔어. 넌 늦었어!"라며 쳐내는 완벽한 이중 방어망을 구축한다.
시나리오 — 주키퍼(ZooKeeper) 클러스터의 Session Timeout 빈발과 락 증발: 클러스터 노드 100대가 주키퍼와 통신하며 락을 잡고 있는데, 자꾸 "Session Expired" 에러가 뜨면서 주키퍼가 임시 노드(Ephemeral)를 지워버려 락이 허공으로 날아간다.
- 원인 분석: 주키퍼는 클라이언트가 일정 시간(틱) 동안 하트비트(Ping)를 안 보내면 "어? 얘 죽었네!" 하고 락을 뺏어버린다. 문제는 클라이언트가 안 죽었는데 네트워크 스위치에 일시적 지연이 생겼거나 서버에 부하가 걸려 핑(Ping)을 늦게 보낸 것이다. 주키퍼의 tickTime과 syncLimit이 너무 빡빡하게 조여져 있으면 멀쩡한 앱의 락을 뺏어버리는 참사가 일어난다.
- 아키텍트 판단 (하트비트 튜닝 및 Jute Max Buffer 조정): 네트워크 지연이 잦은 환경이라면 주키퍼 서버의 tickTime을 늘리고 클라이언트의 세션 타임아웃을 넉넉히(예: 10초 이상) 잡아줘야 한다. 또한 락 정보가 담긴 znode의 데이터가 너무 크면 직렬화(Jute) 버퍼 병목으로 핑이 밀리므로, 락 노드 안에는 어떠한 뚱뚱한 페이로드(데이터)도 저장하지 말고 순수하게 1바이트짜리 껍데기만 남겨 통신 오버헤드를 제로에 가깝게 최적화해야 한다.

  ┌───────────────────────────────────────────────────────────────────┐
  │                 안전한 분산 락 시스템 설계를 위한 아키텍트 결정 트리           │
  ├───────────────────────────────────────────────────────────────────┤
  │                                                                   │
  │   [ 분산 서버 환경에서 상호 배제(Mutex)가 필요한 비즈니스 로직이다 ]        │
  │                │                                                  │
  │                ▼                                                  │
  │      락이 뚫려서 2명이 동시에 접근했을 때 금전적 피해(결제 등)가 막심한가?       │
  │          ├─ 예 ─────▶ 🚨 [ Redis(Redlock) 금지! ZooKeeper / etcd 강제! ]│
  │          │             (비동기 복제의 데이터 유실 리스크를 절대 허용하면 안됨) │
  │          │                                                        │
  │          └─ 아니오 (크롤링 봇 중복 방지 등 약간 뚫려도 다시 하면 됨)         │
  │                │                                                  │
  │                ▼                                                  │
  │      응답 속도가 1ms 이내로 극한의 초저지연을 필요로 하는가?                   │
  │          ├─ 예 ─────▶ [ Redis 분산 락 (Lettuce / Redisson) 채택 ]   │
  │          │             (RAM 기반 단일 스레드로 극강의 레이턴시 보장)       │
  │          │                                                        │
  │          └─ 아니오 ──▶ [ RDBMS Named Lock (MySQL GET_LOCK) 타협 ]  │
  │                        (새로운 인프라 도입이 부담스러울 때 DB 하나로 퉁치기) │
  └───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 분산 락의 세계에서 "가장 빠르고 가장 안전한" 마법은 없다. 레디스는 빠르지만 과반수 합의를 포기하여 스플릿 브레인(Split-brain) 발생 시 락이 터진다. 주키퍼는 매번 3대의 디스크에 fsync를 치고 과반수 투표를 받느라(ZAB 프로토콜) 락을 얻는 데 수 밀리초가 걸려 레디스보다 느리지만, 지구가 멸망해도 락의 유일성(Uniqueness)을 지켜낸다. 아키텍트는 비즈니스 도메인이 '은행'인지 'SNS 좋아요 수'인지 정확히 파악하여 무결성과 속도의 시소 게임을 선택해야 한다.

안티패턴

주키퍼 Znode에 비즈니스 데이터(JSON, 사진)를 무식하게 저장하기: 주키퍼의 Znode는 파일 시스템처럼 생겼지만 절대 데이터베이스나 파일 서버가 아니다! Znode는 1MB 이하의 메타데이터만 담을 수 있도록 하드코딩되어 있다. 초보자가 설정 파일 전체(수 MB)를 Znode 안에 때려 박으면, 주키퍼는 매 투표(Commit)마다 그 수 메가바이트를 3대의 노드로 복제하느라 네트워크가 터지고 램이 마비되어 분산 락 기능 전체가 동반 사망한다. 락 노드에는 "이 락의 주인은 나야" 정도의 몇 바이트만 저장하고, 진짜 뚱뚱한 데이터는 무조건 MySQL이나 S3로 빼야 한다.
📢 섹션 요약 비유: 주키퍼는 국회(합의 기관)입니다. "이 법안을 통과시킬까?"라는 종이 한 장(락 껍데기)만 올리면 국회의원 3명이 1초 만에 찬반 투표를 마칩니다. 그런데 그 종이 뒤에 수백만 권의 소설책(비즈니스 데이터)을 붙여서 투표하라고 올리면 의원들이 책을 다 읽느라(복제 병목) 국회 기능이 1년 내내 마비되는 최악의 만행입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	DB 락 / Redis 락 오남용 시	ZooKeeper 기반 분산 락 적용 시	개선 효과
정성 (무결성 보장)	마스터 노드 죽을 때 락 유실 및 동시 접근	ZAB(과반수 합의)로 절대적 1인 접근 보장	결제, 재고 차감 등 치명적 금융 트랜잭션 사고 원천 방어
정량 (장애 복구 시간)	타임아웃(TTL)이 끝날 때까지 락이 잠겨있음	클라이언트 사망 시 세션 종료로 1초 내 즉각 반환	임시 노드(Ephemeral)를 통한 데드락 해방 및 리소스 회수
정량 (부하 분산)	Lock 폴링 시 1만 대 서버가 동시에 DB 폭격	앞 순번만 감시(Sequential Watch)하여 트래픽 O(1)	허드 이펙트(Herd Effect) 제거로 코디네이터 서버 생존

미래 전망

etcd와 Kubernetes의 지배: 주키퍼가 자바(Java) 기반이라 너무 뚱뚱하고 느리다는 불만이 커지자, Go 언어로 짜여 가볍고 뗏목(Raft) 알고리즘을 쓴 etcd가 등장하여 쿠버네티스의 뇌(Brain)로 완벽히 자리를 잡았다. 원리는 100% 동일하지만, REST API 지원과 클라우드 네이티브 친화성을 무기로 주키퍼의 자리를 맹렬하게 대체하고 있다.
분산 락의 인프라 내재화 (Chubby $\rightarrow$ Spanner): 구글이 만든 분산 락 시스템(Chubby)의 철학은 이제 아예 글로벌 분산 데이터베이스(Spanner) 안으로 녹아들었다. 개발자가 명시적으로 분산 락을 걸 필요도 없이, DB 자체가 원자 시계(TrueTime API)를 이용해 대륙 간 떨어진 서버들의 락 시간을 물리적으로 정렬시켜 완벽한 글로벌 트랜잭션을 알아서 쳐주는 신의 경지로 인프라가 진화했다.

참고 표준

ZAB (ZooKeeper Atomic Broadcast): 주키퍼가 분산 노드들의 의견을 100% 하나로 일치시키기 위해 팍소스(Paxos) 알고리즘을 실무에 맞게 변형하여 만든 리더 기반 원자적 브로드캐스트 프로토콜.
Apache Curator: 자바로 주키퍼 분산 락을 직접 짜면 데드락 덩어리가 되기 십상이므로, 이 위험한 락 획득/해제/재시도 로직을 넷플릭스(Netflix)가 안전하게 래핑(Wrapping)하여 전 세계 표준으로 퍼뜨린 라이브러리.

분산 락 주키퍼(ZooKeeper) 합의 동기화는 "서로를 1도 믿을 수 없는 무법천지 네트워크 세계에, 어떻게 절대 배신하지 않는 완벽한 법원(Coordinator)을 지을 것인가?"에 대한 분산 시스템 공학의 기념비적인 대답이다. 누군가 죽고, 랜선이 뽑히고, 서버가 거짓말을 하는 혼돈 속에서도 "과반수의 합의(Quorum)"라는 민주적 알고리즘을 통해 100% 단 하나의 진실(Lock)만을 빚어낸다. 이 보이지 않는 오케스트라 지휘자가 없었다면, 수만 대의 서버로 움직이는 하둡, 카프카, 쿠버네티스는 단 1초 만에 서로의 데이터를 물어뜯는 지옥으로 전락했을 것이다.

📢 섹션 요약 비유: 각자 시계가 5분씩 틀린 100명의 장님(서버)이 한 방에 모여 있습니다. 각자 "내가 먼저 도착했으니 내가 열쇠(Lock)를 쥐어야 해!"라고 우기며 싸우면 피바람이 붑니다. 이때 중앙에 앉은 3명의 지혜로운 판사(ZooKeeper 클러스터)가 투표를 통해 "네가 1번이야"라고 도장을 찍어주는 순간, 100명의 장님은 아무 불만 없이 완벽한 질서 속에 줄을 서게 되는 민주주의 합의의 마법입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
상호 배제 (Mutual Exclusion)	하나의 임계 구역에 무조건 한 명만 들어가야 한다는 운영체제의 근본 원리로, 분산 락이 네트워크 너머에서 수호하려는 절대 가치다.
스플릿 브레인 (Split-brain)	네트워크가 끊겨 두 그룹이 각자 "내가 락 쥐었어"라고 주장하는 파국으로, 주키퍼의 과반수(Quorum) 투표는 이 파국을 원천 차단한다.
허드 이펙트 (Herd Effect)	락이 풀리는 순간 1만 마리의 소 떼(서버)가 동시에 락을 잡으러 몰려와 서버를 죽이는 현상으로, 순차 감시(Sequential Watch)로 해결한다.
에피메럴 노드 (Ephemeral Node)	클라이언트의 세션이 끊기면(죽으면) 주키퍼가 알아서 그 노드(락)를 폭파시켜, 영원한 데드락을 방지하는 스마트한 생명줄이다.
뗏목 (Raft) 알고리즘	주키퍼의 ZAB과 쌍벽을 이루는 차세대 합의 알고리즘으로, etcd가 이 방식을 써서 쿠버네티스의 분산 락과 상태를 지배하고 있다.

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

100명의 친구들이 동시에 보물 상자(데이터)를 열려고 덤벼들면 쿵 부딪혀서 보물이 다 부서져 버려요! (분산 데이터 꼬임)
그래서 마을 중앙에 '주키퍼 아저씨들(3명)'을 모셔뒀어요. 친구들은 보물에 손대기 전에 아저씨들한테 가서 "저 먼저요!" 하고 번호표를 뽑아야 해요.
아저씨들 중 2명 이상(과반수)이 "그래, 네가 1번이야!"라고 도장을 찍어준 딱 1명만 보물 상자를 열 수 있어서, 아무도 안 다치고 안전하게 보물을 나눌 수 있답니다!