Dead Letter Topic

Kafka Dead Letter Topic

Kafka를 사용하는 이유 중 하나는 대규모 비동기 이벤트 처리에 적합하다는 점입니다. 하지만 "시스템이 안정적이기 위해선 실패한 메시지를 어떻게 처리할 것인가?"에 대한 설계가 반드시 필요합니다.

이를 위해 사용하는 것이 바로 DLT(Dead Letter Topic)입니다.

 

Dead Letter Topic

Dead Letter Topic은 Kafka Consumer가 메시지를 처리하는 도중 예외가 발생했을 때, 해당 메시지를 따로 저장하는 전용 토픽입니다.

다시 말해, "이 메시지는 정상 처리할 수 없으니 따로 보관하겠습니다."라는 백업 공간이라고 볼 수 있습니다.

 

예를 들어 상품 재고를 차감하는 Consumer가 있는데, 특정 메시지에 포함된 productId가 DB에 존재하지 않아 처리에 실패한다면, 해당 메시지를 무한 재시도하거나 그대로 유실시킬 수는 없습니다. 이때 Dead Letter Queue로 메시지를 보내면 나중에 수동 확인 혹은 후처리가 가능합니다.

 

Dead Letter Topic이 필요한 이유

Kafka는 기본적으로 at-least-once delivery 모델을 따르며, 메시지 처리 중 예외가 발생하면 같은 메시지를 계속 재시도 합니다.

계속 재시도 할 경우 발생하는 문제는 다음과 같습니다.

• 예외가 영구적일 경우, 무한 루프가 발생합니다.
• 서비스 하나의 장애로 전체 Consumer group 병목을 유발합니다.
• 데이터 유실 가능성이 있습니다.

Dead Letter Topic은 이러한 문제를 해결하기 위한 안전 장치입니다. 오류가 발생한 메시지를 따로 저장해두면, 아래와 같은 추가 조치를 취할 수 있게 됩니다.

• 수동으로 확인 및 재처리
• 오류 로그와 함께 알림 전송
• 관리 툴에서 실시간 모니터링

 

Dead Letter Topic 일반적인 구조

Dead Letter Topic의 일반적인 구조는 다음과 같습니다.

1. 메시지 처리 성공시, 정상 종료됩니다.
2. 메시지 처리를 실패시, Dead Letter Topic Producer가 실패 메시지를 전송합니다.
3. 해당 메시지는 Dead Letter Topic에 적재됩니다.

 

Dead Letter Topic의 구성 요소

Dead Letter Topic을 구성할 때 고려애햐 하는 요소는 아래와 같습니다.

항목	설명
Dead Letter Topic 이름 규칙	예시, original-topic-name.DLT
메시지 포맷	실패 원인, stack trace, 원본 payload
실패 재처리 전략	수동 재처리, 스케줄 기반 재소비
DLT 적재 조건	특정 예외만 DLT로 전송하거나 재시도 횟수 초과시만 처리

 

 

Retry와 Dead Letter Topic의 차이점

 

Retry와 Dead Letter Topic의 차이점은 아래와 같습니다.

항목	Retry	Dead Letter Topic
목적	일시적인 실패 복구	영구적인 실패 처리 및 분리
처리 방식	메시지를 다시 소비자로 재전송	실패 메시지를 별도 토픽에 분리 저장
활용 대상	네트워크 지연, 일시적 DB 오류 등	데이터 오류, 잘못된 형식 등 영구 실패 메시지
재시도 한계	제한된 횟수 or 시간 기반	DLT 이동 후, 수동 재처리 필요
실무 전략	재시도 후 실패시 → DLT 이동	수동 확인 후 복구 or 삭제

 

 

Retry + Dead Letter Topic 함께 적용

Kafka 기반 메시징 시스템에서는 메시지 처리 중 실패가 발생할 수 있습니다. 이때 실패를 효과적으로 처리하기 위해 Retry(재시도)와 Dead Letter Topic(DLT)를 함께 적용하는 것이 일반적입니다. 이 두가지는 각각 다른 목적을 가지고 있으며, 서로를 보완하는 역할을 합니다.

 

1. Retry는 일시적인 문제를 해결하기 위한 장치입니다.
   •   예시: 네트워크 오류, 일시적인 DB 장애 등은 시간이 지나면 해결할 수 있기 때문에 다시 시도하면 성공할 가능성이 있습니다.
   •   이 경우 메시지를 다시 처리하도록 재시도 큐나 Delayed Topic으로 보내는 방식이 사용됩니다.
   •   일반적으로 재시도는 일정 횟수(예: 3번), 혹은 일정 시간 간격(예: 5초 후 재시도)으로 제한됩니다.
2. Dead Letter Topic은 영구적인 문제를 안전하게 분리하는 장치입니다.
   •   예시: 메시지 포맷이 잘못되었거나, 비즈니스 로직 상 절대 처리할 수 없는 경우에 사용합니다.
   •   이 경우 아무리 재시도해도 실패하므로, 해당 메시지를 DLT(전용 Kafka 토픽)에 보냅니다.
   •   DLT에 쌓인 메시지를 수동으로 확인하거나, 후처리 시스템에서 별도로 처리할 수 있습니다.

 

함께 적용하는 이유

Retry만 사용하면 영구 실패 메시지가 무한 재시도되어 시스템에 부담을 줍니다.

반면, DLT만 사용하는 경우 일시적인 오류로도 메시지를 너무 빨리 포기하게 됩니다.

 

따라서, 두 기능을 함께 사용하면, 일시적인 오류는 자동으로 복구하고, 복구가 어려운 메시지는 격리해서 나중에 안전하게 처리할 수 있습니다.

 

적용 예시 흐름

1. Consumer가 메시지를 처리하다가 실패합니다.
2. 재시도 토픽으로 이동(최대 3회 재시도)
3. 3회 모두 실패시 DLT 토픽으로 전송합니다.
4. DLT 메시지를 보고 수동 복구하거나 알림을 받아 대응합니다.

 

마무리

Kafka 기반 아키텍처에서 Retry와 Dead Letter Topic은 단순한 실패 처리 수단을 넘어, 시스템의 안정성과 신뢰성을 확보하기 위한 핵심 전략입니다. 특히 대규모 트래픽 환경이나 중요한 비즈니스 로직이 포함된 시스템에서는, 실패한 메시지를 어떻게 안전하게 처리하고 복구할 것인지에 대한 명확한 설계가 필요합니다.

 

Retry는 일시적인 오류를 자동으로 복구하기 위한 장치이며, Dead Letter Topic(DLT)은 반복적으로 실패하는 메시지를 격리하고 추적 가능한 형태로 보관하는 역할을 합니다.

 

안정적인 메시지 시스템을 만든다는 것은 오류를 아예 없애는 것이 아니라, 오류가 발생했을 때 이를 제어 가능한 상태로 관리하는 구조를 만드는 것입니다. Retry와 DLT는 바로 그 출발점이며, Kafka 기반 시스템의 신뢰성과 복원력을 높이는 데 핵심적인 역할을 합니다.