74 lines
9.7 KiB
Markdown
74 lines
9.7 KiB
Markdown
# API 재시도는 횟수가 아니라 부하 예산으로 설계한다
|
|
|
|
## 먼저 결론: 무엇을 해결하는가
|
|
|
|
이 글의 독자는 백엔드 개발자, 플랫폼 엔지니어이다. 읽고 나면 **재시도가 장애를 증폭하지 않도록 타임아웃, 재시도 횟수, 백오프, 지터, 멱등성을 함께 설계한다**할 수 있어야 한다. 먼저 결론부터 말하면, 재시도는 성공 확률을 높이는 무료 기능이 아니라 실패 중인 의존성에 추가 부하를 보내는 예산이므로, 멱등성·한도·백오프·지터·관측성을 하나의 정책으로 묶어야 한다.
|
|
범위는 서비스 간 동기 HTTP 호출의 클라이언트 재시도 정책, 정책을 검증하는 운영 지표와 실패 실험이다. 합리적으로 기대할 수 있지만 이 글에서 다루지 않는 범위는 메시지 큐의 전달 보장 전체 설계, 특정 클라우드 SDK의 모든 기본값, 정확히 한 번 처리 보장이다. 적용 맥락은 HTTP 의미론은 RFC 9110, 예시는 2026-07-23 기준이다.
|
|
제공된 근거 팩은 다음 사실을 확인 대상으로 제시한다: Retries can increase load on a dependency that is already failing. [S1]
|
|
|
|
## 문제가 생기는 맥락과 제약
|
|
|
|
이 절은 ‘왜 이 문제가 실제 시스템에서 어려워지는가?’에 답한다. 판단의 기준은 **재시도는 성공 확률을 높이는 무료 기능이 아니라 실패 중인 의존성에 추가 부하를 보내는 예산이므로, 멱등성·한도·백오프·지터·관측성을 하나의 정책으로 묶어야 한다.**이다. 다룰 핵심 항목은 현상, 원인 후보, 제약, 재시도의 부하 증폭, 멱등성이며, 설명은 독자의 목표인 “재시도가 장애를 증폭하지 않도록 타임아웃, 재시도 횟수, 백오프, 지터, 멱등성을 함께 설계한다”에 필요한 범위로 제한한다.
|
|
현실의 문제는 재시도의 부하 증폭, 멱등성, 지수 백오프, 지터, 재시도 한도, 성공 및 중단 기준가 독립적으로 움직이지 않는다는 점이다. 입력, 상태, 시간, 실패 복구가 연결되므로 한 요소만 최적화하면 다른 경로에서 비용이 나타날 수 있다.
|
|
제공된 근거 팩은 다음 사실을 확인 대상으로 제시한다: A client can automatically retry an idempotent request after a communication failure before reading the response, subject to the specification's conditions. [S2]
|
|
|
|
## 핵심 판단 기준과 멘털 모델
|
|
|
|
이 절은 ‘뒤의 세부사항을 이해하려면 어떤 모델이 필요한가?’에 답한다. 판단의 기준은 **재시도는 성공 확률을 높이는 무료 기능이 아니라 실패 중인 의존성에 추가 부하를 보내는 예산이므로, 멱등성·한도·백오프·지터·관측성을 하나의 정책으로 묶어야 한다.**이다. 다룰 핵심 항목은 용어 정의, 인과 관계, 판단 기준이며, 설명은 독자의 목표인 “재시도가 장애를 증폭하지 않도록 타임아웃, 재시도 횟수, 백오프, 지터, 멱등성을 함께 설계한다”에 필요한 범위로 제한한다.
|
|
멘털 모델은 ‘입력 → 판단 기준 → 상태 변화 → 관측 결과’의 네 칸으로 잡는다. 재시도의 부하 증폭, 멱등성, 지수 백오프, 지터, 재시도 한도, 성공 및 중단 기준를 이 흐름에 배치하면 구현 세부사항이 바뀌어도 인과 관계를 추적할 수 있다.
|
|
제공된 근거 팩은 다음 사실을 확인 대상으로 제시한다: Retry behavior should consider whether the operation is idempotent. [S3]
|
|
|
|
## 해결 방식이 동작하는 과정
|
|
|
|
이 절은 ‘구성요소와 데이터 흐름은 어떻게 연결되는가?’에 답한다. 판단의 기준은 **재시도는 성공 확률을 높이는 무료 기능이 아니라 실패 중인 의존성에 추가 부하를 보내는 예산이므로, 멱등성·한도·백오프·지터·관측성을 하나의 정책으로 묶어야 한다.**이다. 다룰 핵심 항목은 구성요소, 데이터 또는 제어 흐름, 불변조건, 재시도의 부하 증폭, 멱등성이며, 설명은 독자의 목표인 “재시도가 장애를 증폭하지 않도록 타임아웃, 재시도 횟수, 백오프, 지터, 멱등성을 함께 설계한다”에 필요한 범위로 제한한다.
|
|
동작은 다음 인과 순서로 이해할 수 있다.
|
|
1. 입력과 사전 조건을 검증하고 처리 가능한 상태인지 확인한다.
|
|
2. 명시된 판단 기준으로 경로를 선택하고 상태 변경 범위를 제한한다.
|
|
3. 결과를 기록한 뒤 성공 기준과 비교해 다음 행동을 결정한다.
|
|
제공된 근거 팩은 다음 사실을 확인 대상으로 제시한다: Retries can increase load on a dependency that is already failing. [S1]
|
|
|
|
## 끝까지 따라가는 구현 예시
|
|
|
|
이 절은 ‘구체적인 입력이 어떻게 결과로 바뀌는가?’에 답한다. 판단의 기준은 **재시도는 성공 확률을 높이는 무료 기능이 아니라 실패 중인 의존성에 추가 부하를 보내는 예산이므로, 멱등성·한도·백오프·지터·관측성을 하나의 정책으로 묶어야 한다.**이다. 다룰 핵심 항목은 초기 조건, 단계별 변화, 최종 결과, 재시도의 부하 증폭, 멱등성이며, 설명은 독자의 목표인 “재시도가 장애를 증폭하지 않도록 타임아웃, 재시도 횟수, 백오프, 지터, 멱등성을 함께 설계한다”에 필요한 범위로 제한한다.
|
|
아래는 특정 제품의 실제 측정값이 아니라 판단 흐름을 드러내기 위한 예시다.
|
|
```text
|
|
입력: 변경 요청과 현재 상태
|
|
판단: 사전 조건 충족 여부 → 안전한 실행 경로 선택
|
|
실행: 최소 범위 변경
|
|
관측: 예상 상태와 실제 상태 비교
|
|
결과: 성공이면 확정, 불일치면 중단 후 복구
|
|
```
|
|
예시의 핵심은 명령 자체가 아니라 각 단계의 입력, 판단, 관측이 끊기지 않는다는 점이다.
|
|
제공된 근거 팩은 다음 사실을 확인 대상으로 제시한다: A request method is idempotent when multiple identical requests have the same intended effect as one request. [S2]
|
|
|
|
## 어떻게 검증할 것인가
|
|
|
|
이 절은 ‘주장이 맞고 구현이 동작한다는 것을 어떻게 확인하는가?’에 답한다. 판단의 기준은 **재시도는 성공 확률을 높이는 무료 기능이 아니라 실패 중인 의존성에 추가 부하를 보내는 예산이므로, 멱등성·한도·백오프·지터·관측성을 하나의 정책으로 묶어야 한다.**이다. 다룰 핵심 항목은 검증 절차, 성공 기준, 관측 지표, 재시도의 부하 증폭, 멱등성이며, 설명은 독자의 목표인 “재시도가 장애를 증폭하지 않도록 타임아웃, 재시도 횟수, 백오프, 지터, 멱등성을 함께 설계한다”에 필요한 범위로 제한한다.
|
|
검증 계획은 주장과 관측을 일대일로 연결한다.
|
|
1. 핵심 주장마다 확인 가능한 로그, 테스트, 상태 또는 출처를 지정한다.
|
|
2. 정상 경로뿐 아니라 실패 경로와 복구 경로를 실행한다.
|
|
3. 성공 기준과 중단 기준을 실행 전에 고정한다.
|
|
제공된 근거 팩은 다음 사실을 확인 대상으로 제시한다: Exponential backoff increases the delay between retry attempts and should use bounded limits. [S3]
|
|
|
|
## 대안, 트레이드오프, 실패 조건
|
|
|
|
이 절은 ‘언제 이 접근법을 선택하지 말아야 하는가?’에 답한다. 판단의 기준은 **재시도는 성공 확률을 높이는 무료 기능이 아니라 실패 중인 의존성에 추가 부하를 보내는 예산이므로, 멱등성·한도·백오프·지터·관측성을 하나의 정책으로 묶어야 한다.**이다. 다룰 핵심 항목은 대안, 얻는 것과 잃는 것, 적용 한계이며, 설명은 독자의 목표인 “재시도가 장애를 증폭하지 않도록 타임아웃, 재시도 횟수, 백오프, 지터, 멱등성을 함께 설계한다”에 필요한 범위로 제한한다.
|
|
이 접근은 구조와 검증 가능성을 얻는 대신 초기 설계와 근거 정리에 비용이 든다. 빠른 초안만 필요한 상황에서는 과할 수 있고, 규제·운영 위험이 큰 문서에서는 더 강한 사실 검증이 필요하다.
|
|
대안은 더 자유로운 서술, 단일 모델 작성, 수동 리뷰다. 선택 기준은 문서의 위험도, 변경 빈도, 독자의 숙련도, 검증 비용이다.
|
|
제공된 근거 팩은 다음 사실을 확인 대상으로 제시한다: Retries can increase load on a dependency that is already failing. [S1]
|
|
|
|
## 실무 적용 체크리스트
|
|
|
|
실무 적용 전 다음을 확인한다.
|
|
- 독자 목표와 비범위를 한 문장으로 고정했는가?
|
|
- 판단 기준과 근거가 연결되어 있는가?
|
|
- 예시가 시작 상태부터 검증 결과까지 이어지는가?
|
|
- 실패 조건, 중단 기준, 롤백이 있는가?
|
|
- 버전 또는 시점이 드러나는가?
|
|
제공된 근거 팩은 다음 사실을 확인 대상으로 제시한다: A client can automatically retry an idempotent request after a communication failure before reading the response, subject to the specification's conditions. [S2]
|
|
|
|
## 결론
|
|
|
|
기억해야 할 판단은 하나다. **재시도는 성공 확률을 높이는 무료 기능이 아니라 실패 중인 의존성에 추가 부하를 보내는 예산이므로, 멱등성·한도·백오프·지터·관측성을 하나의 정책으로 묶어야 한다.** 독자의 다음 행동은 자신의 환경에서 재시도가 장애를 증폭하지 않도록 타임아웃, 재시도 횟수, 백오프, 지터, 멱등성을 함께 설계한다을 검증 가능한 기준으로 바꾸는 것이다.
|
|
제공된 근거 팩은 다음 사실을 확인 대상으로 제시한다: Retry behavior should consider whether the operation is idempotent. [S3]
|