러시아 검색 서비스인 Yandex에서 800개의 마이크로 서비스로 운영중이던 시스템에서 요청 재시도로 인해서 발생했던 장애를 가상의 스토리로 다시 정리한 글인데 재미도 있고 네트워크 문제를 피하기 위해서 흔히 하는 요청 재시도의 복잡한 문제를 쉽게 이해할 수 있는 글입니다.

서비스를 구현하면서 반복되는 요청 실패 문제를 해결하기 위해서 재시도를 구현하는데 재시도로 인한 문제를 방지하기 위해서 지수 백오프와 지터를 구현해서 적용합니다. 지수 백오프는 요청이 실패했을 때 재시도를 똑같은 시간마다 하는게 아니라 1,2,4, 8초 같은 식으로 늘려가는 방법을 말하고 지터는 모든 클라이언트가 똑같은 시간에 재시도를 해서 서버에 과부하가 일어나지 않도록 임의의 시간을 추가해서 각 클라이언트가 다른 간격으로 재시도를 하게 하는 방법입니다.

하지만 백엔드에 큰 장애가 발생하게 되자 문제 상황을 해결하기 위해 롤백을 했음에도 재시도로 인한 요청이 너무 많아서 백엔드 시스템에 정상적으로 돌아오지 않았고 결국 트래픽을 차단해서 문제를 해결했습니다.

재시도로 인해서 시스템 복구에 더 오랜 시간이 걸리자 재시도가 왜 요청을 증폭시키는지를 조사하고 이를 해결하기 위해서 서킷브레이커와 재시도 예산을 테스트하고 비교한 결과 재시도 예산을 선택하게 됩니다. 서킷 브레이커는 일정 임계점에 이르면 요청을 차단하는 방법이고 재시도 예산은 재시도를 할 수 있는 예산을 가지고 그만큼만 재시도하는 방식입니다.

재시도를 개선해 나가면서 각 단계의 시뮬레이션 결과와 동료들과 논의한 가상 스토리가 있어서 언뜻 쉬워보이는 재시도의 복잡성을 쉽게 이해할 수 있습니다.

https://medium.com/yandex/good-retry-bad-retry-an-incident-story-648072d3cee6