지연된 메시지 문제 해결: 일반적인 큐 설정 오류 식별

RabbitMQ에서 지연된 메시지는 일반적으로 세 가지 중 하나를 의미합니다: 메시지가 messages_ready에서 대기 중이거나, messages_unacknowledged 상태로 소비자에게 있거나, 예상치 못한 재시도/데드레터 경로를 거치고 있는 경우입니다. 해결 방법은 어떤 상황에 해당하는지에 따라 다릅니다. 메시지가 잘못된 큐로 라우팅되고 있다면 소비자를 추가해도 도움이 되지 않습니다. 한 소비자가 이미 수천 개의 메시지를 가져와 승인을 중단했다면 라우팅 키를 변경해도 소용없습니다.

설정을 변경하기 전에 큐 상태를 확인하는 것으로 시작하세요:

rabbitmqctl -p prod list_queues name messages_ready messages_unacknowledged consumers arguments policy state
rabbitmqctl -p prod list_bindings source_name destination_name routing_key arguments

이 간단한 스냅샷만으로도 지연이 백로그 문제인지, 소비자 문제인지, 토폴로지 문제인지 알 수 있습니다.

지연된 메시지의 일반적인 원인

여러 설정 측면이 RabbitMQ 내에서 메시지가 지연되거나 멈춘 것처럼 보이게 할 수 있습니다. 이러한 원인은 데드레터링과 같은 고급 기능의 의도하지 않은 부작용부터 단순한 리소스 고갈이나 비효율적인 소비자 동작까지 다양합니다.

1. 데드레터링 루프 및 잘못된 설정

데드레터링은 메시지가 거부되거나, 만료되거나, 큐 길이 제한을 초과하거나, 지원하는 큐 유형에서 전달 제한에 도달할 때 메시지를 다른 익스체인지로 보냅니다. 이 기능은 재시도 및 잘못된 메시지 보관에 유용하지만, 부주의한 데드레터 경로는 하나의 실패를 루프로 만들 수 있습니다.

시나리오: 우발적인 DLX 루프

일반적인 시나리오는 큐에 데드레터 익스체인지(DLX)를 설정했지만, DLX가 메시지를 원래 큐로 다시 라우팅하거나 원래 큐를 DLX로 가진 다른 큐로 라우팅하도록 구성하는 것입니다. 이는 무한 루프를 만듭니다.

잘못된 설정 예시:

• 큐 A는 x-dead-letter-exchange: DLX_A 및 x-dead-letter-routing-key: routing_key_A로 설정됩니다.
• DLX_A (익스체인지)는 routing_key_A로 메시지를 큐 B로 라우팅합니다.
• 큐 B는 x-dead-letter-exchange: DLX_B 및 x-dead-letter-routing-key: routing_key_B로 설정됩니다.
• DLX_B가 routing_key_B로 메시지를 큐 A로 다시 라우팅하도록 설정되면 루프가 형성됩니다.

식별:

1. 큐 인수 확인: x-dead-letter-exchange, x-dead-letter-routing-key, x-message-ttl 및 재시도 큐 이름을 찾습니다.
2. 바인딩 검사: 원래 큐에서 DLX로, DLX에서 다음 큐로의 경로를 추적합니다.
3. 신중하게 샘플링: rabbitmqadmin get을 사용하는 경우 조사 중에는 재큐잉 ack 모드를 사용하여 실수로 프로덕션 메시지를 소비하지 않도록 합니다.

해결 방법:

• 재시도 경로를 명시적이고 유한하게 만듭니다.
• 영구적으로 실패한 메시지를 알림이 있는 보관 큐로 보냅니다.
• 포이즌 메시지에 대한 basic.nack(requeue=True) 루프를 피합니다. 처리할 수 없는 동일한 메시지를 재큐잉하면 영원히 지연된 것처럼 보일 수 있습니다.

2. 과도한 큐 길이 제한 및 메시지 누적

