Rate Limit Backpressure
3줄 요약
- Rate Limit은 사용자를 괴롭히는 제한이 아니라 시스템이 감당 가능한 속도 안에서 핵심 기능을 보호하는 장치다.
- Backpressure는 처리 능력을 넘는 유입을 무조건 받아 queue에 쌓지 않고, 늦추거나 거절하거나 우선순위를 낮추는 설계 판단이다.
- 좋은 제한 정책은
누구를, 어떤 API에서, 어떤 기준으로, 얼마나, 어떤 응답으로 제한할지와 그 지표를 함께 정한다.
핵심 정리
- Rate Limit은 남용 방지, 비용 보호, downstream 보호, 공정성, 장애 확산 방지를 위해 둔다.
- 제한 기준은 IP, userId, API key, tenant, endpoint, device, internal job처럼 업무 비용과 책임 단위에 맞춰 골라야 한다.
- Token Bucket은 짧은 burst를 허용하면서 평균 속도를 제한한다. 이벤트 오픈, 검색, public API처럼 순간 유입을 어느 정도 받아야 할 때 유용하다.
- Sliding Window는 최근 기간 사용량을 더 정확히 본다. 로그인, 결제, 쿠폰 발급처럼 경계 시간 악용을 줄여야 할 때 유리하다.
- Backpressure는 queue depth, oldest message age, worker 처리량, downstream 오류율을 보고 producer 제한, consumer 조정, degraded mode, 429를 결정한다.
- 429는 단순 실패 응답이 아니라 클라이언트가 언제 다시 시도해야 하는지 알려주는 계약이다.
Retry-After, 남은 quota, reset 시점, idempotency 안내가 필요할 수 있다.
- 제한 정책은 성능을 보호하지만 정상 사용자 차단, UX 저하, 정책 우회, 운영 복잡도 증가를 만든다.
헷갈리는 지점
- Rate Limit을 보안 기능으로만 생각하기 쉽다. 실제로는 DB, queue, 외부 API, 비용 예산을 보호하는 용도도 크다.
- 핵심은 제한 대상이 공격자인지, 비싼 정상 사용자이지, downstream 병목인지 먼저 구분하는 것이다.
- 429를 많이 줄수록 안정적이라고 생각하기 쉽다. 과한 제한은 핵심 전환율과 신뢰를 떨어뜨릴 수 있다.
- 핵심은 보호할 자원과 포기할 요청을 명시하고, 제한율을 사용자 영향 지표와 함께 보는 것이다.
- Queue를 크게 만들면 backpressure가 필요 없다고 생각하기 쉽다. 큰 queue는 장애를 늦게 보이게 만들고 오래된 작업을 쌓는다.
- 핵심은 queue depth뿐 아니라 oldest age와 처리 완료 시간을 함께 보는 것이다.
- 모든 API에 같은 limit을 적용하기 쉽다. API마다 비용, 위험, 사용자 기대가 다르다.
- 핵심은 로그인, 검색, 결제, export, 내부 batch가 서로 다른 제한 단위를 가져야 한다는 점이다.
확인 질문
- 확인 질문: Rate Limit이 바꾸는 설계 축은 무엇인가?
- 답변: 성능과 장애 격리를 보호하지만 정상 요청 거절, 공정성 판단, 정책 운영이라는 복잡도를 만든다.
- 확인 질문: Backpressure를 queue depth만 보고 판단하면 부족한 이유는 무엇인가?
- 답변: queue가 짧아도 oldest age가 길거나 downstream 오류가 커질 수 있고, queue가 길어도 처리 가능한 backlog일 수 있기 때문이다.
- 확인 질문: 429 응답에
Retry-After가 필요한 이유는 무엇인가?
- 답변: 클라이언트가 즉시 재시도하면 제한이 부하 증폭으로 바뀌므로 재시도 시점과 행동을 계약으로 알려야 한다.