Master-Slave 구성을 위한 'Pluggable Storage'의 종류는?

Master-Slave 구성을 위한 'Pluggable Storage'의 종류는?

엔터프라이즈 환경에서 메시지 브로커(ActiveMQ 등)의 무중단 운영을 보장하는 고가용성(HA, High Availability)의 대원칙은 언제나 'Master-Slave' 구조입니다. 클러스터 내의 여러 브로커 노드 중 오직 하나의 마스터(Master) 노드만이 클라이언트의 요청을 처리하며, 마스터가 죽는 순간 대기하고 있던 슬레이브(Slave) 노드가 즉각적으로 마스터 권한을 승계(Failover)받아 서비스를 이어갑니다.

이러한 무결점의 권한 승계가 가능하려면, 마스터와 슬레이브는 '동일한 상태(메시지 데이터)'를 완벽하게 공유하고 있어야 합니다. ActiveMQ는 아키텍처 내부의 저장소 엔진을 자유롭게 끼워 맞출 수 있는 'Pluggable Storage(플러거블 스토리지)' 인터페이스를 제공하여, 인프라 환경에 맞춰 상태 공유 방식을 유연하게 선택할 수 있도록 지원합니다.

본 가이드에서는 Master-Slave 구성을 위해 플러그인처럼 교체하여 사용할 수 있는 핵심 스토리지 종류와 각각의 잠금(Lock) 메커니즘, 그리고 장단점을 상세히 해부합니다.

---

1. 성능의 제왕: Shared File System (공유 파일 시스템 기반 KahaDB)

가장 널리 쓰이며 브로커의 성능을 극한으로 끌어올릴 수 있는 표준적인 HA 스토리지 구성입니다. SAN(Storage Area Network)이나 고성능 NAS(Network Attached Storage)와 같은 공유 물리 디스크를 마스터와 슬레이브가 동시에 마운트(Mount)하여 사용하는 방식입니다.

• 사용 스토리지: KahaDB (ActiveMQ의 기본 초고속 파일 스토리지 엔진)
• Lock 메커니즘 (OS File Lock): 마스터와 슬레이브는 공유 폴더 내의 KahaDB 디렉토리를 바라보고 기동됩니다. 가장 먼저 구동된 마스터 브로커가 운영체제 레벨의 파일 잠금(OS-level Exclusive Lock)을 통해 lock 파일을 움켜쥡니다. 슬레이브 브로커들은 이 lock 파일이 풀리기만을 끝없이 기다리며 대기(Standby) 상태에 머뭅니다. 마스터 서버가 죽으면 OS가 락을 해제하고, 대기하던 슬레이브 중 하나가 재빨리 락을 획득하여 새로운 마스터로 승격합니다.
• 아키텍처적 장점: 브로커의 메인 스토리지인 KahaDB를 그대로 사용하므로 메시지 처리 성능(TPS)이 단독(Standalone) 브로커와 거의 동일하게 유지됩니다. 데이터베이스 엔진을 거치지 않고 OS 레벨에서 I/O가 처리되므로 가장 빠르고 가볍습니다.
• 치명적 약점 (NFS Lock 버그): NFSv3 버전을 사용하는 구형 NAS 환경에서는, 마스터 서버가 비정상 종료되었음에도 불구하고 네트워크 단절로 인해 NFS 서버가 파일 락을 해제하지 않고 물고 있는 '고스트 락(Ghost Lock)' 현상이 종종 발생합니다. 이 경우 슬레이브가 승격하지 못하고 전체 인프라가 멈춰버리는 끔찍한 교착 상태에 빠질 수 있습니다.

---

2. 범용성과 관리의 편의성: JDBC Database Store

파일 시스템의 불완전한 잠금 관리나 공유 디스크 장비 도입이 부담스러운 환경에서, 기존에 구축되어 있는 관계형 데이터베이스(RDBMS - Oracle, MySQL, PostgreSQL 등)를 메시지 저장소이자 클러스터 관리자로 사용하는 방식입니다.

