API Gateway Rate Limiting

요청이 Gateway에 도착하면 API Key, 사용자, IP, 라우트 등에 맞는 제한 정책을 찾습니다. 가용 토큰이 있으면 요청 하나당 토큰 하나를 원자적으로 차감한 뒤 허용된 요청만 백엔드로 전달합니다.

• 정책 한도: 시각화의 10 req/s는 예시 정책이며 실제 값은 서비스 요구사항에 따라 다릅니다.
• 가용 토큰: 입장 팔찌는 물리적인 클럽 수용 인원이 아니라 지금 허용할 수 있는 요청량을 뜻합니다.
• 정상 전달: 토큰을 받은 요청은 백엔드에서 처리되고 성공 응답을 받습니다.

요청 유입 속도가 높아지면 저장된 토큰이 빠르게 줄어듭니다. Token Bucket은 미리 모아 둔 토큰만큼 짧은 버스트를 허용하지만, Arrival Rate가 Refill Rate보다 계속 높으면 결국 0에 도달합니다.

• 한도 아래: 현재 요청률이 정책 한도보다 낮으면 요청은 계속 허용됩니다.
• 버스트 허용: 저장된 토큰이 순간적인 요청 증가를 흡수합니다.
• 빠른 소진: 유입이 충전보다 빠르면 가용 토큰은 감소합니다.

사용량이 정책 한도에 도달하고 버킷이 비면 Gateway는 새로운 요청을 더 이상 통과시키지 않습니다. 이미 Gateway를 지난 요청은 취소되지 않고 백엔드에서 정상 처리됩니다.

• 새 요청 차단 준비: 이후 도착한 요청부터 토큰 유무에 따라 즉시 허용 또는 거절을 결정합니다.
• 기존 요청 유지: 한도 도달 전에 전달된 요청은 정상적으로 완료됩니다.

토큰이 없는 Request #11은 Gateway에서 HTTP 429 Too Many Requests를 받습니다. 일반적인 Token Bucket Rate Limiter는 초과 요청을 반드시 대기열에 쌓지 않고 빠르게 거절할 수 있습니다.

• 로컬 응답: 백엔드 호출 없이 Gateway가 직접 429를 반환합니다.
• 재시도 안내: Retry-After는 클라이언트가 언제 다시 요청할지 판단하도록 돕습니다.
• 백엔드 보호: 거절된 요청은 내부 서비스의 CPU, 스레드, DB 커넥션을 소비하지 않습니다.

토큰은 요청이 줄었다는 이유만으로 즉시 복구되지 않습니다. 독립적인 refill clock이 정해진 속도로 토큰을 추가하고, 최대 Capacity를 넘겨 저장하지 않습니다. Request #11은 잠시 기다린 뒤 새 토큰을 소비해 정상 입장합니다.

• Refill Rate: 단위 시간마다 추가되는 토큰 수입니다.
• Capacity: 저장 가능한 최대 토큰 수이며 허용 가능한 순간 버스트 크기를 결정합니다.
• 임시 거절: 429는 영구 차단이 아니며 정책과 토큰 상태가 허용하면 재시도할 수 있습니다.

시스템 요구사항과 트래픽 특성에 따라 다양한 속도 제한 알고리즘이 채택됩니다.

• Token Bucket: 고정된 속도로 토큰을 채우고 요청마다 소비하며, 순간적인 버스트(Burst) 트래픽을 유연하게 수용할 수 있어 가장 널리 쓰입니다.
• Leaky Bucket: 큐에 요청을 담고 일정한 속도로 누수(처리)시켜 트래픽을 완벽하게 평활화(Smoothing)합니다.
• Fixed Window Counter: 고정된 시간 단위로 카운터를 증가시키며 단순하지만 경계 지점(Window Boundary)에서 2배 트래픽이 몰리는 한계가 있습니다.
• Sliding Window Log/Counter: 이전 윈도우의 가중치를 계산하여 경계 지점 급증 문제를 해결한 고정밀 알고리즘입니다.