190. 스플릿 브레인 (Split Brain) 방어 주키퍼 (ZooKeeper) 펜싱 합의 코디 연계망

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

본질: 스플릿 브레인(Split Brain)은 네트워크 파티션(분할) 발생 시 클러스터가 두 개 이상의 독립 그룹으로 나뉘어 각자 리더라고 주장하며 이중 쓰기(Dual Write)를 일으키는 분산 시스템의 가장 위험한 장애 패턴이다.

가치: 주키퍼(ZooKeeper)의 ZAB(ZooKeeper Atomic Broadcast) 합의 프로토콜과 쿼럼(Quorum, 과반수) 메커니즘은 네트워크 분할에서도 **하나의 일관된 진실(Single Source of Truth)**을 유지하게 하는 핵심 인프라다.

판단 포인트: Kafka의 KRaft 모드(Kafka 2.8+)는 ZooKeeper 의존성을 제거하여 운영 복잡도를 낮추고 메타데이터 분산을 개선—이것이 기술사 답안에서 최신 트렌드로 반드시 언급해야 할 포인트다.

Ⅰ. 개요 및 필요성

1.1 스플릿 브레인 발생 시나리오

정상 상태: 5-노드 Kafka 클러스터
  브로커1 - 브로커2 - 브로커3 - 브로커4 - 브로커5
  [리더: 브로커1]

네트워크 파티션 발생:
  ┌── 그룹 A ──┐      ┌── 그룹 B ──┐
  │ 브로커1     │ ╳    │ 브로커4    │
  │ 브로커2     │(단절) │ 브로커5    │
  │ 브로커3     │      └────────────┘
  └────────────┘

스플릿 브레인 위험:
  그룹 A: "우리가 과반수(3/5), 브로커1이 리더 유지!"
  그룹 B: "우리도 과반수라 착각, 브로커4를 리더로 선출!"
  → 두 리더가 동시에 쓰기 수행 → 데이터 충돌!

쿼럼 메커니즘으로 방지:
  그룹 A: 3노드 (과반수 O) → 정상 운영
  그룹 B: 2노드 (과반수 X) → 운영 중단 (쓰기 거부)
  → 단일 리더만 유지 (CAP 이론의 CP 선택)

1.2 CAP 이론과 스플릿 브레인

CAP 이론 트레이드오프:
  C (Consistency):  모든 노드 동일한 데이터
  A (Availability): 모든 요청에 응답
  P (Partition Tolerance): 네트워크 분할 허용

분산 시스템은 P는 반드시 처리해야 함 → C 또는 A 선택

  CP 시스템 (ZooKeeper, HBase):
    네트워크 분할 시 → 소수 파티션 쓰기 거부 (일관성 우선)
    → 스플릿 브레인 방지 O, 일부 가용성 포기

  AP 시스템 (Cassandra, CouchDB):
    네트워크 분할에서도 모든 노드 응답 (가용성 우선)
    → 스플릿 브레인 가능, 나중에 충돌 해결(Eventually Consistent)

📢 섹션 요약 비유: 스플릿 브레인은 마치 회사가 통신 장애로 두 팀으로 나뉘어, 각 팀이 독립적으로 계약서를 수정하면 나중에 두 개의 서로 다른 계약서가 존재하는 것과 같다. 쿼럼은 "3명 중 2명 동의 없으면 서명 금지" 규칙으로 이를 방지한다.

Ⅱ. 아키텍처 및 핵심 원리

2.1 ZooKeeper ZAB (ZooKeeper Atomic Broadcast) 합의 프로토콜

ZAB 합의 프로토콜 흐름:

리더 선출 (Leader Election):
  1. 모든 노드가 자신의 서버ID + 트랜잭션ID로 투표
  2. 최신 트랜잭션ID를 가진 노드가 리더 후보
  3. 과반수(N/2 + 1) 투표 받으면 리더 확정
  4. 리더가 팔로워에게 최신 상태 동기화

