도구스개발

요청 제한(레이트 리밋) 계산기

분당 몇 회 같은 한도가 실제로 초당 몇 건인지, 고정 윈도의 경계에서 얼마나 몰릴 수 있는지 계산합니다. 토큰 버킷의 통 크기와 필요한 서버 수도 함께 봅니다.

0으로 두면 한도와 같게 봅니다. 작게 잡으면 버스트를 줄일 수 있습니다.

rps

600회 / 분

지속 10 rps

고정 윈도라면 경계에서 최대 1,200회가 몰릴 수 있습니다

지속 처리량10 req/s
고정 윈도 · 순간 최대1,200회
슬라이딩 윈도 · 순간 최대600회
토큰 버킷 · 통 크기600개
통을 다 채우는 시간1.0분
토큰 하나를 얻는 시간100.0 ms

클라이언트 100명이 모두 쓴다면

전체 지속 처리량1,000 req/s
모두가 동시에 몰아칠 때60,000회
지속 부하용 서버10대
순간 부하까지 받으려면600대

한도에 걸리면 얼마나 기다리나

곧바로 처리40회
기다려야 하는 요청60회
다 처리하는 데6.00초

세는 방식

고정 윈도만들기 쉽지만 칸의 경계에서 두 배가 몰릴 수 있습니다.
슬라이딩 윈도어느 순간을 잘라도 한도를 넘지 않습니다. 요청 시각을 기억해야 합니다.
토큰 버킷버스트를 얼마나 허용할지 따로 정할 수 있습니다.
같은 한도라도 세는 방식에 따라 순간 부하가 두 배 다릅니다. 고정 윈도는 칸을 나눠 세기 때문에, 앞 칸의 끝에 600회를 보내고 뒤 칸이 시작하자마자 다시 600회를 보낼 수 있습니다. 서버는 그 순간 1,200회를 견뎌야 합니다. 슬라이딩 윈도는 지금부터 거꾸로 세기 때문에 이 문제가 없습니다.
토큰 버킷은 버스트를 따로 정할 수 있습니다. 채우는 속도가 지속 처리량이고 통 크기가 허용하는 버스트입니다. 통을 작게 잡으면 평균은 그대로 두면서 순간 몰림만 줄일 수 있어, 필요한 서버 수가 크게 내려갑니다 — 지금 설정에서 통을 20개로 줄이면 순간 부하용 서버가 20대면 됩니다.
클라이언트가 모두 동시에 몰아치는 경우는 흔치 않지만, 장애가 나서 여러 클라이언트가 한꺼번에 재시도할 때는 실제로 일어납니다. 그래서 재시도에 지수 백오프와 무작위 지연(지터)을 넣어 몰림을 흩뜨립니다.

사용 방법

  1. 1한도와 기간을 넣습니다. “분당 600회”라면 600과 분당을 고릅니다.
  2. 2세는 방식에 따라 순간 최대가 얼마나 달라지는지 확인합니다.
  3. 3클라이언트 수와 서버 처리량을 넣으면 필요한 서버 대수가 나옵니다.

자주 묻는 질문

평균으로는 초당 10건이지만, 세는 방식에 따라 순간 부하가 다릅니다. 고정 윈도라면 앞 칸 끝에 600회, 뒤 칸 시작에 다시 600회를 보낼 수 있어 짧은 순간에 1,200회가 몰릴 수 있습니다.

시계를 정해진 칸으로 나눠 세기 때문에 생깁니다. 분당 한도라면 00:59.9에 한도만큼, 01:00.0에 다시 한도만큼 보낼 수 있어 0.2초 사이에 두 배가 들어옵니다. 만들기는 가장 쉽지만 서버가 그 순간을 견뎌야 합니다.

지금부터 거꾸로 정해진 시간만큼을 늘 세기 때문에 어느 순간을 잘라도 한도를 넘지 않습니다. 대신 요청 시각을 기억해야 해서 메모리를 더 씁니다. 근사 방식으로 앞뒤 칸을 비율로 섞어 세는 구현도 많이 씁니다.

통에 토큰을 일정 속도로 채우고 요청마다 하나씩 꺼내 씁니다. 통이 비면 거절합니다. 채우는 속도가 지속 처리량이고 통 크기가 허용하는 버스트라, 두 가지를 따로 정할 수 있는 것이 장점입니다. 평소 조용하다가 가끔 몰아치는 클라이언트를 막지 않으면서 평균은 지키게 할 수 있습니다.

평균 처리량은 그대로 두면서 순간 몰림만 줄일 수 있습니다. 클라이언트가 많을수록 효과가 큰데, 모두가 동시에 통을 비우는 최악의 경우가 그만큼 작아져 필요한 서버 대수가 크게 내려갑니다.

장애가 나서 여러 클라이언트가 한꺼번에 재시도할 때 일어납니다. 그래서 재시도에 지수 백오프와 무작위 지연(지터)을 넣어 몰림을 흩뜨립니다. 지터 없이 정확한 간격으로 재시도하면 오히려 몰림이 반복됩니다.

알아두면 좋은 점

  • 순간 부하용 서버 대수는 버스트가 1초 안에 몰린다고 보고 잡은 값입니다. 실제로는 큐와 백프레셔로 완화합니다.
  • 분산 환경에서는 여러 서버가 카운터를 나눠 갖게 되어 한도가 정확히 지켜지지 않을 수 있습니다. 중앙 저장소나 근사 알고리즘이 필요합니다.

함께 보면 좋은 도구

마지막 검증: 2026년 8월 30일 · 결과는 참고용 추정치입니다.