Request Hedging의 정의
Request Hedging(리퀘스트 헤징)은 하나의 요청에 대한 응답이 늦어질 것을 대비해, 같은 요청을 여러 서버에 중복으로 보내고 그중 가장 먼저 도착한 응답만 사용하는 지연 시간 최적화 전략입니다. 이름 그대로 ‘헤지(hedge)’, 즉 위험을 분산시키는 금융 용어에서 따온 개념으로, 특정 서버 하나가 느려지더라도 전체 응답 시간이 늘어지지 않도록 안전장치를 마련하는 방식입니다.
예를 들어 콜택시를 부를 때 한 기사님에게만 요청하면 그 기사님이 늦게 응답할 경우 계속 기다려야 하지만, 동시에 여러 기사님에게 요청을 보내고 가장 먼저 수락한 사람의 차를 타는 것과 비슷합니다. 다만 나머지 기사님들에게는 ‘이미 다른 차를 탔다’고 취소 요청을 보내야겠죠. Request Hedging도 마찬가지로 먼저 응답이 오면 나머지 요청은 취소하거나 무시합니다.
동작 원리와 예시
일반적인 구현 방식은 다음과 같습니다.
- 클라이언트가 요청을 보낸 후 일정 시간(P95 지연시간 등) 동안 응답이 오지 않으면 동일한 요청을 다른 서버에 추가로 전송합니다.
- 여러 응답 중 가장 먼저 도착한 것을 사용하고, 나머지 요청은 취소(cancel)하거나 결과를 버립니다.
- 모든 요청을 동시에 보내는 방식(Fan-out)도 있지만, 자원 낭비를 줄이기 위해 지연이 감지될 때만 추가 요청을 보내는 방식(Tail Hedging)이 더 흔히 사용됩니다.
예를 들어 Google의 내부 시스템에서는 P95 지연시간을 기준으로, 요청이 그 시간을 넘기면 자동으로 두 번째 요청을 다른 서버에 보내는 방식을 사용합니다. 이렇게 하면 전체 요청량은 소폭 증가하지만, 꼬리 지연(tail latency)은 크게 줄어드는 효과가 있습니다.
실무에서 왜 사용하는가
분산 시스템에서는 개별 서버의 일시적인 부하나 GC(가비지 컬렉션), 네트워크 지연 등으로 인해 특정 요청만 유독 느려지는 ‘꼬리 지연’ 문제가 자주 발생합니다. 평균 응답 시간은 빠르더라도 상위 1~5%의 느린 요청이 사용자 경험을 크게 해칠 수 있는데, Request Hedging은 이런 문제를 완화하는 데 효과적입니다.
단, 무분별하게 사용하면 서버 부하가 증가하고 중복 처리로 인한 부작용(결제 중복 등)이 생길 수 있으므로, 멱등성(idempotency)이 보장된 읽기 요청이나 조회성 API에 주로 적용하는 것이 안전합니다. 실제로 gRPC, Envoy, Google 내부 인프라 등에서는 이러한 헤징 전략을 옵션으로 제공하며, 캐시 조회나 검색 서비스처럼 실패해도 큰 부작용이 없는 영역에서 널리 활용되고 있습니다.