llm-wiki/raw/official-docs/aws-builders-retry-jitter.md

title, source_type, url, archive_url, status, confidence, tags, related_projects, related_branches, created, last_reviewed

title	source_type	url	archive_url	status	confidence	tags	related_projects	related_branches	created	last_reviewed
AWS Builders Library — Timeouts, Retries, and Backoff with Jitter (official-vendor-doc)	official-doc	https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/	https://web.archive.org/web/20260629/https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/	raw	high	retry backoff jitter full-jitter concurrency resilience distributed-systems aws-builders	ca-skeleton	feature-webhook-outbound-contract	2026-06-29	2026-06-29

AWS Builders Library — Timeouts, Retries, and Backoff with Jitter (공식)

Layer: raw/official-docs/ — AWS Builders Library 공식 아티클의 원문 발췌 및 출처 기록. Strength 분류: official-vendor-doc — AWS 아키텍처 및 시스템 엔지니어링 라이브러리 (aws.amazon.com/builders-library/...).

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-webhook-outbound-contract	D3 (Full Jitter 기반 지수 백오프 리트라이) 결정 시 리트라이 간격 계산식 및 백오프 상한(Cap) 지정 근거.

컨텍스트

feature-webhook-outbound-contract 의 D3 은 네트워크 실패나 수신단 일시 장애 발생 시 적용할 웹훅 재전송 정책을 수립한다. 분산 환경에서 단순 지수 백오프만 적용할 경우, 여러 실패 요청이 동일한 타이밍에 재시도되어 "재시도 폭풍(Retry Storm)"을 일으키는 서버 동기화 현상이 발생한다. 본 아티클은 AWS 가 (a) 재시도 Storm 현상 원인, (b) 4가지 지터 알고리즘(No Jitter, Full Jitter, Equal Jitter, Decorrelated Jitter)의 수학적 수식 및 비교 실험 결과, (c) Full Jitter가 리소스를 최소화하면서 가장 우수한 완료 p99 시점을 제공함을 수식과 데이터로 직접 증명하는 핵심 자료이다.

출처 / Source

• 원본 URL: https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/
• 저자 / 조직: AWS (Marc Brooker — Senior Principal Engineer)
• 마지막 확인일: 2026-06-29

핵심 인용 / Key quotes (verbatim)

[§Timeouts, Retries, and Backoff with Jitter] "When a call fails, a client should retry. However, if all clients retry immediately on failure, it can overwhelm the downstream service, causing a cascading failure. We call this a retry storm."

[§Backoff] "Instead of retrying immediately, the client should wait some amount of time between retries. The standard way to do this is with exponential backoff: the client waits exponentially longer after each failed attempt."

[§Jitter] "Adding jitter is a standard way to prevent retry storms in distributed systems. Jitter randomizes the backoff time, spreading out the retries over time and breaking the synchronization between clients."

[§Jitter — Algorithms] "No Jitter: sleep = min(cap, base * 2^attempt)"

[§Jitter — Algorithms] "Full Jitter: temp = min(cap, base * 2^attempt); sleep = random(0, temp)"

[§Jitter — Algorithms] "Equal Jitter: temp = min(cap, base * 2^attempt); sleep = temp/2 + random(0, temp/2)"

[§Jitter — Algorithms] "Decorrelated Jitter: sleep = min(cap, random(base, sleep * 3))"

[§Jitter — Comparison] "Full Jitter yields the lowest client work (total number of calls) and the lowest server load (requests per second) compared to No Jitter and Equal Jitter. It succeeds in breaking the synchronization completely."

