Redis로 rate limiting을 어떻게 구현하나요?

Question

Accepted Answer

**Rate limiting**(시간 창 내에 허용되는 요청/동작 수 제한)은 흔한 Redis 사용 사례입니다 — Redis의 빠른 원자적 카운터와 TTL이 이상적으로 만듭니다. 여러 알고리즘(fixed window, sliding window, token bucket)이 있으며 각각 트레이드오프가 있습니다.

## fixed window (가장 단순)

```js
// TTL이 있는 원자적 카운터로 시간 창당 N 요청 허용
async function rateLimit(userId, limit = 100, windowSec = 60) {
  const key = `rate:${userId}:${Math.floor(Date.now() / 1000 / windowSec)}`;
  const count = await redis.incr(key);     // 원자적 증가
  if (count === 1) await redis.expire(key, windowSec);  // 첫 요청에 TTL 설정
  return count <= limit;                    // 한계 이하면 허용
}
// → INCR은 원자적(동시성에서 올바름); 키는 매 창마다 자동 만료
```

**fixed window** 방식: (사용자, 시간 창)당 TTL이 있는 원자적 카운터 — 요청마다 증가, 한계 초과 시 거부. 원자적 `INCR`과 자동 만료를 활용한 간단하고 효율적인 방법입니다.

```text
✗ 제한: 창 경계의 버스트 (인접한 두 창에 걸쳐 한계의 2배 가능)
```

## sliding window (더 부드러움)

```text
SLIDING WINDOW → 롤링 시간 구간에 걸쳐 요청 추적 (경계 버스트 없음)
  → 종종 SORTED SET 사용: 각 요청을 타임스탬프 점수로 추가,
    오래된 항목 제거(ZREMRANGEBYSCORE), 남은 것 카운트(ZCARD)
  ✓ 더 정확/부드러움  ✗ 더 많은 메모리와 복잡성
```

## token bucket (제어된 버스트 허용)

```text
TOKEN BUCKET → 토큰이 일정 속도로 충전; 각 요청이 토큰 하나 소비
  → 평균 속도를 제한하면서 버스트 허용 (버킷 크기까지)
  → 원자적 check-and-consume을 위해 종종 Lua SCRIPT로 구현
```

## Redis가 이에 이상적인 이유

```text
✓ 원자적 카운터 (INCR) → 동시성에서 올바름, race condition 없음
✓ 빠름 (인메모리) → 각 요청에 최소 지연 추가
✓ TTL → 자동 창 정리 (수동 만료 관리 불필요)
✓ 서버 간 공유 → 분산 rate limiting (모든 앱 서버가 하나의 Redis 사용)
→ Redis는 분산 rate limiting의 표준 도구입니다.
```

## 왜 중요한가

Redis로 rate limiting을 구현하는 것은 흔하고 실무적인 사용 사례이므로, 이를 이해하는 것은 가치 있는 지식입니다 — rate limiting(API와 서비스를 남용으로부터 보호, 공정한 사용 보장, 과부하 방지)은 거의 보편적인 요구이고 Redis가 그 표준 도구입니다.

**Redis가 이상적인 이유**를 이해하는 것이 핵심입니다: **원자적 카운터**(`INCR`)가 rate 카운팅을 동시성에서 올바르게(race condition/손실된 카운트 없이) 만들고, **속도**(인메모리)가 각 요청에 최소 지연을 추가하며, **TTL**이 창 정리를 자동 처리하고, 결정적으로 **서버 간 공유**되어 — 모든 애플리케이션 서버가 하나의 일관된 한계를 강제하는 **분산 rate limiting**을 가능하게 합니다(다중 서버 배포에서 필수적이며, 서버별 인메모리 한계는 동작하지 않음).

**알고리즘**과 그 트레이드오프를 이해하면 적절히 선택할 수 있습니다: **fixed window**(가장 단순 — 시간 창당 TTL이 있는 원자적 카운터이지만 경계 버스트 허용), **sliding window**(타임스탬프가 찍힌 요청의 sorted set을 써서 더 부드럽고 정확하나 메모리 비용 높음), **token bucket**(평균 속도를 제한하면서 제어된 버스트 허용, 원자성을 위해 종종 Lua 스크립트로).

이를 구현하는 방법(특히 `INCR` + `EXPIRE`의 간단하고 흔한 fixed-window 패턴)을 아는 것은 실용적이고 적용 가능한 기술입니다.

rate limiting은 서비스 보호를 위한 흔한 요구이고, Redis(원자적 카운터, 속도, TTL, 서버 간 공유)가 분산 rate limiting의 표준적이고 이상적인 도구이므로, Redis로 이를 구현하는 방법 — 알고리즘, 트레이드오프, Redis가 잘 맞는 이유 — 을 이해하는 것은 견고하고 보호된 서비스를 만드는 데 가치 있고 자주 적용 가능한 지식이며, caching을 넘어선 가장 흔한 실무적 Redis 응용 중 하나입니다.