장애 때 재시도가 시스템을 더 망가뜨리지 않게 하려면

외부 API가 느려지면 재시도를 늘려 복구를 기대하기 쉽습니다. 하지만 많은 요청이 동시에 다시 몰리면 이미 느린 서비스와 우리 서버가 함께 무너질 수 있습니다. 재시도 횟수, 간격, 전체 시간 예산을 하나의 정책으로 설계해야 합니다.

실패 종류를 분리한다

네트워크 시간 초과와 서버의 일시적 오류는 재시도 가능할 수 있지만 잘못된 입력이나 권한 오류는 반복해도 낫지 않습니다. 상태 코드와 작업 의미에 따라 재시도 여부를 정합니다. 결제나 발송처럼 중복 효과가 있는 요청에는 멱등 키가 필요합니다.

개별 API 호출의 시간 초과만 정하면 여러 단계와 재시도가 합쳐져 사용자 요청이 너무 길어집니다. 전체 요청 마감시간 안에서 남은 시간을 계산해 재시도 횟수를 제한합니다. 사용자에게는 진행 중인지 실패인지 명확한 상태를 보여 줍니다.

모든 서버가 1초 뒤 동시에 재시도하면 장애가 반복될 수 있습니다. 점차 늘어나는 대기와 무작위 지터를 적용하고 최대 대기를 제한합니다. 제공자가 재시도 시점을 알려 주면 그 지침도 반영합니다.

연속 실패가 일정 수준을 넘으면 잠시 호출을 중단하고 빠르게 실패시키는 회로 차단기를 고려합니다. 다만 복구 후 시험 호출과 재개 조건을 명확히 해야 장시간 멈춘 상태가 되지 않습니다. 핵심·비핵심 업무의 우선순위도 구분합니다.

장애 시험에서 외부 API가 5분간 느려질 때 우리 큐와 DB가 어떻게 변하는지 봅니다. 재시도 성공률만이 아니라 전체 지연, 중복 실행, 실패 후 회복 시간을 측정합니다. 재시도가 적절한지 데이터로 조정합니다.

주의할 실패: 무제한 즉시 재시도

관찰할 지표: 지연·중복·회복 시간

AWS Builders Library: Timeouts, retries, and backoff with jitter. 시간 초과·백오프·지터와 재시도 폭주의 원리를 참고했습니다. 임계값과 예산은 서비스의 실제 부하 시험으로 정해야 합니다.

이미지와 도식은 이해를 돕기 위한 개념 시각화입니다. 특정 고객의 실제 설비·데이터·화면을 재현한 것이 아닙니다.

#재시도 #서킷브레이커 #백오프 #지터 #장애대응 #API운영 #분산시스템 #멱등성 #회복탄력성 #서버안정성