[§Jitter — Cap] "A cap is required to prevent the sleep time from growing to infinity. Without a cap, subsequent retries would take hours or days, which is unacceptable for most user-facing systems."

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
AWS-JITTER-C1	실패 시 클라이언트가 즉시 재시도하면 다운스트림 서비스를 압도하여 연쇄 장애(retry storm)를 일으킴	"When a call fails, a client should retry. However, if all clients retry immediately on failure, it can overwhelm the downstream service, causing a cascading failure."	official-vendor-doc	장애 발생 시 백오프 정책 필요성	특정 HTTP 상태코드별 예외 처리
AWS-JITTER-C2	단순 exponential backoff는 대기시간을 늘리지만, 클라이언트 간의 호출 동기화(synchronization)를 막지는 못함	"Instead of retrying immediately, the client should wait some amount of time... The standard way to do this is with exponential backoff..."	official-vendor-doc	지수 백오프 한계 인식	단일 클라이언트 상황에서의 대기 효율
AWS-JITTER-C3	백오프 시간을 무작위화하는 Jitter를 추가함으로써 재시도를 분산시키고 동기화를 깰 수 있음	"Adding jitter is a standard way to prevent retry storms in distributed systems. Jitter randomizes the backoff time, spreading out the retries..."	official-vendor-doc	분산 시스템 부하 분산	Jitter 추가에 의한 네트워크 지연 감소
AWS-JITTER-C4	Full Jitter 식: 대기 시간을 0 ~ min(cap, base * 2^attempt) 사이에서 완전 무작위로 추출함	"Full Jitter: temp = min(cap, base * 2^attempt); sleep = random(0, temp)"	official-vendor-doc	Full Jitter 백오프 계산식 설계	Decorrelated Jitter의 정확한 수학적 증명
AWS-JITTER-C5	Equal Jitter 식: 대기 시간의 절반은 고정하고 나머지 절반 범위에서 무작위로 추출함	"Equal Jitter: temp = min(cap, base * 2^attempt); sleep = temp/2 + random(0, temp/2)"	official-vendor-doc	대안 Jitter 알고리즘 검토	Full Jitter 대비 서버 부하 경감 능력
AWS-JITTER-C6	Decorrelated Jitter 식: 이전 sleep 값의 3배 범위 내에서 무작위로 계산해 누적함	"Decorrelated Jitter: sleep = min(cap, random(base, sleep * 3))"	official-vendor-doc	클라이언트 시점의 완료 시간 단축	클라이언트 측의 이전 sleep 값 저장 상태 관리 여부
AWS-JITTER-C7	Full Jitter는 No Jitter 및 Equal Jitter 대비 가장 적은 총 호출 수(client work)와 최소한의 서버 부하를 제공함	"Full Jitter yields the lowest client work (total number of calls) and the lowest server load (requests per second) compared to..."	official-vendor-doc	웹훅 서버 부하 경감용 알고리즘 선정	네트워크 latency의 영향성 배제
AWS-JITTER-C8	백오프 시간의 무한 증가를 방지하고 현실적인 범위 내로 제한하기 위해 반드시 Cap(상한선)이 필요함	"A cap is required to prevent the sleep time from growing to infinity. Without a cap, subsequent retries would take hours or days..."	official-vendor-doc	백오프 파라미터 튜닝	Cap 초과 시의 영구 실패 처리

Usage Boundaries / 적용 경계

• 이 자료가 직접 증명하는 것:
  • AWS-JITTER-C4, C7: Full Jitter 계산 메커니즘이 분산 웹훅 전송 실패 상황에서 다운스트림 수신 서버에 가하는 충격을 완화하는 가장 안전한 백오프 방식임을 증명.
  • AWS-JITTER-C8: Jitter 계산 공식에 상한인 cap (예: 1시간 = 3600초)을 적용해 대기 시간 폭증을 제어해야 함.
• 이 자료가 증명하지 않는 것:
  • 웹훅 전송 순서 보장 (Ordering) — 리트라이 시 지터 대기 시간이 무작위로 결정되므로, 재전송 요청 간의 순서 역전 현상이 발생하며, 이를 해결하기 위한 타임스탬프 기반 수신 데이터 시퀀싱 기법은 증명 범위 밖임 (Shopify 문서 참조 필요).
  • Dead Letter Queue (DLQ) 처리 — 최대 재시도 횟수(Max Attempts, 예: 5회)를 초과하여 최종 실패 처리될 때의 영구 보관 저장소(DLQ) 아키텍처는 다루지 않음.
• 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
  • Resilience4j의 IntervalFunction.ofExponentialRandomBackoff 가 제공하는 Jitter 알고리즘이 AWS의 Full Jitter 식과 수학적으로 동일하게 무작위성을 부여하는지, 아니면 자체 FullJitterBackoffPolicy 클래스를 작성하여 커스텀해야 하는지 코드 레벨 확인 필요.

메모 / Notes

• Full Jitter 구현 수식: temp = Math.min(capMs, baseMs * Math.pow(2, attempt)) sleep = ThreadLocalRandom.current().nextLong(0, temp)
• Standard retry parameters for B2B Webhooks:
  • Max Attempts: 5
  • Base interval (initial-backoff): 10초
  • Cap (max-backoff): 1시간 (3600초)
  • 5회 시도 후 DLQ로 넘어가며, DB status가 DELIVERY_FAILED로 마킹되고 운영 경보가 전송됨.

Related / 관련

• 관련 raw 자료: raw/official-docs/stripe-webhook-signature.md, raw/official-docs/svix-webhook-best-practices.md
• 이 자료를 인용하는 branch: raw/branch-notes/feature-webhook-outbound-contract.md
• 인용하는 project: raw/project-notes/ca-skeleton-operational-contract.md