[Cloudflare Queues][운영] delayed retry cohort를 분리한 뒤 DLQ replay 전 어떤 tail-message incident field를 다시 남기나

IT 리서치 노트

[Cloudflare Queues][운영] delayed retry cohort를 분리한 뒤 DLQ replay 전 어떤 tail-message incident field를 다시 남기나

Cloudflare Queues 운영에서 oldest message age tail을 다루다 보면 한 번은 post 364 같은 질문에 닿는다. delayed retry cohort와 lease renew·ack gap을 같은 incident로 보면 안 된다는 사실까지는 알겠는데, 그 다음 단계인 DLQ replay 직전 메모는 무엇을 다시 남겨야 할지 애매한 순간이 온다. 2026년 8월 30일 KST 기준 Cloudflare 공식 문서를 다시 보면 metrics의 realtime 값은 point-in-time이고, delaySeconds, lease_id, visibility_timeout, DLQ retry limit은 각각 다른 판단 경계를 가진다. 이 글은 delayed retry cohort를 이미 분리한 뒤 DLQ replay 전에 어떤 tail-message incident field를 다시 남기면 되는지 정리한다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 DLQ replay 직전 tail-message incident 메모는 graph window, oldest_age_seconds, delayed_retry_cohort, lease_id_state, dlq_replay_candidate 다섯 줄이 핵심이다. delayed retry와 lease 문제를 이미 갈랐더라도, replay를 실행하기 전에는 tail 메시지 상태를 다시 기록해야 한다.

이 메모가 필요한 이유는 point-in-time 지표와 평균 지표, 의도적 delay와 재전달, 아직 replay 대상이 아닌 cohort와 실제 DLQ 재처리 대상을 같은 문장으로 묶지 않기 위해서다. 같은 Cloudflare branch에서는 post 364가 원인 분리를 했다면, 이번 글은 replay 직전 체크 포인트를 붙이는 역할을 한다.

2. 어디서 실제로 막히는가

실무에서 가장 흔한 실패는 delayed retry cohort를 분리한 직후 모든 남은 tail 메시지를 replay 후보처럼 취급하는 것이다. average backlog는 이미 줄었고 oldest age만 남았는데, 운영자가 아직 안 사라졌으니 DLQ로 돌리자라고 판단하면 의도적으로 지연된 메시지까지 과잉 재처리할 수 있다. 반대로 lease timeout 또는 ack 누락이 남아 있는데 delayed retry만 추적하면 재전달 원인을 놓친다.

Cloudflare Metrics 문서는 realtime backlog 값이 point-in-time이라고 밝힌다. Batching and Retries 문서는 delaySeconds가 붙은 메시지가 이후 배치에서 다시 전달될 수 있다고 설명한다. Pull consumers 문서는 lease_id가 ack 또는 retry에 쓰이고, ack하지 않으면 visibility timeout 뒤 재전달된다고 적는다. Dead Letter Queues 문서는 retry limit에 도달한 메시지가 DLQ로 간다고 적는다. 네 문장을 합치면 tail age가 남았다는 한 문장만으로는 replay 결정을 할 수 없다는 뜻이다.

또 incident 메모가 구간 없이 남아 있으면 더 헷갈린다. 평균 backlog는 5분 구간인데 oldest age는 특정 시각 폴링 값이고, lease 재전달은 별도 API 응답이며, DLQ 전환은 retry limit 경계다. 이 값을 같은 표에 다시 적지 않으면 팀원마다 다른 시간축으로 판단해 서로 다른 replay 결론을 내린다. 결국 로그를 조회하고, oldest age를 계산하고, ack 상태를 확인하고, replay 후보를 저장하는 최소 필드가 필요하다.

• 증상: backlog는 회복됐는데 tail age만 남아 replay를 고민하게 된다.
• 실패: delayed retry cohort를 분리한 뒤에도 모든 tail 메시지를 같은 replay 후보로 적는다.
• 원인: graph window, lease_id 상태, replay 후보 여부를 다시 저장하지 않는다.
• 재발: 의도적 delay 메시지를 불필요하게 재처리하거나 ack 누락을 놓친다.