• 사용 스토리지: JDBC Persistence Adapter
• Lock 메커니즘 (Database Row Lock): 브로커들은 기동 시 지정된 데이터베이스에 접속하여 ACTIVEMQ_LOCK 이라는 관리 테이블을 조회합니다. 가장 먼저 접속한 마스터 노드가 UPDATE 쿼리를 날려 해당 테이블의 특정 로우(Row)에 대해 데이터베이스 레벨의 배타적 락(Exclusive Row Lock)을 획득합니다. 슬레이브들은 이 DB 락을 얻기 위해 폴링(Polling)하며 대기합니다. 마스터 프로세스가 죽거나 DB 커넥션이 끊어지는 순간 RDBMS가 락을 즉시 해제하므로 슬레이브의 승격이 이루어집니다.
• 아키텍처적 장점: 기업 내 전문 DBA 그룹의 관리를 받을 수 있으며, 백업, 복구, 모니터링 체계를 기존 DB 인프라에 통합하기 매우 쉽습니다. NAS 환경과 달리 '락 해제 실패'와 같은 네트워크 파일 시스템의 고질적인 버그로부터 완벽하게 자유롭습니다.
• 치명적 약점 (극악의 성능 하락): 모든 메시지의 저장과 삭제가 RDBMS의 트랜잭션(INSERT/DELETE)으로 치환됩니다. 초당 수만 건의 메시지가 유입되면 데이터베이스의 트랜잭션 로그와 인덱스가 감당하지 못하고 병목을 일으킵니다. 파일 시스템 기반 스토리지 대비 처리량이 10분의 1 수준으로 급감하므로, 고트래픽 서비스에는 절대 단독으로 도입해서는 안 됩니다.

---

3. 하이브리드 아키텍처: Lease Database Locker (KahaDB + JDBC)

앞서 살펴본 두 가지 방식의 단점(공유 파일 시스템의 불안정한 Lock + JDBC의 느린 속도)을 상쇄하고 장점만 취하기 위해 설계된 진보된 '플러거블 락커(Pluggable Locker)' 아키텍처입니다.

• 동작 원리 (역할의 완벽한 분리): 이 구성에서 메시지의 저장(Data)은 고성능의 KahaDB(NAS/SAN 공유 디스크)가 전담합니다. 반면, 마스터-슬레이브의 권한을 결정하는 락(Lock) 관리는 파일 시스템을 믿지 않고 고가용성이 보장된 RDBMS(JDBC)에 전적으로 위임합니다.
• 임대(Lease) 메커니즘: 마스터 브로커는 DB에 접속하여 영구적인 락을 쥐는 것이 아니라, 짧은 시간(예: 5초) 단위의 임대권(Lease)을 획득합니다. 마스터는 살아있는 동안 이 임대 시간을 계속 갱신(Keep-alive)합니다. 만약 마스터가 갑자기 죽어 갱신을 멈추면, 슬레이브는 임대 시간이 만료된 것을 DB에서 확인하고 즉시 새로운 임대권을 쟁취하여 승격합니다.
• 아키텍처적 장점: KahaDB를 쓰므로 디스크 I/O 성능은 최고 수준을 유지하면서도, 스플릿 브레인(Split Brain)이나 고스트 락 현상을 완벽하게 방어하는 가장 견고한 HA 스토리지 파이프라인이 완성됩니다.

---

4. Storage 선택을 위한 아키텍트의 결단 (Best Practices)

'Pluggable Storage'의 유연성은 곧 인프라 환경에 맞는 최적의 무기를 고를 수 있다는 뜻입니다. 서비스의 특성에 따라 다음과 같이 스토리지를 결정해야 합니다.

1. 고성능 대용량 트래픽 환경 (금융, 로그 수집): 반드시 Shared File System (KahaDB)을 선택해야 합니다. 최신 SAN 장비나 NFSv4 이상의 신뢰할 수 있는 스토리지 프로토콜을 사용하여 OS File Lock의 안정성을 확보하는 것이 전제 조건입니다.
2. 트래픽이 적고 데이터 정합성이 최우선인 사내망 환경: 별도의 NAS 스토리지를 구매할 예산이 없고 사내에 튼튼한 Oracle 클러스터가 구축되어 있다면, 관리 비용이 들지 않는 JDBC Database Store가 가장 현명한 선택입니다.
3. 가장 완벽한 무결점을 추구하는 엔터프라이즈 환경: 속도와 락 관리의 안정성을 모두 포기할 수 없다면, 설정이 다소 복잡하더라도 KahaDB와 RDBMS를 결합한 Lease Database Locker 아키텍처를 도입하여 인프라의 맹점을 상호 보완해야 합니다.

결론적으로 Master-Slave를 구성하는 핵심은 물리적인 서버 두 대를 띄우는 것이 아니라, 두 서버가 공유하는 '상태 데이터(Storage)'의 정합성과 배타성을 어떻게 보장하느냐에 달려 있습니다. 브로커 성능의 목줄을 쥐고 있는 이 스토리지 계층을 신중하게 설계하여, 어떠한 하드웨어 장애 앞에서도 무너지지 않는 견고한 메시징 파이프라인을 구축하시기 바랍니다.