핵심 요약
rate limiting은 사용자/IP/키별로 일정 시간당 요청 수를 제한한다. 고정 윈도우는 구현이 쉽지만 경계에서 2배가 몰리는 문제가 있고, 토큰 버킷이나 슬라이딩 윈도우가 더 매끄럽다. 다중 서버면 카운터를 Redis에 둬 공유한다.
1. 알고리즘 비교
| 방식 | 특징 |
|---|---|
| 고정 윈도우 | 단순, 경계에서 버스트 허용 |
| 슬라이딩 윈도우 | 경계 문제 완화 |
| 토큰 버킷 | 평균 제한+버스트 허용 조절 |
2. Redis 토큰 버킷(개념)
// 키마다 토큰 수·마지막 보충 시각 저장
// 요청 시: 경과시간만큼 토큰 보충 → 1개 차감
// 토큰 < 1 이면 429 Too Many Requests
// 원자성 위해 Lua 스크립트로 처리3. 함정
- 여러 인스턴스면 메모리 카운터는 무용 — Redis 등 공유 저장소 필수
- 제한 시
429와Retry-After헤더를 주자 - 프록시 뒤라면 진짜 클라이언트 IP(X-Forwarded-For)를 신뢰 가능한 범위에서만 사용
자주 묻는 질문
고정 윈도우의 경계 문제가 뭔가요?
윈도우 끝과 다음 윈도우 시작에 요청이 몰리면 짧은 순간 한도의 2배가 통과합니다. 슬라이딩 윈도우나 토큰 버킷이 이를 완화합니다.
왜 Redis가 필요하죠?
서버가 여러 대면 각자 메모리 카운터를 가져 제한이 무력화됩니다. Redis로 카운터를 공유해야 전체 기준으로 제한됩니다.
댓글 0