RabbitMQ 살펴보기 - 성능
RabbitMQ는 매우 유연하고 신뢰할 수 있는 메시지 브로커 시스템으로서, 수많은 기업에서 실시간 데이터 처리 및 비동기 메시지 통신을 위해 사용되고 있습니다. 이 글에서는 RabbitMQ의 성능을 최적화하는 다양한 기술과 전략을 소개하며, 이를 통해 시스템의 처리량을 극대화하고 지연 시간을 최소화하는 방법을 탐구할 것입니다. 성능 개선을 위한 구체적인 설정 조정, 모니터링 방법 및 일반적인 문제 해결 방법에 대해서도 다룰 예정입니다.
RabbitMQ 살펴보기 - 성능
Message Publish Performance vs. Delivery Guarantee
Notification on failure
- mandatory = true : 메세지를 라우팅할 수 없는 경우 publisher 에게 메세지를 다시 반환한다.
Publisher confirms
- 큐 소비자가 메세지를 사용하거나, 메세지의 디스크 저장이 성공하면 브로커가 publisher 에 Basic.Ack 전송
- 메세지 라우팅이 불가한 경우 브로커가 publisher 에 Basic.Nack 를 전송
- ‘Publisher confirms’ 기능은 트랜잭션과 함께 사용할 수 없으며, Basic.Ack/Nack 처리를 비동기로 수행된다
Alternate exchanges
- 처음 Exchange 선언시, 대체 Exchange 를 함께 선언할 수 있다.
- Exchange 가 라우팅할 수 없는 경우, 메세지는 대체 Exchange 로 전달된다.
HA Queues
- AMQP 스펙 아님, RabbitMQ 만의 기능
- RabbitMQ 클러스터 모든/특정 노드에 저장되는 큐를 정의하여 가용성을 보장할 수 있다.
Transactions
- AMQP 의 Transaction, Commit/Rollback 스펙을 따른다.
- RabbitMQ는 모든 명령이 단일 큐에 영향을 줄때만 트랜잭션 원자성(atomicity) 을 보장해준다.
- delivery-mode: 2 인 경우, 디스크에 저장하는 I/O 로 인해 성능 문제가 발생할 수 있다.
HA Queues w/ Transactions
- HA 큐에서 트랜잭션 처리를 해줌
Persisted Messages
- delivery-mode: 2 로 메세지를 디스크에 저장
- 클러스터 node fail 에도 메세지를 유지하도록 해준다
- I/O 과부하/병목이 RabbitMQ 성능 저하로 이어질 수 있다
Message Get / Consume Performance
Consuming with acks and QoS > 1
- 한번에 여러개의 메세지를 가져온다 (prefetch)
- 한번에 가져온 (prefetch 된) 메세지에 대해 하나의 ack를 전송한다 (가져온 모든 메세지가 확인되었음을 알림)
- Rabbit MQ 의 QoS == Message Prefetch Count
Consuming with no-acks mode enabled
- 메세지를 소비자에게 보내는 가장빠른 방법
- 소비자의 메세지 수신여부를 확인(ack)하지 않는다
- RabbitMQ 는 수신자의 소켓 버퍼(rmem_default, rmem_max)가 다 찰때까지 메세지를 계속 전송한다
Consuming and using transactions
- 대부분의 경우 성능이 좋지 않다
- (QoS 설정을 사용하지 않는 경우에도) 트랜잭션을 사용해 메세지 확인 응답(ack)을 일괄 처리하면 성능이 향상될 수 있다
- 메세지 수신이 비활성화된(no_ack=true) 경우에는 트랜잭션이 동작하지 않는다
결론
RabbitMQ의 성능 최적화는 정확한 모니터링, 적절한 설정, 그리고 시스템의 규모에 맞는 아키텍처 설계에 의해 크게 좌우됩니다. 이러한 최적화 기법을 통해, RabbitMQ는 높은 동시성을 지원하며, 데이터 통신의 신뢰성과 효율성을 보장할 수 있습니다. 앞서 설명한 전략들을 실행함으로써, 기업은 데이터 흐름을 원활하게 관리하고 비즈니스 요구에 보다 빠르고 효과적으로 응답할 수 있을 것입니다. 성능 문제에 대응하기 위해 지속적인 관리와 개선이 필수적이라는 점을 잊지 마세요.
댓글남기기