[Cloudflare Queues][운영] upstream 429가 잦을 때 batch size를 줄인 뒤 consumer autoscale delay를 어떤 순서로 다시 분리하나

IT 리서치 노트

[Cloudflare Queues][운영] upstream 429가 잦을 때 batch size를 줄인 뒤 consumer autoscale delay를 어떤 순서로 다시 분리하나

Cloudflare Queues에서 upstream API가 429를 자주 돌려줄 때 많은 팀이 먼저 batch size를 줄이거나 max concurrency를 만진다. 하지만 2026년 8월 16일 기준 Cloudflare 공식 문서를 다시 보면 upstream 제한이 있는 워크플로는 backlog 증가를 감수하는 선택지가 있고, retry는 consumer autoscale down을 유발하지 않으며, backlog와 consumer concurrency와 message operations를 별도 metrics 축으로 읽을 수 있다. 이 글은 batch size를 이미 줄인 뒤에도 429가 남을 때 upstream backpressure와 consumer autoscale delay를 어떤 순서로 다시 나누는 편이 운영 메모를 덜 꼬이게 만드는지 정리한 것이다.

목차

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

1. 개요

결론부터 말하면 Cloudflare Queues에서 429 incident를 볼 때는 batch size 변경 시각, retry delay_seconds, consumer concurrency 파형, backlog 기울기를 한 메모에 같이 남겨야 한다. batch size를 줄였는데도 429가 남는다고 해서 곧바로 autoscale이 느리다고 결론 내리면 retry와 upstream rate limit을 헷갈리기 쉽다.

Cloudflare 문서는 upstream 제한이 있으면 backlog가 늘어나는 쪽을 택할 수 있다고 설명하고, retry는 autoscale down을 만들지 않는다고 분리한다. 그래서 첫 판단은 지금 남은 429가 upstream backpressure인지, 아니면 consumer concurrency가 아직 늦게 반응하는지다.

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

현장에서 흔한 실수는 세 가지다. 첫째, batch size를 50에서 10으로 줄인 뒤에도 429가 보이면 autoscale이 늦다고 바로 적는다. 둘째, retry delay_seconds를 바꾸면서 같은 시점에 concurrency cap도 손대고 원인을 섞는다. 셋째, backlog 숫자만 보고 message operations나 retry 파형을 저장하지 않는다.

Cloudflare 문서를 다시 보면 이 셋은 서로 다른 층이다. consumer concurrency 문서는 upstream 시스템이 병목일 수 있다고 적고, batching 문서는 retry가 autoscale down을 유발하지 않는다고 적고, metrics 문서는 backlog와 consumer concurrency와 message operations를 따로 측정할 수 있다고 설명한다. 세 축을 한 번에 적지 않으면 batch size cut 이후의 남은 문제를 좁히기 어렵다.

이미 batch size와 consumer concurrency 기본 분기 글이 batch tuning 첫 단계였다면, 이번 글은 그 다음 단계다. batch size를 줄인 뒤에도 429가 남을 때 autoscale이 늦은 것인지, retry와 upstream가 그대로인 것인지 가르는 기준을 만든다.

• 증상: batch size를 줄여도 upstream 429가 줄지 않거나 backlog가 계속 오른다.
• 실패: retry delay, batch size, consumer concurrency 변경을 같은 메모에 한 줄로 적는다.
• 막힘: backlog만 보고 concurrency와 message operations를 같이 저장하지 않는다.
• 누락: 429 응답 유무와 autoscale 시차를 따로 기록하지 않는다.

보이는 현상	먼저 볼 값	판단 기준
429가 명시적으로 보인다	retry delay_seconds와 upstream 응답 로그	upstream backpressure일 가능성을 먼저 둔다
backlog는 오르는데 concurrency가 늦다	consumer metrics와 cap 설정	autoscale delay 또는 ceiling을 의심한다
retry 수만 늘고 처리량은 그대로다	message operations	retry가 autoscale down을 만들지 않는다는 전제를 유지한다

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

실무 순서는 다섯 단계가 가장 짧다. 먼저 batch size를 언제 얼마나 줄였는지 적는다. 두 번째로 같은 시점의 retry delay_seconds와 실제 429 응답 로그를 저장한다. 세 번째로 backlog 기울기와 consumer concurrency 시계열을 붙인다. 네 번째로 concurrency가 ceiling 근처였는지, auto 상태에서 늦게 올라왔는지 나눈다. 마지막으로 그 뒤에야 max concurrency 조정 또는 retry delay 재설정을 결정한다.

1. batch size cut 전후 시각과 값을 적는다.
2. retry delay_seconds와 429 로그를 같은 incident 메모에 붙인다.
3. backlog와 consumer concurrency metrics를 같은 시간축으로 저장한다.
4. concurrency ceiling 도달 여부를 본다.
5. 그 뒤에만 autoscale 또는 upstream rate limiting 조정을 결정한다.

실제 작업에서는 dashboard를 열고, consumer settings를 확인하고, batch size cut 시각을 incident 문서에 입력하고, 429 로그를 별도 파일로 저장하고, retry delay 변경을 실행한 뒤, metrics 그래프를 다시 비교하는 순서를 메모에 남기는 편이 좋다.

중요한 점은 retry가 autoscale down을 만들지 않는다는 공식 문서 전제를 유지하는 것이다. 즉 retry count가 올랐다고 해서 consumer가 스스로 줄어들었다고 해석하면 안 된다. 오히려 429 직후 backlog는 계속 오르고, retry도 늘고, concurrency도 ceiling에 붙어 있다면 upstream backpressure가 더 강한 설명일 가능성이 높다.

