RabbitMQ 클러스터링: 설정, 구성 및 모범 사례

RabbitMQ 클러스터링은 종종 오해를 받습니다. 클러스터는 여러 Erlang 노드로 구성된 하나의 논리적 브로커를 제공합니다. 사용자, vhost, 교환, 바인딩, 정책 및 기타 메타데이터를 노드 간에 공유합니다. 그러나 모든 큐의 메시지를 모든 곳에서 자동으로 사용할 수 있게 하지는 않습니다. 큐 가용성은 큐 유형과 복제 설정에 따라 달라집니다.

이 차이는 프로덕션 환경에서 중요합니다. 클러스터는 관리와 라우팅을 더 쉽게 만들고 고가용성 큐를 지원할 수 있지만, 마법 같은 성능 향상 스위치는 아닙니다. 모든 핫 큐를 하나의 노드에 배치하면 해당 노드가 모든 작업을 수행합니다. 복제 없이 클래식 큐를 사용하고 큐 리더의 노드가 사라지면 해당 큐는 노드가 반환될 때까지 사용할 수 없습니다. 실제로 실행하는 큐를 중심으로 클러스터를 설계하세요.

클러스터가 공유하는 것과 공유하지 않는 것

RabbitMQ 클러스터 메타데이터는 복제됩니다. 한 노드에서 교환을 선언하면 다른 노드도 이를 알게 됩니다. 사용자나 정책을 추가하면 클러스터가 해당 정의를 저장합니다. 클라이언트 애플리케이션은 모든 노드에 연결하여 동일한 토폴로지를 사용할 수 있습니다.

메시지는 다릅니다. 큐에는 리더가 있습니다. 클래식 큐의 경우, 이전 미러링된 큐를 사용하지 않는 한 메시지는 해당 큐를 호스팅하는 노드에 저장됩니다. 쿼럼 큐의 경우, RabbitMQ는 합의 프로토콜을 사용하여 큐 데이터를 노드 그룹에 복제합니다. 스트림의 경우, 데이터는 스트림 구성에 따라 복제됩니다. 최신 RabbitMQ 배포에서는 쿼럼 큐가 복제된 내구성 있는 작업 큐에 더 안전한 선택인 경우가 많습니다.

오래된 문서에서는 종종 "HA 큐"를 마치 현대의 기본값인 것처럼 이야기합니다. RabbitMQ 용어에서 이는 일반적으로 정책에 의해 구성된 클래식 미러링된 큐를 의미합니다. 일부 설치에서는 여전히 존재하지만, 대부분의 새로운 내구성 있는 복제 큐 설계는 쿼럼 큐를 고려해야 합니다. 기존 워크로드를 마이그레이션하기 전에 항상 RabbitMQ 버전과 환경의 운영 제약 조건을 확인하세요.

노드를 조인하기 전에

먼저 지루한 확인을 수행하세요:

• 노드는 서로의 호스트 이름을 일관되게 확인할 수 있어야 합니다.
• Erlang 분배 포트와 RabbitMQ 포트는 노드 간에 연결 가능해야 합니다.
• RabbitMQ와 Erlang 버전은 클러스터 전체에서 호환되어야 합니다.
• 모든 노드는 동일한 Erlang 쿠키를 공유해야 합니다.
• 시간 동기화는 특히 모니터링과 TLS에 의존하는 경우 적절해야 합니다.

Erlang 쿠키는 Erlang 노드가 사용하는 공유 비밀입니다. 많은 Linux 패키지에서 /var/lib/rabbitmq/.erlang.cookie에 위치하며, rabbitmq 사용자가 소유하고 모드는 600입니다.

sudo systemctl stop rabbitmq-server
sudo install -o rabbitmq -g rabbitmq -m 600 .erlang.cookie /var/lib/rabbitmq/.erlang.cookie
sudo systemctl start rabbitmq-server

실행 중인 클러스터에서 쿠키를 무심코 재생성하지 마세요. 한 노드가 다른 쿠키를 가지고 있으면 다른 노드와 통신하지 못하며, 오류 메시지가 항상 친절하지는 않습니다.

노드 조인

rabbit@rmq-a가 이미 실행 중이고 rabbit@rmq-b가 조인해야 한다고 가정합니다. rmq-b에서:

sudo rabbitmqctl stop_app
sudo rabbitmqctl reset
sudo rabbitmqctl join_cluster rabbit@rmq-a
sudo rabbitmqctl start_app

그런 다음 모든 노드에서 확인:

rabbitmqctl cluster_status
rabbitmq-diagnostics cluster_status

reset은 조인하기 전에 로컬 노드의 RabbitMQ 데이터베이스를 제거합니다. 이는 일반적으로 새 빈 노드에 대해 원하는 작업입니다. 중요한 큐를 소유한 노드에서 무심코 실행해서는 안 됩니다.

세 개의 노드의 경우, rmq-c에서 동일한 프로세스를 반복합니다. rmq-b와 rmq-c를 모두 rmq-a에 조인할 수 있습니다. 일단 조인되면 사람들이 종종 상상하는 방식의 영구적인 "마스터" 노드는 없습니다.