RabbitMQ는 최대 메시지 수(x-max-length) 또는 최대 크기(바이트)(x-max-length-bytes)로 큐 크기를 제한하는 메커니즘을 제공합니다. 리소스 관리에 유용하지만, 이러한 제한이 너무 낮게 설정되거나 소비자가 따라잡지 못하면 새 메시지가 삭제되거나 오래된 메시지가 처리 또는 잠재적 데드레터링을 기다리며 효과적으로 지연될 수 있습니다.

시나리오: x-max-length 트리거

큐가 x-max-length 제한에 도달하면 가장 오래된 메시지가 일반적으로 삭제되거나 데드레터링됩니다. 소비자가 느린 경우, 제한으로 인해 큐의 앞부분에서 메시지가 지속적으로 제거되고 새 메시지가 추가되어 앞부분의 메시지에 대해 지연 또는 손실 인식이 발생할 수 있습니다.

설정 예시:

# 큐에 대한 예시 설정 스니펫
queues:
  my_processing_queue:
    arguments:
      x-max-length: 1000
      x-dead-letter-exchange: my_dlx

이 예시에서 my_processing_queue에 1000개의 메시지가 포함되면 가장 오래된 메시지가 데드레터링됩니다. my_processing_queue의 소비자가 느린 경우 새 메시지가 DLX에 도달하는 데 지연되거나 x-max-length-bytes도 설정되어 도달하면 삭제될 수 있습니다.

식별:

1. 큐 깊이 모니터링: RabbitMQ 관리 UI 또는 메트릭을 통해 메시지 수(messages_ready 및 messages_unacknowledged)를 정기적으로 확인합니다. 지속적으로 높거나 빠르게 증가하는 큐 깊이는 위험 신호입니다.
2. 소비자 처리량: 소비자가 메시지를 승인하는 속도를 모니터링합니다. 승인 속도가 메시지 생성 속도보다 현저히 낮으면 큐가 커집니다.
3. 데드레터 큐 활동: x-max-length가 설정된 경우 기본 큐에서 삭제되는 메시지에 대해 데드레터 큐를 관찰합니다.

해결 방법:

• 제한 증가: 리소스 제약이 허용하는 경우 x-max-length 또는 x-max-length-bytes를 늘려 더 많은 버퍼를 제공합니다.
• 소비자 확장: 가장 효과적인 해결책은 종종 소비자 수를 늘리거나 기존 소비자의 처리 능력을 향상시켜 메시지 부하를 더 빠르게 처리하는 것입니다.
• 소비자 로직 최적화: 소비자가 메시지를 효율적으로 처리하고 신속하게 승인하는지 확인합니다.
• x-overflow 정책 고려: x-max-length 및 x-max-length-bytes의 경우 RabbitMQ는 x-overflow 정책을 지원합니다. 기본값은 drop-head(가장 오래된 메시지 제거)입니다. reject-publish로 설정하면 제한에 도달할 때 새 메시지가 거부되어 문제를 더 명확하게 알릴 수 있습니다.

3. 잘못된 소비자 프리페치 설정

프리페치는 일반적으로 클라이언트 코드에서 basic.qos로 구성되는 소비자 QoS 설정입니다. x-prefetch-count라는 일반적인 큐 인수가 아닙니다. 이 설정은 RabbitMQ가 승인을 기다리기 전에 소비자에게 전달할 수 있는 미승인 메시지 수를 제어합니다.

시나리오: 프리페치가 너무 높음

프리페치 수가 너무 높게 설정되면 단일 소비자가 빠르게 처리할 수 없는 대량의 메시지를 받을 수 있습니다. 이러한 메시지는 브로커에 의해 "미승인"으로 간주되어 다른 소비자가 사용할 수 없지만, 수신 소비자가 멈추거나 느린 경우 효과적으로 지연됩니다. 이는 다른 가용 소비자가 작업을 수행하지 못하게 할 수 있습니다.

