RabbitMQ 액티브-패시브 클러스터 배포를 위한 단계별 가이드

RabbitMQ 고가용성은 서로를 볼 수 있는 두 대 이상의 서버만으로는 충분하지 않습니다. 공유 메타데이터를 위한 클러스터링, 메시지 가용성을 위한 복제된 큐, 그리고 클라이언트를 위한 명확한 장애 조치 경로가 필요합니다.

이 가이드는 액티브-패시브 스타일 배포의 RabbitMQ 측면을 보여줍니다. 클라이언트 장애 조치는 일반적으로 로드 밸런서, DNS 변경, 서비스 디스커버리 또는 RabbitMQ 외부에서 관리되는 가상 IP를 통해 이루어집니다.

액티브-패시브 클러스터를 위한 사전 요구 사항

구성을 시작하기 전에 모든 대상 클러스터 노드(노드 A - 액티브, 노드 B - 패시브)에서 다음 사전 요구 사항이 충족되었는지 확인하십시오.

호환 가능한 소프트웨어 버전: 모든 노드에서 RabbitMQ 서버와 Erlang/OTP 버전을 일치시키십시오. 실제로는 RabbitMQ의 문서화된 롤링 업그레이드 경로를 따르지 않는 한 모든 노드에서 동일한 RabbitMQ 버전을 실행하십시오.
네트워크 접근성: 노드는 클라이언트가 사용하는 AMQP 포트, 클러스터링에 사용되는 분산 포트, 그리고 활성화한 관리 또는 TLS 포트를 통해 통신할 수 있어야 합니다.
호스트 이름 확인: 모든 노드에서 /etc/hosts 파일(또는 DNS)을 구성하여 각 노드가 다른 모든 노드의 호스트 이름을 안정적으로 확인할 수 있도록 하십시오.
쿠키 일관성: Erlang '매직 쿠키'는 모든 노드에서 동일해야 합니다. 이는 노드가 클러스터링을 위해 서로를 신뢰하는 데 중요합니다.

쿠키 일관성 확립

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

노드 A (첫 번째 노드):

쿠키 파일(일반적으로 설치 방법에 따라 /var/lib/rabbitmq/.erlang.cookie 또는 ~/.erlang.cookie에 위치)을 찾아 내용을 복사하십시오.

노드 B (및 후속 노드):

RabbitMQ 서비스를 중지합니다:
```
sudo systemctl stop rabbitmq-server
```

기존 쿠키 파일을 노드 A에서 복사한 내용으로 교체하고, 올바른 권한(일반적으로 400)을 설정합니다.

# echo 사용 예시 (내용은 적절히 교체)
echo "YOUR_LONG_COOKIE_STRING" | sudo tee /var/lib/rabbitmq/.erlang.cookie
sudo chmod 400 /var/lib/rabbitmq/.erlang.cookie

노드 B에서 서비스를 시작합니다:
```
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는 클러스터가 처음 설정되는 초기 기본 노드가 됩니다.

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

3단계: 두 번째 노드(패시브)를 클러스터에 조인

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

노드 B에서 RabbitMQ 애플리케이션 중지 (Erlang 노드는 유지):
```
sudo rabbitmqctl stop_app
```
노드 B의 로컬 상태 재설정 (이미 독립 노드로 초기화된 경우):
```
sudo rabbitmqctl reset
```
조인 명령: 노드 B에서 조인 명령을 실행하고 피어로 노드 A의 호스트 이름을 지정합니다.
```
sudo rabbitmqctl join_cluster rabbit@rabbitmq-node-a
```
팁: /etc/hosts에 정의된 호스트 이름을 사용하십시오.
노드 B에서 RabbitMQ 애플리케이션 시작:
```
sudo rabbitmqctl start_app
```

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 클러스터링은 사용자, 교환, 바인딩 및 정책과 같은 메타데이터를 공유합니다. 노드 장애 시 메시지를 유지하려면 큐 콘텐츠에 복제된 큐 유형이 필요합니다.

최신 RabbitMQ 배포의 경우 복제된 내구성 있는 큐에 쿼럼 큐를 사용하십시오. 클래식 미러링된 큐는 이전 RabbitMQ 릴리스에서 ha-mode 정책을 사용했지만, 해당 접근 방식은 더 이상 사용되지 않으며 최신 주요 버전에서 제거되었습니다.

쿼럼 큐 선언

애플리케이션에서 또는 rabbitmqadmin을 사용하여 쿼럼 큐를 선언할 수 있습니다. 다음 예제는 내구성 있는 쿼럼 큐를 생성합니다:

rabbitmqadmin declare queue name=orders durable=true arguments='{"x-queue-type":"quorum"}'

두 노드 실험실의 경우 쿼럼 큐가 실행될 수 있지만, 하나의 노드 손실을 견디고 여전히 과반수를 유지할 수는 없습니다. 프로덕션의 경우 쿼럼 큐에 대해 최소 3개의 RabbitMQ 노드를 사용하여 하나의 노드가 실패하더라도 큐가 여전히 과반수를 유지할 수 있도록 하십시오.

6단계: 장애 조치 테스트

클러스터가 준비되었다고 판단하기 전에 클라이언트가 사용할 경로를 테스트하십시오:

몇 개의 지속적인 테스트 메시지를 쿼럼 큐에 게시합니다.
sudo rabbitmqctl stop_app 명령으로 액티브 노드의 RabbitMQ 애플리케이션을 중지합니다.
클라이언트가 로드 밸런서, DNS 대상 또는 서비스 디스커버리 설정을 통해 다시 연결되는지 확인합니다.
생존 노드에서 테스트 메시지를 소비합니다.
sudo rabbitmqctl start_app 명령으로 중지된 애플리케이션을 다시 시작하고 rabbitmqctl cluster_status를 확인합니다.

최종 정리

RabbitMQ 클러스터링은 공유 브로커 메타데이터를 제공하지만, 큐 가용성은 큐 유형과 클라이언트 장애 조치 설계에 따라 달라집니다. 복제된 내구성 있는 큐에는 쿼럼 큐를 사용하고, 실제 내결함성을 위해 최소 3개의 노드를 유지하며, 애플리케이션이 사용하는 것과 동일한 연결 경로로 장애 조치를 테스트하십시오.