Mar 23, 2026

마지막 업데이트 Mar 31, 2026

RabbitMQ Connection Blocked 가이드

RabbitMQ에서 connection blocked가 보이면 broker가 갑자기 이상해진 경우보다, 리소스 압박 아래에서 자신을 보호하려고 publishing을 늦추거나 멈추는 경우가 더 많습니다. 많은 팀이 client부터 디버깅하지만, 실제로는 broker가 이미 안전 임계치를 넘었다는 신호를 주고 있는 경우가 흔합니다.

핵심은 간단합니다. 먼저 memory나 disk 같은 명시적 resource alarm 때문에 blocked인지 확인하고, 그다음 flow control인지, 더 아래쪽 queue backlog 문제인지 분리해서 봐야 합니다. blocked publisher는 대개 root cause가 아니라 broker 보호 메커니즘의 표면 증상입니다.

blocked와 일반적인 publisher slowdown을 먼저 분리하세요

blocked connection은 단순히 publisher가 느린 상태와 다릅니다.

RabbitMQ blocked-connection notification은 broker가 리소스 경계를 넘었기 때문에 publishing을 의도적으로 늦추거나 멈춘다는 뜻에 가깝습니다. 즉 client 증상만이 아니라 broker 쪽 안전 신호입니다.

connection blocked는 보통 무엇을 뜻하나

RabbitMQ 문서를 보면 publishing connection은 broker resource가 안전 기준 아래로 내려가면 blocked될 수 있습니다.

대표적인 명시적 이유는 아래입니다.

memory alarm
disk alarm

경보가 해소되면 RabbitMQ는 다시 unblocked notification을 보냅니다.

memory와 disk alarm부터 확인하세요

처음 분기는 거의 항상 여기서 시작하는 게 좋습니다.

node가 memory watermark를 넘었는가
free disk가 threshold 아래로 내려갔는가
한 node만 문제인가, cluster 전체 문제인가

이 확인을 건너뛰고 client library만 디버깅하면 시간을 많이 잃기 쉽습니다.

blocked와 flow control은 비슷해 보여도 다릅니다

RabbitMQ는 queue나 downstream component가 publisher 속도를 따라가지 못할 때 flow control이라는 back pressure도 사용합니다.

즉 publish가 막혀 보인다고 해도 실제로는 두 가지 다른 이야기가 섞여 있을 수 있습니다.

memory나 disk alarm 때문에 blocked된 상태
나머지 pipeline이 못 따라와서 flow control이 걸린 상태

둘 다 publish progress를 줄이지만, 다음에 봐야 할 곳은 다릅니다.

흔한 원인

1. Memory alarm

node가 설정된 memory watermark를 넘었습니다.

2. Disk alarm

가용 디스크 공간이 기준치 아래로 떨어졌습니다.

3. publisher는 빠르고 downstream은 느린 경우

나머지 pipeline이 못 따라와서 flow control이 걸립니다.

4. 실제 bottleneck은 queue나 consumer 쪽인 경우

connection blocked는 표면 증상이고, 근본 원인은 더 아래에 있을 수 있습니다.

실전 점검 순서

1. broker alarm부터 확인합니다

memory나 disk 압박이 있다면 그것이 첫 번째 원인입니다.

2. blocked인지 flow-controlled인지 구분합니다

앱에서 느끼는 증상은 비슷해도 해결 방향은 달라집니다.

3. queue growth와 consumer throughput을 같이 봅니다

queue가 늘고 consumer가 밀린다면 blocked connection은 surface symptom일 가능성이 큽니다.

4. client가 blocked와 unblocked notification을 실제로 받는지 봅니다

broker가 보내는 신호를 애플리케이션이 어떻게 인식하는지 확인해야 합니다.

5. 용량 문제인지, 디스크 정리 문제인지, traffic shaping 문제인지 결정합니다

문제 종류를 구분하기 전에 publisher restart를 반복하지 않는 편이 좋습니다.

바로 확인할 명령

rabbitmqctl list_connections name state channels send_pend
rabbitmqctl list_queues name messages_ready messages_unacknowledged
rabbitmq-diagnostics status

이 명령으로 broker resource pressure와 queue growth가 동시에 있는지 빠르게 확인할 수 있습니다.

초반 분기에 도움이 되는 shortcut

publish가 멈춘 것처럼 보일 때는 아래처럼 먼저 갈라보세요.

alarm이 있고 memory나 disk가 빠듯하다: broker resource protection 먼저 의심
alarm은 없는데 queue가 계속 는다: throughput mismatch나 flow control 먼저 의심
alarm이 해소되면 publish도 바로 돌아온다: client보다 resource threshold를 먼저 확인
app에서 blocked notification을 못 받는다: broker 침묵보다 client-side handling을 먼저 점검

이 분기만으로도 초반의 잘못된 restart를 꽤 줄일 수 있습니다.

blocked publisher를 볼 때의 관점

가장 중요한 질문은 “왜 client가 publish를 못 하지?”보다 “broker가 어떤 resource pressure나 back-pressure에 반응하고 있지?”입니다.

이 관점으로 보면 조사 방향이 아래처럼 빨리 정리됩니다.

memory, disk 같은 강한 resource pressure
flow control 같은 더 부드러운 pipeline pressure
queue growth와 느린 consumer 같은 더 아래쪽 workload imbalance

어느 가지인지 먼저 알면 해결 경로가 훨씬 선명해지고, 의미 없는 client restart도 줄어듭니다.

FAQ

Q. blocked면 RabbitMQ가 다운된 건가요?

아니요. broker가 node를 보호하기 위해 publishing을 의도적으로 늦추거나 멈춘 경우가 더 많습니다.

Q. blocked와 flow control은 같은 건가요?

아니요. 둘 다 back pressure지만 blocked는 보통 명시적인 resource alarm과 더 직접적으로 연결됩니다.

Q. 가장 빠른 첫 단계는 무엇인가요?

client를 만지기 전에 memory watermark, free disk, queue backlog를 같이 보세요.

Q. publisher를 재시작해도 왜 금방 다시 막히나요?

broker가 특정 프로세스가 아니라 resource pressure 자체에 반응하고 있기 때문입니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.