DLQ 이론

개발주제 스터디 2주차

---

작성계기

DLQ라는 용어는 어디서 들어봤는데 구체적으로 무엇인지 잘 떠오르지 않았습니다.

 

DLQ가 무엇일까?

소프트웨어 시스템에서 오류로 인해 처리할 수 없는 메시지를 임시로 저장하는 대기열(Queue)을 의미합니다.

Consumer Application 내의 잘못된 조건이나 예기치 않은 상태 변경등 다양한 문제로 메시지가 처리되지 않을 수 있습니다.

Consumer Application이 메시지를 처리하려고 했지만 예외가 발생하거나, 지정된 횟수만큼 재시도를 할때 해당 메시지를 대기열로 이동합니다.

예외로 인해 메시지 전송이 실패되거나, 재시도를 할 때만 사용되는 별도로 분리된 대기열을 DLQ라 합니다.

실패한 메시지가 대기열에 영구적으로 남아 다른 정상 메시지의 처리를 방해하는 것을 막습니다.

메시지 전송 실패원인을 파악하거나 재처리를 할 수 있습니다.

 

DLQ의 장점?

(1) 데이터 유실 방지

메시지 브로커에서 Consumer가 메시지를 정상적으로 처리하지 못하면 기본적으로 재시도 없이 메시지가 손실될 가능성이 있습니다.

DLQ는 실패한 메시지를 안전하게 저장하기 때문에 다른 메시지의 소비에 영향을 주지 않게끔 합니다.

DLQ를 사용하지 않은 경우 (출처: https://rudaks.tistory.com/entry/신뢰성-오류-복구-패턴-데드-레터-큐Dead-Letter-Queue-패턴 )

DLQ를 사용하는 경우 (출처: https://rudaks.tistory.com/entry/신뢰성-오류-복구-패턴-데드-레터-큐Dead-Letter-Queue-패턴 )

(2) 재시도

재시도 횟수를 지정하여 실패한 메시지를 재처리할 수 있습니다. 이로인해 무한 재시도를 막습니다.

• 언제 재시도 정책을 사용할까?
  • 일시적인 네트워크 문제 
  • 외부 서비스 일시적 장애 
  • 데이터베이스 연결 문제
  • 시스템 부하로 인해 요청 거부할 경우 (throttling)

 

(3) 실패 메시지 원인 분석 (장애발생시 모니터링)

개발자의 실수, 네트워크 오류, 서비스내에서 발생된 장애 등으로 메시지가 소비되지 않을 수 있습니다. 개발자는 DLQ에 있는 메시지들을 조사하여 잠재되는 오류를 해결할 수 있습니다.

---

DLQ의 단점?

1. 시스템 복잡도가 높습니다.

• 재처리 로직등 복잡성 증가로 운영부담이 크고 유지보수가 어려워질 수도있습니다.
• 장애가 발생시에 DLQ로 전송하는 로직도 구현해야하며 모니터링 시스템까지 구축해야합니다.

2. 데이터 순서 유지가 어렵습니다.

• 데이터의 순서보장이 필요한 경우에는 어렵습니다. 실패한 메시지를 별도로 대기열에 즉시 이동 합니다.
  성공적으로 처리된 후속메시지들이 실패한 메시지보다 먼저 처리할 수 있습니다.
• DLQ에 들어간 메시지는 나중에 수동 또는 자동화된 프로세스를 통해 재처리됩니다.
  재처리 시점이 불확실하기 때문에 재처리되는 메시지가 원래 처리되었어야할 시점의 순서를 맞추기가 어렵습니다.
• DLQ에 저장된 메시지를 다시 처리할 때는 순서가 깨질 가능성이 높습니다.메시지를 특정 시점에만 재처리하도록 조정해야합니다.

 

---

배우면서 느낀점 및 결론

• DLQ를 도입해본 적은 없지만, MSA환경에서는 메시지 전달실패를 전담하는 큐이므로 일반적인 메시지큐와 분리되어 장애대응을 위한 시스템인거 같습니다.
• 실패된 메시지를 수집하여 잠재된 원인파악을 위해서 사용할 수 있습니다.
• 재시도(Retry) 를 수행할 수 있습니다.
• DLQ를 사용하게되면 에러를 피할 수는 없지만 에러를 관리할 수 있습니다.
• 아직은 프로젝트에 적용하지 못했고 실무에서도 적용해보지 못했던터라, 사이드프로젝트에 적용해봐야 될거같습니다.