정상 쓰기 흐름 (2-Phase Commit):
  클라이언트 쓰기 요청 → 리더 수신
       ↓
  리더 → 팔로워 전체에게 PROPOSAL 전송 (Phase 1)
       ↓
  과반수 팔로워 → ACK 응답
       ↓
  리더 → 전체에게 COMMIT (Phase 2)
       ↓
  클라이언트에게 성공 응답

쿼럼: 2n+1 노드 중 n+1개 응답 필요
  3노드: 2개 ACK 필요
  5노드: 3개 ACK 필요
  7노드: 4개 ACK 필요

2.2 ZooKeeper 클러스터 아키텍처

┌──────────────────────────────────────────────────────────┐
│          ZooKeeper 앙상블 (5-노드) 아키텍처                 │
│                                                           │
│  ZK-1 (리더)    ZK-2 (팔로워)    ZK-3 (팔로워)           │
│  ┌─────────┐    ┌─────────┐    ┌─────────┐              │
│  │ ZAB 리더 │◄──►│ ZAB팔로워│◄──►│ ZAB팔로워│              │
│  │ 쓰기처리  │    │ 읽기처리 │    │ 읽기처리 │              │
│  └────┬─────┘    └─────────┘    └─────────┘              │
│       │                                                  │
│  ZK-4 (팔로워)   ZK-5 (팔로워)                            │
│  ┌─────────┐    ┌─────────┐                              │
│  │ ZAB팔로워│    │ ZAB팔로워│                              │
│  │ 읽기처리 │    │ 읽기처리 │                              │
│  └─────────┘    └─────────┘                              │
│                                                           │
│  쿼럼 = 3 (5/2 + 1)                                      │
│  → ZK-1 장애 시: ZK-2~5 중 과반수로 새 리더 선출          │
│  → 최대 2개 노드 동시 장애까지 허용                         │
│                                                           │
│  ZNode 구조:                                             │
│  /kafka                                                  │
│  ├── /brokers                                            │
│  │   ├── /ids/1 (브로커 메타데이터)                        │
│  │   └── /ids/2                                          │
│  ├── /controller (현재 Kafka 컨트롤러 ID)                 │
│  └── /consumers (컨슈머 그룹 오프셋)                      │
└──────────────────────────────────────────────────────────┘

2.3 펜싱 (Fencing) 메커니즘

펜싱의 필요성:
  구형 리더(Old Leader)가 장애에서 복구 시,
  새 리더가 이미 선출된 상태에서 두 리더가 공존 가능
  → 이중 쓰기 방지를 위해 구형 리더를 강제 격리

펜싱 기법 1: 에포크 토큰 (Epoch Token / Fencing Token)
  ┌──────────────────────────────────────────────┐
  │  리더 선출 시마다 에포크 번호 증가             │
  │  에포크 5: 구형 리더 (이미 격리되어야 함)      │
  │  에포크 6: 새 리더                            │
  │                                              │
  │  스토리지 서버: 에포크 < 6인 요청 거부!        │
  │  → 구형 리더의 쓰기 자동 차단                 │
  └──────────────────────────────────────────────┘

펜싱 기법 2: STONITH (Shoot The Other Node In The Head)
  ┌──────────────────────────────────────────────┐
  │  장애 노드(구형 리더)를 물리적으로 강제 종료   │
  │  - IPMI/iDRAC/iLO로 원격 전원 차단            │
  │  - SCSI 예약(SCSI-3 PR)으로 디스크 접근 차단  │
  │  주의: 잘못 작동 시 정상 노드 종료 위험         │
  └──────────────────────────────────────────────┘

펜싱 기법 3: ZooKeeper 에페머럴 ZNode
  리더 = /leader ZNode 소유 (에페머럴)
  리더 세션 만료 시 → ZNode 자동 삭제 → 재선출
  새 리더가 ZNode 재생성 → 구형 리더는 ZNode 없음
  → 구형 리더의 쓰기 시도 시 ZooKeeper가 거부

