무료 체험 시작로그인

용어집

속도 제한(Rate Limiting)이란 무엇인가요?

속도 제한은 서버 측 방어 기법으로, 특정 시간 창 내에서 단일 클라이언트(IP, 계정, 세션으로 식별됨)가 만들 수 있는 요청 수를 제한하며, 인프라를 보호하고, 남용을 방지하며, 공정한 리소스 사용을 보장하는 데 사용됩니다.

웹사이트와 API가 대용량 클라이언트를 어떻게 제한하는지, 속도 제한의 알고리즘(토큰 버킷, 슬라이딩 윈도우, 고정 윈도우)은 무엇인지, 그리고 로테이팅 프록시가 IP별 상한을 어떻게 무력화하는지 이해합니다.

설명

속도 제한은 서버가 남용으로부터 스스로를 보호하는 방식입니다. 모든 공개 API와 웹사이트는 단일 클라이언트가 특정 시간 창 내에 보낼 수 있는 요청 수를 제한합니다 — `100 requests per IP per minute`, `5000 requests per API key per hour`, `30 logins per account per day`. 클라이언트가 한도를 초과하면 서버는 429 Too Many Requests 응답을 반환하거나(경우에 따라 응답을 조용히 지연시키거나, 요청을 대기열에 넣거나, CAPTCHA를 제공하기 시작합니다).

스크래핑 및 데이터 수집 워크로드의 경우, 속도 제한은 얼마나 빠르게 진행할 수 있는지를 결정하는 운영상의 하한선입니다. 단순한 해결책인 요청 수를 줄이는 방식은 처리량을 제한합니다. 진짜 해결책은 요청을 여러 식별자(IP, 계정, 세션 ID)에 분산시켜 단일 식별자가 한도를 초과하지 않도록 하는 것입니다. 이것이 바로 레지덴셜 프록시가 하나의 제품 카테고리로 존재하는 전체 이유입니다.

서버 측 속도 제한 알고리즘에는 몇 가지 형태가 있습니다. 토큰 버킷(Token bucket)은 클라이언트가 한도까지 일정한 속도로 토큰을 축적하도록 하여 한도 크기까지 버스트를 허용합니다. 슬라이딩 윈도우(Sliding window)는 이동하는 시간 창 내에서 요청을 세어 한도를 완만하게 만듭니다. 고정 윈도우(Fixed window)는 시계 경계(분당, 시간당)에서 카운트를 재설정합니다. 각 방식은 스크레이퍼가 요청 속도를 조절하는 방법에 서로 다른 영향을 미칩니다.

작동 방식

서버는 들어오는 모든 요청에서 클라이언트를 식별합니다(IP, API 키, 계정 ID 또는 세션 토큰 기준) 그리고 현재 윈도우에서 해당 식별자에 대한 카운터를 확인합니다. 카운터가 한도 이하이면 요청이 통과되고 카운터가 증가합니다. 카운터가 한도를 초과하면 서버는 대기해야 하는 시간을 나타내는 `Retry-After` 헤더와 함께 429를 반환합니다.

대부분의 대형 API는 여러 식별자를 조합해 사용합니다. 동일한 IP와 계정이 서로 다른 한도를 가진 다른 카운터에 걸릴 수 있습니다. 예를 들어 Cloudflare의 rate-limit 규칙은 IP, URL 경로, 세션 또는 이들의 조합으로 한도 범위를 지정할 수 있습니다. 일부 고급 시스템은 더 매끄러운 제어를 위해 leaky-bucket이나 sliding-window-counter 방식을 사용합니다.

타입

토큰 버킷

버킷은 상한선까지 일정한 속도로 토큰을 채웁니다. 각 요청은 토큰 하나를 소비합니다. 버킷 크기만큼의 버스트를 허용하며, 시간에 따라 완화됩니다. 최신 API 속도 제한에서 가장 일반적인 알고리즘입니다.

리키 버킷

요청은 고정된 속도로 배출되는 큐(버킷)에 들어갑니다. 초과 요청은 넘쳐서 거부됩니다. 토큰 버킷보다 더 엄격하게 버스트를 완화합니다.