겉증상	다시 확인할 필드	판단 기준
tail age만 남아 있다	graph_window, oldest_age_seconds	평균 회복과 point-in-time 잔존을 분리한다
메시지가 다시 보인다	lease_id_state, visibility_timeout_hit	재전달인지 의도적 delay인지 본다
DLQ replay를 고민한다	dlq_replay_candidate	지금 replay할 메시지인지 따로 표시한다

3. 실무에서 적용하는 순서

가장 짧은 절차는 다섯 단계다. 1단계에서 average backlog와 retry를 본 GraphQL 시간 구간을 메모에 고정한다. 2단계에서 realtime oldest age를 조회한 시각과 값을 저장한다. 3단계에서 남은 tail이 delayed retry cohort인지 표시한다. 4단계에서 lease_id 반복, ack 누락, visibility timeout hit 여부를 저장한다. 5단계에서 그 뒤에야 dlq_replay_candidate=true|false를 결정한다.

1. GraphQL 구간을 먼저 메모에 고정한다.
2. oldest age 값을 조회한 시각과 숫자를 저장한다.
3. delayed retry cohort 여부를 표시한다.
4. lease_id와 ack 상태를 다시 확인한다.
5. 그 뒤에만 DLQ replay 후보 여부를 결정한다.

이 절차가 실용적인 이유는 replay를 마지막 의사결정으로 밀어 주기 때문이다. 많은 운영 사고는 replay를 먼저 떠올리기 때문에 생긴다. 하지만 실제로는 로그를 조회하고, retry delay를 확인하고, lease 상태를 저장하고, oldest age를 비교하고, 그다음에야 replay 범위를 정해야 한다. 즉 문제 해결 순서는 실행보다 기록이 먼저다.

특히 lease_id_state는 단순 문자열처럼 보여도 중요하다. repeated, expired_before_ack, not_repeated 정도로만 정리해도 delayed retry cohort와 재전달 tail을 훨씬 짧게 구분할 수 있다. 운영자는 같은 메모에서 delayed_retry_cohort=true인데 lease_id_state=not_repeated라면 replay보다 대기 추적을 택하고, lease_id_state=repeated라면 ack 흐름 조사부터 다시 시작하면 된다.

tail replay decision memo

graph_window=2026-08-30T09:00:00Z..2026-08-30T09:05:00Z
oldest_age_seconds=540
delayed_retry_cohort=true
lease_id_state=not_repeated
visibility_timeout_hit=false
dlq_replay_candidate=false
next_action=track delayed cohort before replay

같은 Cloudflare branch의 독자라면 delayed retry cohort와 lease renew·ack gap을 분리한 글을 원인 설명으로 먼저 보고, DLQ replay 체크리스트 글를 실제 재처리 순서로 붙이는 편이 좋다. 이번 글은 그 둘 사이에 끼는 운영 메모 레이어다.

4. 공식 문서와 예시 화면으로 확인하기

첫 자료는 Metrics 문서다. Cloudflare는 realtime backlog 관련 값이 aggregated 평균이 아니라 point-in-time 값이라고 설명한다.

tail 메시지 incident는 평균 backlog와 point-in-time 지표를 분리해 기록해야 한다.

이 전제가 있어야 delayed retry cohort를 분리한 뒤에도 어떤 tail이 실제로 남아 있는지, 아니면 평균 그래프만 회복한 것인지 구분할 수 있다.

두 번째 자료는 retry delay 설정 문서다. delaySeconds를 준 메시지는 의도적으로 나중에 다시 읽히므로, tail age가 남아도 원인이 다를 수 있다.

delaySeconds가 있는 cohort는 남아 있는 tail age를 의도적으로 만들 수 있다.

따라서 tail-message incident 메모에는 delay된 cohort인지 아닌지를 먼저 남겨야 한다. 이 필드가 없으면 나중에 DLQ replay 전후 비교가 무의미해진다.

