네트워크 분단을 똑똑하게 견디기 위하여 재시도 로직을 사용합니다.
분산 시스템에서는 네트워크 요청이 언제나 실패할 수 있습니다. 네트워크 요청이 실패한다면 우리는 원하는 동작을 수행하지 못하며, 사용자에게 실패를 반환해야할 수도 있습니다. 하지만 이런 요소들은 사용자들에 대한 경험 저하로 나타날 수 있습니다.
우리의 분산 시스템은 되도록 네트워크 분단을 견디게 설계되어야하며, 실패한 요청에 대한 대비를 해야합니다. 그 방법중 하나가 바로 재시도입니다. 네트워크 요청이 실패했다면 다시 시도할 수 있습니다.
이렇게 재시도를 진행하면 사용자에게 오류를 반환하는 것 보다 더 간편하게 문제를 해결할 수 있습니다. 1번의 네트워크 실패로 인해 특정 기능이 실패하는 것 보다, 재시도를 통해 사용자 경험과 효율성 2가지의 이점이 있습니다.
하지만 이 방법에는 단점이 있습니다. 요청이 계속해서 시도된다면 네트워크 부하를 가중시키거나 크게 의미없을 가능성도 많습니다.
우리는 더 나은 재시도 방법이 필요합니다. 그 방법중 하나가 바로 Exponential Backoff입니다. 간단하면서도 꽤나 효과적인 재시도 방법입니다.
Exponential Backoff는 재시도하는 간격을 지수적으로 증가시키며 네트워크 부하를 최소화합니다. 1, 2, 4, 16처럼 간격이 늘어날 수록 더 오랜기간 기다리게됩니다. 이러한 방법은 일시적인 문제에는 빠른 해결이 되면서도, 지속적인 문제의 경우 부하를 줄여줍니다.
요청이 몰려서 서버의 요청이 실패하고, 그로인한 재시도를 진행한다면 같은 타이밍에 많은 요청이 몰리는 문제로 재시도가 장애에 영향을 줄 수도 있습니다. 이 경우 jitter를 사용해서 한순간에 몰리는 부하를 분산시킬 수 있습니다.
기본적인 Jitter는 네트워크상의 지연이 바뀐다는 의미로 사용됩니다. 이전 글에서 소개한 Phi Accrual Failure Detector가 Jitter를 사용합니다. Exponential Backoff에서는 Jitter개념을 빌려와서 사용합니다.
재시도 요청을 하는 경우 Jitter는 확률적으로(eg. 0ms~100ms) 요청을 지연시킵니다. 적용하게 된다면 요청이 한번에 몰리지않고, 점진적으로 늘어나게됩니다.
Exponential Backoff을 적용할 때 몇가지 고려해야할 사항이 있습니다.
Infinite Retry
첫번째는 재시도 횟수입니다. 시간이 지날때마다 점점 더 텀이 길어지지만, 영원히 재시도하는 것은 문제가 될 수 있습니다. 또한 구현하는 것도 쉽지않죠. 따라서 횟수를 제한하는 것이 권장됩니다. 저는 보통 5회정도로 사용합니다.
At Leaset Once
성공할때까지 계속 시도해야하는 요청에 Exponential Backoff를 적용하는 경우, 노드가 죽어도 문제없도록 고려해야합니다. 외부 시스템에 언제 재시도할지 기록하는 등의 방법으로 '적어도 한번' 처리가 되어야하는 요청에도 Exponential Backoff를 적용할 수 있습니다.
API Idenpotent
재시도를 하게 된다면 항상 API의 idenpotent를 고려해야합니다. 요청이 클라이언트에서 실패하더라고 서버에서는 처리했을 가능성이 있습니다. 따라서 idenpotent하지 않은 API를 재시도하는 경우 문제가 생실 수 있습니다.
Long Term Wait
만약 외부 서버 장애와 같은 문제들에 대응하고 싶은 경우 재시도 간격이 Exponential하게 증가하더라도 짧게 느껴질 수 있습니다. 이 경우에는 증가 폭을 변경하는 방법이 있습니다. 또한 짧은 주기와 넓은 주기를 각각 구현해서 이용하는 방법도 있습니다.
짧은 주기의 경우 재시도를 3번(1, 2, 4)까지만 진행합니다. 만약 이 과정에서도 실패한 경우 1시간, 2시간, 4시간, 16시간처럼 더 큰 범위로 점프할 수도 있습니다