Split-Brain 프로덕션 완벽 해결 가이드: 분산 시스템에서 두 개의 리더가 동시에 존재할 때 데이터 충돌 방지하기

정상 상태:
Cluster → 1 Leader → 모든 노드 동기화 → 일관된 데이터

Split-Brain 상태:
Cluster → Network Partition → Group A (Leader 1) ← 독립적 쓰기
 → Group B (Leader 2) ← 독립적 쓰기
 → 재연결 시 데이터 충돌! (Merge 불가능)

Step 1: 정상 클러스터
┌─────────────────────────────────┐
│ Leader: Node 1 │
│ Followers: Node 2, Node 3 │
│ 모든 쓰기가 Node 1을 통해 처리 │
└─────────────────────────────────┘

Step 2: 네트워크 파티션 발생
┌──────────────┐ ️ Network ┌──────────────┐
│ Partition A │ Partition │ Partition B │
│ Node 1 │ ←──────────→ │ Node 2 │
│ │ 연결 끊김! │ Node 3 │
└──────────────┘ └──────────────┘

Step 3: Split-Brain 발생
┌──────────────┐ ┌──────────────┐
│ Partition A │ │ Partition B │
│ Leader: Node1│ │ Leader: Node2│ ← 새 리더 선출!
│ "나만 살아있음"│ │ "Node 1 죽음" │
│ 쓰기 계속 처리│ │ 쓰기 계속 처리│
└──────────────┘ └──────────────┘
 ↓ ↓
 데이터 A 데이터 B
 (독립적) (독립적)

Step 4: 재연결 시 충돌
┌─────────────────────────────────┐
│ 데이터 A와 데이터 B가 충돌! │
│ 어느 것이 정답? │
│ Merge 불가능한 경우 많음 │
└─────────────────────────────────┘

Before:
Node 1 (Leader), Node 2, Node 3

After (Node 3 죽음):
Node 1 (Leader), Node 2 ← 여전히 과반수 (2/3)
정상 작동 계속

Before:
Node 1, Node 2, Node 3

After (Network Partition):
Group A: Node 1 ← 1/3 (과반수 아님, 하지만 자신만 본다)
Group B: Node 2, Node 3 ← 2/3 (과반수)

문제: Group A도 자신이 유일하다고 착각하면?
→ 두 그룹 모두 독립적으로 쓰기!

// Split-Brain 상황에서의 데이터 충돌

// Partition A에서:
// User가 Product 1 주문 (재고 10 → 9)
db.Exec("UPDATE products SET stock = stock - 1 WHERE id = 1")
// stock = 9

// Partition B에서 (동시에):
// 다른 User가 Product 1 주문 (재고 10 → 9)
db.Exec("UPDATE products SET stock = stock - 1 WHERE id = 1")
// stock = 9

// 재연결 후:
// 실제로는 2개 팔렸는데 stock = 9!
// 정답은 stock = 8이어야 함
// 1개 초과 판매 위험!

Initial Balance: $1,000

Partition A: 출금 $500 → Balance = $500
Partition B: 출금 $800 → Balance = $200

재연결 후:
- Last Write Wins 전략 사용 시: Balance = $200 (Partition A의 출금 무시!)
- 실제 정답: Balance = -$300 (초과 출금 발생!)
- 어느 쪽이든 틀림!

T+0s: 정상 클러스터 (1 Primary)
T+10s: 높은 네트워크 트래픽 발생
T+15s: TCP 메모리 고갈, Keepalive 실패
T+20s: Node1-Node4 간 연결 타임아웃
T+25s: Group A와 Group B 분리
T+30s: Group B가 새 Primary 선출 (Node4)
T+35s: Split-Brain 상태! (Node1 + Node4 모두 Primary)

// AIStore의 재통합 전략

type ClusterMap struct {
 Generation int // 세대 번호
 Primary NodeID // Primary 노드
 Nodes []NodeID // 클러스터 멤버
}

func reunifyCluster(partitionA, partitionB ClusterMap) {
 // 1. Generation 비교
 if partitionA.Generation > partitionB.Generation {
 // Partition A가 최신 → B를 폐기
 discardPartition(partitionB)
 return partitionA
 }

 // 2. Generation 같으면 Node ID 비교 (결정론적)
 if partitionA.Primary < partitionB.Primary {
 discardPartition(partitionB)
 return partitionA
 }

 discardPartition(partitionA)
 return partitionB
}

