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
|
출처
'DevOps > Kafka' 카테고리의 다른 글
| [Debezium] 1. Introduction (2) | 2025.08.11 |
|---|---|
| [MongoDB Kafka Connector] 1. Kafka Connector (0) | 2025.08.10 |
| [Kafka] 9. Kafka Streams (0) | 2025.05.12 |
| [실전 카프카 개발부터 운영까지] 6. 컨슈머의 내부 동작 원리와 구현 (0) | 2025.05.08 |
| [실전 카프카 개발부터 운영까지] 5. 프로듀서의 내부 동작 원리와 구현 (0) | 2025.05.07 |