'Mirroring' 기능을 통한 리전 간 데이터 동기화 방식은?

'Mirroring' 기능을 통한 리전 간 데이터 동기화 방식은?

현대의 엔터프라이즈 아키텍처는 단일 데이터센터의 물리적 장애(화재, 정전 등)에 대비하기 위해 두 개 이상의 물리적 지역(Region)에 시스템을 분산 구축하는 멀티 리전(Multi-Region) 또는 재해 복구(DR, Disaster Recovery) 환경을 필수로 요구합니다.

메시지 브로커 환경에서 이러한 멀티 리전 아키텍처를 구현할 때 가장 큰 난제는 "서울 리전의 브로커에 쌓인 메시지와 처리 상태를 어떻게 부산 리전의 브로커와 똑같이 맞출 것인가?"입니다. ActiveMQ Artemis는 이를 해결하기 위해 AMQP 프로토콜 기반의 'Mirroring(미러링)'이라는 강력한 브로커 연결(Broker Connection) 기능을 제공합니다.

이 가이드에서는 단순한 메시지 전달을 넘어 브로커의 완벽한 '상태 동기화'를 이루어내는 미러링의 동작 원리와 설정법, 그리고 아키텍처 설계 시의 핵심 고려사항을 상세히 분석합니다.

---

1. 기존 Bridge 방식과 Mirroring의 결정적 차이

리전 간 데이터를 넘길 때 과거에는 Core Bridge나 Network of Brokers 기능을 사용했습니다. 하지만 이 방식들과 Mirroring은 근본적인 철학이 다릅니다.

• 기존 Bridge (단순 라우팅): 브로커 A에 들어온 메시지를 브로커 B로 '이동'시킵니다. 브로커 B로 넘어가면 브로커 A에서는 메시지가 지워집니다. 분산 처리를 위한 로드 밸런싱에는 적합하지만, 동일한 복제본을 유지해야 하는 DR(재해 복구) 용도로는 부적합합니다.
• Mirroring (상태 동기화): 브로커 A의 큐에 메시지가 들어오면 브로커 B의 큐에도 똑같은 복사본을 생성합니다. 가장 중요한 점은 '소비 상태(Acknowledgement)'까지 동기화한다는 것입니다. 만약 서울 리전에서 컨슈머가 메시지를 읽고 처리를 완료(ACK)하면, 부산 리전의 브로커에도 "해당 메시지를 삭제하라"는 동기화 이벤트가 전달되어 양쪽 브로커의 큐 상태가 항상 동일하게 유지됩니다.

---

2. Mirroring의 핵심 동작 메커니즘

Artemis의 미러링 기능은 내부적으로 다음과 같은 매커니즘을 통해 안정적이고 빠른 동기화를 보장합니다.

• 비동기 복제 (Asynchronous Replication): 미러링은 생산자(Producer)의 트랜잭션을 블로킹하지 않습니다. 서울 리전에 메시지가 인입되면 즉시 생산자에게 성공 응답을 내린 뒤, 백그라운드 스레드가 비동기적으로 부산 리전으로 데이터를 복제합니다. 따라서 리전 간의 물리적인 네트워크 지연(WAN Latency)이 메인 비즈니스 로직의 처리 속도에 영향을 주지 않습니다.
• SNF (Store and Forward) 큐 활용: 두 리전 사이의 전용망 네트워크가 일시적으로 단절되더라도 데이터는 유실되지 않습니다. 브로커는 내부적으로 $SNF (Store and Forward)라는 특수한 시스템 큐를 생성하여 동기화해야 할 이벤트(메시지 생성, ACK, 큐 생성/삭제 등)를 임시로 보관합니다. 네트워크가 복구되면 SNF 큐에 쌓여 있던 이벤트들이 순차적으로 타겟 리전으로 밀려 들어가 상태를 다시 맞춥니다.
• AMQP 1.0 프로토콜 기반: Artemis 내부의 고유 프로토콜이 아닌 국제 표준인 AMQP 1.0을 기반으로 통신하므로, 네트워크 오버헤드가 적고 상호 운용성이 뛰어납니다.