️ 재통합 시 한쪽 파티션의 데이터 손실!
- Partition B가 폐기되면
- Partition B에서 발생한 모든 쓰기가 사라짐
- 일부 데이터 손실은 불가피

클러스터: 5개 노드
Quorum: 3개 (5 / 2 + 1)

정상 상태:
Node 1, Node 2, Node 3, Node 4, Node 5
쓰기 요청 → 최소 3개 노드가 응답해야 성공

Network Partition:
Group A: Node 1, Node 2 ← 2개 (Quorum 미달!)
Group B: Node 3, Node 4, Node 5 ← 3개 (Quorum 달성!)

결과:
Group A: 쓰기 거부 (Quorum 없음)
Group B: 쓰기 계속 (Quorum 있음)

 Split-Brain 방지! (한쪽만 작동)

# Split-Brain 방지 설정

# Cluster 구성
cluster.name: production-cluster
node.name: node-1

# Discovery 설정
discovery.seed_hosts:
 - node-1.example.com
 - node-2.example.com
 - node-3.example.com
 - node-4.example.com
 - node-5.example.com

# Quorum 설정 (핵심!)
cluster.initial_master_nodes:
 - node-1
 - node-2
 - node-3
 - node-4
 - node-5

# Master 선출을 위한 최소 노드 수
discovery.zen.minimum_master_nodes: 3 # (5 / 2) + 1

# 이 설정으로:
# - 3개 미만의 Master-eligible 노드는 Master 선출 불가
# - Network Partition 시 과반수 그룹만 작동

5 노드 클러스터, minimum_master_nodes = 3

Scenario 1: 2-3 분할
Group A (2 nodes): Master 선출 불가 → Read-Only 모드
Group B (3 nodes): Master 선출 가능 → 정상 작동

Scenario 2: 1-4 분할
Group A (1 node): Master 선출 불가 → Read-Only
Group B (4 nodes): Master 선출 가능 → 정상 작동

Scenario 3: 3-2 분할
Group A (3 nodes): Master 선출 가능 → 정상 작동
Group B (2 nodes): Master 선출 불가 → Read-Only

 모든 경우에 최대 1개 그룹만 쓰기 가능!

# Redis Cluster Quorum 설정

# Cluster 활성화
cluster-enabled yes
cluster-txtig-file nodes.txt
cluster-node-timeout 5000

# Replica가 Master로 승격되기 위한 최소 Master 수
cluster-replica-validity-factor 10

# Cluster 구성 (3 Master + 3 Replica)
# Master 1: Node A
# Master 2: Node B
# Master 3: Node C
# Replica 1: Node D (Master A의 Replica)
# Replica 2: Node E (Master B의 Replica)
# Replica 3: Node F (Master C의 Replica)

# Redis Cluster의 Quorum 기반 Failover

# 상황: Master A 죽음

# Replica D가 승격을 시도:
# 1. 다른 Master들(B, C)에게 투표 요청
# 2. 과반수(2개) 동의 필요 (총 Master 3개)
# 3. B와 C가 동의 → Replica D가 새 Master로 승격

# Network Partition 발생:
# Group 1: Master A, Replica D
# Group 2: Master B, Master C, Replica E, Replica F

# Master A 죽음:
# Group 1: Replica D만 남음
# - 투표 요청하지만 다른 Master 없음 (Quorum 미달)
# - 승격 불가!

# Group 2: Master B, C 생존
# - 정상 작동 계속
# - 과반수 Master 존재

# Split-Brain 방지!

Follower: 평소 상태, Leader로부터 명령 수신
Candidate: Leader 선출 시도 중
Leader: 클러스터의 리더, 모든 쓰기 처리

Step 1: Follower → Candidate
- Election Timeout (150-300ms) 내에 Heartbeat 없으면
- Term 증가, 자신에게 투표, 다른 노드에 투표 요청

Step 2: 투표 수집
- 과반수 투표 받으면 Leader로 승격
- 과반수 못 받으면 다시 Follower

Step 3: Leader 작동
- 주기적으로 Heartbeat 전송 (Append Entries RPC)
- 모든 쓰기 처리, 과반수 복제 확인 후 커밋

5 노드 클러스터: Node 1 (Leader), Node 2, 3, 4, 5

Network Partition:
Group A: Node 1, Node 2 ← 2개 (과반수 아님)
Group B: Node 3, Node 4, Node 5 ← 3개 (과반수!)

