Jitter: 재시도에 무작위성을 더하는 이유

Context

retry 로직 설계 관련 AWS 아키텍처 블로그를 읽다가 jitter 개념을 제대로 이해하게 됐다.

What I Learned

Exponential Backoff만으로는 부족하다

실패 후 대기 시간을 지수적으로 늘리는 exponential backoff는 좋은 전략이지만, 클라이언트가 여럿이면 문제가 생긴다. 모두 같은 공식으로 대기하면 시간이 지난 뒤 동시에 다시 몰려서 요청이 집중된다. N개 클라이언트 경합 시 작업량이 N²에 비례하게 되는 것.

Jitter란

재시도 대기 시간에 무작위성을 추가해서 요청을 시간에 분산시키는 기법이다. 반직관적으로 들리지만, 의도적인 무작위성이 전체 시스템 부하를 낮춘다.

3가지 Jitter 전략

Full Jitter — 가장 효율적, 대기 시간이 0에 가까울 수 있음

sleep = random(0, min(cap, base * 2^attempt))

Equal Jitter — 최소 대기 시간 보장

sleep = base * 2^attempt / 2 + random(0, base * 2^attempt / 2)

Decorrelated Jitter — 직전 대기 시간 기반으로 계산

sleep = min(cap, random(base, sleep * 3))

결과

Full Jitter와 Decorrelated Jitter가 가장 우수. Jitter 없는 exponential backoff 대비 작업량 50% 이상 감소.

Note

retry 로직을 짤 때 backoff만 넣고 끝내지 말 것. 클라이언트가 여럿이면 jitter 없이는 thundering herd 문제가 그대로 남는다. 실용적으로는 Full Jitter가 간단하고 효과적이다.