세 번째 자료는 pull consumer 문서다. 메시지가 ack 또는 retry 처리되지 않으면 visibility timeout 뒤 다시 전달된다고 설명한다.

ack 누락이나 lease timeout은 delayed retry와 전혀 다른 재전달 원인이다.

즉 delayed retry cohort를 이미 분리했더라도, 남은 tail이 lease timeout에서 왔는지 별도 필드로 다시 적어야 DLQ replay 전에 재처리 기준이 흔들리지 않는다.

네 번째 자료는 DLQ 문서다. Cloudflare는 메시지가 retry limit에 도달하면 DLQ로 이동한다고 설명한다.

DLQ replay 전 incident field를 정리해야 하는 이유는 retry limit 경계를 넘기기 전에 판단이 필요하기 때문이다.

tail 메시지가 정말 replay 후보인지, 아니면 아직 delay cohort 추적 대상인지, 아니면 lease ack 조사 대상인지 분리하지 않으면 DLQ 재처리 범위가 불필요하게 넓어진다.

실제 운영에서는 incident field 표를 먼저 고정하는 편이 빠르다. 아래 표는 delayed retry를 분리한 뒤 DLQ replay 직전에 다시 남기면 좋은 최소 필드다.

DLQ replay 직전에는 tail-message incident field를 다시 정리해야 한다.

운영자는 이 표에 맞춰 GraphQL 구간을 조회하고, oldest age를 확인하고, lease_id 상태를 저장하고, replay 후보를 고르는 식으로 메모를 단순화할 수 있다.

마지막 자료는 incident 메모 예시다. 핵심은 DLQ replay 전에 tail-message 상태를 JSON 한 장으로 다시 저장하는 것이다.

DLQ replay 전 메모는 delay, lease, replay 후보를 한 번 더 분리해야 한다.

이렇게 저장해 두면 post 364의 delayed retry vs lease renew 정리와 DLQ replay 체크리스트 글 사이를 자연스럽게 이어 붙일 수 있다.

5. 주의사항과 리스크

첫 번째 리스크는 delayed retry cohort를 분리한 뒤에도 replay 후보 여부를 다시 적지 않는 것이다. 두 번째는 lease_id 상태를 기록하지 않아 재전달 원인을 놓치는 것이다. 세 번째는 point-in-time oldest age와 평균 backlog 구간을 같은 숫자처럼 적는 것이다.

운영 전에 최소한 graph_window, oldest_age_seconds, delayed_retry_cohort, lease_id_state, dlq_replay_candidate는 incident 표에 남겨 두는 편이 좋다.

• DLQ replay는 원인 분리 다음 단계이지 첫 반응이 아니다.
• lease 재전달과 delayed retry는 같은 tail age라도 조치가 다르다.
• replay 전 메모를 다시 쓰면 과잉 재처리와 누락 조사를 동시에 줄일 수 있다.

6. 결론

Cloudflare Queues에서 delayed retry cohort를 분리한 뒤 DLQ replay 전에 다시 남겨야 할 핵심은 단순하다. graph window, oldest age, delayed retry 여부, lease_id 상태, replay 후보 여부를 한 번 더 적으면 된다. 이 다섯 줄이 있으면 tail 메시지를 기다려야 하는지, ack 흐름을 다시 조사해야 하는지, 실제 replay를 시작해도 되는지 훨씬 짧게 갈린다.

같은 분기의 부모 글로는 post 364가 delayed retry와 lease renew·ack gap 분리를 먼저 설명한다. 이번 글은 그 뒤 replay 직전 메모를 붙이는 후속편이다.

7. 참고 링크

1. https://developers.cloudflare.com/queues/observability/metrics/
2. https://developers.cloudflare.com/queues/configuration/batching-retries/
3. https://developers.cloudflare.com/queues/configuration/dead-letter-queues/
4. https://developers.cloudflare.com/queues/configuration/pull-consumers/