Group A (Node 1 - 기존 Leader):
- Heartbeat를 Node 3, 4, 5에 전송 시도
- 응답 없음 (Network Partition)
- 과반수 응답 없으면 Leader 자격 상실!
- Follower로 강등 (Step-down)
- 쓰기 거부!

Group B (Node 3, 4, 5):
- Election Timeout 도래
- Node 3이 Candidate가 됨, Term 증가 (Term 2)
- Node 4, 5에게 투표 요청
- 2표 획득 (과반수 3/5 달성!)
- Node 3이 새 Leader 선출 (Term 2)
- 쓰기 계속 처리

재연결 시:
- Node 1 (Term 1, Old Leader)
- Node 3 (Term 2, New Leader)
- Node 1이 Node 3의 Heartbeat 수신
- Term 2 > Term 1 → Node 1이 Node 3를 Leader로 인정
- 자동 재통합!

// etcd의 Raft Leader Election

type Raft struct {
 term int // 현재 Term
 state NodeState // Follower, Candidate, Leader
 votedFor NodeID // 투표한 후보
 leader NodeID // 현재 리더
 votes int // 받은 표 수
}

func (r *Raft) startElection() {
 // 1. Term 증가
 r.term++
 r.state = Candidate
 r.votedFor = r.id
 r.votes = 1 // 자신에게 투표

 // 2. 모든 노드에게 투표 요청
 for _, peer := range r.peers {
 go func(p Node) {
 resp := p.RequestVote(r.term, r.id)

 if resp.VoteGranted {
 r.votes++

 // 3. 과반수 획득?
 if r.votes > len(r.peers)/2 {
 r.becomeLeader()
 }
 }
 }(peer)
 }
}

func (r *Raft) becomeLeader() {
 r.state = Leader
 r.leader = r.id

 // 4. Heartbeat 전송 시작
 go r.sendHeartbeats()
}

func (r *Raft) sendHeartbeats() {
 for r.state == Leader {
 successCount := 0

 for _, peer := range r.peers {
 if peer.AppendEntries(r.term, r.id) {
 successCount++
 }
 }

 // 과반수 응답 없으면 Leader 자격 상실!
 if successCount <= len(r.peers)/2 {
 r.stepDown() // Follower로 강등
 return
 }

 time.Sleep(50 * time.Millisecond) // Heartbeat interval
 }
}

version: '3'
services:
 etcd-1:
 image: quay.io/coreos/etcd:v3.5.10
 command:
 - /usr/local/bin/etcd
 - --name=etcd-1
 - --initial-advertise-peer-urls=http://etcd-1:2380
 - --listen-peer-urls=http://0.0.0.0:2380
 - --advertise-client-urls=http://etcd-1:2379
 - --listen-client-urls=http://0.0.0.0:2379
 - --initial-cluster=etcd-1=http://etcd-1:2380,etcd-2=http://etcd-2:2380,etcd-3=http://etcd-3:2380
 - --initial-cluster-state=new
 - --initial-cluster-token=etcd-cluster

 etcd-2:
 image: quay.io/coreos/etcd:v3.5.10
 command:
 - /usr/local/bin/etcd
 - --name=etcd-2
 - --initial-advertise-peer-urls=http://etcd-2:2380
 - --listen-peer-urls=http://0.0.0.0:2380
 - --advertise-client-urls=http://etcd-2:2379
 - --listen-client-urls=http://0.0.0.0:2379
 - --initial-cluster=etcd-1=http://etcd-1:2380,etcd-2=http://etcd-2:2380,etcd-3=http://etcd-3:2380
 - --initial-cluster-state=new
 - --initial-cluster-token=etcd-cluster

 etcd-3:
 image: quay.io/coreos/etcd:v3.5.10
 command:
 - /usr/local/bin/etcd
 - --name=etcd-3
 - --initial-advertise-peer-urls=http://etcd-3:2380
 - --listen-peer-urls=http://0.0.0.0:2380
 - --advertise-client-urls=http://etcd-3:2379
 - --listen-client-urls=http://0.0.0.0:2379
 - --initial-cluster=etcd-1=http://etcd-1:2380,etcd-2=http://etcd-2:2380,etcd-3=http://etcd-3:2380
 - --initial-cluster-state=new
 - --initial-cluster-token=etcd-cluster

정상 클러스터:
Node 1 (Primary), Node 2 (Standby)

