DB는 서버 한 대의 문제가 아니라, 데이터 일관성의 문제다
AP 서버는 상대적으로 수평 확장이 쉽다. 상태를 잘 분리하면 노드를 늘리기도 쉽고, 특정 노드 장애가 전체 서비스 중단으로 직결되지 않도록 만들 수도 있다.
DB는 이야기가 다르다. DB는 단순히 요청을 처리하는 실행 노드가 아니라, 데이터의 정합성과 최종 상태를 책임지는 계층이다. 그래서 DB 이중화는 “서버를 하나 더 둔다”에서 끝나지 않는다. 반드시 이 질문으로 이어진다.
“어느 노드가 진짜인가?” “동시에 쓰기가 발생하면 어떻게 막을 것인가?” “장애 판단이 틀렸을 때 어떤 보호 장치가 있는가?”
액티브-스탠바이 — 보수적이지만 여전히 많이 쓰이는 이유
평소에는 한 대만 서비스하고, 다른 한 대는 대기하는 방식이다. 구조는 단순해 보이지만, 핵심은 “대기 노드가 있는가”가 아니라 정확하게 장애를 판단하고, 안전하게 역할을 넘길 수 있는가다.
일반적으로 이 구조에는 다음 요소가 들어간다.
- Active 노드 — 실제 서비스 제공
- Standby 노드 — 대기 상태, 필요 시 승격
- Heartbeat — 노드 간 생존 신호 확인
- Quorum / Witness / Voting Disk — 다수결 또는 제3자 판단 장치
- Fencing(STONITH) — 문제 노드를 강제로 배제하는 장치
이 중 가장 중요한 건 fencing이다. DB 이중화에서 가장 위험한 상황은 “한 노드가 죽는 것”이 아니라, 두 노드가 동시에 자신이 정상이라고 믿는 상황이기 때문이다.
스플릿 브레인 — 이중화가 오히려 더 위험해지는 순간
스플릿 브레인(Split-Brain). 두 노드가 서로를 장애로 오인하고, 각자 자신이 서비스 주체라고 판단하는 상황이다.
DB에서는 이게 치명적이다. 두 노드가 동시에 쓰기를 받기 시작하면 데이터가 갈라지고, 어느 쪽이 진짜인지 나중에 합치기 어렵다.
시나리오는 이렇다. Active와 Standby가 heartbeat로 서로를 감시하고 있었다. 네트워크 단절이 발생한다. Active는 “Standby가 죽었다”고 판단하고, Standby도 “Active가 죽었다”고 판단한다. 양쪽이 동시에 자신이 서비스 주체라고 선언하면 — 스플릿 브레인이다.
이걸 막기 위해 사용하는 게 quorum과 fencing이다.
Quorum — 제3의 판단 기준
두 노드만 서로 보는 게 아니라, witness 노드나 quorum disk를 두고 누가 다수의 연결성을 확보했는지 판단한다.
Fencing — 의심 노드를 강제 차단
장애 의심 노드가 스토리지나 서비스 자원에 더 이상 접근하지 못하도록 강제로 차단한다. 전원 차단, 네트워크 차단, 스토리지 접근 차단이 여기에 포함된다.
현장에서 기억해야 할 핵심은 하나다. “DB 이중화에서 중요한 건 빠른 승격보다, 잘못된 이중 마스터를 막는 것.”
액티브-스탠바이는 이해하기 쉽고 데이터 일관성을 지키기 유리하다. 다만 평소에는 대기 노드 자원이 적극 활용되지 않고, 장애 감지와 승격 과정에서 수초~수분의 공백이 발생한다. 복제 지연이나 승격 시점의 상태 차이에 따라 일부 트랜잭션 정합성 검토도 필요하다. “안전한 대신 단순히 느린 구조”가 아니라, 데이터 일관성을 우선하는 보수적 설계라고 보는 편이 맞다.
액티브-액티브 — 확장성을 얻는 대신 복잡성을 감수하는 구조
여러 노드가 동시에 서비스에 참여한다. 듣기에는 이상적이지만, 구현 철학에 따라 완전히 다른 계열로 나뉜다.
Shared Everything — 같은 데이터를 함께 바라보는 구조
Oracle RAC, IBM Db2 pureScale 같은 계열이 여기에 가깝다. 여러 노드가 같은 DB 자원과 저장소를 공유하면서 동시에 처리한다.
특정 노드 장애 시 다른 노드가 같은 데이터에 접근하기 쉽고, 소규모 트랜잭션이 다량 발생하는 환경에서 수평 처리 이점을 볼 수 있다. 하지만 노드 간 캐시 일관성 관리가 필요하고, 같은 블록을 여러 노드가 자주 갱신하면 경합이 커진다. 고성능 인터커넥트와 세밀한 설계가 필수다.
RAC에서 자주 언급되는 캐시 퓨전(Cache Fusion)도 본질적으로는 이 문제를 다룬다. 디스크 I/O를 줄이고 메모리 기반으로 블록을 교환하지만, 특정 블록에 대한 경합이 심하면 노드 간 통신 비용이 오히려 병목이 된다.
Shared Everything은 “무조건 빠른 구조”가 아니라, 설계를 잘했을 때 강력한 구조다.
Shared Nothing — 데이터를 나눠 들고 확장하는 구조
각 노드가 자신의 데이터 조각을 들고 분산 처리하는 방식이다. 샤딩, 분산 DB, 일부 NewSQL 계열이 여기에 해당한다.
노드 추가를 통한 확장이 용이하고, 클라우드 환경에서 물리 공유 스토리지 의존도가 낮다. 하지만 데이터 분산 설계를 잘못하면 특정 샤드에 부하가 몰리고, 조인·트랜잭션·글로벌 일관성 보장이 복잡해진다. 재분산(rebalancing), 파티션 설계, 키 설계가 매우 중요하다.
확장성 관점에서 유리하지만, 그만큼 데이터 모델링과 애플리케이션 설계에 대한 요구가 높아지는 구조다.
“뭐가 더 좋은가”라는 질문에 대한 답
금융·정산·원장처럼 정합성이 최우선이면 보수적 구조가 유리하다. 대규모 조회와 확장성이 핵심이면 분산 구조가 적합하다. 클라우드 네이티브 환경에서는 Shared Nothing이 현실적이고, 온프레미스 고성능 DB 클러스터에서는 Shared Everything이 강점을 갖는다.
중요한 건 “어느 쪽이 더 좋아 보이느냐”가 아니라, 장애 시 어떤 실패 모드가 발생하는지, 그 실패를 운영 조직이 감당할 수 있는지까지 포함해 판단하는 것이다.
운영의 함정 — vmstat 한 줄이 서버를 죽인 게 아니다
“vmstat 한 줄이 서버를 죽였다”는 이야기가 현장에서 돌기도 한다. 현장감은 강하지만, 정확히 말하면 vmstat 같은 명령이 일반적으로 위험한 건 아니다. 매우 기본적인 상태 점검 도구다.
다만 이미 하드웨어 이상이나 메모리 불안정이 잠복해 있던 시스템에서는, 추가적인 메모리 접근이나 상태 조회가 문제를 표면화하는 계기가 될 수 있다.
교훈은 “vmstat는 위험하다”가 아니다. “장애 상황에서는 진단 행위 자체도 시스템 부하와 자원 접근을 유발하므로, 무엇을 어떤 순서로 볼지 기준이 있어야 한다.”
장애 상황에서 진단 명령을 다루는 기준
저부하 관찰부터 시작한다. 서비스 상태, 클러스터 상태, heartbeat, replication lag, pool 사용률 같은 저비용 지표부터 확인한다. 장애 순간일수록 “일단 이것저것 다 보자”는 접근이 더 위험하다.
고비용 진단은 영향도를 알고 써야 한다. strace, 대량 tcpdump, 과도한 스택덤프, 상세 DB wait/event 조회 등은 상황에 따라 부하를 키울 수 있다. 이미 고부하 상태라면 진단이 병목을 더 악화시킨다.
클러스터 환경에서는 fencing과 failover 조건을 먼저 이해해야 한다. 현재 상태가 진짜 장애인지, 일시적 지연인지, heartbeat 타임아웃인지 모른 채 진단을 확대하면 의도치 않은 failover를 유발할 수 있다.
운영 Runbook이 있어야 한다. 문제는 기술이 아니라 순서다. 누가, 어떤 상황에서, 어떤 명령까지 실행할 수 있는지 정해 두지 않으면, 장애 순간에는 숙련자도 판단이 흔들린다.
DB 이중화 설계를 검토할 때 꼭 물어야 할 질문
- 장애 판단은 누가 하는가?
- Quorum 또는 witness는 있는가?
- Split-brain 발생 시 fencing은 어떻게 보장되는가?
- Failover 목표 시간(RTO)은 얼마인가?
- 복제 지연이 생기면 데이터 손실 가능성(RPO)은 어느 수준인가?
- Active-Active라면 캐시 경합, 분산 트랜잭션, 샤드 불균형을 어떻게 관리하는가?
- 운영 중 진단 절차와 권한 범위는 문서화되어 있는가?
이 질문에 답하지 못하면, 그 이중화는 “구성은 되어 있지만 검증되지 않은 상태”일 가능성이 높다.
DB 이중화는 구성의 문제가 아니라 운영 가능한 구조의 문제다
DB 이중화는 단순히 장애 대비용 장치가 아니다. 잘못 설계하면, 장애가 났을 때 오히려 더 큰 혼선을 만드는 구조가 된다.
액티브-스탠바이는 정합성을 우선하는 보수적 선택이고, 액티브-액티브는 확장성과 가용성을 높이는 대신 높은 설계 복잡성을 요구한다.
그러면 이건 어떤가. 지금 운영하고 있는 DB 이중화 구성에서, split-brain 시나리오를 마지막으로 점검한 게 언제인가? 그때 fencing이 제대로 동작하는지 실제로 테스트해 봤는가?
초점 키프레이즈: DB 이중화, 스플릿 브레인
태그: DB 이중화, Active Standby, Active Active, Split Brain, Quorum, Fencing, Oracle RAC, Shared Everything, Shared Nothing, Failover, 클러스터 설계, 데이터 일관성
메타 설명: DB 이중화 아키텍처를 엔지니어 관점에서 정리했습니다. 액티브-스탠바이와 액티브-액티브의 차이, 스플릿 브레인, quorum, fencing, 운영 진단 리스크까지 실무적으로 설명합니다.