요청이 한꺼번에 몰릴 때 어떻게 막는가?

먼저 무엇을 보호할지 정한다. 사용자별 사용량을 고르게 나누려면 rate limit을 둔다. 서버의 CPU·메모리·스레드·커넥션을 지키려면 동시 처리 수와 대기열 길이를 제한한다.

토큰 버킷은 평소 남은 토큰으로 짧은 급증을 허용한다. 요청이 계속 몰리면 토큰이 채워지는 속도까지만 통과한다. 호출자·API·비용 등 어떤 단위로 토큰을 나눌지도 정책의 일부다.

rate limit만으로 서버 과부하를 막았다고 볼 수는 없다. 느린 요청 100개가 오래 붙잡혀 있으면 초당 요청 수가 낮아도 자원은 바닥난다. 실제 동시 요청 수, 대기열, CPU와 지연을 보고 진입을 줄여야 한다.

대기열을 무한히 늘리면 이미 응답 기한이 지난 요청까지 자원을 먹는다. 값싼 경로에서 먼저 거절하고 우선순위가 높은 작업을 남긴다. 더 싼 응답이나 캐시로 낮출 수 있다면 부하 완화도 함께 쓴다.

호출자가 정해진 할당량을 넘겼다면 429가 맞다. 서비스 자체가 감당하지 못하는 과부하는 503으로 구분할 수 있다. 재시도를 허용할 때는 Retry-After, 지수 백오프와 jitter를 함께 안내해 다시 한꺼번에 몰리지 않게 한다.

한도는 추측으로 고정하지 않는다. 부하 시험으로 어느 자원이 먼저 한계에 닿는지 확인한다. 거절률·대기 시간·처리 중 요청 수를 보며 조정하고 제한 경로도 정기적으로 시험한다.