'Primary-Backup' 구조에서 데이터 동기화 완료 확인 방식은?

'Primary-Backup' 구조에서 데이터 동기화 완료 확인 방식은?

분산 시스템에서 고가용성(HA)을 달성하기 위한 가장 표준적인 아키텍처는 노드를 'Primary(Active)'와 'Backup(Passive/Standby)'으로 나누고 데이터를 복제(Replication)하는 것입니다.

클라이언트의 모든 요청은 Primary 노드가 처리하며, Primary는 이 변경 사항을 네트워크를 통해 Backup 노드로 전송하여 양쪽 디스크의 동일한 상태를 유지합니다. 하지만 여기서 인프라 엔지니어를 괴롭히는 가장 치명적이고 중요한 질문이 등장합니다. "Primary는 Backup이 데이터를 진짜로, 안전하게 디스크에 저장했는지 어떻게 확신할 수 있는가?"

이 가이드에서는 고성능 분산 메시징 브로커가 데이터 유실을 제로(0)로 만들기 위해 양 노드 간의 동기화 완료를 확인하고 검증하는 아키텍처 원리를 상세히 해부합니다.

---

1. 동기식(Synchronous) 복제의 대원칙

Primary-Backup 구조에서 데이터 무결성을 보장하는 핵심은 한 치의 오차도 허용하지 않는 '동기식 복제' 메커니즘입니다.

• 비동기식의 치명적 위험성: 만약 Primary가 Backup으로 데이터를 던지기만 하고 확인을 받지 않는다면 어떻게 될까요? Primary가 클라이언트에게 성공 응답을 준 직후 전원 차단으로 죽어버렸을 때, Backup에는 아직 네트워크 스트림이 도달하지 않았거나 큐에 머물러 있을 수 있습니다. Backup이 새로운 Primary로 승격하더라도 최신 데이터가 존재하지 않아 영구적인 비즈니스 데이터 유실이 발생합니다.
• 동기식의 확신: 이를 원천 차단하기 위해 Primary는 Backup으로부터 "데이터를 안전하게 수신하고 내 로컬 물리 스토리지에 기록했다"는 명시적인 승인(Acknowledge) 응답을 받을 때까지, 클라이언트에게 절대 성공 응답을 주지 않고 대기(Block)합니다. 이것이 완벽한 정합성을 보장하는 절대 원칙입니다.

---

2. 동기화 완료 확인을 위한 4단계 파이프라인

클라이언트가 보낸 단 하나의 메시지가 완벽하게 복제되었다고 시스템이 판정하기까지, 내부에서는 다음과 같은 숨 막히는 4단계 핑퐁(Ping-Pong) 파이프라인이 가동됩니다.

1. Primary 수신 및 분기: 클라이언트가 Primary로 메시지를 전송합니다. Primary는 이를 자신의 메모리에 올리고 로컬 디스크(저널)에 쓰기 작업을 시작함과 동시에, 복제 네트워크 채널을 통해 이 메시지의 바이트 스트림을 Backup으로 전송합니다.
2. Backup 수신 및 물리적 기록: Backup 노드는 네트워크를 통해 스트림을 수신합니다. Backup 역시 이 데이터를 즉시 자신의 로컬 디스크(저널 파일)에 기록하고 운영체제의 커널 버퍼를 우회하여 물리적 디스크 동기화(Flush)를 강제 수행합니다.
3. Backup의 ACK 회신: Backup의 디스크 컨트롤러가 물리적 쓰기 완료를 보고하면, Backup 노드는 그제야 복제 채널을 역으로 거슬러 Primary를 향해 "나도 완벽하게 디스크에 저장 완료했음(Replication ACK)"이라는 짧은 제어 신호를 발송합니다.
4. Primary의 최종 승인: Primary는 자신의 로컬 디스크 쓰기가 완료되었고, Backup으로부터 Replication ACK도 무사히 도착한 것을 확인합니다. 이 양방향 조건이 모두 충족되는 바로 그 시점에 비로소 클라이언트 애플리케이션에게 최종 "전송 성공" 응답을 반환합니다.

---