📢 섹션 요약 비유: 펜싱은 마치 회사 사장이 교체된 후 전 사장의 출입카드를 즉시 비활성화하는 것이다. 에포크 토큰은 "새 사장은 직인 번호 6번, 5번 이하 직인은 무효" 규칙으로 전 사장의 서류 결재를 자동 차단한다.

Ⅲ. 비교 및 연결

3.1 RAFT vs ZAB 분산 합의 알고리즘 비교

항목	RAFT	ZAB (ZooKeeper)
설계 목적	이해하기 쉬운 합의	ZooKeeper 전용 합의
리더 선출	타임아웃 기반 무작위 선출	FastLeaderElection (투표 기반)
로그 복제	AppendEntries RPC	PROPOSAL + ACK + COMMIT
클라이언트 쓰기	리더만 처리	리더만 처리
클라이언트 읽기	리더 or 팔로워 (설정에 따라)	팔로워도 읽기 가능
장애 복구	로그 복제 완료 보장	트랜잭션 순서 보장
대표 구현	etcd, Consul, TiKV	ZooKeeper

3.2 Kafka ZooKeeper 의존성 vs KRaft 모드 비교

기존 Kafka + ZooKeeper 아키텍처:
  ┌──────────────────────────────────────────────┐
  │  Kafka 클러스터                               │
  │  브로커1 - 브로커2 - 브로커3                   │
  │       ↕          ↕          ↕                │
  │  ZooKeeper 앙상블 (별도 운영)                  │
  │  ZK-1 - ZK-2 - ZK-3                         │
  │  메타데이터: 브로커 목록, 토픽 설정, ISR 등     │
  └──────────────────────────────────────────────┘
  단점:
  - ZooKeeper 별도 운영 복잡도
  - 메타데이터 변경 시 ZooKeeper 병목
  - 파티션 수 100만 개 이상 시 성능 한계

Kafka KRaft 모드 (Kafka 2.8+, 3.0 프로덕션 안정):
  ┌──────────────────────────────────────────────┐
  │  Kafka KRaft 클러스터                         │
  │  컨트롤러 1 - 컨트롤러 2 - 컨트롤러 3         │
  │  (RAFT 합의 + 메타데이터 관리 통합)            │
  │  브로커 1 - 브로커 2 - 브로커 3               │
  └──────────────────────────────────────────────┘
  장점:
  - ZooKeeper 불필요 → 운영 단순화
  - 파티션 수 백만 개 이상 지원
  - 컨트롤러 페일오버 수초 → 수십 밀리초로 단축
  - 단일 보안 모델 (ZooKeeper 별도 인증 불필요)

3.3 분산 코디네이션 서비스 비교

서비스	합의	특징	주요 사용처
ZooKeeper	ZAB	성숙한 오픈소스, Hadoop 에코시스템	Kafka (구버전), HBase, Hadoop NameNode
etcd	RAFT	Kubernetes 기본 스토어	Kubernetes, CoreDNS
Consul	RAFT	서비스 디스커버리 특화	마이크로서비스 MSA
Apache Curator	ZAB (ZK 래퍼)	ZooKeeper 레시피 라이브러리	ZooKeeper 고수준 API

📢 섹션 요약 비유: KRaft 모드는 마치 회사 행정팀(ZooKeeper)이 분리되어 있던 것을 없애고, 경영진(Kafka 컨트롤러)이 직접 회사 기록을 관리하게 된 것이다. 중간 관리 비용이 줄고 의사결정이 빨라진다.

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

4.1 ZooKeeper 고가용성 배포 설계

