Kafka Dead Letter 처리 구조란

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