사내 서비스들 중 대부분 RabbitMQ를 사용하고 있지만, 과연 우리가 RabbitMQ를 100% 활용하고 있는가에 대한 의문이 들었다.
내가 알고 있는 RabbitMQ에 대한 정보는 극히 적었다.
AMQP를 통해 Producer와 Consumer 사이에서 메시지를 중계해주는 “메시지 브로커”라는 것이며,
크게 Standalone과 Cluster로 구성할 수 있으며, Standalone은 흔히 아는 단독으로 1개의 노드를 띄우며, Cluster는 3개 이상의 노드로 홀 수의 노드를 띄우는 구조로 나뉜다.
작은 서비스에서는 비용과 관리측면에서 Standalone으로 구성하였고, 어느정도 규모가 있는 서비스에는 Cluster로 구성하였다.
하지만 Kubernetes에 오면서 다수의 RabbitMQ가 필요한 상황이 생겼고 이를 전부 개별 Cluster로 구성할 지, 공통 Cluster를 사용할 지 등 전반적인 RabbitMQ에 대한 이해가 필요했다.
이 기회를 통해 RabbitMQ에 대해 분석 및 이해하여 성능을 최대한으로 올려보겠다.
RabbitMQ?
RabbitMQ는 “AMQP를 구현한 메시지 브로커”이다.
위의 한 줄로 RabbitMQ를 정의할 수 있지만, 내가 이해하기 쉽게 풀어서 작성하자면
Producer가 보낸 메시지를 Queue에 저장하고 해당 Queue를 바라보고 있는 Consumer에게 메시지를 전달하는 오픈소스 Tool이라고 생각한다.
Standalone vs Cluster
위 2가지 방식이외에도 다른 구조가 존재할 수는 있지만, 내가 알고 경험한 바로는 1개의 노드로 RabbitMQ를 구성하는 Standalone과 3개 이상의 홀 수 노드로 RabbitMQ를 구성하는 Cluster가 있다.
Cluster에서는 모든 노드가 마스터이며, 어떤 노드에 붙든 Read, Write를 할 수 있다.
Cluster에서의 Queue 동기화 방식
크게 2가지 방식으로 나뉘는 것 같다.
1. Classic Queue를 HA-mode를 통해 데이터 미러링
2. Quorum Queue 사용
1번 같은 경우는 일반적으로 Producer가 메시지를 RabbitMQ에 전달하고 Queue에 적재되면 해당 노드에서 다른 노드로 복제를 하고 복제가 완료되서야 Consumer가 해당 메시지를 사용할 수 있다.
(복제 후 Consumer가 소비되기 까지의 성능이 Cluster Node개수에 따라 얼만큼 달라지는 지 궁금하다.)
2번 같은 경우는 최근에 공식적으로 추가된 Queue이며, 복제 방식이 1번과 달리 메세지가 들어오는대로 Raft consensus 알고리즘을 통해 모든 노드에 각각 저장된다고 한다.
2번은 1번에 비해 높은 메모리 및 디스크 사용량이 필요하기에 단일 큐에 대한 성능은 1번이 조금 더 유리할 수 있다.
또한 비교적 최근에 추가된 큐여서 여러 기능들이 지원되지 않을 수 있지만, 데이터의 안정성과 전체적인 데이터의 처리량에 대해서는 이점을 가지는 것 같다. 특히나 노드 장애가 있을 경우에도 데이터의 일관성을 보장한다고 한다.
(이 부분은 이론보다 데모 테스트를 진행해서 조금 확인해보고 싶다.)
다만 공식문서에 따르면 Quorum Queue 사용을 적극 권장하고 있으며 버전 4.0부터는 유일한 옵션으로 채택될 것이라고 한다….? 선택의 여지가 없지만… 중요한 기능 호환이 안될 수 있기에 이 부분을 잘 확인해봐야 한다.
(https://www.rabbitmq.com/docs/migrate-mcq-to-qq)
Consumer의 동작 방식
여기서 Comsumer가 Queue에 있는 메시지를 Pull 하는 것이 아닌 RabbitMQ에서 Consumer로 Push 한다는 것에 의문이 들었다.
이는 여러가지 이유가 있지만 몇가지 눈에 띄는 내용을 보자면
1. Consumer는 RabbitMQ로부터 메시지를 받기만 하면 되기에 코드가 단순화된다.
2. RabbitMQ가 여러 Consumer들에게 메시지를 균등하게 분배할 수 있다.
3. Consumer가 메시지를 받은 후 정상적으로 처리하면 다시 RabbitMQ에 확인 신호를 보낼 때 용이하다.
4. RabbitMQ의 데이터 미러링이 끝난 후에 Consumer에 메시지를 Push 하는 것이 더 용이하다.
물론 더 심오한 내용이 있겠지만 내가 납득할 수 있을만한 이유들을 기록했다.
다음에는 RabbitMQ 내부 동작원리에 대해서 공부해봐야겠다.