레이트 리미팅 (Rate Limiting)
쉽게 풀면
놀이공원 인기 놀이기구에서 "1인당 한 시간에 3번까지만 탈 수 있습니다"라는 규칙을 정한다고 해봅시다. 이렇게 해야 한 사람이 계속 줄을 서서 독차지하는 일 없이, 모두가 골고루 이용할 수 있고 대기줄도 감당할 수 있는 수준으로 유지됩니다.
레이트 리미팅도 같은 원리로, 서버가 "이 사용자(또는 이 IP, 이 API 키)는 1분에 요청을 100번까지만 받아준다"처럼 상한선을 정해둡니다. 정해진 횟수를 넘어서면 서버는 추가 요청을 거절하거나 잠시 기다리게 합니다.
이렇게 하면 특정 사용자가 실수로, 혹은 악의적으로 요청을 폭주시키더라도 서버 전체가 느려지거나 멈추는 것을 막을 수 있습니다.
왜 중요한가
레이트 리미팅은 시스템의 가용성과 공정성을 동시에 지키는 기본 방어 수단이기 때문에, 분산시스템·클라우드 인프라·보안 연구에서 빠지지 않고 다뤄집니다. 서비스 거부 공격 방어뿐 아니라 여러 사용자가 유한한 서버 자원을 나눠 쓰는 멀티테넌트 환경에서 자원을 공평하게 배분하는 기법으로도 연구되며, API 경제가 커지면서 과금 정책과 결합된 레이트 리미팅 설계도 활발히 논의되는 주제입니다.
어떤 절차인가
- 제한 단위를 정합니다: 사용자, IP, API 키, 엔드포인트별로 “시간당 요청 수”를 정합니다.
- 알고리즘을 고릅니다. 고정 윈도우는 구간마다 개수를 세고, 슬라이딩 윈도우는 직전 일정 시간을 계속 세며, 토큰 버킷은 일정 속도로 토큰을 채우고 요청마다 소모합니다. 리키 버킷은 요청을 대기열에 넣고 일정 속도로 내보냅니다(Turner, 1986의 leaky bucket이 원형).
- 초과하면 거절(HTTP 429 Too Many Requests, RFC 6585), 지연, 대기열 처리 중 하나를 합니다. 보통 남은 횟수나 재시도 시간을 응답 헤더로 알립니다.
- 분산 환경에서는 카운터를 여러 서버가 공유할 저장소가 필요합니다.
언제 쓰고 무엇을 얻나
API 남용 방지, 서버 보호, 사용자 간 공정한 자원 배분, 과금 정책에 씁니다. 로드 밸런싱은 요청을 서버들에 고르게 나누는 것이고 레이트 리미팅은 요청량 자체를 제한하는 것입니다.
알고리즘마다 순간 폭주(버스트)를 다루는 방식이 다릅니다. (가상의 예) “10초에 5건” 제한을 가정하고 코드로 시뮬레이션했습니다.
- 고정 윈도우: 요청이 9.0, 9.2, 9.4, 9.6, 9.8초에 5건, 10.0, 10.2, …, 10.8초에 5건 들어오면 창이 10초에서 바뀌므로 10건 모두 허용됩니다. 1.8초 안에 한도의 2배가 통과합니다.
- 토큰 버킷(용량 5, 초당 1개 충전): t = 0초에 8건이 한꺼번에 오면 5건 허용, 3건 거절(429)되고, 이후 1초에 1건씩 허용됩니다. 평균 속도는 제한하되 용량만큼의 버스트는 허용합니다.
한계: 한 IP당 제한은 많은 IP로 나뉜 분산 공격(DDoS)을 혼자서 막지 못합니다. 공유 IP(회사, 학교)에서는 정상 사용자가 함께 제한될 수 있습니다.
논문에는 이렇게 적는다
- 제한의 단위(키)와 한도, 윈도우 길이, 알고리즘 이름을 적습니다.
- 초과 시 동작(거절/지연)과 응답 코드, 재시도 안내를 적습니다.
- 평가는 허용된 요청 비율, 거절률, 지연, 공정성 지표(사용자 간 처리량 차이), 정상 사용자 오차단율을 보고합니다.
- 분산 구현이면 카운터 저장 방식과 정확도·지연의 절충을 설명합니다.
논문에서는 이렇게 쓰입니다
실제 논문에서
이 용어를 직접 쓴 국내 논문 문장을 아직 수집하지 못했습니다. 수집되는 대로 출처와 함께 싣겠습니다.
예시 문장
아래는 용어의 쓰임을 보여 주려고 만든 예시로, 실제 논문에서 가져온 문장이 아닙니다.
이 문장은 사용자마다 초당 보낼 수 있는 요청 수에 상한을 두는 방식으로, 트래픽이 갑자기 몰려도 서버가 견딜 수 있게 설계했다는 뜻입니다.
멀티테넌트 클라우드 환경에서 자원을 공평하게 나누기 위한 격리 수단으로 레이트 리미팅을 사용했다는 뜻입니다.
클라이언트 쪽에서 서버의 레이트 리미팅에 대응해 요청 재시도 방식을 어떻게 설계했는지 설명할 때 쓰이는 표현입니다.
조금 더 깊게 보면
레이트 리미팅을 구현하는 대표적인 알고리즘으로는 토큰 버킷(token bucket), 리키 버킷(leaky bucket), 고정 윈도우(fixed window), 슬라이딩 윈도우(sliding window) 방식 등이 있으며, 각각 순간적인 트래픽 폭주(버스트)를 얼마나 허용하는지, 제한을 얼마나 매끄럽게 적용하는지에서 차이가 있습니다. 분산 환경에서는 여러 서버 인스턴스가 요청 카운트를 공유해야 하므로, 이를 위해 별도의 저장소나 조정 메커니즘을 두는 것이 일반적입니다.
주의할 점
레이트 리미팅은 대량의 요청을 보내 서버를 마비시키는 분산서비스거부공격을 막는 데도 쓰이지만, 정상적인 사용자의 요청까지 지나치게 자주 막으면 서비스 이용에 불편을 줄 수 있습니다. 그래서 실제 서비스에서는 사용자 등급이나 상황에 따라 제한 기준을 다르게 두는 경우가 많으며, 여러 서버로 요청을 고르게 분배하는 로드밸런싱과는 목적이 다르다는 점(트래픽 분산 vs. 요청량 자체를 제한)을 구분해야 합니다.
헷갈리기 쉬운 용어
| 용어 | 한 줄 설명 | 구별 포인트 |
|---|---|---|
| 레이트 리미팅 | 요청량 상한을 두는 정책 | 서버 보호·공정성 |
| 로드 밸런싱 | 요청을 서버들에 나눔 | 총량 제한이 아님 |
| API 게이트웨이 | 요청 진입 관문 | 레이트 리미팅을 구현하는 위치가 되곤 함 |
| 토큰 버킷 | 레이트 리미팅의 알고리즘 하나 | 버스트를 용량만큼 허용 |
참고 문헌
- Turner, J. S. (1986). New directions in communications (or which way to the information age?). IEEE Communications Magazine, 24(10), 8–15.
- Tanenbaum, A. S., & Wetherall, D. J. (2011). Computer Networks (5th ed.). Pearson.
- Nottingham, M., & Fielding, R. (2012). Additional HTTP Status Codes (RFC 6585). Internet Engineering Task Force.
표의 기준값은 위 문헌에 근거한 관례이며, 분야·학술지마다 다른 기준을 쓸 수 있습니다.