요청 하나의 팬아웃과 각 계층 재시도가 겹칩니다. 재시도 예산은 어떻게 계산하나요?

사용자 요청 하나가 만든 모든 실제 시도를 합쳐야 합니다. 각 계층에서 작은 횟수라고 생각해도 곱해져 하위 서비스에 큰 부하를 줄 수 있습니다.

동작 원리와 전제

상위가 3번 재시도하고 내부 client도 매번 3번 시도하면 같은 작업이 최대 9번 호출될 수 있습니다. 동시에 5개 하위 API를 부르면 정상 경로부터 여러 요청이 생깁니다. 논리 요청 ID와 물리 시도를 나눠 기록합니다.

선택과 실패 처리

서비스 전체 재시도 비율이나 요청별 토큰 예산을 두고 필수·선택 호출에 배분합니다. deadline이 거의 끝났으면 새 시도를 시작하지 않습니다. fallback도 같은 자원과 예산을 쓴다면 공짜로 세지 않습니다.

구체적인 사례와 검증

추적 로그에 원래 사용자 요청 ID와 계층별 시도 번호를 넣으면 한 요청이 하위에 몇 번 도달했는지 알 수 있습니다. 제한은 성공 요청 수뿐 아니라 실패한 시도도 세어야 합니다. 보상·상태 조회 같은 복구 호출은 일반 재시도와 역할이 다르지만 같은 하위 자원을 쓰므로 총 예산에는 포함합니다. 이미 하위 client가 재시도하는데 상위에서 이를 모르면 원래 예상보다 deadline이 길어질 수 있습니다. 함수 계약과 오류 코드에 재시도 책임을 명시하고 불확정 변경은 단순 backoff가 아니라 결과 조회로 전환합니다. 부하를 줄인 뒤 정상 사용자 결과가 어떻게 변하는지 함께 관찰하겠습니다.

장애 상태에서 최초 호출·재시도·실패·하위 포화의 시간축을 비교합니다. 예산을 줄여 성공률이 낮아질 수 있어 사용자 결과와 원본 회복을 함께 평가합니다. 모든 계층에 재시도를 넣는 대신 책임 계층과 오류 의미를 명확히 하겠습니다.