RabbitMQ queue가 계속 커질 때 가장 먼저 물어야 할 질문은 단순합니다. publisher가 넣는 속도가 consumer가 처리하는 속도보다 빠른가입니다. 여기서 흔히 하는 실수는 total message count만 보고 끝내는 것입니다. ready가 늘어나는 큐와 unacked가 늘어나는 큐는 전혀 다른 병목을 의미합니다.
핵심은 backlog를 ready, unacked, 또는 둘 다인지로 먼저 나누는 것입니다. queue growth는 대개 broker 문제로 보기 전에 throughput balance 문제로 보는 편이 훨씬 정확합니다.
먼저 ready와 unacked를 나눠서 보세요
RabbitMQ queue incident에서 가장 신호가 좋은 분기입니다.
늘어나는 queue는 보통 아래 중 하나로 보입니다.
ready는 높고unacked는 낮음ready는 낮고unacked는 높음- 둘 다 같이 증가
이 셋은 같은 문제가 아닙니다. total message count만 보면 bottleneck 위치를 놓치기 쉽습니다.
ready가 계속 늘어난다면
이건 delivery 이전 단계에서 consumer가 못 따라간다는 뜻에 가깝습니다.
대표 원인은 아래와 같습니다.
- consumer 수가 부족함
- consumer가 끊겼거나 idle 상태
- consumer throughput이 publish rate보다 낮음
- burst traffic을 받을 buffering이나 shedding 계획이 없음
unacked가 계속 늘어난다면
이건 메시지가 consumer까지는 갔지만 in-flight 상태로 너무 오래 머문다는 뜻입니다.
대표 패턴은 아래와 같습니다.
- manual acknowledgement가 늦음
- prefetch가 너무 큼
- handler가 느림
- failure path가 requeue나 stall을 반복
이 패턴이라면 RabbitMQ Messages Stuck in unacked가 가장 직접적인 다음 글입니다.
consumer capacity와 prefetch를 같이 봐야 합니다
RabbitMQ 문서에서 prefetch는 in-flight로 허용되는 unacknowledged delivery 수를 제한하는 개념입니다.
즉 prefetch가 너무 크면 느린 consumer가 큰 in-flight window 뒤에 숨어버리고, 너무 낮으면 반대로 throughput이 불필요하게 제한될 수 있습니다.
중요한 질문은 “최적 prefetch가 몇이냐”가 아니라 “지금 prefetch가 handler 속도와 queue 동작에 맞느냐”입니다.
이 증가가 정상 buffering인지 병적 증가인지 구분하세요
모든 queue growth가 곧바로 장애는 아닙니다.
queue는 원래 아래 같은 역할도 합니다.
- burst traffic 흡수
- downstream recovery 동안 작업 버퍼링
- 짧은 spike 완화
하지만 증가가 안정화되지 않고, drain이 너무 느리거나, memory와 disk, latency 목표를 위협하기 시작하면 운영 incident가 됩니다.
queue length limit은 피해 범위를 줄일 뿐 throughput을 고치지는 않습니다
RabbitMQ는 queue length limit을 지원하고 정책으로 관리하는 방식을 권장합니다.
queue limit은 느린 consumer를 고쳐주지는 않지만, failure mode와 resource usage를 더 예측 가능하게 만들어줍니다.
실전 점검 순서
1. ready와 unacked를 구분합니다
backlog가 delivery를 기다리는지, 이미 consumer 안에 들어가 있는지 먼저 알아야 합니다.
2. consumer가 실제로 연결되어 있고 active한지 확인합니다
consumer가 없거나 idle이면 queue growth는 거의 mystery가 아닙니다.
3. publish rate와 실제 consume rate를 비교합니다
여기서 throughput mismatch가 분명해집니다.
4. acknowledgement 동작을 확인합니다
늦거나 비정상적인 ack는 delivery 문제를 growing queue로 바꿀 수 있습니다.
5. prefetch와 queue limit을 함께 봅니다
이 설정들은 root cause를 만들지 않더라도, 문제가 보이는 방식과 영향 범위를 크게 바꿉니다.
바로 확인할 명령
rabbitmqctl list_queues name messages_ready messages_unacknowledged consumers
rabbitmqctl list_consumers
rabbitmqctl list_connections name state channels
rabbitmq-diagnostics ping이 명령으로 ready backlog와 unacked backlog를 분리하고, consumer와 connection이 실제로 건강한지 빠르게 볼 수 있습니다.
첫 15분에 쓰기 좋은 shortcut
queue가 안 줄어들 때는 아래처럼 먼저 분기해보세요.
- high
ready, lowunacked: missing consumer나 receive capacity 부족 먼저 - low
ready, highunacked: handler 속도, ack timing, prefetch 먼저 - 둘 다 증가: publish와 consume 양쪽 throughput mismatch 먼저
- burst 때만 늘고 나중에 안정화: queue가 의도한 buffering 역할인지 먼저 확인
이 분기만으로도 prefetch를 무작정 바꾸는 실수를 많이 줄일 수 있습니다.
queue growth를 보는 실전 관점
queue가 커질 때 가장 빠른 사고 방식은 “broker 문제인가?”보다 먼저 “throughput balance 문제인가?”로 보는 것입니다.
이 관점으로 보면 속도가 느려지는 위치를 더 쉽게 찾을 수 있습니다.
- delivery 이전: consumer가 없거나 충분히 빨리 받지 못함
- consumer 내부: handler가 메시지를 오래 붙잡고 있음
- downstream 의존성: DB나 외부 API 때문에 acknowledgement가 늦어짐
이 세 질문만 분명해져도 queue 그래프는 훨씬 덜 막연해집니다.
FAQ
Q. queue가 늘어나면 항상 RabbitMQ가 unhealthy한 건가요?
아니요. broker 고장보다 애플리케이션 throughput balance 문제인 경우가 더 많습니다.
Q. 가장 빠른 첫 단계는 무엇인가요?
설정을 바꾸기 전에 ready와 unacked를 따로 보세요.
Q. queue limit만 걸면 해결되나요?
아니요. 영향은 줄여주지만 근본 throughput mismatch를 해결하지는 못합니다.
Q. 언제 broker 탓을 멈춰야 하나요?
패턴이 consumer throughput이나 acknowledgement behavior bottleneck을 분명히 보여줄 때입니다.
Read Next
- delivered-but-not-finished work가 대부분이라면 RabbitMQ Messages Stuck in unacked를 보세요.
- publisher도 같이 느려진다면 RabbitMQ Connection Blocked를 보세요.
- consumer마다 너무 많은 work가 묶여 있다면 RabbitMQ Prefetch Guide를 보세요.
Related Posts
- RabbitMQ Messages Stuck in unacked
- RabbitMQ Prefetch Guide
- RabbitMQ Connection Blocked
- Kafka Consumer Lag Increasing
Sources:
- https://www.rabbitmq.com/docs/queues
- https://www.rabbitmq.com/docs/confirms
- https://www.rabbitmq.com/docs/4.1/maxlength
- https://www.rabbitmq.com/docs/4.0/consumer-prefetch
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.
먼저 읽어볼 가이드
검색 유입이 많은 핵심 글부터 이어서 보세요.
- 미들웨어 트러블슈팅 가이드: Redis vs RabbitMQ vs Kafka 개발자를 위한 미들웨어 트러블슈팅 허브 글입니다. Redis, RabbitMQ, Kafka 중 어떤 증상부터 먼저 봐야 하는지와 어떤 문제 패턴이 각 시스템에 가까운지 정리합니다.
- Kubernetes CrashLoopBackOff: 먼저 볼 것들 startup failure, probe, config, resource limit 관점에서 CrashLoopBackOff를 어떻게 나눠서 봐야 하는지 정리한 가이드입니다.
- Kafka consumer lag가 계속 늘 때: 트러블슈팅 가이드 Kafka consumer lag가 계속 늘어날 때 무엇부터 봐야 하는지 정리합니다. poll 주기, 처리 속도, rebalance, consumer 설정까지 실전 기준으로 다룹니다.
- Kafka Rebalancing Too Often 가이드 Kafka consumer group에서 rebalance가 너무 자주 일어날 때 membership flapping, poll timing, protocol, assignment churn을 어떤 순서로 봐야 하는지 설명하는 실전 가이드입니다.
- Docker container가 계속 재시작될 때: 먼저 확인할 것들 exit code, command failure, environment mistake, health check 관점에서 Docker restart loop를 푸는 실전 가이드입니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.