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

RabbitMQ는 애플리케이션 간의 비동기 통신을 용이하게 하는 강력하고 유연한 메시지 브로커입니다. 단일 RabbitMQ 인스턴스로도 많은 사용 사례를 처리할 수 있지만, 복잡하거나 고가용성이 요구되는 시스템은 클러스터링을 통해 상당한 이점을 얻을 수 있습니다. RabbitMQ를 클러스터링하면 여러 RabbitMQ 노드를 단일 논리적 단위로 그룹화하여 로드 분산, 향상된 내결함성 및 확장성을 개선할 수 있습니다.

이 글에서는 RabbitMQ 클러스터링의 기본 개념, 다양한 노드 유형, 네트워크 분할 처리 방법, 데이터 동기화 메커니즘 등을 다룹니다. 그런 다음 견고한 클러스터 환경을 설정하고 구성하는 단계별 지침과 안정성 및 성능을 보장하기 위한 필수 모범 사례를 제공합니다.

RabbitMQ 클러스터링 이해

RabbitMQ 클러스터는 함께 작동하는 하나 이상의 RabbitMQ 노드 컬렉션입니다. 이러한 노드는 정보를 공유하여 단일 통합 메시지 브로커 역할을 할 수 있습니다. 클러스터의 핵심 구성 요소와 동작을 이해하는 것은 효과적인 설정 및 관리에 중요합니다.

노드 유형

클러스터의 RabbitMQ 노드는 두 가지 주요 유형으로 분류할 수 있습니다.

미러링된 큐 (클래식) / 고가용성 (HA) 큐 (정책 기반): 내결함성을 달성하기 위한 주요 메커니즘입니다. 큐가 미러링되거나 고가용성을 갖추면 해당 큐의 내용이 클러스터의 여러 노드에 복제됩니다. 한 노드에 장애가 발생하면 큐의 복제본을 보유한 다른 노드가 인계하여 메시지 가용성을 보장할 수 있습니다. HA 큐는 정책을 통해 구성되며 현대적인 접근 방식으로, 클래식 미러링 큐보다 더 많은 유연성을 제공합니다.
미러링되지 않은 큐: 이러한 큐는 선언된 노드에만 존재합니다. 해당 노드를 사용할 수 없게 되면 해당 큐의 메시지는 손실됩니다 (예: 프로듀서 확인 및 재시도, 신중한 소비자 설계를 통한 영구 메시지).

네트워크 분할

네트워크 분할은 네트워크 문제로 인해 클러스터의 노드 간 통신이 불가능해질 때 발생합니다. 이는 노드 그룹이 클러스터의 나머지 부분이 실패했다고 믿는 상황으로 이어질 수 있습니다. RabbitMQ는 큐 유형에 따라 분할을 다르게 처리합니다.

HA 큐: 분할이 발생하면 HA 큐의 리더 복제본을 가진 노드가 계속 작동합니다. 소수 파티션에 있는 다른 노드는 파티션이 복구될 때까지 해당 큐에 대한 연결을 수락하지 않습니다. 이는 메시지가 파티션의 서로 다른 측면에 독립적으로 기록될 수 있는 분할 브레인 시나리오를 방지합니다.
클래식 미러링 큐: HA 큐와 유사하게, 클래식 미러링 큐의 소수 파티션은 작동을 중지합니다.

데이터 동기화 및 일관성

RabbitMQ 클러스터에서 특정 메타데이터(교환 및 큐 정의, 사용자 자격 증명, 가상 호스트 구성 등)는 모든 노드에 복제됩니다. 그러나 메시지 내용은 주로 큐에 대한 미러링 또는 HA 정책을 통해 관리됩니다.

메타데이터 동기화: 어느 노드에서든 교환 또는 큐를 선언하면 이 정의가 클러스터의 다른 모든 노드로 전파됩니다. 이를 통해 모든 노드가 토폴로지에 대한 일관된 뷰를 갖도록 합니다.
메시지 동기화 (미러링/HA를 통해): 미러링 또는 HA 큐의 경우 RabbitMQ는 해당 큐에 게시된 메시지가 미러 노드에 복제되도록 보장합니다. 리더 복제본이 게시 및 소비를 처리하며, 해당 상태는 미러와 동기화됩니다.

RabbitMQ 클러스터 설정

RabbitMQ 클러스터를 설정하려면 여러 RabbitMQ 인스턴스가 서로를 검색하고 통신하도록 구성해야 합니다. 가장 일반적인 방법은 erlang.cookie 파일을 사용하는 것입니다.

전제 조건:

RabbitMQ를 설치할 여러 서버 또는 가상 머신.
모든 서버 간의 네트워크 연결.
모든 노드에 RabbitMQ 설치 (버전 호환성 확인).

단계:

모든 노드에 RabbitMQ 설치: 각 서버의 운영 체제에 대한 공식 RabbitMQ 설치 가이드를 따릅니다.
Erlang Cookie 구성:
Erlang 쿠키는 클러스터의 모든 노드가 통신하기 위해 공유해야 하는 비밀 키입니다. 일반적으로 rabbitmq 또는 root인 RabbitMQ 프로세스를 실행하는 사용자의 홈 디렉터리에 있는 .erlang.cookie라는 파일에 저장됩니다.
- 첫 번째 노드 (노드 A)에서:
  강력하고 무작위적인 쿠키를 생성합니다. uuidgen 또는 openssl rand -hex 16과 같은 명령을 사용할 수 있습니다.
  bash # openssl을 사용한 예시 openssl rand -hex 16 | sudo tee /var/lib/rabbitmq/.erlang.cookie sudo chown rabbitmq:rabbitmq /var/lib/rabbitmq/.erlang.cookie sudo chmod 600 /var/lib/rabbitmq/.erlang.cookie
  RabbitMQ 데이터 디렉터리가 다른 경우 /var/lib/rabbitmq/로 바꾸십시오.
- 후속 노드 (노드 B, 노드 C 등)에서:
  RabbitMQ 서비스를 중지합니다.
  bash sudo systemctl stop rabbitmq-server
  .erlang.cookie 파일을 노드 A에서 노드 B(및 C 등)의 해당 위치로 복사합니다. 소유권과 권한이 동일한지 확인합니다.
  bash # 노드 B에서 파일을 복사한 후 sudo chown rabbitmq:rabbitmq /var/lib/rabbitmq/.erlang.cookie sudo chmod 600 /var/lib/rabbitmq/.erlang.cookie
모든 노드에서 RabbitMQ 시작:
모든 노드에서 RabbitMQ 서비스를 시작합니다. 클러스터 조인 역할을 할 첫 번째 노드를 마지막에 시작하는 것이 좋습니다.
bash sudo systemctl start rabbitmq-server
노드를 클러스터에 조인:
초기 노드가 될 노드 하나(예: 노드 A)를 선택합니다. 그런 다음 각 후속 노드(예: 노드 B)에서 노드 A에 조인합니다.
- 노드 B에서:
  bash sudo rabbitmqctl join_cluster rabbit@node-a
  노드 A의 호스트 이름으로 node-a를 바꾸십시오. 노드 B에서 호스트 이름을 확인할 수 있는지 확인하십시오. DNS가 신뢰할 수 없는 경우 전체 네트워크 이름(예: [email protected])을 지정해야 할 수 있습니다.
- 노드 C에서:
  bash sudo rabbitmqctl join_cluster rabbit@node-a
- 중요 참고: 기본적으로 join_cluster는 노드를 클러스터의 일부로 만들지만 큐와 교환은 유지합니다. "