3. 저널 플러시(Journal Flush)와 병목의 딜레마

이 엄격한 동기화 확인 방식에서 발생하는 가장 큰 병목은 네트워크 지연 속도가 아닙니다. 바로 양쪽 노드에서 각각 발생하는 '물리적 디스크 쓰기 대기 시간'입니다.

Primary와 Backup은 각각 독립적인 스토리지 컨트롤러를 가지고 있습니다. 클라이언트가 체감하는 응답 지연 시간(Latency)은 'Primary 디스크 쓰기 시간'과 '네트워크 왕복 시간' 그리고 'Backup 디스크 쓰기 시간' 중 가장 늦게 끝나는 작업의 시간에 맞춰집니다.

만약 Backup 노드의 디스크 노후화로 IOPS 성능이 Primary보다 떨어지거나, 일시적인 스토리지 스파이크가 발생한다면 어떻게 될까요? Backup의 ACK 회신이 늦어지게 되며, 이는 즉각적으로 Primary의 메인 스레드 병목으로 직결됩니다. 결국 클라이언트 애플리케이션 전체에 타임아웃 장애를 유발하는 나비효과가 발생합니다. 따라서 아키텍처를 구성할 때 Primary와 Backup의 하드웨어 스펙(특히 디스크의 물리적 쓰기 성능)은 반드시 100퍼센트 동일하게 구성해야 하는 것이 철칙입니다.

---

4. 네트워크 단절과 타임아웃 예외 처리 (Failover)

동기화 완료 응답을 기다리는 도중 복제 전용 네트워크 케이블이 단절되거나 Backup 프로세스가 패닉에 빠진다면 Primary는 어떻게 행동할까요? 무한정 기다리며 시스템을 마비시킬 수는 없습니다.

• 응답 대기 한계: Primary는 무한정 Backup의 응답을 기다리지 않습니다. 설정된 복제 타임아웃 시간(예: 30초)이 지나면, Primary는 Backup 노드가 죽었거나 네트워크가 유실되었다고 확정 짓습니다.
• 격리 및 단독 실행: Primary는 즉시 Backup과의 복제 연결을 끊어버립니다. 그리고 멈춰있던 클라이언트의 스레드들을 풀어주며, 이때부터는 자신의 로컬 디스크에만 데이터를 쓰고 즉시 클라이언트에게 성공을 응답하는 '단독(Standalone)' 모드로 전환하여 서비스 마비를 막아냅니다.
• 재동기화 (Resynchronization): 추후 장애가 복구되어 Backup 노드가 다시 연결되면, Primary는 단독 모드일 때 자신만이 쌓아두었던 새로운 차분 데이터를 통째로 Backup에게 밀어 넣어 다시 완벽한 쌍둥이 상태를 만든 뒤에야 본래의 동기식 복제 모드로 복귀합니다.

---

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

Primary-Backup 동기식 복제는 데이터 유실을 완벽하게 차단하는 가장 훌륭한 패턴이지만, 그 이면에는 가혹한 지연 시간(Latency) 페널티가 숨어 있습니다.

이러한 검증 오버헤드와 디스크 병목을 최소화하려면 다음의 아키텍처 원칙을 반드시 준수해야 합니다.

1. 배치 복제(Batch Replication) 활성화: 개별 메시지마다 ACK를 주고받는 대신, 수십 개의 메시지 쓰기 요청을 메모리에 모았다가 한 번의 네트워크 전송과 디스크 I/O로 묶어서 처리하는 그룹 커밋(Group Commit) 기술을 적극적으로 활용하여 초당 처리량을 극대화해야 합니다.
2. 전용 복제 네트워크(Dedicated Replication Network) 분리: 클라이언트가 접속하는 퍼블릭 트래픽 망과 Primary-Backup 간의 동기화 트래픽 망이 같은 LAN 케이블을 공유하면 대역폭 고갈로 인해 ACK 신호가 지연됩니다. 이를 막기 위해 반드시 스토리지 동기화 전용의 물리적으로 격리된 10Gbps 이상의 고속 백본망을 구축하는 것이 인프라 아키텍트의 필수 의무입니다.