RabbitMQ 명령어로 메시지 제거 및 큐 내용 관리하기

RabbitMQ 큐를 비우는 것은 단순한 도구입니다. 큐에 테스트 메시지, 오류 작업 항목 또는 의도적으로 폐기하기로 결정한 백로그가 포함된 경우 유용합니다. 하지만 단순히 추측만 하는 경우에는 위험합니다. 제거 작업은 백로그가 발생한 이유를 알려주지 않으며, 느린 소비자, 잘못된 재시도 루프, 또는 메시지를 잘못된 위치로 보내는 데드 레터 정책을 수정하지 않습니다.

이 가이드의 명령어를 운영 체크리스트로 사용하세요: 큐를 검사하고, 가상 호스트를 확인하고, 소비자에게 어떤 일이 발생할지 결정하고, 제거하려는 메시지만 제거한 후 결과를 확인하세요.

`rabbitmqctl`로 큐 내용 이해하기

제거하기 전에 큐의 현재 상태를 이해하는 것이 필요한 경우가 많습니다. rabbitmqctl 도구는 큐 통계를 검사하는 여러 명령어를 제공합니다. 메시지 수를 이해하는 데 가장 관련 있는 명령어는 list_queues입니다.

큐 및 메시지 수 나열하기

rabbitmqctl list_queues 명령어는 큐 메트릭을 표시합니다. 제거 결정을 위해 가장 중요한 구분은 준비된 메시지와 확인되지 않은 메시지 간의 차이입니다.

구문:

rabbitmqctl list_queues [옵션]

예제: 큐 이름 및 메시지 수 표시

모든 큐와 해당 메시지 수를 표시하려면 다음 명령어를 사용할 수 있습니다:

rabbitmqctl list_queues name messages_ready messages_unacknowledged

이 명령어는 다음과 유사한 출력을 생성합니다:

name            messages_ready    messages_unacknowledged    consumers
my_queue        0                 0                          2
another_queue   150               25                         4

이 출력에서:

name: 선택된 가상 호스트 내의 큐 이름입니다.
messages_ready: 전달을 기다리는 메시지입니다.
messages_unacknowledged: 이미 소비자에게 전달되었지만 아직 확인되지 않은 메시지입니다.
consumers: 연결된 소비자 수입니다.

messages_ready가 증가하고 있다면, 생산자가 소비자보다 빠르거나 소비자가 누락된 것입니다. messages_unacknowledged가 증가하고 있다면, 소비자가 작업을 수락했지만 완료하지 못하고 있는 것입니다. 제거는 준비된 메시지만 지웁니다. 소비자가 이미 처리 중인 작업을 제거하는 깔끔한 방법이 아닙니다.

특정 큐 세부 정보 검사

스크립팅을 위해 JSON 출력을 사용하고 JSON 인식 도구로 필터링하세요:

rabbitmqctl list_queues -p /prod name messages_ready messages_unacknowledged consumers --formatter json

인간이 사고를 확인할 때는 테이블 출력이 더 빠른 경우가 많습니다:

rabbitmqctl list_queues -p /prod name messages_ready messages_unacknowledged consumers state

큐에서 메시지 제거하기

큐에 더 이상 필요하지 않은 메시지가 쌓였거나 테스트 데이터를 지우려는 경우 purge_queue 명령어가 주요 도구입니다. 이 명령어는 지정된 큐에서 모든 메시지를 제거합니다. 강력한 작업이므로 주의해서 사용해야 하며, 제거된 메시지는 복구할 수 없습니다.

`purge_queue` 명령어

rabbitmqctl purge_queue 명령어는 큐 이름을 인수로 사용합니다. 가상 호스트를 지정하려면 -p를 사용하세요.

구문:

rabbitmqctl purge_queue [-p <vhost_name>] <queue_name>

예제: 기본 가상 호스트에서 큐 제거하기

기본 가상 호스트에 processing_errors라는 큐가 있고 모든 메시지를 지우려고 한다고 가정해 보겠습니다:

rabbitmqctl purge_queue processing_errors

성공적으로 실행되면 rabbitmqctl이 제거된 메시지 수를 보고합니다:

Purged 150 messages from queue 'processing_errors' in vhost '/'

예제: 특정 가상 호스트에서 큐 제거하기

dead_letter_queue 큐가 my_vhost라는 가상 호스트에 있는 경우 다음을 사용합니다:

rabbitmqctl purge_queue -p my_vhost dead_letter_queue

이 명령어는 지정된 큐와 가상 호스트에서 제거된 메시지 수를 나타내는 유사한 확인 메시지를 반환합니다.

`purge_queue`의 중요한 고려 사항