┌──────────────────────────────────────────────────────────┐
│            ZooKeeper 엔터프라이즈 배포 아키텍처             │
│                                                           │
│  데이터센터 A           데이터센터 B           데이터센터 C  │
│  ┌──────────┐         ┌──────────┐         ┌──────────┐  │
│  │  ZK-1    │         │  ZK-2    │         │  ZK-3    │  │
│  │  ZK-2(2) │         │  ZK-4    │         │  ZK-5    │  │
│  └──────────┘         └──────────┘         └──────────┘  │
│                                                           │
│  5노드 앙상블: 최대 2개 노드 장애 허용                       │
│  데이터센터 단위 장애 시에도 쿼럼(3/5) 유지               │
│                                                           │
│  주의사항:                                               │
│  ① 홀수 노드 구성 (2n+1)                                │
│  ② 전용 SSD 사용 (fsync 지연 최소화)                     │
│  ③ NTP 동기화 필수 (타임아웃 기반 선출)                   │
│  ④ 힙 크기: 4~8GB (너무 크면 GC 정지 악화)               │
└──────────────────────────────────────────────────────────┘

4.2 스플릿 브레인 방지 종합 전략

스플릿 브레인 방지 레이어드 전략:

  레이어 1: 네트워크 인프라
  - 이중화 네트워크 (Bonding/LACP)
  - 멀티패스 네트워크 (여러 경로)
  - 네트워크 분리 모니터링

  레이어 2: ZooKeeper/합의 프로토콜
  - 쿼럼(Quorum) 기반 의사결정
  - ZAB/RAFT 합의로 단일 리더 보장

  레이어 3: 펜싱 메커니즘
  - 에포크 토큰 (애플리케이션 레벨)
  - STONITH (인프라 레벨)
  - SCSI 예약 (스토리지 레벨)

  레이어 4: 데이터 검증
  - 체크섬 검증 (CRC32)
  - 버전 벡터 (Vector Clock)
  - 쓰기 후 읽기 검증 (Write-then-Read)

4.3 기술사 답안 핵심 포인트

스플릿 브레인 / ZooKeeper 설계 시 필수 언급:
  ✓ 스플릿 브레인 정의 + 이중 쓰기 위험성
  ✓ CAP 이론: ZooKeeper는 CP 선택 (일관성 우선)
  ✓ ZAB 프로토콜: PROPOSAL → ACK(과반수) → COMMIT
  ✓ 쿼럼 계산: 2n+1 노드 구성 필요
  ✓ 펜싱 기법: 에포크 토큰 + STONITH 레이어드 방어
  ✓ KRaft 모드: Kafka 3.0+ ZooKeeper 의존성 제거
  ✓ 홀수 노드 구성 이유: 과반수 계산 용이, 동점 방지
  ✓ etcd vs ZooKeeper: Kubernetes는 etcd+RAFT 사용
  ✓ ZooKeeper 운영 주의: 전용 SSD, NTP 동기화, 힙 크기

📢 섹션 요약 비유: 스플릿 브레인 방지 레이어드 전략은 마치 은행 금고의 다중 잠금 장치와 같다. 네트워크 이중화(첫 번째 자물쇠), 쿼럼 합의(두 번째 자물쇠), 펜싱(세 번째 자물쇠) 중 하나가 뚫려도 다음 단계에서 차단한다.

Ⅴ. 기대효과 및 결론

5.1 ZooKeeper 기반 분산 코디네이션 도입 효과

효과	내용
데이터 일관성	스플릿 브레인 원천 차단으로 이중 쓰기 0
리더 선출 자동화	수동 개입 없이 수초 내 자동 페일오버
분산 잠금	글로벌 뮤텍스로 크리티컬 섹션 보호
서비스 디스커버리	동적 서비스 등록·조회 (마이크로서비스)

5.2 분산 합의 기술 발전 방향

