rate limiting을 어디에 어떻게 구성하나요?

Question

Accepted Answer

rate limiting은 클라이언트가 시간 창 안에서 할 수 있는 요청 수를 제한합니다. 각 계층이 서로 다른 것을 보기 때문에 **여러 계층**에 적용하고, **남용자를 식별하는 무엇이든**으로 key를 잡습니다.

## 어디에 구성하나

- **Edge / CDN** — 트래픽이 당신에게 닿기 전 첫 번째 방어선. 시행 비용이 가장 저렴하지만(공격자가 origin에 닿지 않음) 거칠고, 보통 IP로 key를 잡습니다.
- **Reverse proxy** (nginx, Envoy) — CDN을 통과한 flood로부터 origin을 보호하며, zone과 burst를 세밀하게 제어합니다.
- **애플리케이션 계층** — 가장 똑똑한 계층: **user, API key, token**을 알기 때문에 계정별 할당량을 적용하고 proxy가 볼 수 없는 비싼 업무 작업을 보호할 수 있습니다.

## key와 형태를 잡는 방법

- **key 기준** IP(익명), API key(파트너), 또는 인증된 user(계정별 공정성).
- **token bucket vs leaky bucket** — token bucket은 토큰을 모아 짧은 **burst**를 허용한 뒤 안정화되고, leaky bucket은 일정한 속도로 평탄화합니다. 대부분의 API는 정당한 burst가 벌받지 않도록 token bucket을 원합니다.
- **baseline + headroom에서 한도 선택** — 클라이언트별 정상 피크를 측정한 뒤, 실제 사용자가 결코 닿지 않도록 그보다 넉넉히 높게 상한을 설정합니다.
- **`429 Too Many Requests`를 `Retry-After`와 함께 반환** — 클라이언트가 계속 두드리는 대신 정중하게 물러나도록.

## 예시: nginx limit_req

```nginx
# 클라이언트 IP로 key를 잡는 공유 메모리 zone 정의.
# rate=10r/s = 안정적인 토큰 재충전 속도 (token bucket).
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        # burst=20: 대기열에 쌓이는 20개 요청의 짧은 스파이크 허용
        # nodelay: 간격을 두지 않고 burst를 즉시 처리
        limit_req zone=api burst=20 nodelay;

# 기본 503이 아닌 429를 반환해 클라이언트가 rate-limit 신호를 보게 함
        limit_req_status 429;

proxy_pass http://backend;
    }
}
```

여기서 각 IP는 초당 10요청으로 재충전되고, 최대 20까지 burst할 수 있으며, 그 이상은 `429`를 받습니다.

## 왜 중요한가

rate limiting은 Layer 7 flood, credential stuffing, 폭주하는 scraper에 대한 가장 저렴한 상시 방어입니다. 이를 계층화하고(볼륨은 edge, origin은 proxy, 업무 로직은 app) 올바르게 key를 잡으면 남용자는 막히고 실제 사용자와 정당한 burst는 손상 없이 통과합니다. 실제 baseline에서 한도를 설정하는 것이 이것이 스스로 만든 장애가 되지 않게 합니다.