7.3 KiB
title, source_type, url, archive_url, related_branches, related_projects, tags, created
| title | source_type | url | archive_url | related_branches | related_projects | tags | created | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Exponential Backoff And Jitter — AWS Architecture Blog (Marc Brooker) | company-tech-blog | https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/ |
|
|
|
2026-06-11 |
Exponential Backoff And Jitter — AWS Architecture Blog (Marc Brooker)
Layer:
raw/company-tech-blogs/— 외부 기술 블로그 원문 발췌·출처 기록. 검증된 요약은/ingest후wiki/concepts/에 별도 작성. 원본은 raw 에 영구 보관.
Parent / 활용 branch
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-background-job-async-contract | D4 — "기본 backoff = exponential + jitter" 의 jitter 종류(Full/Equal/Decorrelated) 비교 및 Full Jitter 권고 근거. |
출처 / Source
- 원본 URL: https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/
- 아카이브 URL: (미제공)
- 저자 / 조직: Marc Brooker / AWS Architecture Blog
- 발행일: (최초 게시일 불명; 2023년 업데이트 확인)
- 마지막 확인일: 2026-06-11
왜 저장했는지 / Why archived
feature-background-job-async-contract branch 의 D4 결정("기본 backoff = exponential + jitter") 이 정량 근거 없이 UNSUPPORTED_DECISION 상태였다. 본 자료는 Full/Equal/Decorrelated Jitter 세 종류를 시뮬레이션으로 비교한 AWS 엔지니어링 블로그 포스트로, Full Jitter 공식·no-jitter 제거 근거·client work 비교 수치를 verbatim 으로 제공한다. company-tech-blog 이므로 공식 best practice 로 단정하지 않고, 사례/관점으로만 인용한다.
핵심 인용 / Key quotes (verbatim, 3~5문장)
[§Full Jitter] "sleep = random(0, min(cap, base * 2 ** attempt))"
[§No-jitter comparison] "The no-jitter exponential backoff approach is the clear loser. It not only takes more work, but also takes more time than the jittered approaches. In fact, it takes so much more time we have to leave it off the graph to get a good comparison of the other methods."
[§Client work comparison] "Looking at the amount of client work, the number of calls is approximately the same for "Full" and "Equal" jitter, and higher for "Decorrelated"."
[§Full vs Equal conclusion] "The 'Full Jitter' approach uses less work, but slightly more time."
[§Rationale] "we want to spread out the spikes to an approximately constant rate"
Claims Extracted / 추출된 주장
이 자료가 직접 말하는 것만 claim 으로 분리한다. 내 프로젝트에 적용한 결론은 여기 쓰지 않는다.
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| AWS-JITTER-C1 | Full Jitter 공식은 sleep = random(0, min(cap, base * 2 ** attempt)) 이다 |
[§Full Jitter] "sleep = random(0, min(cap, base * 2 ** attempt))" | company-case-study |
분산 시스템에서 retry sleep 계산 시 | cap·base·attempt 의 구체 적정값은 증명하지 않음 |
| AWS-JITTER-C2 | no-jitter exponential backoff 는 jitter 적용 방식 대비 work 와 time 이 모두 더 크므로 실제 비교 그래프에서 제외되었다 | [§No-jitter comparison] "It not only takes more work, but also takes more time than the jittered approaches. In fact, it takes so much more time we have to leave it off the graph to get a good comparison of the other methods." | company-case-study |
retry storm 발생 시 no-jitter 의 열위 설명 | 특정 부하·인프라 조건이 달라도 동일하게 열위임을 증명하지 않음 |
| AWS-JITTER-C3 | client work(총 호출 수) 기준에서는 Full Jitter 와 Equal Jitter 가 거의 동등하며, Decorrelated Jitter 가 더 높다 | [§Client work comparison] "the number of calls is approximately the same for "Full" and "Equal" jitter, and higher for "Decorrelated"." | company-case-study |
jitter 방식 선택 시 client work 트레이드오프 | 완료 시간(completion time) 축에서도 Full Jitter 가 최선임을 직접 증명하지 않음 |
| AWS-JITTER-C4 | Full Jitter 는 Equal Jitter 대비 work 는 적고 completion time 은 약간 더 걸린다 | [§Full vs Equal conclusion] "The 'Full Jitter' approach uses less work, but slightly more time." | company-case-study |
Full vs Equal Jitter 트레이드오프 선택 | "약간(slightly)" 의 수치 정의 없음; 모든 시나리오에서 동일한 트레이드오프임을 증명하지 않음 |
| AWS-JITTER-C5 | jitter 도입 목적은 retry spike 를 분산시켜 근사 일정 속도(approximately constant rate)로 만드는 것이다 | [§Rationale] "we want to spread out the spikes to an approximately constant rate" | company-case-study |
retry 설계 목적 서술 | "일정 속도"의 정량적 정의나 SLO 기준은 증명하지 않음 |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
AWS-JITTER-C1: Full Jitter 의 sleep 계산 공식 (문자 단위 verbatim)AWS-JITTER-C2: no-jitter exponential backoff 가 jitter 방식 대비 work·time 모두 열위라는 AWS 시뮬레이션 결과AWS-JITTER-C3: Full/Equal 은 client work 유사, Decorrelated 는 더 높다는 비교AWS-JITTER-C4: Full Jitter 는 Equal 대비 work 절감 + completion time 소폭 증가 트레이드오프AWS-JITTER-C5: jitter 의 설계 목적 = spike 분산 → 일정 속도
- 이 자료가 증명하지 않는 것:
- max_attempts = 3 이 적정하다는 주장 (D4 의 정량값은 별도 source 필요)
- DLQ after exhausted attempts 패턴이 올바르다는 주장
- cap·base 의 구체 적정값
- Java / Spring Retry 환경에서의 구현 방법
- 본 결과가 AWS DynamoDB 외 시스템에서도 동일하게 적용된다는 보장
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-tmpl 도메인에서 cap·base·max_attempts 의 실측 최적값 (부하 테스트 필요)
- Spring Retry 또는 Resilience4j 가 Full Jitter 공식과 동등한 방식으로 구현되는지 공식 doc 확인
- Decorrelated Jitter 가 ca-tmpl 부하 프로파일에서 실제로 더 높은 client work 를 유발하는지 검증
메모 / Notes
- 본 포스트는 company-tech-blog (AWS Architecture Blog) 이며 공식 AWS SDK 문서가 아님. D4 에 대한 jitter 종류 비교 근거로는 유효하나, "공식 AWS best practice" 로 표현 금지.
- 2023 업데이트에서 "most AWS SDKs now incorporate this pattern natively" 언급 — SDK 사용 시 별도 구현 불필요할 수 있으나, Spring Retry / Resilience4j 구현 여부는 해당 라이브러리 공식 doc 에서 별도 확인 필요.
- D4 의 max_attempts = 3 + DLQ 정량값은 여전히 외부 reference 미확보 상태. 본 자료는 jitter 선택 근거만 제공.
Related / 관련
- 같은 주제 공식 doc (Spring Retry):
raw/official-docs/아래 (미작성) - 같은 주제 공식 doc (Resilience4j):
raw/official-docs/아래 (미작성) - 같은 주제 다른 블로그 (Stripe rate-limit retry): raw/company-tech-blogs/outbound-stripe-rate-limit-retry-engineering
- 이 자료를 인용한 wiki 요약:
wiki/concepts/아래 (생성 시)