되돌릴 수 없음: 제거된 준비 메시지는 다른 곳에 캡처된 데이터나 재생 가능한 소스 데이터가 없는 한 사라집니다.
확인되지 않은 메시지: 제거는 이미 소비자에게 전달된 메시지를 안정적으로 지우지 않습니다. 깨끗한 재설정이 필요한 경우 먼저 소비자를 중지하세요.
권한: rabbitmqctl을 실행하는 사용자는 가상 호스트와 큐에 대한 적절한 액세스 권한이 필요합니다.
잘못된 가상 호스트 위험: 공유 환경에서는 항상 -p를 지정하세요.

다음은 프로덕션 수준 큐를 위한 더 안전한 제거 순서입니다:

# 1. 정확한 가상 호스트에서 큐 검사
rabbitmqctl list_queues -p /prod name messages_ready messages_unacknowledged consumers

# 2. 배포 시스템에서 소비자 중지 또는 축소
# 예시일 뿐입니다. 플랫폼의 일반 제어 평면을 사용하세요.

# 3. 진행 중인 메시지를 이해하기 위해 다시 확인
rabbitmqctl list_queues -p /prod name messages_ready messages_unacknowledged consumers

# 4. 큐 제거
rabbitmqctl purge_queue -p /prod processing_errors

# 5. 확인
rabbitmqctl list_queues -p /prod name messages_ready messages_unacknowledged consumers

큐가 데드 레터 큐인 경우, 제거하기 전에 관리 UI나 제어된 소비자를 통해 몇 개의 메시지를 샘플링하는 것이 좋습니다. 데드 레터 큐는 종종 직렬화 버그, 잘못된 라우팅 키, 만료된 메시지 또는 거부된 작업의 유일한 쉬운 증거를 포함합니다.

큐 관리 모범 사례

효과적인 큐 관리는 제거 방법을 아는 것 이상을 포함합니다. 고려해야 할 몇 가지 모범 사례는 다음과 같습니다:

정기적인 모니터링

rabbitmqctl list_queues 또는 RabbitMQ 관리 UI를 사용하여 큐를 지속적으로 모니터링하세요. messages_ready 및 messages_unacknowledged 수에 특히 주의하세요. 예상치 못하게 높은 숫자는 다음을 나타낼 수 있습니다:

소비자가 다운되었거나 처리를 중단했습니다.
소비자가 생산 속도를 따라잡기에는 너무 느립니다.
메시지 처리 로직의 버그로 인해 확인이 실패하고 있습니다.

알림 설정

큐 메트릭을 기반으로 알림을 설정하세요. 예를 들어, messages_ready가 특정 임계값을 장기간 초과하면 알림을 트리거합니다. 이 사전 예방적 접근 방식을 통해 애플리케이션 성능이나 데이터 무결성에 영향을 미치기 전에 문제를 해결할 수 있습니다.

통제된 제거

예정된 유지보수: 임시 큐가 의도적으로 폐기 가능한 경우, 알려진 시간대에 정리를 자동화하세요.
문제 해결: 백로그를 설명할 충분한 증거를 확보한 후에 제거하세요.
용량 계획: 반복적인 제거는 문제의 신호입니다. 일반적으로 소비자 용량, 재시도 동작 또는 라우팅에 주의가 필요함을 의미합니다.

데드 레터링

성공적으로 처리할 수 없는 메시지의 경우 데드 레터링을 구성하세요. 이는 거부되거나, 만료되거나, 제한을 초과한 메시지를 검사용 다른 교환/큐로 라우팅합니다. 해당 메시지를 재생, 보관 또는 폐기해야 하는지 이해한 후에만 데드 레터 큐를 제거하세요.

멱등성

소비자를 멱등적으로 설계하세요. 즉, 동일한 메시지를 여러 번 처리하는 것이 한 번 처리하는 것과 동일한 효과를 가져야 합니다. 이는 제거 및 재전달의 위험을 줄이기 때문에 중요합니다. 중복 처리가 잘못된 애플리케이션 상태로 이어지지 않기 때문입니다.

제거하지 말아야 할 경우

그래프가 높다고 해서 제거하지 마세요. 백로그는 유용한 압력이 될 수 있습니다: 생산자가 소비자보다 빠르거나, 소비자가 실패하거나, 다운스트림 서비스가 느리다는 것을 알려줍니다. 제거는 그 신호를 숨깁니다. 비즈니스에서 해당 메시지를 처리하지 않기로 결정했을 때 올바른 조치입니다.

좋은 제거 티켓이나 사고 기록은 네 가지 질문에 답해야 합니다:

어떤 가상 호스트와 큐가 제거되었습니까?
제거 전에 준비된 메시지와 확인되지 않은 메시지의 수는 얼마였습니까?
소비자가 중지되었습니까, 아니면 계속 실행 중이었습니까?
메시지를 폐기하는 것이 왜 허용되었습니까?

그 기록은 당시에는 지루하게 느껴질 수 있지만, 나중에 누군가 작업이 어디로 갔는지 물을 때 많은 논쟁을 절약해 줍니다.