브로커 간 메시지 복제(Replication) 시 'Split Brain' 방지 원리는?

브로커 간 메시지 복제(Replication) 시 'Split Brain' 방지 원리는?

엔터프라이즈 환경에서 메시지 브로커의 고가용성(HA)을 확보하기 위해, 물리적인 공유 스토리지(SAN/NAS)를 사용하는 대신 네트워크를 통해 데이터를 실시간으로 동기화하는 '데이터 복제(Replication)' 아키텍처를 도입하는 경우가 늘고 있습니다. ActiveMQ Artemis와 같은 최신 브로커들은 마스터 노드가 수신한 모든 메시지와 트랜잭션 상태를 슬레이브 노드로 즉시 복제하여, 디스크 병목 없이 높은 성능과 가용성을 동시에 달성합니다.

하지만 네트워크 기반의 복제 시스템은 태생적으로 분산 시스템의 가장 끔찍한 재앙인 '스플릿 브레인(Split Brain)'이라는 치명적인 약점을 안고 있습니다.

이 가이드에서는 스플릿 브레인이 어떻게 데이터 정합성을 산산조각 내는지 그 파괴적인 원리를 살펴보고, 브로커가 이 딜레마를 극복하기 위해 아키텍처 내부에 구축해 둔 정교한 방어 메커니즘을 상세히 해부합니다.

---

1. 스플릿 브레인(Split Brain)의 정의와 파괴적 파급 효과

'스플릿 브레인(뇌 분열)'은 분산 클러스터 내에서 노드 간의 네트워크 연결만 끊어지고, 각 노드 자체의 전원이나 프로세스는 멀쩡히 살아있을 때 발생하는 논리적 장애입니다.

재난 발생 시나리오:

1. 마스터 브로커(A)와 슬레이브 브로커(B)가 정상적으로 복제를 수행 중입니다.
2. 갑자기 A와 B 사이를 연결하는 전용 네트워크 스위치에 장애가 발생하여 두 브로커 간의 통신이 단절됩니다.
3. 슬레이브(B) 입장에서는 마스터(A)에서 하트비트(Heartbeat)가 오지 않으므로, "마스터가 죽었다!"고 판단하고 즉시 자신을 새로운 마스터로 승격(Failover)시킵니다.
4. 하지만 마스터(A)는 죽은 적이 없습니다. 단지 B와의 연결만 끊어졌을 뿐, 클라이언트들과의 네트워크는 여전히 살아있습니다. A는 여전히 자신이 마스터라고 생각합니다.
5. 결과: 하나의 클러스터 안에 두 명의 마스터가 존재하는 '스플릿 브레인' 상태가 됩니다. 프로듀서들은 A와 B 양쪽으로 메시지를 무분별하게 쏟아내고, 컨슈머들 역시 양쪽에서 메시지를 가져가며 데이터베이스의 트랜잭션 순서와 비즈니스 로직이 완전히 파괴됩니다.

---

2. 방어선 1: Quorum(정족수) 기반의 투표 메커니즘

스플릿 브레인을 막는 가장 정석적이고 강력한 방법은 다수결의 원칙인 'Quorum(정족수)'을 도입하는 것입니다. ZooKeeper 기반의 복제나 Artemis의 내장 Quorum 기능을 사용할 때 작동하는 원리입니다.

• 최소 3대의 법칙: 정족수를 구성하려면 브로커 클러스터는 반드시 홀수(예: 3대, 5대)로 구성되어야 합니다.
• 과반수(N/2 + 1)의 동의: 네트워크가 단절되었을 때, 슬레이브는 무작정 자신이 마스터로 승격하지 않습니다. 다른 노드들에게 투표를 요청하여, 클러스터 전체 노드 중 '과반수' 이상의 표를 얻어야만 마스터가 될 수 있습니다.
• 격리 노드의 강등: 만약 3대(A, B, C) 중 마스터인 A가 네트워크에서 고립되었다면, B와 C는 통신이 가능하므로 과반수(2표)를 채워 B를 새로운 마스터로 승격시킵니다. 고립된 A는 자신이 과반수와 통신할 수 없음을 깨닫고 즉시 마스터 권한을 내려놓고 클라이언트의 연결을 끊어버립니다. 이를 통해 두 명의 마스터가 공존하는 것을 완벽하게 차단합니다.

---

3. 방어선 2: Network Pinger (네트워크 타이 브레이커)

하지만 예산이나 인프라 제약으로 인해 브로커를 3대 구성하지 못하고, 오직 2대(Master 1, Slave 1)로만 운영해야 하는 경우가 많습니다. 2대 구성에서는 1대가 죽었을 때 남은 1대가 과반수를 넘길 수 없으므로 투표 시스템 자체가 성립하지 않습니다.

이 한계를 극복하기 위해 Artemis는 'Network Pinger'라는 매우 실용적인 검증 장치를 제공합니다.

