API 레이트 리밋: 알고리즘, 구현, 그리고 그 뒤의 전략적 사고

Source: Dev.to

인터넷에 노출하는 모든 API는 결국 남용당하게 됩니다—자동 스크래퍼, 자격 증명 채우기 봇, 오작동하는 통합, 혹은 너무 빠르게 반복되는 루프를 가진 선의의 클라이언트까지도 말이죠. 속도 제한이 없으면, 단 한 명의 악의적인 사용자가 서버 자원을 모두 소모시켜 다른 모든 사용자의 경험을 저하시킬 수 있습니다.

Rate Limiting이 해결하는 위협

• 리소스 보호 – 단일 클라이언트가 CPU, 메모리, 데이터베이스 연결 또는 대역폭을 과도하게 차지하는 것을 방지합니다.
• 비용 제어 – 제한이 없는 클라이언트는 몇 분 만에 큰 비용을 발생시킬 수 있습니다(예: AI 추론 API, SMS 제공업체, 결제 처리업체).
• 남용 방지 – 크리덴셜 스터핑 및 열거 공격은 대량 요청에 의존하므로, 레이트 리밋은 공격자의 비용을 증가시킵니다.
• 공정한 접근 – 멀티‑테넌트 시스템에서 레이트 리밋은 한 테넌트의 급증이 다른 모든 사용자의 경험을 저하시키는 것을 방지합니다.

Common Algorithms

Fixed Window

• 클라이언트별로 고정된 시간 간격 내 요청 수를 카운트합니다.
• Redis 구현: INCR 하나와 EXPIRE 하나로 처리합니다.
• Weakness: 경계 문제 — 클라이언트가 한 윈도우의 끝에서 최대치를 보내고, 다음 윈도우 시작에서도 다시 최대치를 보내면 일시적으로 전송 속도가 두 배가 됩니다.

Sliding Window Log

• 윈도우 안의 모든 요청 타임스탬프를 추적하여 경계 문제를 없앱니다.
• Drawback: 메모리 사용량이 많습니다 (예: 1,000 요청/분 × 10,000 클라이언트 = 1,000만 개 타임스탬프).
• 로그인이나 비밀번호 재설정과 같이 트래픽은 적지만 가치가 높은 엔드포인트에 적합합니다.

Sliding Window Counter (recommended default)

• 현재 고정 윈도우와 이전 고정 윈도우의 카운터를 유지한 뒤, 현재 윈도우가 진행된 비율에 따라 가중치를 적용해 총합을 계산합니다.
• 정확도, 메모리 효율성, 구현 단순성 사이에서 좋은 균형을 제공합니다.

Token Bucket

• 레이트 리밋을 일정한 속도로 채워지는 버킷 모델로 표현합니다.
• 두 가지 파라미터: refill rate (지속 가능한 처리량)와 bucket capacity (버스트 허용량).
• 대부분의 클라우드 제공업체에서 사용되며, 단계별 요금 모델과 자연스럽게 매핑됩니다.

계층형 속도 제한

1. Edge / Load Balancer (Nginx, Cloudflare, AWS API Gateway) – 애플리케이션 서버에 도달하기 전에 과도한 트래픽으로부터 보호합니다.
2. API Gateway or Middleware – 인증된 사용자, API 키, 구독 등급 또는 엔드포인트별로 비즈니스 수준 제한을 적용합니다.
3. Individual Services – 마이크로서비스 아키텍처에서, 오작동하는 업스트림 서비스가 다운스트림 종속성을 압도하는 것을 방지합니다.

각 계층은 서로 다른 장애 모드를 완화하며, 단일 방어선에만 의존하지 마세요.

Transparency to Clients

• 모든 응답에 rate‑limit 헤더 포함:
  • X-RateLimit-Limit – 허용된 최대 요청 수.
  • X-RateLimit-Remaining – 현재 윈도우에 남은 요청 수.
  • X-RateLimit-Reset – 윈도우가 리셋되는 시점(epoch 시간).
• 429 Too Many Requests 응답 시, 클라이언트가 재시도할 수 있는 시점을 나타내는 Retry-After 헤더 추가.
• 이렇게 하면 rate limiting이 거친 도구가 아니라 API와 소비자 간의 협업 메커니즘이 됩니다.

실용적인 권장 사항

• 기본 알고리즘: Sliding Window Counter – 메모리 오버헤드가 최소이면서 거의 정확한 결과를 제공하며, 전체 로그를 유지하는 복잡성을 피할 수 있습니다.
• 클라이언트를 식별할 때는 IP 주소가 아니라 API 키를 사용하세요. 공유 기업 프록시와 봇넷을 통한 요청이 늘어나면서 IP 기반 제한은 점점 신뢰성이 떨어지고 있습니다.
• 레이트 리밋은 기술적인 요소뿐 아니라 제품적인 결정이기도 합니다: 티어 제한을 정의하고, 429를 반환할 시점과 부드러운 다운그레이드 방식을 결정하며, 사용자 경험 기대치에 맞게 버스트 용량을 설정하세요.

Read the full article at for complete algorithm implementations, Redis code examples, and a guide to designing rate‑limit tiers for subscription‑based APIs.

원래 NovVista에 게시되었습니다.