고정 윈도우

카운터는 시계 경계(매분, 매시간)마다 재설정됩니다. 구현은 간단하지만 윈도우 경계에서 버스트 문제가 있습니다(클라이언트가 두 윈도우에 걸쳐 요청을 보내면 한도의 2배를 보낼 수 있습니다).

슬라이딩 윈도우

카운터는 별개의 윈도우가 아니라 최근 N초를 살펴봅니다. 고정 윈도우보다 부드러운 집행 방식입니다. 슬라이딩 윈도우 로그와 슬라이딩 윈도우 카운터가 일반적인 변형입니다.

적응형 / 행동 기반 속도 제한

제한은 요청 패턴과 위험 점수에 따라 조정됩니다. Cloudflare, Datadome 같은 안티봇 벤더가 사용하며, 트래픽이 얼마나 '실제처럼' 보이는지에 따라 동일한 클라이언트가 분당 1000회 요청을 허용받을 수도 있고 10회만 허용받을 수도 있습니다.

일반적인 사용 사례

공개 API를 남용으로부터 보호
크리덴셜 스터핑 공격 방지(로그인 속도 제한)
규모에 따른 인프라 비용 관리
고객 전반에 걸친 공정 사용 등급 시행
스크레이퍼 및 콘텐츠 악용 지연시키기
장애 시 재시도 폭주 속도 제한
자주 묻는 질문

자주 묻는 질문

다음에 대한 일반적인 질문 속도 제한.

요청을 여러 IP에 분산시킴으로써입니다. 대상이 IP당 분당 60개 요청으로 속도를 제한하고, 10,000개의 레지덴셜 IP 풀을 통해 요청마다 로테이션한다면, 이론적으로는 단일 IP가 한도를 초과하지 않고도 대상에 대해 분당 600,000개의 요청을 보낼 수 있습니다. 실제로는 행동 신호도 중요하지만, IP 로테이션이 기본 기술입니다.

HTTP 429 'Too Many Requests'는 클라이언트가 요청 제한을 초과했음을 나타냅니다. 응답에는 보통 재시도 전 대기 시간을 나타내는 `Retry-After` 헤더가 포함됩니다. 정상적으로 동작하는 클라이언트는 Retry-After를 준수하지만, 더 높은 처리량이 필요한 스크래퍼는 새 IP로 전환하여 즉시 재시도합니다.

제한적으로만 가능합니다. 한도 아래로 요청 속도를 조절하고 하나의 IP를 천천히 재사용하는 방식입니다. 실질적인 규모의 사용 사례라면 로테이팅 프록시가 필요합니다. 레지덴셜 IP 풀 없이 IP당 요율 제한을 무력화할 만큼 충분한 독립 IP를 구매하는 경제성은 소규모 작업이 아니면 실용적이지 않습니다.

응답 헤더를 읽으세요. 많은 API가 `X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset` 헤더를 전송하여 한도, 남은 여유분, 윈도우가 재설정되는 시점을 알려줍니다. 그렇지 않은 사이트의 경우, 응답 코드(401, 429, 503)를 관찰하고 이런 코드가 나타나기 시작하면 속도를 늦추세요.

속도 제한은 요청 양을 조절하고, CAPTCHA는 클라이언트가 사람임을 증명하도록 도전 과제를 제시합니다. 대부분의 안티봇 스택은 두 가지를 결합합니다. 속도 제한 이하에서는 요청이 통과되고, 한도를 초과하면 완전 차단 대신 CAPTCHA 도전 과제를 받습니다. 두 방식 모두 서로 다른 각도에서 동일한 위협으로부터 보호합니다.

예. Shifter의 레지덴셜 프록시 게이트웨이는 대규모 IP 풀에 걸쳐 요청을 분산시키므로 IP당 속도 제한이 전체 볼륨의 일부에만 적용됩니다. 세션당 현실적인 페이싱과 최신 브라우저 핑거프린트를 결합하면 대부분의 속도 제한 벽이 사실상 보이지 않게 됩니다.