네트워크 장애:
Node 2가 Node 1의 Heartbeat를 받지 못함

Node 2의 판단:
"Node 1이 죽었나? 내가 Primary가 되어야 하나?"

️ 위험 상황:
- 실제로는 Node 1이 살아있을 수 있음 (네트워크만 끊김)
- Node 2가 Primary로 승격하면 Split-Brain!

 STONITH 작동:
Node 2: "Node 1을 확실히 죽이자!"
 → IPMI/iLO를 통해 Node 1의 전원 강제 OFF
 → Node 1 완전히 종료 확인
 → Node 2가 안전하게 Primary로 승격

Cluster: node1 (Primary), node2 (Standby)

T+0s: 네트워크 파티션 발생
T+5s: node2가 node1의 Heartbeat 수신 실패
T+10s: node2가 Fence 결정
 "node1을 죽이고 내가 Primary가 되자"
T+15s: node2 → IPMI 명령 → node1 강제 종료
T+20s: node1 전원 OFF 확인
T+25s: node2가 Primary로 승격
T+30s: 단일 Primary 보장! (node1은 죽음)

재연결 시:
T+60s: 관리자가 node1 수동 재시작
T+65s: node1이 Standby로 재참여
T+70s: 정상 클러스터 복구

# Patroni (PostgreSQL HA) + Watchdog

scope: postgres-cluster
name: node1

restapi:
 listen: 0.0.0.0:8008
 connect_address: node1:8008

etcd:
 hosts: etcd1:2379,etcd2:2379,etcd3:2379

bootstrap:
 dcs:
 ttl: 30
 loop_wait: 10
 retry_timeout: 10
 maximum_lag_on_failover: 1048576

watchdog:
 mode: required # Watchdog 강제!
 device: /dev/watchdog
 safety_margin: 5

postgresql:
 listen: 0.0.0.0:5432
 connect_address: node1:5432
 data_dir: /var/lib/postgresql/14/main
 authentication:
 replication:
 username: replicator
 password: rep_password
 superuser:
 username: postgres
 password: postgres_password

초기 상태:
Leader: Node 1 (Generation 1)

Network Partition:
Group A: Node 1 (Generation 1 - Old Leader)
Group B: Node 2, 3 (새 Leader 선출 → Generation 2)

재연결 시:
Node 1 (Generation 1): "나는 Leader다!"
Node 2 (Generation 2): "너의 Generation이 낮다. 거부!"

 Node 1이 자동으로 Follower로 강등
 Node 2가 유일한 Leader

// Kafka Producer가 Epoch를 통해 Leader 검증