┌──────────────────────────────────────────────────────┐
│           분산 합의 기술 발전 트렌드                    │
│                                                      │
│  2006: ZooKeeper + ZAB 오픈소스 공개                  │
│  2014: etcd + RAFT (CoreOS, Kubernetes 핵심)          │
│  2019: Kafka KIP-500: KRaft 제안 (ZK 제거)           │
│  2021: Kafka 2.8: KRaft 얼리 액세스                  │
│  2022: Kafka 3.3: KRaft 프로덕션 안정화              │
│  2023: Kafka 3.7: ZooKeeper 지원 완전 제거 예고       │
│                                                      │
│  트렌드:                                              │
│  → 합의 알고리즘 내재화 (외부 ZK 의존 제거)            │
│  → RAFT 우세 (이해 쉬움, 구현 라이브러리 풍부)          │
│  → 분산 합의의 클라우드 네이티브화 (etcd + K8s)        │
└──────────────────────────────────────────────────────┘

5.3 분산 시스템 설계 원칙 요약

원칙	구현 방법
홀수 노드 구성	2n+1 노드로 쿼럼 계산 단순화
레이어드 펜싱	에포크 토큰 + STONITH + 스토리지 예약
장애 허용 설계	최대 n개 노드 장애 허용 (n = (클러스터 크기-1)/2)
합의 내재화	ZooKeeper 외부 의존 → KRaft 내재화

📢 섹션 요약 비유: 분산 합의의 발전은 마치 회사 이사회 구조 발전과 같다. 처음엔 외부 공증 회사(ZooKeeper)에게 의사결정 기록을 맡겼지만, 이제는 이사회(Kafka 컨트롤러) 자체에 기록과 합의 권한을 내재화하여 더 빠르고 효율적으로 운영하는 방향으로 발전했다.

📌 관련 개념 맵

관계	개념	설명
핵심 장애	스플릿 브레인 (Split Brain)	네트워크 분할 시 이중 리더 발생
해결 메커니즘	쿼럼 (Quorum)	과반수 노드 동의로만 결정
합의 프로토콜	ZAB (ZooKeeper Atomic Broadcast)	ZooKeeper 전용 2-phase 합의
격리 메커니즘	펜싱 (Fencing)	구형 리더 강제 격리
이론 기반	CAP 정리	일관성/가용성/파티션 허용 트레이드오프
비교 알고리즘	RAFT	etcd, Consul, KRaft의 합의 알고리즘
최신 트렌드	KRaft (Kafka RAFT)	Kafka 3.x+ ZooKeeper 의존성 제거
물리적 펜싱	STONITH	구형 리더 원격 전원 차단으로 격리

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

스플릿 브레인은 마치 반장 선거를 하다가 교실이 둘로 나뉘어, 앞쪽 학생들은 A가 반장이라 하고 뒤쪽 학생들은 B가 반장이라고 주장하는 상황이에요—두 명이 동시에 반장 노릇을 하면 학급이 혼란에 빠지는 것처럼 데이터베이스도 엉망이 돼요.

📈 관련 키워드 및 발전 흐름도

분산 시스템 네트워크 파티션 발생
    │
    ▼
스플릿 브레인: 두 리더가 동시 존재 → 데이터 불일치
    │
    ▼
방어 메커니즘
    ├─► 쿼럼 (Quorum): 과반수 합의 (N/2+1)
    ├─► 펜싱 (Fencing): 이전 리더 강제 차단 (STONITH)
    └─► ZooKeeper · etcd: 분산 코디네이터
    │
    ▼
CAP 정리: Consistency vs Availability 트레이드오프
    │
    ▼
Raft · Paxos 합의 알고리즘 → 안전한 리더 선출

쿼럼은 "반 전체 30명 중 16명 이상이 동의해야 반장이 된다"는 규칙이에요—교실이 둘로 나뉠 때 한쪽이 16명 이상이어야만 반장을 선출할 수 있어서, 양쪽 동시에 반장이 나오는 일이 없어요.
펜싱은 새 반장이 뽑힌 후 전 반장의 교실 열쇠와 반장 도장을 즉시 회수하는 것처럼, 구형 리더가 실수로 데이터를 건드리지 못하게 물리적으로 차단하는 방법이에요.