dead letter queue

DLQ(Dead Letter Queue)

DLQ(Dead Letter Queue)는 모든 메시지 지향 미들웨어에서 필수적인 부분입니다. 잘못된 메시지 형식, 네트워크 오류, 시스템 장애 등 다양한 이유로 인해 의도한 수신자에게 전달되지 못한 메시지를 보관하는 특별한 큐입니다. 메시지가 수신자에게 전달되지 못하면 추가 처리를 위해 DLQ에 보관됩니다.

DLQ의 특징

첫째, 전달할 수 없는 메시지를 처리하는 메커니즘을 제공함으로써 신뢰성 있는 시스템을 구현할 수 있습니다. 만약, DLQ가 없다면 수신자에게 전달되지 못한 메시지들은 손실되어 데이터 손실 및 심각한 문제로 이어질 수 있습니다.

둘째, DLQ를 사용하면 시스템 가시성과 모니터링이 향상됩니다. 시스템 관리자는 DLQ의 내용을 검토하여 일반적인 오류 또는 문제 패턴을 파악하고 수정 조치를 취할 수 있습니다.

셋째, DLQ는 시스템 장애 발생 시 복구 프로세스를 단순화합니다. 처리되지 못한 메시지들을 쉽게 식별하고 재처리할 수 있습니다.

넷째, DLQ에 저장된 메시지는 문제 발생 원인을 분석하고 디버깅하는 데 중요한 정보를 제공합니다.

DLQ는 그렇다면 언제 사용될까?

DLQ는 보통 데이터 신뢰성이 매우 중요한 시스템에서 특히 유용합니다. 이러한 큐는 금융,물류 또는 의료 시스템과 같이 높은 수준의 안정성이 요구되는 시스템에서도 유용합니다.

또한 DLQ는 대량의 메시지를 처리하는 시스템에서도 유용합니다. DLQ를 사용하면 시스템 리소스에 부담을 주지 않으면서도 모든 메시지가 올바르게 처리되도록 보장할 수 있습니다.

그리고 여러 서비스 간 통신이 빈번한 마이크로서비스 환경에서 메시지 처리 실패를 관리하는 데 유용합니다.

마지막으로 이벤트 소싱 또는 CQRS(Command Query Responsibility Segregation) 패턴을 사용하는 시스템에서 이벤트 처리 실패를 관리하는 데 도움이 됩니다.

🚫 단점도 있다.

높은 수준의 신뢰성이 필요하지 않은 경우에는 필요하지 않고, DLQ 구현에 따른 추가적인 복잡성과 오버헤드를 정당화해야 할 수 있습니다.

또한 일부 실시간 처리 시스템에서는 DLQ를 사용하면 오히려 데이터 처리 지연이나 다른 문제가 발생할 수 있습니다.

📌 메시지 보관 정책 또한 중요

DLQ에 메시지를 보관하는 것은 데이터 보호법과도 관련이 있습니다. 메시지에 개인정보가 포함된 경우, 해당 데이터를 보호하는 적절한 보안 조치와 함께 데이터 보관 정책을 철저히 준수해야 합니다. 이는 불필요한 데이터 노출을 방지하고, 법적 요건을 충족시키는 데 중요합니다.

DLQ 구현 방법

Kafka를 사용하는 경우, Consumer 객체의 설정을 통해 DLQ를 구현할 수 있습니다.

1. enable.auto.commit=false과 같이 자동 커밋을 비활성화하여 메시지 처리 실패 시 재처리할 수 있도록 합니다.

2. max.poll.records처럼 한번에 가져올 레코드 수를 제한하여 처리 부하를 조절합니다.

3. 마지막으로 오류 발생 시 해당 메시지를 별도의 DLQ 토픽으로 전송합니다.

메시지 재처리 전략

DLQ에 들어간 메시지를 처리하는 전략에는 다음과 같은 것들이 있습니다.

• 주기적인 재시도(정해진 시간 후에 재전송)
• 메시지 수정 후 재처리(메시지 포맷과 같은 것을 재전송하는 방법)
• 관리자의 수동 개입을 통한 예외 처리
• 임계값 기반 알림(특정 메시지가 DLQ에 여러 번 도달하면 알림을 발생시켜 즉각적인 조치)

결론

DLQ는 메시지 기반 시스템의 안정성과 신뢰성을 크게 향상시킬 수 있는 중요한 컴포넌트입니다. 그러나 시스템의 특성과 요구사항을 고려하여 적절히 구현하고 관리해야 합니다. 올바르게 사용된다면, DLQ는 시스템의 견고성을 높이고 문제 해결 시간을 단축시켜 전반적인 서비스 품질을 개선하는 데 큰 도움이 될 것입니다.