장애 복구 순간 재시도 요청이 동시에 몰립니다. exponential backoff에 jitter를 넣는 이유는 무엇인가요?

백오프는 재시도 간격을 늘리고 지터는 여러 클라이언트의 시점을 분산합니다. 같은 고정 간격이나 동일한 지수 간격만 쓰면 동기화된 요청 파도가 반복될 수 있습니다.

동작 원리와 전제

처음 실패한 수천 클라이언트가 모두 1초·2초·4초 뒤 호출하면 서버는 회복할 여유를 얻기 어렵습니다. 허용 구간 안 무작위 지연을 선택하되 최대 간격·전체 deadline·시도 수를 제한합니다. 지터 방식에 따라 평균 대기와 분산이 달라집니다.

선택과 실패 처리

Retry-After와 API 제한을 존중하고 재시도 가능한 오류만 분류합니다. 여러 계층의 재시도 횟수가 곱해지지 않게 예산을 공유합니다. 비멱등 변경은 응답 유실 시 결과 조회·논리 키가 필요합니다.

구체적인 사례와 검증

재시도 간격을 계산할 때 서버가 복구된 뒤 모든 client가 최대 backoff에서 동시에 깨어나는지 확인합니다. 같은 고정 seed를 각 프로세스에 사용하면 지터를 넣고도 비슷한 순서가 나올 수 있습니다. 운영에서는 적절한 난수 원천을 쓰고 테스트에서는 seed나 난수 함수를 주입해 재현합니다. 실패가 오래 지속되면 circuit breaker와 재시도 예산으로 호출 자체를 줄입니다. 지터가 순서를 섞어도 같은 논리 변경의 멱등 키는 유지해야 합니다. 다음 시도를 기다리는 동안 사용자가 취소하면 timer와 대기 요청도 해제하고, 이미 실행한 외부 효과는 별도 결과 조회로 확인하겠습니다.

동시 장애·서버 회복·인스턴스 재시작을 시험하고 순간 호출률·성공률·지연을 봅니다. 무작위화가 실제 업무 순서를 바꾸지 않도록 순서가 필요한 작업은 별도 큐를 사용합니다. 재시도는 회복 기회이지 처리 용량을 늘리는 방법은 아닙니다.