11 KiB
11 KiB
title, source_type, status, confidence, url, archive_url, related_branches, related_projects, tags, created, last_reviewed
| title | source_type | status | confidence | url | archive_url | related_branches | related_projects | tags | created | last_reviewed | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Resilience4j vs Spring Retry — retry/circuit breaker library 비교 | official-doc | raw | high | https://resilience4j.readme.io/docs/getting-started |
|
|
|
2026-05-22 | 2026-05-27 |
Resilience4j vs Spring Retry — retry/circuit breaker library 비교
Layer:
raw/official-docs/— Resilience4j Getting Started 페이지의 정의/모듈 발췌 + Spring Retry / Hystrix 상태에 대한 별도 출처 참조. ca-tmpl outbound Group G-C 의 resilience tool 비교 (Resilience4j 채택 + Spring Retry 좁은 예외 + Hystrix 배제) 근거.
Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-outbound-http-client-baseline | outbound retry/circuit breaker library 채택 (Resilience4j default) 근거 |
| raw/branch-notes/feature-background-job-async-contract | background job retry 정책에서 Resilience4j Retry vs Spring Retry @Retryable 의 분리 사용 결정 |
| raw/branch-notes/feature-metrics-alerting-contract | circuit breaker metric (dependency.name, outcome 등) 의 Resilience4j Micrometer 통합 의존 결정 |
컨텍스트
ca-tmpl 결정 "retry/circuit breaker 는 Resilience4j, Spring Retry 는 simple blocking 에만" 의 근거. Hystrix 가 maintenance 인 이유까지 묶음.
출처 / Source
- Resilience4j Getting Started: https://resilience4j.readme.io/docs/getting-started
- Spring Retry GitHub README: https://github.com/spring-projects/spring-retry
- Netflix Hystrix README: https://github.com/Netflix/Hystrix (maintenance-mode 안내)
- 아카이브 URL: (미수집)
- 저자 / 조직: Resilience4j community (Robert Winkler 등) / Spring (Pivotal/Broadcom) / Netflix OSS
- 발행일: rolling docs
- 마지막 확인일: 2026-05-27
핵심 인용 / Key quotes (verbatim)
[§Resilience4j Getting Started — Introduction] "Resilience4j is a lightweight fault tolerance library designed for functional programming."
[§Resilience4j Getting Started — Introduction] "Resilience4j provides higher-order functions (decorators) to enhance any functional interface, lambda expression or method reference with a Circuit Breaker, Rate Limiter, Retry or Bulkhead."
[§Resilience4j Getting Started — NOTE] "NOTE: Resilience4j 2 requires Java 17."
[§Resilience4j Getting Started — Modules] "resilience4j-circuitbreaker: Circuit breaking" / "resilience4j-ratelimiter: Rate limiting" / "resilience4j-bulkhead: Bulkheading" / "resilience4j-retry: Automatic retrying (sync and async)" / "resilience4j-cache: Result caching" / "resilience4j-timelimiter: Timeout handling"
[§Resilience4j Getting Started — Vavr] (Vavr
Trymonad 예시) "Vavr'sTrymonad to recover from an exception and invoke another lambda expression as a fallback, when all retries have failed."
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| R4J-C1 | Resilience4j 는 functional programming 을 위해 설계된 lightweight fault tolerance library | [§Getting Started — Introduction] "Resilience4j is a lightweight fault tolerance library designed for functional programming." | official-vendor-doc |
Java 17+ 환경에서 Resilience4j 2 사용 | "lightweight" 가 특정 메모리/jar 크기 임계값을 의미한다는 뜻 아님 — 정성적 표현 |
| R4J-C2 | Resilience4j 는 functional interface / lambda / method reference 를 decorator 로 감싸 CircuitBreaker / RateLimiter / Retry / Bulkhead 를 부착하는 higher-order function 모델 | [§Getting Started] "Resilience4j provides higher-order functions (decorators) to enhance any functional interface, lambda expression or method reference with a Circuit Breaker, Rate Limiter, Retry or Bulkhead." | official-vendor-doc |
함수형 호출 site 에 decorator 부착하는 사용 패턴 | Spring AOP @CircuitBreaker annotation 사용이 항상 가능한 것은 아님 — 별도 resilience4j-spring-boot3 starter 필요 |
| R4J-C3 | Resilience4j core 모듈 6종 — circuitbreaker / ratelimiter / bulkhead / retry / cache / timelimiter | [§Getting Started — Modules] "resilience4j-circuitbreaker" / "resilience4j-ratelimiter" / "resilience4j-bulkhead" / "resilience4j-retry: Automatic retrying (sync and async)" / "resilience4j-cache" / "resilience4j-timelimiter" | official-vendor-doc |
Resilience4j 2.x core 모듈 채택 시 | 각 모듈이 동일한 default 정책 / 동일한 thread model 을 쓴다는 뜻 아님 — Bulkhead 는 semaphore vs threadpool 두 변종 |
| R4J-C4 | Resilience4j 2.x 는 Java 17 을 요구 | [§Getting Started — NOTE] "NOTE: Resilience4j 2 requires Java 17." | official-vendor-doc |
Resilience4j 2.x 도입 결정 | Resilience4j 1.x 가 여전히 active maintained 라는 뜻 아님 — 별도 확인 필요 |
| R4J-C5 | Resilience4j 는 retry 모두 소진 후 fallback 으로 다른 lambda 를 호출할 수 있도록 Vavr Try monad 와 연동 |
[§Getting Started — Vavr] "Vavr's Try monad to recover from an exception and invoke another lambda expression as a fallback, when all retries have failed." |
official-vendor-doc |
Vavr 의존성을 함께 사용하는 경우 | Vavr 없이도 동일 fallback 표현이 가능하다는 뜻 아님 — 별도 API 확인 필요 |
| R4J-C6 | Spring Retry README (별도 출처) 및 Hystrix README (별도 출처) 의 상태 인용은 본 WebFetch 범위 밖. 본 raw 만으로는 Spring Retry 의 "circuit breaker 미포함" 또는 Hystrix 의 "maintenance" 상태가 증명되지 않음 | (negative finding — Resilience4j Getting Started 페이지에 Spring Retry / Hystrix 비교 없음) | needs-confirmation |
Resilience4j vs Spring Retry vs Hystrix 비교 표 작성 시 | 이 부정 확인은 비교 결론이 거짓 이라는 뜻이 아니라 별도 출처 보강 필요 라는 뜻 |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
R4J-C1~C5: Resilience4j 의 정의, decorator 모델, 6 core 모듈, Java 17 요구사항, VavrTryfallback 연동
- 이 자료가 증명하지 않는 것:
- Spring Retry 의
@Retryable지원 / circuit breaker 미포함 — 본 Resilience4j 페이지에 없음 (R4J-C6). Spring Retry GitHub README 별도 출처 필요 - Netflix Hystrix 의 maintenance 상태 — 본 페이지에 없음 (
R4J-C6). Hystrix GitHub README 별도 출처 필요 - "Lightweight because the library only uses Vavr, which does not have any other external dependencies" — 본 WebFetch 결과에 없음. 이전 인용은 다른 페이지 (또는 archived) 출처 — needs-confirmation
- Micrometer integration "내장" 여부 — 본 페이지에 없음 (
micrometer모듈은 별도 artifact 일 가능성, 별도 확인 필요) - circuit breaker state machine 의 정확한 상태 (CLOSED/OPEN/HALF_OPEN/DISABLED/FORCED_OPEN) — 본 페이지에 없음
- Spring Retry 의
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-tmpl 의 circuit breaker metric tag scope (
dependency.name,dependency.type,outcome) 가 Resilience4j default tag 와 어떻게 매핑되는지 —resilience4j-micrometer모듈 별도 확인 - retry-after header honor 가 Resilience4j Retry default 가 아니라는 점 — 본 페이지 미언급, 별도 검증 필요
resilience4j-spring-boot3starter 의 정확한 artifact 좌표 + auto-configuration 동작
- ca-tmpl 의 circuit breaker metric tag scope (
메모 / Notes (내 프로젝트 해석)
본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.
- 비교 표 (별도 출처 보강 필요한 항목 다수):
| 항목 | Resilience4j | Spring Retry | Hystrix |
|---|---|---|---|
| status | active (R4J-C1,C4) |
active (needs-confirmation, 별도 출처) | maintenance (needs-confirmation, Hystrix README 별도 출처) |
| circuit breaker | yes (R4J-C3) |
no (needs-confirmation) | yes (needs-confirmation) |
| retry | yes (R4J-C3) |
yes — declarative @Retryable (needs-confirmation) |
no (needs-confirmation) |
| rate limiter | yes (R4J-C3) |
no (needs-confirmation) | no (needs-confirmation) |
| bulkhead | yes (semaphore + threadpool, R4J-C3 + 변종은 미확인) |
no (needs-confirmation) | yes — threadpool (needs-confirmation) |
| time limiter | yes (R4J-C3) |
no (needs-confirmation) | yes (needs-confirmation) |
| metric | resilience4j-micrometer 모듈 (needs-confirmation) |
Spring Boot Actuator (needs-confirmation) | Hystrix dashboard (needs-confirmation) |
| reactive | yes (Reactor / RxJava) — 본 페이지 미언급 | no (needs-confirmation) | RxJava (needs-confirmation) |
| spring boot starter | resilience4j-spring-boot3 (needs-confirmation, 정확한 좌표) |
spring-retry + spring-aspects (needs-confirmation) |
spring-cloud-starter-netflix-hystrix deprecated (needs-confirmation) |
- ca-tmpl 결정 정당성 (해석):
- Resilience4j default — circuit breaker 가 필요한 시점이 retry 와 분리되지 않음. 두 module 이 같은 library 에 있어야 metric/operations 이 일관 (해석 —
R4J-C3의 모듈 list 가 부분 근거). - Spring Retry 예외 허용 — circuit breaker 불필요 + reactive 아닌 simple blocking retry 만 필요한 좁은 케이스 (예: idempotent admin job 한 군데). over-engineering 방지 (해석).
- Hystrix 배제 — 공식 maintenance 상태 가정 (needs-confirmation, Hystrix README 별도 출처 필요).
- Resilience4j default — circuit breaker 가 필요한 시점이 retry 와 분리되지 않음. 두 module 이 같은 library 에 있어야 metric/operations 이 일관 (해석 —
- ca-tmpl test 계약 매핑 (해석):
- "retry/circuit breaker enabled 인데 Resilience4j metric 과 retryable classification 이 없으면 실패" ← 라이브러리 선택을 강제하고 metric/registry 등록을 강제.
- circuit breaker metric tag scope
dependency.name,dependency.type,outcome만 허용 — Resilience4j 기본 tag (state, kind 등) 를 그대로 노출하면 high cardinality 위험. tag 재맵 필요 (해석).
- 시사점: ca-tmpl Resilience4j 선택은 module 통합성 + 공식 maintenance status 가정 기반. 비교 표의 다수 항목이 별도 출처로 보강되어야 wiki 승급 가능.
Related / 관련
- 같은 주제 다른 official-doc:
- 같은 주제 company-tech-blog:
- raw/company-tech-blogs/outbound-stripe-rate-limit-retry-engineering — Stripe retry/backoff/idempotency 사례
- 인용하는 branch:
- 인용하는 wiki: (미작성)