반대로 backlog는 급격히 오르는데 concurrency가 ceiling에 닿지 못하고 늦게 올라간다면 autoscale delay 또는 설정 문제를 따로 봐야 한다. 이때는 dashboard 또는 Wrangler의 max concurrency 설정과 metrics 지연 구간을 먼저 기록해야 한다. 이미 pull consumer lease와 retry delay 글을 읽었다면, 이번 글은 push consumer 쪽에서 같은 시간축 사고를 적용하는 버전이라고 보면 된다.

incident 메모 예시

batch_size_before=50
batch_size_after=10
retry_delay_seconds=120
upstream_429_seen=true
backlog_slope=+1800 messages / 5m
consumer_concurrency_peak=48
consumer_cap=auto
next_check=separate upstream backpressure from autoscale delay

이 메모가 있으면 회고에서도 'batch size를 줄였는데 왜 안 줄었나'를 막연히 적지 않게 된다. 어떤 신호가 upstream를 가리켰는지, 어떤 신호가 autoscale을 가리켰는지 재검증이 쉬워진다.

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

첫 공식 화면은 Consumer concurrency 문서의 핵심 분기다. Cloudflare는 upstream API나 외부 시스템이 병목이면 backlog가 늘어나는 쪽을 감수하고 과도한 동시성을 피할 수 있다고 설명한다.

Cloudflare는 upstream 제한이 있는 워크플로에서는 backlog 증가와 과도한 동시성 사이의 trade-off를 먼저 기록하라고 안내한다.

즉 429가 보인다고 해서 항상 consumer concurrency를 더 키우는 방향으로 보면 안 된다. 먼저 지금 장애가 backlog 축인지 upstream 축인지 나눠야 한다.

두 번째 자료는 Batching, Retries and Delays 문서의 retry와 autoscale 경계다. retry나 retryAll은 consumer concurrency autoscale down을 유도하지 않는다고 문서가 분명히 적고 있다.

retry() 또는 retryAll()은 consumer concurrency autoscale down을 유발하지 않는다고 Cloudflare 문서가 설명한다.

그래서 batch size를 줄였는데도 429가 계속 보이면 단순 retry 증가를 autoscale 반응으로 착각하면 안 된다. retry 파형과 concurrency 파형을 별도로 기록해야 한다.

세 번째 자료는 Cloudflare Queues metrics 문서다. backlog, consumer concurrency, message operations를 따로 볼 수 있다는 점이 triage의 기준이 된다.

Queues metrics는 backlog, consumer concurrency, message operations를 별도 축으로 제공한다.

즉 429 incident 메모에는 최소한 backlog 기울기, active consumer 수, retry 또는 failed delivery 같은 message operations를 같은 시간축에 붙여야 한다. 이 셋을 섞으면 autoscale delay와 upstream backpressure가 구분되지 않는다.

실무에서는 429를 받았을 때 batch size만 줄이고 끝내는 경우가 많다. 하지만 delaySeconds와 explicit retry를 남기지 않으면 다시 처리되는 속도가 얼마나 늦춰졌는지 추적하기 어렵다.

429를 받았을 때 retry delay와 batch size 변경을 함께 기록하는 Worker 예시다.

이 메모는 batch size와 consumer concurrency 기본 분기 글 다음 단계에 해당한다. 이번 글은 그보다 더 좁게, batch size를 이미 줄였는데도 429가 남을 때 autoscale delay를 어떻게 분리 기록할지에 초점을 둔다.

마지막 자료는 429와 autoscale delay를 빠르게 자르는 표다. backlog 기울기는 커지는데 concurrency가 이미 ceiling에 닿았는지, 아니면 concurrency가 아직 오르지 못하는지 같은 축을 한 번에 봐야 한다.

upstream 429와 consumer autoscale delay를 backlog, concurrency, retry 신호로 나눈 비교표다.

이 표를 팀 메모에 붙여 두면 post 350의 pull consumer delay_seconds 체크리스트와도 자연스럽게 연결된다. push consumer든 pull consumer든 결국 시간축 메모가 triage 속도를 좌우한다.

5. 주의사항과 리스크

첫 번째 리스크는 429 incident에서 retry를 늘리면서 concurrency cap도 동시에 바꾸는 것이다. 둘째는 backlog만 보고 consumer metrics를 저장하지 않는 것이다. 셋째는 retry가 autoscale down을 만들지 않는다는 문서 조건을 잊고 concurrency 파형을 잘못 읽는 것이다.

• batch size cut과 retry delay 변경은 따로 기록한다.
• 429 로그, backlog, concurrency를 같은 시간축으로 남긴다.
• retry 증가는 autoscale down 증거가 아니다.

6. 결론

Cloudflare Queues에서 batch size를 이미 줄였는데도 429가 남으면, 다음 질문은 concurrency를 키울까가 아니라 429와 autoscale delay를 어떻게 분리할까다. backlog, retry, concurrency 세 축을 같이 적으면 원인을 훨씬 짧게 가를 수 있다.

• 429 응답과 retry delay부터 적는다.
• backlog와 consumer concurrency를 같은 시간축에 붙인다.
• 그 뒤에만 autoscale 또는 upstream 조정을 결정한다.

batch size를 줄였는데도 backlog가 줄면서 oldest message age만 남는 단계까지 왔다면, 다음에는 backlog slope와 oldest message age를 같은 사건 메모에서 어떻게 분리 기록하는지 다룬 follow-up 글로 이어서 평균 backlog와 순간 oldest age를 따로 적는 편이 좋다.

7. 참고 링크

1. https://developers.cloudflare.com/queues/configuration/consumer-concurrency/
2. https://developers.cloudflare.com/queues/configuration/batching-retries/
3. https://developers.cloudflare.com/queues/observability/metrics/