예시 시나리오:

• 큐에 1000개의 준비된 메시지가 있습니다.
• 5명의 소비자가 있습니다.
• 각 소비자는 프리페치 수를 500으로 사용합니다.

소비자가 시작되면 브로커는 처음 두 소비자에게 각각 500개의 메시지를 전달할 수 있습니다. 나머지 3명의 소비자는 아무것도 받지 못합니다. 처음 두 소비자 중 하나라도 지연이나 오류가 발생하면 최대 500개의 메시지가 불필요하게 보류되어 전체 처리량에 영향을 미칠 수 있습니다.

식별:

1. 미승인 메시지 모니터링: 큐의 messages_unacknowledged 수를 관찰합니다. 이 숫자가 지속적으로 높고 활성 소비자의 프리페치 수 합계와 대략적으로 일치하면 프리페치 문제를 나타낼 수 있습니다.
2. 불균등한 소비자 부하: 일부 소비자가 많은 메시지를 처리하는 반면 다른 소비자는 거의 또는 전혀 처리하지 않는지 확인합니다.
3. 소비자 지연: 소비자가 메시지 생성 속도를 따라잡지 못하는 경우 높은 프리페치 수는 더 많은 메시지를 보류하여 문제를 악화시킵니다.

해결 방법:

• 프리페치 수 조정: 느리거나 가변적인 작업의 경우 낮게 시작한 다음 지연 시간, 처리량 및 messages_unacknowledged를 관찰하면서 증가시킵니다. 보편적인 최적 값은 없습니다. 빠른 멱등성 핸들러는 느린 외부 API를 호출하는 작업자보다 훨씬 높은 프리페치를 허용할 수 있습니다.
• 동적 프리페치 조정: 일부 복잡한 시나리오에서는 애플리케이션이 소비자 부하에 따라 프리페치 수를 동적으로 조정할 수 있습니다.
• 소비자 응답성 보장: 프리페치 문제를 완화하는 주요 방법은 소비자가 효율적이고 메시지를 신속하게 승인하도록 하는 것입니다.

4. 비정상적인 소비자 또는 소비자 충돌

엄격히 큐 설정 오류는 아니지만, 소비자 상태는 메시지 전달 시간에 직접적인 영향을 미칩니다. 소비자가 충돌하거나, 응답하지 않거나, 적절한 오류 처리가 없이 배포되면 메시지가 무기한 미승인 상태로 남아 지연될 수 있습니다.

식별:

1. messages_unacknowledged 모니터링: 지속적으로 높은 수의 미승인 메시지는 소비자가 처리 또는 승인하지 않고 있음을 강력히 나타냅니다.
2. 소비자 상태 확인: 소비자 애플리케이션에 대한 상태 확인을 구현합니다. RabbitMQ 관리 UI는 연결된 소비자를 표시할 수 있습니다.
3. 오류 로그: 소비자 애플리케이션의 로그에서 예외, 충돌 또는 반복되는 오류를 확인합니다.

해결 방법:

• 강력한 오류 처리: 소비자의 메시지 처리 로직 주위에 try-catch 블록을 구현합니다. 오류가 발생하면 재큐잉(루프를 피하기 위해 신중하게)하여 메시지를 nack하거나 데드레터링합니다.
• 소비자 재시작/복원력: 소비자 배포 전략에 충돌한 애플리케이션의 자동 재시작이 포함되도록 합니다.
• 재큐잉 전략: 재큐잉(basic.nack(requeue=True))에 주의하십시오. 메시지가 지속적으로 처리에 실패하면 큐를 차단할 수 있습니다. 처리할 수 없는 메시지에는 데드레터링을 사용하는 것을 고려하십시오.

5. 잘못된 큐 선언 및 라우팅

때로는 메시지가 단순히 잘못된 익스체인지나 큐로 전송되거나 바인딩이 올바르게 설정되지 않아 지연될 수 있습니다. 이는 배포 또는 설정 변경 중에 발생할 수 있습니다.

