Redis 레이트 리미터

Redis 레이트 리미터 (Rate limiter)

분산된 서비스 인스턴스 전체에서 사용자·API·테넌트별 요청 쿼터를 일관되게 강제하는 레이트 리미팅 패턴입니다. Redis를 중앙 공유 저장소로 써서 모든 인스턴스가 동일한 카운터를 보고 판단하게 합니다.

출처: 공식문서 — Redis rate limiter

언제 Redis 레이트 리미터를 쓰는가

분산된 서비스 인스턴스 전체에서 사용자·API·테넌트별 요청 쿼터를 일관되게 강제할 필요가 있을 때 사용합니다.

왜 이 문제가 어려운가

API·서비스는 트래픽 스파이크, 악성 클라이언트, 잘못 구성된 통합으로 과부하됩니다. 레이트 리밋이 없으면 다운스트림 시스템(DB, 서드파티 API, LLM 제공자, 결제 게이트웨이)이 사용 불가 상태가 되거나 무제한 비용이 발생합니다.

로컬 프로세스별 카운터는 로드 밸런서 뒤에서 깨집니다. 같은 클라이언트가 다른 인스턴스를 때리며 한도를 우회할 수 있기 때문입니다. 레이트 리미터는 요청 경로에 앉아도 의미 있는 지연을 추가하지 않을 만큼 빠른 중앙 집중 저장소가 필요합니다.

Redis 솔루션에서 기대할 수 있는 것

  • 모든 인스턴스에 걸쳐 사용자·IP·API 키·테넌트·모델별 쿼터 강제
  • 단일 Redis 배포에서 고정 창(fixed window), 슬라이딩 창(sliding window), 토큰 버킷(token bucket) 알고리즘 실행
  • 요청 경로의 게이트웨이·서비스에 동기 레이트 체크 추가
  • 의미 있는 지연을 추가하지 않고 다운스트림 시스템 보호

Redis가 이 솔루션을 어떻게 지원하는가

실제로 Redis 레이트 리미터는 모든 서비스 인스턴스가 매 요청마다 쿼리하는 단일 공유 저장소이며, 서브 밀리초 안에 허용/거부 결정을 반환합니다. 카운터는 한도를 적용하는 차원(사용자, IP, API 키, 테넌트, 모델)에 따라 스코프된 키 뒤에 있고, 시간 창은 Redis가 직접 정리합니다.

  • INCR와 EXPIRE로 자동 시간 창 정리가 되는 원자적 고정 창 카운터
  • Hashes, sorted sets, strings로 슬라이딩 창·토큰 버킷 알고리즘에 필요한 데이터 형태 커버
  • Redis 8의 해시 필드 만료(HEXPIRE)로 필드 수준의 시간 제한 레이트 리밋 단순화
  • EVAL과 함께하는 Lua 스크립팅으로 read-decide-update 사이클을 원자적으로 유지 — 동시 요청이 토큰을 이중 소비하거나 카운터 갱신을 잃지 못함
  • 서브 밀리초 대기 시간으로 초당 수백만 요청에도 동기 요청 경로에 의미 있는 지연을 추가하지 않음
  • Active-Active 복제로 지역 간에 강제되는 레이트 리밋의 CRDT 기반 전역 일관성 제공

에코시스템

더 알아보기 (Learn more)

  • 토큰 버킷 레이트 리미터를 Redis + Lua로 만드는 코드 예제: redis-py, node-redis, go-redis, Jedis, Lettuce, StackExchange.Redis, Predis, redis-rb, redis-rs — 각 라이브러리용 실행 가능한 인터랙티브 데모 제공.
  • Redis 만료·퇴출 정책 — 카운터 키의 TTL 정리와 maxmemory 퇴출.
  • Redis 해시 데이터 타입 — 필드 수준 카운터 구조.