느린 조회를 줄이려고 잠시 뒤 같은 요청을 다른 서버에도 보냅니다. hedged request는 언제 유리하고 무엇이 위험한가요?

헤지 요청은 첫 요청이 지연될 때 중복 후보를 보내 빠른 결과를 채택하는 방식입니다. 꼬리 지연을 줄일 수 있지만 하위 부하와 중복 효과를 늘리므로 읽기·멱등 작업과 제한된 예산에서 평가해야 합니다.

동작 원리와 전제

두 서버가 독립적으로 느려지는 상황이면 이점이 있을 수 있지만 공통 DB가 병목이면 중복이 그 병목을 악화시킵니다. 첫 응답의 성공·신선도·정확성이 유효한지 확인하고 단순히 가장 먼저 온 오류를 채택하지 않습니다.

선택과 실패 처리

임계 지연 이후 일부 요청에만 적용하고 동시 중복 수·비율을 제한합니다. 승자를 얻으면 나머지 취소를 시도하되 실제 종료까지 자원은 남을 수 있습니다. 변경 요청은 같은 멱등 키와 외부 보장 없이는 사용하지 않습니다.

구체적인 사례와 검증

원본과 복제본 중 빠른 답을 고를 때 두 답의 신선도 계약이 같아야 합니다. 오래된 replica가 먼저 응답했다고 최신 결과가 필요한 요청의 승자로 쓰면 지연은 줄지만 정확성이 깨집니다. 성공 조건을 만족하는 첫 결과를 채택하고 나머지의 실제 취소·정리까지 추적합니다. 헤지 임계값을 너무 짧게 잡으면 거의 모든 요청이 두 번 실행되어 서버가 더 느려질 수 있습니다. 최근 지연 분포를 이용할 때도 과부하 중 악순환을 막는 상한이 필요합니다. 독립 서버인지 공통 DB·네트워크를 공유하는지에 따라 오류 상관과 실제 이득이 달라진다는 점을 확인하겠습니다.

헤지 전후 p99·총 QPS·DB CPU·취소 잔존·성공당 비용을 비교합니다. 정상 평균이 조금 좋아져도 과부하 회복이 나빠지면 실패입니다. 헤지는 용량 증설이나 근본 병목 개선을 대체하는 만능 기법이 아닙니다.