DevOps 지식 허브
DevOps 지식 허브

RabbitMQ 활성-수동 클러스터 배포 단계별 가이드

고가용성을 위한 강력한 RabbitMQ 활성-수동 클러스터 구성 방법을 알아보세요. 이 가이드는 사전 요구 사항 설정, 필수 Erlang 쿠키 동기화, 클러스터 노드 참여, 그리고 활성 노드 장애 발생 시 데이터 일관성과 원활한 서비스 장애 조치를 보장하기 위한 미러링 정책(`ha-mode:all`) 적용 방법을 다룹니다.

41 조회수

RabbitMQ Active-Passive 클러스터 배포 단계별 가이드

미션 크리티컬 메시징 서비스에 대한 고가용성(HA)을 구현하려면 강력한 이중화가 필요합니다. RabbitMQ Active-Passive 클러스터 설정은 이를 달성하기 위한 고전적인 접근 방식이며, 활성(Active) 노드가 실패할 경우 지정된 수동(Passive) 노드가 신속하게 인계하여 가동 중지 시간을 최소화합니다. 이 가이드는 이러한 배포를 구성하기 위한 포괄적인 단계별 프로세스를 제공하며, 전제 조건, 노드 구성, 원활한 장애 조치(failover) 기능을 보장하는 방법을 다룹니다.

이 배포 패턴은 표준 RabbitMQ 클러스터링과 외부 메커니즘(Pacemaker 또는 간단한 스크립트 등)을 결합하여 장애 발생 시 IP 주소 인계를 관리합니다. 이 가이드에서는 HA 설정을 뒷받침하는 RabbitMQ 클러스터링 측면에 중점을 둡니다.

Active-Passive 클러스터의 전제 조건

구성을 시작하기 전에 의도된 모든 클러스터 노드(노드 A - 활성, 노드 B - 수동)에서 다음 전제 조건을 충족하는지 확인하십시오.

  1. 동일한 소프트웨어 버전: 모든 노드는 RabbitMQ Server 및 Erlang/OTP의 정확히 동일한 버전을 실행해야 합니다.
  2. 네트워크 접근성: 모든 노드는 필요한 포트(AMQP의 경우 기본 5672, 클러스터링의 경우 25672)를 통해 서로 통신할 수 있어야 합니다.
  3. 호스트 이름 확인: 모든 노드에서 /etc/hosts 파일(또는 DNS)을 구성하여 각 노드가 다른 모든 노드의 호스트 이름을 안정적으로 확인할 수 있도록 합니다.
  4. 쿠키 일관성: Erlang '매직 쿠키(magic cookie)'는 모든 노드에서 동일해야 합니다. 이는 노드가 클러스터링을 위해 서로를 신뢰하는 데 필수적입니다.

쿠키 일관성 확립

Erlang 쿠키는 노드가 안전하게 통신할 수 있는지 여부를 결정합니다. 이 쿠키는 처음 초기화된 노드에서 다른 모든 노드로 복사되어야 합니다.

노드 A에서 (첫 번째 노드):

쿠키 파일(설치 방법에 따라 일반적으로 /var/lib/rabbitmq/.erlang.cookie 또는 ~/.erlang.cookie)을 찾아 그 내용을 복사합니다.

노드 B에서 (및 후속 노드):

  1. RabbitMQ 서비스를 중지합니다:
    bash sudo systemctl stop rabbitmq-server
  2. 기존 쿠키 파일을 노드 A에서 복사한 내용으로 교체하고 올바른 권한(일반적으로 400)을 확인합니다.
    bash # echo 사용 예시 (필요에 따라 내용 교체) echo "YOUR_LONG_COOKIE_STRING" | sudo tee /var/lib/rabbitmq/.erlang.cookie sudo chmod 400 /var/lib/rabbitmq/.erlang.cookie
  3. 노드 B에서 서비스를 시작합니다:
    bash sudo systemctl start rabbitmq-server

1단계: 호스트 이름 및 네트워킹 구성

노드 A와 노드 B 모두에서 호스트 파일이 호스트 이름을 올바르게 매핑하는지 확인합니다.

예시 /etc/hosts (두 서버 모두):

192.168.1.10   rabbitmq-node-a
192.168.1.11   rabbitmq-node-b

2단계: 첫 번째 클러스터 노드 초기화 (활성)

노드 A는 클러스터가 처음 설정되는 초기 기본 노드가 됩니다.

  1. 노드 A에서 서비스 시작 (실행 중이 아닌 경우):
    bash sudo systemctl start rabbitmq-server
  2. 상태 확인: 노드가 올바르게 실행 중인지 확인합니다.
    bash rabbitmqctl status

3단계: 두 번째 노드 (수동)를 클러스터에 연결

이제 노드 B가 노드 A가 이끄는 클러스터에 연결하도록 지시합니다.

  1. 노드 B에서 서비스 중지 (실행 중인 경우):
    bash sudo systemctl stop rabbitmq-server

  2. 연결 명령: 노드 B에서 연결 명령을 실행하고, 노드 A의 호스트 이름을 피어(peer)로 지정합니다.
    bash rabbitmqctl join_cluster rabbit@rabbitmq-node-a
    팁: /etc/hosts에 정의된 호스트 이름을 사용하십시오.

  3. 노드 B에서 서비스 시작:
    bash sudo systemctl start rabbitmq-server

4단계: 클러스터 형성 확인

노드 A에 로그인하여 두 노드가 서로를 인식하는지 확인합니다.

rabbitmqctl cluster_status

예상 출력 스니펫:

running_nodes 아래에 rabbitmq-node-a와 rabbitmq-node-b가 모두 나열되어야 합니다.

Cluster status of node rabbit@rabbitmq-node-a ...
[{nodes,[{disc,[rabbit@rabbitmq-node-a,rabbit@rabbitmq-node-b]}]},
 {running_nodes,[rabbit@rabbitmq-node-a,rabbit@rabbitmq-node-b]},
 ...
]

5단계: 고가용성 구성 (클러스터링 큐)

표준 RabbitMQ 클러스터링은 노드가 메타데이터(사용자, 교환소)를 공유하도록 허용하지만, 특정 HA 정책이 적용되지 않는 한 큐에 상주하는 메시지는 일반적으로 자동으로 복제되지 않습니다. 진정한 Active-Passive 장애 조치를 위해서는 미러링된 큐(mirrored queues)를 사용해야 합니다.

정책 정의

정책은 특정 패턴과 일치하는 큐에 적용되어 클러스터 전체에 큐 복사본이 몇 개 존재해야 하는지, 그리고 어디로 승격되어야 하는지를 정의합니다.

두 노드 중 하나에서 rabbitmqctl set_policy 명령을 사용하여 클러스터 전체 ("^")에 미러링을 적용합니다.

```bash

모든 이름('^')과 일치하는 큐를 클러스터의 모든 노드(총 3개 노드)에 미러링하고 '승격(promote)' 동작을 설정하는 'ha-all'이라는 정책을 설정합니다.

rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"