API의 평균 요청률과 순간 버스트를 제한할 때 고정 윈도우와 토큰 버킷을 어떻게 선택하나요?

고정 윈도우는 예를 들어 1분마다 카운터를 초기화해 구간당 최대 요청 수를 제한하는 단순한 방식입니다. 그러나 12:00:59에 한도만큼 보내고 12:01:00에 다시 한도만큼 보내면 실제 2초 안에 두 구간의 요청이 몰릴 수 있습니다. 토큰 버킷은 일정 속도로 토큰을 채우고 버킷 크기만큼 쌓아 두므로, 장기 평균은 제한하면서 허용한 크기의 짧은 버스트를 수용합니다.

따라서 사용자가 순간적으로 여러 API를 호출해도 되는 일반 서비스 API에는 토큰 버킷이 더 자연스러울 수 있고, 엄격한 시간 구간 사용량이나 과금 정산에는 슬라이딩 윈도우나 고정 구간 집계가 더 설명하기 쉬울 수 있습니다. 요청마다 비용이 다르면 요청 수가 아니라 비용만큼 토큰을 차감해야 합니다. 동시성 제한이 필요한 작업은 속도 제한만으로 충분하지 않아 별도의 동시 실행 상한도 둡니다.

분산 환경에서는 사용자·IP·테넌트·API 키 중 어떤 키를 기준으로 할지 정하고, 모든 인스턴스가 한도를 공유해야 하는지 결정합니다. 공유 저장소는 전역 정확도를 높이지만 매 요청의 왕복과 저장소 장애를 추가합니다. 로컬 예산을 인스턴스별로 나누면 지연은 줄지만 인스턴스 수와 재배치에 따라 총 허용량이 변할 수 있습니다. 로그인 남용처럼 보안상 엄격해야 하는 제한과 일반 사용자의 과금 한도는 장애 시 fail-open/fail-closed 정책도 다를 수 있습니다.

거절 응답에는 재시도 시점이나 Retry-After를 넣고, 클라이언트가 지수 백오프를 사용하게 하겠습니다. 테스트는 윈도우 경계, 버스트, 키 편중, 인스턴스 증감, 저장소 장애에서 실제 허용량과 재시도 폭주를 확인합니다.

버스트와 동시성을 분리합니다

토큰 버킷에서 충전률은 지속 허용률이고 버킷 크기는 허용할 순간 burst입니다. 화면 초기화처럼 짧은 몰림은 받아 주되, 버킷이 너무 크면 DB에 동시에 큰 부하가 들어옵니다. 고정 윈도우는 구현이 쉽지만 경계에 두 구간이 겹치고, 슬라이딩 윈도우는 균일하지만 저장·계산 비용이 늘어납니다. 요청별 비용이 다르면 비용만큼 토큰을 차감하고, 처리 중 작업 수는 별도 동시성·큐 제한으로 둡니다.

분산 한도와 오탐을 계산합니다

IP만으로 로그인 제한을 걸면 공유 NAT 사용자가 함께 막힐 수 있고, 계정만 보면 공격자가 계정을 바꿀 수 있습니다. IP·계정·기기 신호의 역할을 나누고, 전역 한도는 원자적 공유 저장소 비용과 장애 정책을 함께 봅니다. 로컬 한도는 빠르지만 인스턴스 증감으로 총 허용량이 바뀝니다. Retry-After와 백오프를 제공하고, 윈도우 경계·저장소 장애·인스턴스 재배치에서 허용량·오탐·재시도율을 측정해 보안 API와 일반 API의 fail-open/closed를 다르게 정하겠습니다.

구체적인 경계 사례

충전률 r=10토큰/초, 용량 B=20인 버킷이 가득 차 있으면 순간 20건을 허용할 수 있습니다. 이후 1초 동안 추가 충전되는 10토큰도 쓸 수 있으므로 임의 길이 t 구간의 허용량 상한은 초기 상태를 포함해 대략 B+r·t입니다. 한 요청의 비용이 B보다 크면 토큰이 아무리 충전돼도 통과하지 못하므로 별도 요청 분할·거절 계약이 필요합니다.

구현은 현재 토큰에 경과 시간×충전률을 더하되 B로 제한하고, 충분한 경우에만 비용을 빼는 검사와 갱신을 원자적으로 수행합니다. 시간은 권위 계산 지점의 단조 시계나 명확한 저장소 시각을 쓰고 여러 서버 시계를 직접 섞지 않습니다. 제한 상태가 eviction되거나 프로세스가 재시작해 매번 가득 찬 버킷을 받는 경우도 허용량 시험에 포함하겠습니다.