Retry Storm이란?
Retry Storm(재시도 폭풍)은 일시적인 장애가 발생했을 때, 여러 클라이언트가 동시에 재시도 요청을 보내면서 오히려 서버에 더 큰 부하를 유발하고 장애를 확산시키는 현상을 말합니다. 원래 재시도(Retry)는 네트워크 순간 끊김이나 일시적 오류를 자동으로 극복하기 위한 안전장치인데, 잘못 설계되면 이 안전장치 자체가 시스템을 무너뜨리는 원인이 됩니다.
비유하자면 사람이 많이 몰리는 은행 창구에서 갑자기 시스템이 느려졌다고 상상해보세요. 대기하던 사람들이 답답함에 창구를 다시 찾아가고, 또 다른 사람들도 똑같이 재문의를 하면서 창구 직원은 새로운 업무 대신 같은 문의에 반복적으로 시달리게 됩니다. 결국 창구는 더 느려지고, 더 많은 재문의를 유발하는 악순환에 빠집니다.
왜 발생하는가: 동작 원리와 예시
Retry Storm은 보통 다음과 같은 흐름으로 발생합니다.
- 서버가 일시적으로 응답 지연되거나 에러를 반환함
- 클라이언트가 즉시, 그리고 동시에 재시도를 시도함
- 서버는 기존 요청 처리도 버거운데 재시도 요청까지 추가로 받음
- 부하가 늘어나 응답이 더 느려지고, 더 많은 타임아웃과 재시도를 유발함
예를 들어 마이크로서비스 환경에서 A 서비스가 B 서비스를 호출하는데, B가 순간적으로 느려졌다고 가정해봅시다. A의 인스턴스 수백 개가 동시에 타임아웃을 겪고, 각자 정해진 재시도 로직에 따라 즉시 재요청을 보낸다면 B는 정상 요청보다 몇 배 많은 트래픽을 받게 됩니다. 여기에 재시도 시점까지 겹치면(Thundering Herd 현상과 유사) 문제는 더 커집니다. 특히 재시도 로직에 지수 백오프(Exponential Backoff) 없이 고정 간격으로 즉시 재시도하도록 설계된 경우, 이런 폭풍은 훨씬 쉽게 발생합니다.
실무에서의 대응 방법
Retry Storm을 막기 위해 실무에서는 여러 안전장치를 함께 사용합니다.
Exponential Backoff: 재시도 간격을 점점 늘려 서버에 몰리는 요청을 분산시킴Jitter: 재시도 시점에 무작위성을 더해 여러 클라이언트가 동시에 몰리는 것을 방지함Circuit Breaker: 장애가 감지되면 일정 시간 동안 아예 요청을 차단해 시스템 회복 시간을 확보함- 재시도 횟수 제한: 무한 재시도가 아닌 최대 시도 횟수를 정해 무의미한 부하를 막음
결국 재시도는 신중하게 설계되어야 하는 기능입니다. 단순히 실패하면 다시 시도한다는 접근은 장애 상황에서 오히려 독이 될 수 있으므로, 백오프와 서킷 브레이커 같은 패턴을 함께 적용해 시스템 전체의 안정성을 지켜야 합니다.