업로드 확인 폴링에 지수 백오프 도입

[m-a-king]

Situation

• 이미지 등록의 폴링 백스톱이 확인 대상을 매 주기(1초) 다시 집어 S3 HEAD 를 친다. 확인 결과를 어디에도 남기지 않으니, 안 올라온 key 는 만료(7분)까지 같은 질문을 반복해서 받는다.
• 계산하면 key 하나당 약 405회다. 발급 5장을 받고 업로드를 안 하면 2000회가 나간다. S3 는 요청 건당 과금이라 그대로 비용이다.
• 발급(presigned URL 생성) 자체는 로컬 서명 계산이라 비용이 없다. 비용은 발급이 아니라 "아직 안 올라왔다"를 서버가 반복해서 확인하는 데서 난다.
• 백스톱은 confirm 이 유실된 예외 경로를 위한 장치인데, 정상 경로까지 그 비용을 함께 내고 있었다.

Task

• 확인 빈도를 줄이되 검출은 느려지지 않게 한다. 단순히 주기를 30초로 늘리면 confirm 유실 건의 등록이 그만큼 밀린다.
• 폴링 상태를 어디에 어떤 형태로 둘지 정한다.

Action

다음 확인 시각을 행에 남긴다

pending_uploads 에 next_check_at 을 두고, 헛칠 때마다 뒤로 민다.

fun backOffCheck(now: LocalDateTime) {
    nextCheckAt = now.plus(sinceIssued(now))
}

• 규칙은 하나다. 지금까지 기다린 만큼 더 기다린다. 그래서 확인 시각이 1, 2, 4, 8 초로 저절로 두 배씩 벌어진다.
• 시도 횟수 컬럼이 따로 필요 없다. 한 배치의 여러 장이 같은 created_at 을 공유하므로 일정도 함께 움직여, 그룹이 쪼개져 정원 판정이 갈리는 일이 없다.
• 간격에 상하한을 두지 않는다. 상한 120초를 검토했으나 7분 수명에서 확인을 9회에서 10회로 늘릴 뿐이고 최악 검출 지연도 128초 대 120초라 차이가 없었다. 상한을 넘겨 만료까지 못 보는 건도 expireStale 이 마지막 존재 확인을 하므로 유실되지 않는다.

저장 형태 결정

안	답하는 질문	판정
next_check_at	언제 다시 볼 것인가	채택. 폴러가 던지는 질문이 이것 하나다
확인 횟수	몇 번이나 헛쳤는가	미채택. 확인에 상한이 없어(종결은 expires_at 이 낸다) 아무도 안 읽는다
백오프 시작 시각	언제부터 재는가	불필요. created_at 이 이미 담고 있다

• 횟수만 저장하면 조회 서술어가 created_at + f(count) <= now 라는 계산식이 되어 인덱스를 못 쓴다. 결국 파생값을 다시 저장하게 된다.
• DB 작업 큐들(Solid Queue, GoodJob, Oban, SQS visibility timeout)이 공통으로 "다음에 보일 시각"을 저장하는 것과 같은 이유다. 횟수도 같이 두는 곳이 있지만 그건 재시도 상한과 관측용이지 일정 계산용이 아니다.

함께 잡은 결함

• 한 배치에서 일부만 올라온 경우 남은 것이 미뤄지지 않았다. 올라온 것은 claim 으로 사라지는데 남은 것은 next_check_at 이 과거인 채 방치돼, 백오프를 넣고도 그 경로만 만료까지 매 주기 두드렸다. 백오프 도입과 함께 들어간 결함이라 같은 PR 에서 잡는다.

정리된 것

• POLL_GRACE(15초)가 사라졌다. 발급 시 next_check_at = now + 1초 로 박히니 그 개념이 컬럼 안으로 흡수됐고, 조회 파라미터도 하나 줄었다.
• 첫 확인이 15초에서 1초로 당겨져 confirm 유실 건의 검출은 오히려 빨라졌다.

Result

	전	후
안 올라온 key 하나당 HEAD	약 405회	약 9회
첫 확인 시각	발급 후 15초	발급 후 1초

• 부분 그룹 결함은 negative control 로 확인했다. 수정을 되돌리면 새 테스트 하나만 깨진다.
• 검토 중 발견: PendingUpload 는 image/domain/ 에 있지만 역할은 작업 큐다(코드 주석도 스스로 그렇게 부른다). 폴링 상태를 얹는 것 자체는 제자리지만 패키지 위치가 역할과 어긋나 있다. 임포트가 여러 곳 바뀌어 별도 건으로 둔다.
• 후속 후보: 확인 빈도를 더 줄이려면 S3 이벤트 알림이 정석이다(폴링 자체가 없어지고 검출이 즉시가 된다). 인프라가 늘어나므로 백스톱이 실제로 아파질 때 간다. 그 전에 더 싼 개선은 클라이언트의 confirm 재시도다. confirm 은 claim 기반이라 멱등이므로 안전하고, 그것만으로 "confirm 유실" 자체가 급감한다.

---

연관 이슈

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Team

Run ID: b1cf6ddf-e345-4670-a9cf-a966451f1d2c

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}