Dead Letter Queue (DLQ)

❓Dead Letter Queue (DLQ)란?

Dead Letter Queue(DLQ)는 정상적으로 처리할 수 없는 메시지를 따로 저장하는 큐를 말한다. 메시지 소비(Consumer) 중 오류가 발생하거나 재시도(retry)를 여러 번 해도 실패하는 경우 해당 메시지를 버리지 않고 DLQ에 적재한다. 주로 장애 확산 방지, 데이터 유실 방지, 문제 분석 및 복구를 위해 사용한다.

❓왜 필요한가?

메시지 큐를 사용하는 시스템에서는 가끔 비정상적인 메시지가 발생할 수 있다.

예를 들어

• 메시지 포맷이 이상하다.
• 메시지 내용이 누락되었다.
• 비즈니스 로직 상 처리가 불가능하다.
• 외부 시스템 오류로 처리가 실패했다.
• 시스템 버그나 일시적인 장애가 발생했다.

이럴 때 문제 있는 메시지를 무한 재시도하거나 그냥 버려버리면 서비스 전체가 느려지거나 장애가 퍼지거나 데이터 유실이 발생할 수 있다. 그래서 실패한 메시지를 따로 안전하게 관리하는 게 DLQ이다.

✅ DLQ를 사용하는 이유

• 장애 격리 : 잘못된 메시지 하나 때문에 전체 시스템이 장애를 겪지 않도록 한다.
• 분석 및 재처리 : 실패한 메시지를 모아서 원인을 분석하거나 복구 처리를 할 수 있다.
• 데이터 유실 방지 : 에러가 발생해도 메시지를 안전하게 저장해 나중에 다시 처리할 수 있다.

DLQ로 이동하는 조건

• 소비자가 메시지 처리 중 예외가 발생한 경우
• 설정한 재시도 횟수 초과한 경우
• 메시지의 TTL(Time-To-Live)이 만료된 경우
• 메시지 포맷 검증 실패 또는 비즈니스 로직 오류 발생 시

🔄️ DLQ 일반적인 처리 흐름

1. Producer가 메시지를 Main Queue에 전송
2. Consumer가 메시지 소비
3. 메시지 처리 실패
4. 재시도 -> 재시도 실패
5. DLQ로 이동
6. 운영자가 DLQ를 모니터링 및 수동/자동 복구

Producer -> Main Queue -> Consumer -> 처리 실패 -> DLQ 적재

🛠️시스템별 DLQ 차이

시스템	DLQ 처리 방식
Kafka	Dead Letter Topic 생성, Consumer가 실패 메시지를 수동 전송
RabbitMQ	Dead Letter Exchange(DLX) 설정, 메시지 TTL이나 reject로 DLQ 이동
AWS SQS	DLQ를 별도로 연결해놓고 재시도 실패 시 자동 이동

⚠️ DLQ를 운영할 때 주의할 점

DLQ에 쌓이는 메시지 수를 모니터링해야 한다. 왜냐하면 운영 장애의 전조일 수 있기 때문이다. 그리고 쌓인 메시지는 분석 후 수동 복구하거나 별도 복구 워커를 만들어 자동화할 수도 있다. 무조건 재처리하는 게 아니라 루트 원인 분석 후 정상화된 데이터만 복구해야 한다는 점을 주의해야 한다.

📝 배운점

DLQ는 메시징 시스템의 안정성과 신뢰성을 높이는 데 꼭 필요한 요소라는 걸 깨달았다. 특히 장애를 조기에 감지하고 확산을 막는 데 매우 중요하다는 것을 알게 되었다. Kafka, RabbitMQ, SQS처럼 다양한 시스템에서도 DLQ 패턴이 기본적으로 적용되는 이유를 이해했고 앞으로 큐를 사용하는 시스템을 설계할 때는 DLQ를 반드시 기본 설계 요소로 고려해야겠다고 느꼈다.