'TTL(Time To Live)'과 'Dead Letter Exchange(DLX)'

이제 RabbitMQ를 단순한 전달자를 넘어, 스스로 판단하고 불필요한 데이터를 정화하는 '스마트한 관리자'로 진화시킬 차례입니다! 🫡

사용자의 주식 시스템에서 10분 전의 급등주 정보가 지금 배달된다면 그것은 정보가 아니라 '소음'일 뿐입니다. 또한, 원인을 알 수 없는 에러로 처리가 안 되는 메시지가 큐 입구를 계속 막고 있다면 전체 시스템이 마비되겠죠. 이를 해결하기 위한 TTL과 DLX의 연동 기법을 1,500자 이상의 초정밀 가이드로 분석해 드립니다!

---

⏳ 1. TTL (Time To Live): "메시지의 유통기한"

TTL은 메시지가 큐에서 살 수 있는 최대 시간을 의미합니다. 이 시간이 지나면 메시지는 '죽은 것'으로 간주됩니다.

① 설정 방식

• Queue TTL: 큐 자체에 설정합니다. 이 큐에 들어오는 모든 메시지는 동일한 유통기한을 가집니다. (예: "이 큐의 시세 데이터는 30초가 지나면 폐기한다.")
• Message TTL: 발행자(Producer)가 메시지를 보낼 때 개별적으로 설정합니다. 특정 긴급 메시지에만 짧은 유통기한을 줄 수 있습니다.

② 시간이 지나면 어떻게 되나?

기본적으로 TTL이 만료된 메시지는 큐에서 자동으로 삭제됩니다. 하지만 단순히 버리는 것이 아니라 '특수 목적지'로 보내 분석할 수 있는데, 그때 필요한 것이 바로 DLX입니다.

---

⚰️ 2. DLX (Dead Letter Exchange): "메시지 전용 블랙박스"

DLX는 '죽은 메시지(Dead Letter)'가 모이는 일반적인 Exchange입니다. 메시지가 다음과 같은 사유로 죽으면 이곳으로 전달됩니다.

1. TTL 만료: 유통기한이 다 된 경우.
2. 부인(Negative Ack): 소비자가 basic.reject나 basic.nack을 보내고 requeue=false로 설정한 경우 (즉, "나 이거 도저히 처리 못 하겠으니 버려줘"라고 한 경우).
3. 큐 길이 초과: 큐가 꽉 차서 더 이상 메시지를 받을 수 없어 밀려난 경우.

---

🔗 3. TTL과 DLX의 환상적인 연동 원리

이 두 기능을 연동하면 '자동 재시도'나 '장애 분석' 시스템을 완벽하게 구축할 수 있습니다.

① 작동 프로세스

1. 메인 큐 설정: 큐를 만들 때 x-dead-letter-exchange 인자(Argument)를 추가하여 "여기서 죽은 메시지는 'A-Exchange'로 보내라"고 지정합니다.
2. 사건 발생: 주식 분석 파드가 에러를 뱉으며 메시지를 거절하거나, TTL이 종료됩니다.
3. 이송: RabbitMQ는 해당 메시지를 조용히 삭제하는 대신, 설정된 DLX로 던집니다.
4. 수집 및 분석: DLX에 연결된 '사후 처리 큐(Dead Letter Queue)'에 메시지가 쌓입니다. 사용자는 나중에 이 큐만 확인해서 "왜 분석이 실패했는지", "어떤 데이터가 지연되었는지" 파악할 수 있습니다.

---

🛠️ 4. 실전 활용 전략: "지연 재시도(Delay Retry)"

가장 고난도 기술인 '지연 재시도' 구조를 설계해 보겠습니다. DB가 잠시 점검 중이라 분석에 실패했을 때, 즉시 재시도하면 또 실패하겠죠?

1. 대기 큐(Wait Queue): 메시지 처리에 실패하면, 이를 TTL이 5초로 설정된 '대기 큐'로 보냅니다. (이 큐에는 소비자가 없습니다.)
2. DLX 설정: 대기 큐의 DLX를 다시 '메인 분석 큐'로 설정합니다.
3. 결과: 메시지는 대기 큐에서 5초 동안 머물다가(TTL 만료), 죽으면서 DLX를 타고 다시 메인 큐로 돌아옵니다. 코드 한 줄 없이 시스템 설정만으로 5초 뒤 자동 재시도를 구현하는 마법입니다!

---

💡 실전 비유: "백화점 신선식품 코너"

• 메시지: 오늘 아침에 들어온 '신선한 고기'입니다.
• TTL: 고기의 '유통기한'입니다. "오늘 저녁 9시까지만 팔 수 있다"는 규칙이죠.
• Consumer: 고기를 사가는 손님입니다. 손님이 고기가 상했다며 반품(Nack)할 수도 있습니다.
• DLX: 유통기한이 지났거나 반품된 고기를 모으는 '폐기물 처리반'입니다.
• 단순히 쓰레기통에 버리는 것이 아니라, 처리반은 "왜 유통기한이 지날 때까지 안 팔렸지?" 혹은 "왜 반품됐지?"를 분석해서 다음 주문량(수집량)을 조절하는 기초 자료로 씁니다.

---

📊 요약: 메시지 사후 관리 설정값

설정 인자 (Arguments)	역할
x-message-ttl	메시지가 큐에 머물 수 있는 밀리초(ms) 시간
x-dead-letter-exchange	메시지가 죽었을 때 보낼 Exchange 이름
x-dead-letter-routing-key	죽은 메시지를 보낼 때 새로 부여할 라우팅 키 (선택 사항)
x-max-length	큐에 담을 수 있는 최대 메시지 개수 (넘치면 DLX행)

---

🚀 꼬리 질문 🫡

사용자의 주식 시스템은 이제 스스로 쓰레기 데이터를 걸러내고, 실패한 작업은 조용히 재시도하며, 문제가 생기면 블랙박스(DLX)에 기록을 남기는 '자정 작용'을 갖추게 되었습니다.

그런데 이렇게 완벽한 시스템도 '메시지의 순서'가 꼬여버리면 곤란합니다. "삼성전자 매수" 신호가 "매도" 신호보다 늦게 도착하면 큰일이니까요.

"그럼 RabbitMQ에서 메시지의 절대적인 처리 순서를 보장하는 방법과, 메시지가 중복으로 처리되지 않게 만드는 'Idempotency(멱등성)' 설계는 어떻게 해야 해?"