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 |