고가용성(HA)을 위한 'Clustering'과 'Quorum Queues'

이제 RabbitMQ를 단순한 메신저를 넘어, 어떤 풍파에도 메시지를 잃어버리지 않는 '불멸의 통신망'으로 진화시킬 시간이군요! 🫡

주식 시스템에서 RabbitMQ가 단 1분이라도 멈춘다면, 그 사이 들어오는 모든 매수/매도 신호와 시세 데이터가 증발해 버릴 겁니다. 이를 방지하기 위해 여러 대의 RabbitMQ를 묶어 하나처럼 동작하게 만드는 클러스터링(Clustering)과 최신 고가용성 기술인 쿼럼 큐(Quorum Queues)가 존재합니다.

---

🏗️ 1. RabbitMQ Clustering: "운명 공동체의 형성"

클러스터링은 여러 개의 RabbitMQ 노드를 하나의 논리적인 브로커로 묶는 기술입니다.

① 자원 공유의 원리

클러스터가 형성되면 모든 노드는 Exchange, Binding, User 등의 메타데이터를 공유합니다.

• 사용자가 1번 노드에 접속해서 Exchange를 만들어도, 2번과 3번 노드에서 즉시 보이고 사용할 수 있습니다.

② 하지만 큐(Queue)는 다르다?

기본적으로 일반적인 큐는 클러스터 내의 단 하나의 노드에만 존재합니다. 다른 노드들은 해당 큐가 어디 있는지 위치 정보만 알고 있죠. 만약 그 큐가 있는 노드가 죽으면? 메타데이터는 살아있어도 정작 알맹이(데이터)는 사라지는 비극이 발생합니다. 이를 해결하기 위해 등장한 것이 바로 복제(Replication) 기술입니다.

---

🗳️ 2. Quorum Queues: "다수결의 원칙으로 지키는 데이터"

예전에는 'Classic Mirrored Queues'라는 방식을 썼지만, 성능과 안정성 문제로 현재는 Quorum Queues가 표준입니다. 이는 분산 시스템의 합의 알고리즘인 Raft를 기반으로 작동합니다.

① 작동 원리: "리더와 팔로워"

• 쿼럼 큐를 생성하면 클러스터 내 여러 노드에 복제본이 분산 배치됩니다.
• 이 중 한 노드가 리더(Leader)가 되어 모든 읽기/쓰기를 처리하고, 나머지 노드들은 팔로워(Follower)가 되어 데이터를 실시간으로 복제합니다.

② 데이터 확정 (Consensus)

• 메시지가 들어오면 리더는 팔로워들에게 데이터를 보냅니다.
• 전체 노드의 과반수(Quorum) 이상이 "데이터 잘 받았어!"라고 응답하면, 그제야 리더는 메시지가 안전하게 저장된 것으로 간주하고 클라이언트에게 확인을 보냅니다.
• 장점: 노드 한두 개가 죽어도 과반수만 살아있으면 새로운 리더를 선출하여 서비스 중단 없이 계속 운영됩니다.

---

☸️ 3. 쿠버네티스에서의 구성: "RabbitMQ Cluster Operator"

쿠버네티스에서 RabbitMQ 클러스터를 일일이 YAML로 짜는 건 매우 고된 일입니다. 사용자에게는 가장 세련된 방식인 Operator 패턴을 추천합니다.

① 왜 Operator인가?

RabbitMQ는 상태가 있는(Stateful) 서비스이므로 노드 이름 고정, 저장소 연결, 클러스터 합류 과정이 복잡합니다. RabbitMQ Cluster Operator를 쓰면 "노드 3개짜리 클러스터 만들어줘"라는 선언 한 줄로 이 모든 과정을 자동화할 수 있습니다.

② 구성 핵심 요소

• StatefulSet: 각 RabbitMQ 노드에 0, 1, 2 식의 고유 번호와 전용 PVC를 부여합니다.
• Headless Service: 노드들이 서로를 찾아서 클러스터를 맺을 때 사용하는 내부 주소 체계를 제공합니다.
• Pod Anti-Affinity: 3개의 RabbitMQ 파드가 서로 다른 물리 노드에 배치되도록 강제하여, 서버 한 대가 물리적으로 고장 나도 클러스터가 깨지지 않게 보호합니다.

---

💡 4. 운영 노하우: "성능과 안전 사이"

① 홀수(Odd)의 법칙

쿼럼 큐는 과반수 합의를 기반으로 하므로, 노드 개수는 반드시 3, 5, 7개와 같은 홀수로 구성해야 합니다. (2개일 때 1개가 죽으면 과반수 확보가 안 되어 전체가 멈춥니다.)

② 디스크 IOPS의 중요성

쿼럼 큐는 모든 데이터를 디스크에 기록하며 복제합니다. 따라서 클러스터가 느려진다면 가장 먼저 체크해야 할 것은 PVC의 성능(IOPS)입니다. 우량주인 A그룹 시스템이라면 반드시 고성능 SSD 스토리지 클래스를 할당하세요.

---

💡 실전 비유: "삼권 분립과 합의"

• Clustering: 여러 명의 판사가 하나의 법원(Cluster)에 소속되어 서류를 공유하는 것과 같습니다.
• Quorum Queues: 중요한 판결(메시지 저장)을 내릴 때, 판사 한 명의 독단이 아니라 배심원 과반수의 찬성을 얻어야만 확정되는 시스템입니다.
• 한 명의 판사가 아파서 결근해도(노드 장애), 나머지 판사들이 과반수를 채울 수 있다면 재판은 계속 진행됩니다.
• 하지만 판사들이 서로 연락이 안 되면(네트워크 단절), 잘못된 판결을 막기 위해 시스템은 잠시 멈춥니다. 이것이 데이터의 일관성(Consistency)을 지키는 방식입니다.

---

📊 요약: 클래식 미러링 vs 쿼럼 큐

비교 항목	Classic Mirrored Queues (Old)	Quorum Queues (New/Standard)
알고리즘	자체 복제 로직	Raft 합의 알고리즘
안정성	네트워크 단절 시 데이터 유실 위험	강력한 데이터 일관성 보장
성능	비교적 빠름	복제 오버헤드로 약간 느리지만 안정적
추천 용도	호환성 유지	대부분의 고가용성 서비스

---

🚀 꼬리 질문 🫡

이제 어떤 서버가 죽어도 주식 메시지는 쿼럼 큐 안에서 안전하게 보호될 것입니다. 그런데 메시지가 안전하게 전달되는 것도 중요하지만, 메시지 양이 갑자기 수백만 건으로 폭주할 때 '메시지를 받는 속도'를 어떻게 조절하느냐가 시스템의 전체 퍼포먼스를 결정합니다.

**"그럼 소비자(Consumer)가 감당할 수 있는 만큼만 메시지를 가져오게 조절하는 'Prefetch Count' 설정과, 이를 활용한 'Work Queues'의 부하 분산 원리는 뭐야?"