DevOps/Kafka

[Kafka] Dead Letter Queue

noahkim_ 2025. 8. 15. 21:20

1. Dead Letter Queue란?

  • 메시지 브로커가 전달에 실패한 메시지를 별도로 보관하는 백업 저장소
  •  소비자가 처리 중 메시지 처리가 실패될 수 있음
  • ✅ 견고하고 장애에 강한 데이터 파이프라인을 구축할 때 중요한 요소

 

이점

목적 설명
Fault Tolerance
메시지 처리 중 오류가 발생해도 전체 시스템에 영향을 주지 않도록 함
Data Integrity
처리할 수 없는 메시지를 안전하게 저장해 데이터 손실을 방지
Recovery
원인 해결 후 DLQ에 쌓인 메시지를 선택적으로 재처리해 데이터/서비스 복구 가능
Monitoring & Troubleshooting
실패한 메시지를 추적·분석하여 오류 원인 파악 및 디버깅 용이
Scalability
실패한 메시지를 DLQ로 분리하여 메인 처리 흐름의 적체(Backlog) 방지 및 확장성 유지
Flexible Control
실패 유형에 따라 재시도 정책, 타임아웃 등 파라미터를 세밀하게 설정 가능

 

2. 발생 시나리오

이유 설명
존재하지 않는 큐 메시지가 없는 큐로 발송됨
최대 큐 길이 초과 큐의 허용 개수 한도를 넘김
메시지 크기 초과 단일 메시지가 사이즈 제한을 초과
TTL 만료 유효 시간(TTL) 내에 처리되지 않아 만료
교환(라우팅)에서 거절 다른 큐/익스체인지가 수신 거부
과도한 재시도 실패 메시지가 지나치게 많이 읽혔다가 거절됨

 

3. 구현

  • Kafka 자체에서 내장되어 있지 않음
  • 소비자 애플리케이션에서 구현 (Kafka의 오프셋 관리와 재시도 로직을 확장해 구현함)

 

처리 흐름

  • Consumer가 메시지를 처리하다 예외 발생
  • Error Handler가 호출됨
  • 재시도 로직이 설정되어 잇으면 지정된 횟수만큼 재시도
  • 재시도 후에도 실패하면 메시지를 DLQ Topic에 기록

 

구현 단계

단계 설명 특징
1. DLQ 토픽 생성 실패한 메시지를 저장할 전용 Kafka 토픽을 별도로 생성  
2. 에러 처리 로직 구현
Consumer 애플리케이션에 에러 처리 로직을 추가하여 메시지 처리 실패를 감지
 
3. 라우팅 로직 정의 메시지를 DLQ로 보낼 시점을 결정하는 로직 작성
재시도 정책을 적용한 뒤에도 실패하면 DLQ로 이동
4. 오프셋 관리
DLQ 재시도 시 메시지 중복 처리 방지를 위해 오프셋을 올바르게 관리
 

 

4. Best Practice

항목 설명 특징 / 예시
재시도 횟수 제한 설정 무한 루프를 방지하기 위해 재시도 횟수에 명확한 한계를 두어야 함
회복 불가능한 메시지만 DLQ에 쌓이도록 함
스키마 검증 활용
메시지가 예상한 스키마를 준수하는지 검증하여 불필요한 실패를 줄임
Confluent Schema Registry
DLQ 상태 모니터링
장애 상황을 빠르게 감지하고 대응.
메시지 적재량, 소비자 상태 등
Confluent Cloud 기능 활용
관리·모니터링 도구를 활용해 DLQ 운영을 더욱 안정적으로 수행.
Control Center

 

출처