Properties props = new Properties();
props.put("bootstrap.servers", "broker1:9092,broker2:9092,broker3:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("acks", "all"); // 모든 Replica 확인
props.put("enable.idempotence", "true"); // Exactly-Once

KafkaProducer<String, String> producer = new KafkaProducer<>(props);

ProducerRecord<String, String> record = new ProducerRecord<>("my-topic", "key", "value");

try {
 // Producer가 Leader에게 전송
 // Leader는 응답에 Epoch 포함
 RecordMetadata metadata = producer.send(record).get();

 // 만약 Old Leader (낮은 Epoch)에게 전송 시도하면:
 // NotLeaderForPartitionException 발생!
 // Producer가 자동으로 새 Leader 발견 및 재전송

} catch (NotLeaderForPartitionException e) {
 // Old Leader 감지 → Metadata 갱신
 producer.send(record).get(); // 재시도
}

// MongoDB의 Term (Raft의 Term과 유사)

// Replica Set 상태 확인
rs.status()

// 출력:
{
 "set": "rs0",
 "members": [
 {
 "_id": 0,
 "name": "mongo1:27017",
 "stateStr": "PRIMARY",
 "electionTime": Timestamp(1699305600, 1),
 "electionDate": ISODate("2025-11-06T10:00:00Z"),
 "term": NumberLong("5") // ← Term 5
 },
 {
 "_id": 1,
 "name": "mongo2:27017",
 "stateStr": "SECONDARY",
 "syncSourceHost": "mongo1:27017",
 "term": NumberLong("5")
 }
 ]
}

// Network Partition:
// Group A: mongo1 (Term 5, Primary)
// Group B: mongo2, mongo3 (새 Primary 선출 → Term 6)

// 재연결 시:
// mongo1 (Term 5) → mongo2로부터 Heartbeat 수신
// Heartbeat에 Term 6 포함
// mongo1: "Term 6 > Term 5, 나는 더 이상 Primary 아님"
// mongo1이 자동으로 Secondary로 강등

// Split-Brain 방지!

# 잘못된 설정 (elasticsearch.yml)

# Group A와 Group B 모두:
discovery.zen.minimum_master_nodes: 2 # ← 너무 낮음!

# 5개 노드 클러스터에서 minimum_master_nodes = 2이면:
# Group A (2개): Master 선출 가능 (2 >= 2)
# Group B (3개): Master 선출 가능 (3 >= 2)
# 두 그룹 모두 독립적으로 Master 선출!

# 올바른 설정

# 5개 노드 클러스터
discovery.zen.minimum_master_nodes: 3 # (5 / 2) + 1

# 이제:
# Group A (2개): Master 선출 불가 (2 < 3)
# Group B (3개): Master 선출 가능 (3 >= 3)
# 한쪽만 작동!

# Elasticsearch

discovery.zen.minimum_master_nodes: (N / 2) + 1 # N = 총 Master-eligible 노드 수
cluster.initial_master_nodes:
 - node-1
 - node-2
 - node-3
 - node-4
 - node-5

# etcd (Raft)

--initial-cluster=etcd-1=http://etcd-1:2380,etcd-2=http://etcd-2:2380,etcd-3=http://etcd-3:2380
--initial-cluster-state=new
--heartbeat-interval=100 # 100ms
--election-timeout=1000 # 1000ms

# Redis Cluster

cluster-enabled yes
cluster-node-timeout 5000
cluster-require-full-coverage yes

# PostgreSQL Patroni

watchdog:
 mode: required
 device: /dev/watchdog
 safety_margin: 5

dcs:
 ttl: 30
 loop_wait: 10
 maximum_lag_on_failover: 1048576

# Kafka

# ZooKeeper 기반 (기존)
zookeeper.connect=zk1:2181,zk2:2181,zk3:2181
controller.socket.timeout.ms=30000

# KRaft 기반 (신규)
process.roles=broker,controller
controller.quorum.voters=1@kafka1:9093,2@kafka2:9093,3@kafka3:9093

groups:
 - name: split_brain_detection
 interval: 30s
 rules:
 # Elasticsearch Multiple Masters
 - alert: ElasticsearchMultipleMasters
 expr: count(elasticsearch_cluster_health_status{role="master"}) > 1
 for: 1m
 labels:
 severity: critical
 annotations:
 summary: "Multiple Elasticsearch masters detected - Split-Brain!"

 # etcd Multiple Leaders
 - alert: EtcdMultipleLeaders
 expr: count(etcd_server_is_leader == 1) > 1
 for: 1m
 labels:
 severity: critical
 annotations:
 summary: "Multiple etcd leaders - Split-Brain!"

 # Redis Cluster Slot txtlict
 - alert: RedisClusterSlottxtlict
 expr: redis_cluster_slots_fail > 0
 for: 5m
 labels:
 severity: warning
 annotations:
 summary: "Redis cluster has failing slots - possible Split-Brain"

 # Patroni Multiple Primaries
 - alert: PatroniMultiplePrimaries
 expr: count(pg_replication_is_replica == 0) > 1
 for: 1m
 labels:
 severity: critical
 annotations:
 summary: "Multiple PostgreSQL primaries - Split-Brain!"

{
 "panels": [
 {
 "title": "Cluster Leaders",
 "targets": [
 {
 "expr": "sum(etcd_server_is_leader)",
 "legendFormat": "etcd Leaders"
 },
 {
 "expr": "count(elasticsearch_cluster_health_status{role=\"master\"})",
 "legendFormat": "ES Masters"
 }
 ],
 "thresholds": [
 { "value": 1, "color": "green" },
 { "value": 2, "color": "red" } // Multiple leaders!
 ]
 },
 {
 "title": "Network Partition Events",
 "targets": [
 {
 "expr": "rate(node_network_transmit_drop_total[5m])",
 "legendFormat": "{{ instance }}"
 }
 ]
 },
 {
 "title": "Quorum Status",
 "targets": [
 {
 "expr": "elasticsearch_cluster_health_number_of_nodes",
 "legendFormat": "Active Nodes"
 },
 {
 "expr": "elasticsearch_cluster_minimum_master_nodes",
 "legendFormat": "Quorum Threshold"
 }
 ]
 }
 ]
}