728x90
반응형
Kafka의 **Dead Letter 처리 구조(Dead Letter Queue, DLQ)**는 메시지 소비(consumer) 과정에서 오류가 발생했을 때 원본 메시지를 별도 토픽에 안전하게 보관하고, 이후 재처리하거나 수동 분석을 가능하게 하는 방식입니다.
🔥 왜 필요한가?
| 상황 | 문제 |
| 소비자가 예외 발생 | 해당 메시지는 재시도 후에도 실패 |
| 순서 보장 환경 | 재처리를 위해 처리 순서를 깨뜨릴 수 없음 |
| 데이터 유실 위험 | 실패 메시지를 무시하면 분석 불가 |
➡ DLQ는 실패 메시지를 안전하게 분리하여 로그처럼 보관하는 역할
🧱 구조 구성도
[Kafka Topic: eai-events]
│
(Consumer)
▼
┌──────────────────────────────┐
│ try { process(msg) } │
│ catch → produce to DLQ topic │
└──────────────────────────────┘
│
▼
[Kafka Topic: eai-events.dlq]✅ Spring Kafka DLQ 예제
1. DLQ Topic Producer
@Component
@RequiredArgsConstructor
public class DlqProducer {
private final KafkaTemplate<String, String> kafkaTemplate;
public void sendToDlq(String traceId, String message) {
kafkaTemplate.send("eai-events.dlq", traceId, message);
}
}2. Consumer with DLQ Logic
@KafkaListener(topics = "eai-events", groupId = "eai-group")
public void listen(ConsumerRecord<String, String> record) {
try {
processMessage(record.value());
} catch (Exception ex) {
log.error("Processing failed, sending to DLQ: {}", record.value(), ex);
dlqProducer.sendToDlq(record.key(), record.value());
}
}📌 실무 구성 팁
| 구성 요소 | 설명 |
| dlq-topic 명명 규칙 | 원래 토픽명 + .dlq suffix |
| Key 유지 | 원래 메시지의 traceId 또는 slipNo 등 유지 |
| DLQ 모니터링 | 별도 consumer가 DLQ 수신 → Slack, 로그, 재처리 등 |
| 보관 기간 | DLQ topic은 보존 기간 길게 설정 (7일 이상 권장) |
🧠 선택적 기능
- @RetryableTopic (Spring Kafka 2.7+): 자동 DLQ 처리
- DLQ에서 수동 재처리 컨트롤러 추가 (/replay)
- DLQ 메시지 분석용 Kafka UI, Elasticsearch 연동
✅ 요약
| 항목 | 설명 |
| 목적 | 처리 실패 메시지 저장 및 재처리 |
| 방식 | Kafka topic 분리 (.dlq) |
| 장점 | 장애 메시지 유실 방지, 재처리 가능 |
| 구현 | try/catch → DLQ 전송 또는 Spring Retry |
728x90
반응형
'Java' 카테고리의 다른 글
| Java Virtual Thread vs 기존 ThreadPool 구조 비교 (1) | 2025.06.19 |
|---|---|
| 자바 버전별 비교표 (Spring Boot 3.x.x 관점) (0) | 2025.06.19 |
| Retry Backoff 알고리즘 예제 (1) | 2025.06.18 |
| 이기종 DB시스템에 동적으로 Insert (Spring boot) (1) | 2025.06.18 |
| EAI 시스템 아키텍처 예시 (0) | 2025.06.18 |