RabbitMQ 4.x 메시지 신뢰성: 확인, 재시도, 데드 레터, 멱등성
기준: RabbitMQ 4.x 또는 현재 지원되는 3.13+, Java 클라이언트 버전은 서버와 호환되어야 합니다. latest나 기본 비밀번호를 사용하지 마세요.
1. 메시지 발행 경로
Publisher -> Exchange -> Queue -> Consumer
| |
publisher confirm ack/retry/dead letter
publisher confirm은 메시지가 Broker에 수신되었는지 확인해 주고, 소비자의 ack는 메시지가 성공적으로 처리되었는지 확인해 줍니다. 둘은 서로 다른 기능입니다.
2. 발행 측 신뢰성
publisher confirms를 활성화하고 Broker의 confirm을 받은 뒤에만 발행이 성공했다고 판단해야 합니다. 애플리케이션은 nack, 연결 끊김, 타임아웃을 계속 처리해야 하며, 업무 메시지 ID를 이용해 멱등 처리를 해야 합니다.
메시지 영속화와 durable exchange/queue, publisher confirm을 함께 사용하면 메시지 유실 위험을 낮출 수 있습니다. 하지만 이것이 업무 처리가 성공했다는 의미는 아닙니다. 중요한 이벤트의 경우 로컬 메시지 테이블이나 Outbox 패턴을 사용해 데이터베이스 상태와 발송 대기 메시지를 하나의 트랜잭션에 묶으세요.
3. 소비자 측 처리
소비자는 업무 처리가 성공한 뒤 ack해야 합니다. 일시적인 오류는 제한된 횟수만 재시도하고, 처리할 수 없는 메시지는 데드 레터 큐로 들어갑니다. 재시도 횟수와 backoff의 상한을 반드시 정해야 하며, 무한히 requeue하면 hot loop이 생깁니다.
소비 처리 로직은 반드시 멱등적이어야 합니다. 네트워크 재시도, 소비자 재시작, ack 손실로 인해 동일한 메시지가 다시 전달될 수 있습니다.
4. 고가용성과 지연 메시지
고가용성 환경에서는 quorum queue 사용을 우선 검토하세요. classic queue, 미러링 정책, 지연 메시지 플러그인의 동작은 RabbitMQ 버전에 따라 달라지므로 3.8 시절의 배포 명령을 그대로 복사해서는 안 됩니다.
지연 메시지 방식으로 TTL + DLX, 플러그인, Streams, 업무 스케줄러를 검토할 수 있습니다. 선택하기 전에 순서, 재시도, 용량, 운영 비용을 확인하세요.
5. 보안과 모니터링
애플리케이션마다 최소 권한 사용자를 만들고, 관리 인터페이스에서 TLS와 접근 제어를 활성화하세요. confirms, nack, unacked, 큐 깊이, 소비 지연 시간, 재시도 횟수, 데드 레터 수를 모니터링하세요. prefetch를 설정해 하나의 소비자가 한꺼번에 지나치게 많은 unacked 메시지를 보유하지 않도록 하세요.