식별:

1. 게시자 반환 또는 대체 익스체인지 사용: 일치하는 바인딩이 없는 익스체인지에 게시된 메시지는 라우팅 불가능합니다. 게시자가 mandatory 플래그를 사용하고 반환을 처리하는 경우에만 반환되거나, 대체 익스체인지가 구성된 경우 해당 익스체인지로 라우팅될 수 있습니다.
2. 큐 내용: 메시지가 있어야 할 특정 큐가 비어 있지만 생산자 로직이 올바른 것 같으면 바인딩 및 라우팅 키를 확인합니다.
3. 트래픽 분석: RabbitMQ의 메시지 게시 확인 및 반환 값을 사용하여 메시지가 어디로 가는지(또는 가지 않는지)를 이해합니다.

해결 방법:

• 익스체인지 및 큐 이름 확인: 생산자와 소비자가 사용하는 익스체인지 및 큐 이름이 RabbitMQ에 선언된 이름과 정확히 일치하는지 다시 확인합니다.
• 바인딩 검사: 생산자가 사용하는 라우팅 키가 익스체인지와 큐 간 바인딩의 라우팅 키와 일치하는지 확인합니다.
• 실제 브로드캐스트에만 fanout 사용: 바인딩된 모든 큐가 모든 메시지를 수신해야 하는 경우 fanout이 더 간단합니다. 일부 소비자만 메시지를 수신해야 하는 경우 라우팅 키와 바인딩을 수정합니다.

메시지 지연 방지를 위한 모범 사례

• 포괄적인 모니터링: 큐 깊이, 소비자 미승인 메시지, 소비자 처리량 및 네트워크 I/O에 대한 강력한 모니터링을 구현합니다. 이상 징후에 대한 알림을 설정합니다.
• 처리량 이해: 메시지 생성 및 소비 속도를 프로파일링하여 큐와 소비자를 적절히 크기 조정합니다.
• 설정 테스트: 프로덕션에 배포하기 전에 스테이징 환경에서 모든 큐 및 익스체인지 설정, 특히 DLX 설정을 철저히 테스트합니다.
• 우아한 성능 저하: 큐를 차단하는 대신 지속적인 문제에 데드레터링을 사용하여 소비자가 오류를 우아하게 처리하도록 설계합니다.
• 설정 문서화: 익스체인지, 큐, 바인딩 및 해당 인수를 포함하여 RabbitMQ 토폴로지에 대한 명확한 문서를 유지합니다.

작동하는 인시던트 체크리스트

큐가 지연된 것처럼 보이면 변경하기 전에 답을 기록하세요:

rabbitmqctl -p prod list_queues name messages_ready messages_unacknowledged consumers arguments state
rabbitmqctl -p prod list_bindings source_name destination_name routing_key arguments
rabbitmqctl list_channels connection consumer_count messages_unacknowledged prefetch_count state
rabbitmq-diagnostics check_local_alarms

messages_ready가 높고 소비자가 0이면 소비자를 복원하거나 구독하는 큐 이름/vhost를 수정합니다. messages_unacknowledged가 높으면 소비자 상태와 프리페치를 검사합니다. 예상 큐가 비어 있으면 익스체인지 바인딩과 게시자 반환 처리를 검사합니다. 데드레터 큐가 증가하면 DLX 경로를 따라 재시도 루프나 포이즌 메시지를 찾습니다.

RabbitMQ 지연은 토폴로지가 단순할 때 훨씬 쉽게 해결할 수 있습니다: 명확한 큐 이름, 명시적인 데드레터 경로, 유한한 재시도, 측정된 프리페치, 준비 및 미승인 메시지 수에 대한 알림. 브로커는 메시지가 어디에 있는지 알려줄 것입니다. 어려운 부분은 묻기 전에 추측하려는 충동을 참는 것입니다.