---

3. Artemis 브로커 Mirroring 설정법 (broker.xml)

미러링을 구성하려면 서울 리전(Primary)의 broker.xml 내에 <broker-connections> 블록을 추가하여 부산 리전(Backup)을 타겟으로 지정해야 합니다.

<broker-connections>
    <amqp-connection uri="tcp://busan-broker:5672" name="busan-mirror">

        <mirror>
            <message-acknowledgements>true</message-acknowledgements>
            <queue-creation>true</queue-creation>
            <queue-removal>true</queue-removal>

            <source-routing-type>ANYCAST</source-routing-type>
            <address-filter match="business.orders.#"/>
        </mirror>

    </amqp-connection>
</broker-connections>

위와 같이 설정하면 business.orders. 로 시작하는 모든 큐의 데이터와 컨슈머의 소비 내역이 부산 리전으로 실시간 복제됩니다.

---

4. 실무 아키텍처 토폴로지 (Active-Passive vs Active-Active)

미러링 설정을 아키텍처 토폴로지에 어떻게 배치하느냐에 따라 두 가지 운영 시나리오가 도출됩니다.

A. Active-Passive (재해 복구 아키텍처)
가장 일반적이고 안전한 구성입니다. 평소에는 서울 리전(Active)만 프로듀서와 컨슈머의 트래픽을 처리하며, 부산 리전(Passive)은 미러링을 통해 데이터만 묵묵히 받아냅니다.
서울 데이터센터에 전면 장애가 발생하면, 글로벌 로드밸런서(GSLB)가 클라이언트 트래픽을 부산 리전으로 전환합니다. 부산 리전의 큐에는 서울 리전과 동일한 메시지들이 남아있으므로 즉각적인 서비스 재개가 가능합니다.

B. Active-Active (양방향 미러링 아키텍처)
서울과 부산 리전 모두 클라이언트 트래픽을 직접 처리하면서, 양쪽 브로커에 서로를 향하는(Bi-directional) 미러링 설정을 교차로 걸어두는 구성입니다.
Artemis는 메시지의 헤더에 기원(Origin) 노드의 식별자를 내부적으로 기록하므로, 메시지가 서울 -> 부산 -> 서울로 무한 루프를 도는 현상을 방지합니다. 두 리전의 자원을 모두 활용할 수 있어 효율적이지만, 네트워크 단절 후 복구될 때 메시지 처리 순서가 꼬일 수 있는 논리적 충돌 위험이 존재합니다.

---

5. 도입 시 핵심 주의사항 (Trade-off)

미러링은 마법의 지팡이가 아닙니다. 시스템 아키텍트로서 다음의 트레이드오프를 반드시 인지하고 설계에 반영해야 합니다.

1. RPO (Recovery Point Objective) > 0:
   미러링은 비동기 방식으로 동작하므로, 완벽한 실시간(Zero Data Loss)을 보장하지 않습니다. 서울 리전에 메시지가 디스크에 기록된 직후, 부산 리전으로 넘어가기 전의 수 밀리초(ms) 찰나에 서울 데이터센터 전원이 차단된다면 그 짧은 구간의 데이터는 유실됩니다. 이를 원천 차단하려면 성능을 포기하고 동기식(Synchronous) 저널 복제 방식을 채택해야 합니다.
2. SNF 큐의 메모리 관리:
   두 리전 간의 전용망이 몇 시간 동안 단절된다면, 메인 브로커의 $SNF 큐에 엄청난 양의 복제 대기 데이터가 쌓이게 됩니다. 이 SNF 큐 역시 브로커의 디스크와 메모리 자원을 소모하므로, 적절한 페이징(Paging) 설정과 모니터링 경보(Alert)가 필수적으로 동반되어야 브로커 연쇄 장애를 막을 수 있습니다.