클라이언트를 안정적인 엔드포인트 뒤에 배치

애플리케이션은 노드 유지보수를 예상하는 경우 하나의 하드코딩된 브로커 호스트를 가져서는 안 됩니다. 로드 밸런서, DNS 전략 또는 클라이언트 라이브러리 연결 목록을 사용하세요. 로드 밸런서는 RabbitMQ 애플리케이션이 실행 중인지 확인해야 하며, 단순히 포트 5672가 열려 있는지 확인해서는 안 됩니다.

간단한 TCP 검사는 클라이언트를 경보에 의해 차단되었거나 완전히 조인되지 않은 살아있는 노드로 보낼 수 있습니다. 더 엄격한 환경에서는 관리 플러그인을 통해 노출된 상태 확인 또는 rabbitmq-diagnostics -q ping을 실행하는 작은 로컬 확인을 사용하세요.

큐 유형을 의도적으로 선택

내구성 있는 복제 워크로드의 경우, 쿼럼 큐가 종종 좋은 기본값입니다:

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

또는 애플리케이션 선언을 통해:

channel.queue_declare(
    queue='orders.pending',
    durable=True,
    arguments={'x-queue-type': 'quorum'}
)

쿼럼 큐는 더 강력한 복제 동작을 위해 일부 처리량과 지연 시간을 희생합니다. 모든 큐에 대한 무료 업그레이드는 아닙니다. 임시 응답 큐, 단기 팬아웃 구독자 또는 가치가 낮은 일시적 작업의 경우 클래식 큐가 괜찮을 수 있습니다. 노드 손실을 견뎌야 하는 비즈니스 이벤트의 경우 복제된 큐 유형을 사용하고 장애 조치를 테스트하세요.

네트워크 분할은 운영 이벤트이지 체크박스가 아닙니다

네트워크 분할은 클러스터 노드가 서로 통신할 수 없음을 의미합니다. RabbitMQ에는 분할 처리 전략이 있지만, 그 중 어느 것도 손상된 네트워크를 건강한 네트워크로 바꾸지 않습니다. 올바른 대응은 분할이 드물고, 가시적이며, 신중하게 복구되도록 클러스터를 설계하는 것입니다.

대부분의 프로덕션 클러스터의 경우, 쿼럼 기반 워크로드에는 홀수 개의 노드를 사용하고 신뢰할 수 없는 링크를 통해 작은 클러스터를 확장하지 마세요. 지연 시간이 허용된다면 세 개의 가용성 영역에 걸친 세 개의 노드가 잘 작동할 수 있습니다. 두 사이트에 분할된 두 개의 노드는 링크가 끊어지면 과반수가 없기 때문에 고통스러운 결정의 일반적인 원인입니다.

의심되는 분할 후 확인:

rabbitmqctl cluster_status
rabbitmq-diagnostics alarms
rabbitmq-diagnostics check_running
rabbitmqctl list_queues name type leader members online state

큐 리더가 이동했거나 멤버가 오프라인이 된 경우, 연결이 복구되었다고 해서 애플리케이션이 정상이라고 가정하지 마세요. 게시자 확인, 소비자 오류율 및 확인되지 않은 메시지를 모니터링하세요.

클러스터 문제를 방지하는 유지보수 습관

가능하면 노드를 중지하기 전에 연결을 드레인하세요. 클라이언트를 로드 밸런서 뒤에 배치한 경우, 노드를 로테이션에서 제거하고 클라이언트가 다른 곳에 다시 연결될 때까지 기다린 후 RabbitMQ를 다시 시작하세요.

주기적으로 큐 분포를 확인하세요:

rabbitmqctl list_queues name type leader messages consumers

모든 핫 큐 리더가 하나의 노드에 있으면 클러스터가 해당 워크로드에 대해 균형을 이루지 않은 것입니다. 큐를 다시 선언하거나, 정책을 검토하거나, RabbitMQ 버전에 적합한 큐 리더 로케이터 설정을 사용해야 할 수 있습니다.

정책을 소스 제어 하에 유지하세요. 큐 유형, 데드 레터링, 최대 길이 또는 미러링 동작을 변경하는 정책은 UI 조정이 아닌 프로덕션 인프라입니다.

백업은 여전히 중요합니다. 클러스터링은 정의 내보내기, 인프라 자동화 또는 재해 복구 계획을 대체하지 않습니다. 토폴로지 변경 후 정의를 내보내세요:

rabbitmqadmin export rabbitmq-definitions.json

마지막으로, 당신이 견딜 수 있다고 생각하는 실패를 테스트하세요. 큐 리더를 보유한 노드를 중지하세요. 확인되지 않은 메시지가 있는 동안 소비자를 종료하세요. 스테이징에서 디스크 경보 중 게시자를 차단하세요. RabbitMQ 클러스터는 세 개의 노드가 있는 다이어그램이 아니라 지루한 리허설을 통해 신뢰를 얻습니다.