[RabbitMQ] 4. Clustering & Mirroring

Clustering

RabbitMQ Clustering은 다수의 RabbitMQ를 하나의 RabbitMQ로 묶어 사용한다.

• Cluster 안의 RabbitMQ들은 Queue를 제외한 모든 정보를 공유한다. (*Cluster 안의 모든 RabbitMQ는 동일한 Exchange를 가지고 있음)
• Cluster 안에서는 Queue는 하나만 존재할 수 있다. (*Queue의 Routing Key 혹은 Header 정보가 동일한 Queue가 Cluster 안에서 중복 생성될 수 없음)
  • 이 때문에 Mirroring 기법이 등장했다.
• Cluster 안의 모든 RabbitMQ들은 Erlang Cookie라는 비밀키를 공유한다. (*해당 키가 있는지 확인해서 상대 RabbitMQ가 같은 Cluster 구성원인지 확인)
  • CLI Tool 또한 동일한 Cluster의 Erlang Cookie를 갖고있어야 제어가 가능함.
• Client(Pub/Sub)는 Cluster안의 RabbitMQ 중 하나의 RabbitMQ와 Connection을 맺는다.
  단, 연결한 RabbitMQ에 문제가 발생했을 때 빠르게 대처하기 위해 Client는 모든 RabbitMQ와의 Connection을 할 수 있는 환경이 구성되어야 한다.
  • 방법 1. Client와 Cluster 사이 Load balancer를 구성해 Client가 Cluster 안의 모든 RabbitMQ에 접속할 수 있는 환경 구성 및 Connection Load Balancing 수행
  • 방법 2. Client가 Cluster안의 모든 RabbitMQ의 IP, Port 정보를 갖고 있어 Client쪽에서 RabbitMQ 이상을 감지하고 Connection Load Balancing 수행

• Cluster 구성하는 RabbitMQ는 Disk모드와 RAM모드 중 1개 모드를 선택할 수 있다. (기본값은 Disk모드)
  • RAM모드 :
    • 특징 :
      - Message, Message Index, 다른 RabbitMQ 상태를 제외한 모든 정보를 RAM에만 저장 및 구동
      - Message관련 정보는 Disk에 저장하기 때문에 RAM 모드라고 처리량이 증가하진 않는다.
      - Exchange, Queue, Binding 등의 정보가 많고 설정이 자주 변경되는 환경이면 RAM 모드로 빠르게 변경할 수 있다.
  • Cluster 구성시 반드시 하나 이상의 RabbitMQ는 Disk 모드로 동작시켜야 한다.
    • RabbitMQ를 재시작시 최소 1개 이상은 원래 정보를 가지고 있어야하기 때문, RAM 모드는 재시작시 Disk에 저장한 값 이외의 모든 정보는 초기화되고 Disk 모드로 동작하는 RabbitMQ로 부터 정보를 받아오기 때문이다.

• Cluster 동작 중 RabbitMQ 추가할 수 있다.
  • Peer Discovery Plugin을 통해 Cluster에 추가된 RabbitMQ를 자동 발견 및 자동 Clustering 수행한다.
  • 추가된 RabbitMQ에 Queue가 없다면 부하가 제대로 분산되지 않는다.
  • 차가된 RabbitMQ에 Queue Rebalancing 작업을 통해 Cluster 부하를 분산 시킨다.
    • Queue Rebalancing 작업은 Script 수행 혹은 Queue Rebalancing Third-party Plugin을 통해 가능하다.

한계 :
Client가 Cluster의 모든 RabbitMQ에 접근할 수 있더라도 Queue는 Cluster안에서 하나만 존재하기 때문에 해당 Queue를 가진 RabbitMQ에 장애가 발생했을 때 손실을 막을 방법이 없다.
이런 상황에서도 Queue 손실을 막고자 적용한게 Mirroring 기법이다.

 

 

 

Mirroring

Cluster 안에 Message를 다수 RabbitMQ Queue안에 저장하는 기법이다.

• Mirroring 구성 시 Queue는 Master Queue와 Slave Queue로 구성되며 1:N 관계를 가진다.
  • Master Queue는 원본 Queue이며, 이를 복제한게 Slave Queue이다.
  • Master Queue마다 Slave Queue의 개수를 설정할 수 있다.
  • Client(Pub/Sub)과 상호작용하는건 Master Queue이며, Slave Queue는 단순히 Master와 Mirroring 작업만 수행한다.
• Master와 Slave사이 Mirroring은 Sync 방식이다.
  • Producer가 RabbitMQ에 Message를 보내면 첫 번째로 Master Queue에 Message가 전달되고 이를 감지해 Slave Queue들에게 전달받은 Message를 Mirroring 한 후 Producer에게 ACK를 전달한다.
  • 즉, Slave Queue가 많을 수록 Message 처리량이 떨어진다.
• RabbitMQ에서는 Master와 Slave Queue의 수를 Cluster를 구성하는 RabbitMQ의 정족수 만큼 구성하는걸 추천한다.
  • 5개의 RabbitMQ가 있으면 정족수인 3을 맞춰 Master (1), Slave(2) 로 구성한다.
• Slave가 중간에 추가되었을 때 이전 Master 값을 복제해오지 않기 때문에 Slave가 시작된 시점부터 Master를 Mirroring 한다.
  • 이 때문에 새로운 Slave Queue는 Master Queue 와 Message 구성이 다를 수 있으며 이를 Unsynchronised 상태라 표현한다.
  • 대신 Master의 기존 Message들이 Consume되면서 Slave와 Synchronised된다.
• Master Queue를 가진 RabbitMQ에 장애가 발생했을 때 일반적으로 가장 오래된 Slave Queue가 Master Queue로 승격된다. (단, 기본적으로 Unsynchronised 상태의 Slave Queue 는 제외한다.)
  • 만약 모든 Slave Queue가 Unsynchronised라면 Master Queue가 있는 RabbitMQ가 복구될 때까지 Queue 이용이 불가능하다. 이때 복구가 안된다면 Message는 손실된다.
  • 설정을 통해 Unsynchronised Slave Queue여도 Master로 승격시킬 수 있다. 단, 이때도 Message 손실은 발생한다.

 

 

참조 :
https://ssup2.github.io/theory_analysis/RabbitMQ_Ack/
https://ssup2.github.io/theory_analysis/RabbitMQ_Clustering_Mirroring/
https://backtony.github.io/spring/2021-09-21-spring-rabbitmq-1/