• 동작 원리: 브로커 설정(broker.xml)에 신뢰할 수 있는 제3의 외부 IP 주소(예: IDC의 메인 게이트웨이 라우터, 또는 사내망 DNS 서버)를 지정해 둡니다.
• 상황 판단 (Tie-Breaker): 마스터와 슬레이브 간의 연결이 끊어졌을 때, 슬레이브는 즉시 승격하지 않고 지정된 외부 IP(게이트웨이)로 Ping을 날려봅니다.
• 스스로의 고립 확인: * 만약 슬레이브가 게이트웨이로 Ping을 보냈는데 응답이 없다면? "아, 마스터가 죽은 게 아니라 내가 속한 네트워크 대역이 통째로 고립되었구나"라고 판단하여 승격을 포기합니다.
  • 반대로 게이트웨이 Ping은 정상인데 마스터만 안 보인다면? "마스터 서버가 진짜 죽었구나"라고 판단하여 안전하게 자신을 마스터로 승격시킵니다.
• 이 간단한 Ping 테스트 하나가 2대 구성의 클러스터에서 스플릿 브레인을 방지하는 핵심 타이 브레이커(Tie-Breaker) 역할을 수행합니다.

---

4. 방어선 3: Fencing (펜싱)과 노드 강제 격리

새로운 마스터가 안전하게 선출되었다 하더라도, 잠시 기절했던 구(Old) 마스터가 갑자기 네트워크에 다시 연결되며 깨어나는 순간 문제가 발생할 수 있습니다. 이미 새로운 마스터가 데이터를 처리하고 있는데, 구 마스터가 과거의 상태를 가지고 클라이언트 연결을 수락하려 들 수 있기 때문입니다.

이를 차단하기 위해 아키텍처에는 'Fencing(펜싱, 울타리 치기)'이라는 개념이 적용됩니다.

• 자발적 격리: 구 마스터가 네트워크에 다시 합류하면, 가장 먼저 현재 클러스터의 Quorum 상태를 확인합니다. 자신이 과반수에서 밀려났거나 새로운 마스터가 존재함을 인지하는 즉시, 구 마스터는 자신의 리스닝 소켓을 스스로 닫아버리고 브로커 상태를 강제로 슬레이브(Passive)로 전환합니다.
• 복구 프로세스 (Failback 준비): 슬레이브로 강등된 구 마스터는 자신이 멈춰있던 시간 동안 신규 마스터가 처리한 메시지 이력을 네트워크를 통해 쭉 내려받아(Synchronization) 데이터를 최신 상태로 맞춥니다. 동기화가 끝나야만 비로소 예비 슬레이브로서의 역할을 다시 시작하게 됩니다.

---

5. 아키텍처 설계 시의 모범 튜닝 가이드

완벽한 Replication HA를 구축하려면 브로커 설정에서 네트워크 타임아웃 밸런스를 매우 정교하게 조율해야 합니다.

1. 하트비트 주기의 최적화 (connection-ttl):
   마스터와 슬레이브가 서로의 생사를 확인하는 주기가 너무 짧으면(예: 1초), 네트워크 스위치의 찰나의 흔들림에도 불필요한 페일오버(Failover)가 발생하여 시스템이 널뛰기(Flapping)를 하게 됩니다. 비즈니스 허용 범위 내에서 10초~30초 정도의 넉넉한 유예 시간을 주어 일시적 장애에 면역력을 갖춰야 합니다.
2. 클라이언트 재접속(Reconnect) 지연 설정:
   클라이언트 애플리케이션은 브로커와의 연결이 끊겼을 때 즉각적으로 에러를 내뿜거나 다른 노드를 찾지 않도록, initialConnectDelay와 재시도 횟수를 적절히 주어 브로커 클러스터가 Quorum 투표를 마치고 새로운 마스터를 띄울 수 있는 물리적인 시간을 벌어주어야 합니다.
3. 체크포인트(Check-point) 네트워크 분리:
   복제 트래픽(대용량 메시지 전송)과 상태 체크용 투표 트래픽(Heartbeat)이 동일한 네트워크 인터페이스 카드(NIC)를 사용하면, 대용량 파일 전송 중 대역폭이 고갈되어 하트비트가 지연되고 억울하게 마스터 권한을 박탈당할 수 있습니다. 가급적 복제망과 관리망(Quorum 망)을 물리적으로 분리하는 것이 가장 안전한 인프라 설계입니다.

---

결론적으로 분산 시스템에서 '복제'는 마법이 아닙니다. 스플릿 브레인이라는 거대한 위험을 안고 있으며, 이를 회피하기 위해 Quorum, Network Pinger, Fencing이라는 3중 안전장치가 톱니바퀴처럼 맞물려 돌아가고 있습니다. Replication HA를 설계할 때는 반드시 이 검증 장치들이 인프라의 네트워크 토폴로지(Gateway 위치, 노드 개수)에 맞게 올바르게 설정되었는지 최우선으로 점검하시기 바랍니다.