API 속도 제한 (Rate Limiting) 전략: 토큰 버킷, 리키 버킷, 그리고 슬라이딩 윈도우

속도 제한 (Rate limiting)은 API를 남용으로부터 보호하고, 공정한 사용을 보장하며, 시스템 안정성을 유지하는 데 필수적입니다. 선택하는 알고리즘은 정확도, 메모리 사용량, 그리고 버스트 (Burst) 동작에 영향을 미칩니다. 옵션들을 이해하면 사용 사례에 맞는 적절한 알고리즘을 선택하는 데 도움이 됩니다.

토큰 버킷 (Token bucket) 알고리즘은 가장 인기 있는 선택지입니다. 일정한 속도로 토큰이 채워지는 버킷을 유지합니다. 각 요청은 토큰 하나를 소비합니다. 버킷이 비어 있으면 요청은 거부됩니다. 축적된 토큰이 있는 한 버스트 (Burst) 요청을 처리할 수 있습니다. 이를 통해 장기적인 평균 속도를 강제하면서도 자연스러운 버스트를 허용할 수 있습니다. 토큰 버킷은 구현이 쉽고 대부분의 API에서 잘 작동합니다.

리키 버킷 (Leaky bucket) 알고리즘은 요청을 일정한 속도로 처리함으로써 버스트를 완화합니다. 들어오는 요청은 고정된 속도로 누수되는 버킷을 채웁니다. 버킷이 넘치면 초과된 요청은 거부되거나 대기열에 추가됩니다. 이는 매우 일관된 요청 흐름을 생성하지만, 서버가 처리할 수 있는 상황이라 하더라도 버스트 발생 시 요청을 거부할 수 있습니다. 리키 버킷은 버스트를 처리할 수 없는 다운스트림 시스템 (Downstream systems)을 보호해야 할 때 이상적입니다.

슬라이딩 윈도우 (Sliding window) 알고리즘은 이동하는 시간 창 (Time window) 내의 요청을 추적합니다. 가장 단순한 버전은 시간 버킷 (Time bucket)당 카운터를 유지하고 이전 버킷에 가중치를 두어 슬라이딩 윈도우를 근사화합니다. 더 정확한 구현은 클라이언트당 요청 타임스탬프 (Timestamp)의 정렬된 집합 (Sorted set)을 유지합니다. 슬라이딩 윈도우는 토큰 버킷보다 메모리 집약적이지만 요청 속도에 대해 정밀한 제어를 제공합니다.

Redis는 분산 속도 제한 (Distributed rate limiting)을 위한 표준 백엔드입니다. 간단한 카운터에는 TTL과 함께 INCR를 사용하고, 슬라이딩 윈도우에는 ZREMRANGEBYSCORE와 함께 정렬된 집합 (Sorted sets)을 사용하십시오. 매우 높은 처리량 (Throughput)을 가진 시스템의 경우, 동기화된 구성 업데이트를 포함한 로컬 속도 제한을 고려하거나 rate-limiter-flexible와 같은 라이브러리를 사용하십시오.

표준 속도 제한 헤더(rate limit headers)를 반환하십시오: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset. 이를 통해 클라이언트는 제한에 걸리지 않고 요청 속도(request rate)를 조절할 수 있습니다. 클라이언트가 제한을 초과하면 Retry-After 헤더와 함께 429 Too Many Requests 응답을 반환하십시오.

부하 상황(load)에서 속도 제한을 테스트하십시오. 동일한 클라이언트로부터 오는 동시 요청(concurrent requests)에 대해 제한이 올바르게 적용되는지 확인하십시오. Redis가 다운되었을 때의 동작을 테스트하십시오. 속도 제한기(rate limiter)는 보안 요구 사항에 따라 'fail open'(제한 없이 허용) 또는 'fail closed'(모두 차단) 방식으로 동작해야 합니다.

Rizwan Saleem | https://rizwansaleem.co