RabbitMq: ackMode = None
트러블슈팅: ackMode = ‘NONE’
상황
부하테스트를 여러번 시도 했었는데, 이상한 현상이 동일하게 발견됐습니다.
API 서버는 RabbitMQ로 초당 수백 개의 메시지를 쏟아내고 있었습니다.
RabbitMQ는 Consumer의 처리량과 관계없이 메시지를 소비하고 있었습니다.
Consumer 서버의 CPU 사용률은 20% 미만으로 매우 여유로웠고, 스레드들도 분명히 일을 하고 있었습니다.
문제 발생: 처음에는 50개 이상의 스레드가 정상적으로 동작하는 듯 보이다가, 특정 시점 이후 메시지를 처리하는 스레드가 갑자기 2개로 급격하게 줄어들었습니다.
증상 1: Consumer 서버에서 2개의 스레드만 처리를 하게됨
증상 2: RabbitMq에서 분당 소비되는 메시지 수가 급격하게 줄음
증상 3: RabbitMq의 분당 컨텍스트 스위칭 횟수가 급격하게 줄음
이 미스터리를 풀기 위해 두가지 가설을 세우고 검증하는 과정을 거쳤습니다.
가설 1: CPU 라이브락(Livelock)
내용:
busyWait와 같은 CPU 집약적 코드가 너무 많은 스레드와 만나, OS 스케줄러가 스레드 교체에만 모든 자원을 낭비하는 '라이브락' 상태에 빠졌을 것이다.
vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
r b swpd free buff cache si so bi bo in cs us sy id wa st gu
1 0 0 250348 25144 681148 0 0 78 26 255 1 2 0 98 0 0 0
0 0 0 250348 25144 681148 0 0 0 0 192 296 0 1 100 0 0 0
0 0 0 250348 25144 681148 0 0 0 0 270 367 1 0 99 0 0 0
0 0 0 250348 25144 681148 0 0 0 0 1486 1242 1 1 98 0 1 0
0 0 0 250348 25144 681148 0 0 0 12 196 311 1 0 100 0 0 0
1 0 0 248584 25144 681148 0 0 0 0 287 292 5 1 95 0 0 0
0 0 0 248584 25144 681148 0 0 0 0 208 295 1 0 99 0 0 0
0 0 0 248584 25144 681148 0 0 0 24 179 290 0 0 100 0 0 0
0 0 0 248584 25144 681148 0 0 0 0 162 274 1 0 100 0 0 0
0 0 0 248584 25144 681148 0 0 0 0 183 287 0 0 100 0 0 0
0 0 0 248584 25144 681152 0 0 0 0 215 315 2 0 98 0 0 0
0 0 0 248584 25144 681152 0 0 0 0 151 274 0 0 100 0 0 0
0 0 0 248584 25144 681152 0 0 0 0 164 289 0 0 99 0 0 0
0 0 0 248584 25144 681152 0 0 0 0 160 266 0 0 100 0 0 0
......기각:
vmstat지표 확인 결과, 실제 CPU는 대부분 유휴(Idle) 상태였음이 보여 이 가설은 폐기.
가설 2: TCP Zero-Window로 인한 네트워크 마비
내용:
ackMode=NONE으로 인해 Consumer가 메시지를 감당 못 하여 TCP 수신 버퍼가 가득 찼고, 이로 인해 RabbitMQ에 메시지 전송 중단을 요청하여 모든 것이 멈췄을 것이다.기각: RabbitMQ의
Ready큐에 메시지가 쌓인 적이 없습니다. 메시지는 계속 끊임없이 Consumer 애플리케이션으로 전달되고 있었습니다.
가설 3: 메시지가 Heap에 쌓이고, GC가 자주 실행
내용: 메시지들은 Consumer 애플리케이션으로 성공적으로 전달되며 많은 객체들이 JVM 힙 메모리(Heap Memory)에 쌓이고, GC에 부담을 줬을 것이다.
기각:
GC Pressure 그래프는 0%를 기록하며 GC로 인한 CPU 부하가 전혀 없음을 보여주었습니다.
Pause Durations 그래프 역시 GC로 인한 멈춤 시간이 10~30ms 수준으로 매우 짧고 안정적이어서, 시스템이 GC 때문에 멈췄다고 보기 어려웠습니다.
JVM Heap 그래프는 완만하게 사용량이 증가할 뿐, 시스템을 붕괴시킬 만한 급격한 메모리 적체 현상은 보이지 않았습니다.
모든 가설이 기각된 지금, 매우 이상한 상황에 놓였습니다.
CPU는 충분히 여유롭습니다 (라이브락 X)
메시지는 Consumer 애플리케이션까지 잘 전달되고 있습니다 (네트워크 마비 X)
메모리와 GC는 안정적입니다 (GC 문제 X)
분명히 50개 이상의 스레드가 일을 할 준비가 되어 있습니다.
하지만 현실에서는 단 2개의 스레드만이 일을 처리하고 있었습니다. 모든 자원이 정상인데도 애플리케이션이 제 성능을 내지 못하는 이 상황은, 문제의 원인이 하드웨어나 OS 같은 외부 환경이 아닌 애플리케이션과 프레임워크의 내부 동작 방식에 있다고 생각이 듭니다.
지금까지 기각된 모든 가설들의 공통된 전제는 ackMode=NONE 이었습니다. 이 설정은 RabbitMQ와 Consumer 사이의 '흐름 제어(Flow Control)'를 완전히 제거해 버립니다.
그렇다면, 문제의 원인이 CPU, 네트워크, 메모리 같은 자원의 문제가 아니라, 흐름 제어가 부재한 이 특수한 상태에서 스프링 AMQP 프레임워크(SimpleMessageListenerContainer)가 예상치 못하게 동작하는 것일지도 모른다고 생각하게 됐습니다.
어쩌면 프레임워크가 스스로를 보호하기 위해, 혹은 비정상적인 상황에 대응하기 위해 스레드 수를 극단적으로 줄여버리는 것일 수 있습니다.
이 가설을 검증하는 가장 확실한 방법은 ackMode=NONE 설정을 MANUAL로 변경하여, 시스템에 흐름 제어를 도입해보는 것이었습니다.
결과 1: 병목 지점의 이동
가장 먼저 눈에 띈 긍정적인 변화는 메시지가 쌓이는 위치였습니다.
변경 전 (
ackMode=NONE): RabbitMQ의Ready큐는 항상 0이었습니다. 모든 메시지는 Consume 서버로 보내지고 있었습니다.변경 후 (
ackMode=MANUAL): 이제 메시지들은 RabbitMQ의Ready큐에 차곡차곡 쌓이기 시작했습니다. 이제 메시지 백로그는 Consumer의 메모리가 아닌, 안정적이고 영속성이 보장되는 RabbitMQ에 의해 관리되었고, 제대로된 모니터링이 가능해졌습니다.
결과 2: 모든 스레드의 활성화
ackMode를 변경하자, 이전의 가장 큰 미스터리였던 '2개의 스레드만 일하던 현상'이 거짓말처럼 사라졌습니다.
변경 전:
ackMode=NONE이 유발한 내부 마비와 '패닉 리셋' 때문에, 50개 이상의 스레드 중 단 2개만 동작하는 기현상이 발생했습니다.변경 후: 명시적인 흐름 제어가 도입되자, 스프링 컨테이너의 '비상 재시작' 메커니즘이 더 이상 발동하지 않았습니다. 설정된 50개 이상의 모든 Consumer 스레드가 깨어나 동시에 RabbitMQ에 메시지를 요청하며 바쁘게 움직이기 시작했습니다.
위 과정으로 인해 유추할 수 있는게 버퍼 문제라고 생각이 됩니다.
ackMode=MANUAL로의 전환 실험은 매우 성공적이었습니다. '2개 스레드 문제'의 정확한 이유는 설명하지 못하지만, 원인은 ackMode 였던것을 찾아냈습니다.
하지만, 흐름 제어 문제를 해결하자마자 Consumer 서버의 CPU 사용률이 100%에 도달하는 상황이 발생하였고, 새로운 도전 과제가 생기게 됐습니다.
Last updated