17강 / 20강

트래픽 제어 — 몰려드는 요청을 다스리기

토큰 버킷 · 슬라이딩 윈도우 · 그리고 봇 막기

11강에서 큐를 배웠습니다. 하지만 큐도 한계가 있어요. 유입이 처리보다 계속 빠르면 큐는 결국 터집니다.

그럴 때 필요한 것이 유입 자체를 제한하는 것 — 속도 제한(rate limiting)입니다.

"타임세일 시작 3초 만에 서버가 멈췄습니다. 알고 보니 매크로 봇 한 대가 초당 2,000번씩 요청하고 있었어요."

이런 일은 실제로 매우 자주 일어납니다.

고등학생몰려드는 요청을 다스리기

11강에서 큐를 배웠습니다. 그런데 큐도 한계가 있어요.

줄이 너무 길어지면 줄 서는 것도 소용없다

왜 그런가

1시간 기다려야 하는 줄에 서면? 기다리다 포기합니다. 그럴 거면 처음부터 "오늘은 안 됩니다" 라고 하는 게 나아요.

방법	결과
무한정 받는다	전부 느려진다 · 서버가 죽는다
일부를 거절한다	받은 것은 제대로 처리된다

전부 살리려다 전부 죽는 것보다 낫다

비유 — 놀이공원 입장 제한

사람이 너무 많으면 입장을 막습니다. 들어온 사람이 놀이기구를 탈 수 있게 하려고요.

다 들여보내면 아무도 못 탑니다. 줄만 서다 끝나죠.

거절이 서비스를 지키는 방법일 수 있다

그리고 봇 문제도 있습니다

사람이 아니라 프로그램이 초당 수천 번 요청하면? 정상 손님이 밀려납니다.

그래서 "한 사람당 초당 몇 번" 을 정합니다. 그게 속도 제한이에요.

고등학생왜 거절이 필요한가

note 를 조금 더 봅시다. 거절의 논리예요.

받을 수 있는 양보다 더 받으면 전부 나빠진다

숫자로 보면

서버가 초당 1,000건을 처리할 수 있다고 합시다.

들어오는 양	처리	대기
800	800	0 — 정상
1,000	1,000	0 — 아슬아슬
1,200	1,000	초당 200씩 쌓인다

조금만 넘쳐도 대기가 무한히 쌓인다

1분이면 12,000건이 밀립니다. 그 뒤에 온 손님은 12초를 기다려야 해요.

그리고 악순환이 시작됩니다

느려진다
손님이 새로고침을 누른다
요청이 더 늘어난다
더 느려진다

느려지면 요청이 더 오는 것이 무섭다

그래서 일찍 거절합니다

1,200건이 들어오면 200건을 즉시 거절합니다. 그러면 1,000건은 정상 속도로 처리돼요.

일부를 포기해서 나머지를 지킨다

병원 응급실의 트리아지와 같은 발상입니다. 자원이 모자랄 때 어디에 쓸지 정하는 것이죠.

① 고정 윈도우 — 가장 단순하지만 허점이 있다

"1분에 60번까지" — 매 분이 시작되면 카운터를 0으로 되돌립니다.

고정 윈도우의 경계 문제. 실무에서 실제로 겪는 함정입니다.

Python 브라우저에서 실행

# 고정 윈도우의 허점 — 경계에서 2배가 통과합니다
제한 = 60          # 1분에 60번

요청시각 = (
    [59.0 + i * 0.01 for i in range(60)]      # 0분 59초에 60번
    + [60.1 + i * 0.01 for i in range(60)]    # 1분 00초에 또 60번
)

통과 = 0
카운터 = {}
for t in 요청시각:
    창 = int(t // 60)                          # 어느 '분'인지
    카운터[창] = 카운터.get(창, 0) + 1
    if 카운터[창] <= 제한:
        통과 += 1

print(f"제한: 1분에 {제한}번")
print(f"통과: {통과}번")
print()
print("🚨 59초~61초, 즉 2초 사이에 120번이 통과했습니다!")
print("   '1분에 60번' 제한인데 사실상 초당 60번을 허용한 셈이에요.")

② 토큰 버킷 — 실무의 표준

양동이에 일정한 속도로 토큰이 떨어집니다. 요청이 오면 토큰 하나를 씁니다. 토큰이 없으면 거절.

💧

보충

초당 10개씩 채워짐

🪣

양동이

최대 50개까지 저장

🎫

사용

요청 1건 = 토큰 1개

양동이 크기가 순간적인 몰림을 얼마나 봐줄지를 정합니다(burst). 보충 속도가 평균 허용 속도고요. 이 두 숫자만 정하면 끝입니다.

순간 몰림은 받아 주고, 지속적인 과부하는 막는다 — 토큰 버킷의 장점입니다.

Python 브라우저에서 실행

import time

class 토큰버킷:
    def __init__(self, 초당보충, 최대):
        self.rate = 초당보충
        self.max = 최대
        self.토큰 = float(최대)
        self.최근 = 0.0

    def 허용(self, 현재시각):
        경과 = 현재시각 - self.최근
        self.최근 = 현재시각
        self.토큰 = min(self.max, self.토큰 + 경과 * self.rate)   # 보충
        if self.토큰 >= 1:
            self.토큰 -= 1
            return True
        return False

버킷 = 토큰버킷(초당보충=5, 최대=10)

print("t(초)  요청  결과      남은 토큰")
시각 = 0.0
for i in range(20):
    시각 += 0.1                       # 초당 10번씩 요청 (허용치의 2배)
    ok = 버킷.허용(시각)
    print(f"{시각:>4.1f}   #{i+1:<3} {'✅ 통과' if ok else '🚫 거절'}   {버킷.토큰:>5.1f}")

print()
print("💡 처음엔 저장된 토큰 덕에 몰림을 받아 주다가, 바닥나면 초당 5번으로 수렴합니다.")

🎮 토큰 버킷 시뮬레이터

보충 속도와 양동이 크기를 조절해 보세요. 정상 사용자와 봇을 동시에 흘려보내면서 봇은 막히고 정상 사용자는 통과하는 설정을 찾아 보세요.

무엇을 기준으로 제한할까

기준	장점	약점
IP 주소	로그인 전에도 적용 가능	회사·학교는 여러 명이 한 IP를 공유 (억울한 차단)
회원 ID	정확함	비로그인 요청에는 못 씀
API 키	외부 연동에 딱 맞음	내부 사용자엔 부적합
엔드포인트별	비싼 API만 강하게 제한 가능	설정이 복잡해짐

실무에서는 여러 개를 겹쳐서 씁니다 — "IP당 초당 20회 그리고 회원당 분당 300회 그리고 결제 API는 분당 5회".

고등학생거절할 때의 예의

note 가 재미있는 이야기를 합니다. 거절도 잘해야 한다고요.

거절할 거면 빨리 · 분명히 · 언제 다시 오라고

나쁜 거절

방식	왜 나쁜가
그냥 끊는다	왜 안 되는지 모른다 → 계속 재시도
느리게 거절한다	거절하는 데도 자원을 쓴다
500 오류	서버 문제로 보인다 → 재시도

좋은 거절

요소	설명
429 상태 코드	"요청이 너무 많음" — 뜻이 분명
Retry-After	"30초 뒤에 오세요"
즉시 응답	거절은 싸야 한다

언제 오라고 알려 주면 재시도가 몰리지 않는다

왜 중요한가

다 같이 30초 뒤에 오면 그때 또 몰립니다. 그래서 조금씩 다르게 알려 줘요.

재시도 시각을 흩뜨리는 것 — 지터(jitter)

비유 — 식당 대기

안내	결과
"기다리세요"	사람들이 문 앞에 몰린다
"30분 뒤 오세요" + 번호표	흩어졌다가 순서대로 온다

거절도 설계다 — 어떻게 거절하느냐가 시스템을 지킨다

제한 말고 다른 방법들

대기열 페이지 — 거절 대신 "앞에 3,241명 대기 중"을 보여 줍니다. 티켓 예매 사이트가 쓰는 방식이에요. 11강의 큐를 사람에게 보여 주는 것.
캐시 — 16강. 같은 요청이라면 애초에 서버까지 오지 않게 합니다.
서킷 브레이커 — 뒷단이 죽었으면 요청을 보내지 않고 즉시 실패시킵니다. 죽은 서버를 계속 두드려 봐야 회복만 늦어져요.
우아한 성능 저하 — 추천 목록 계산이 느리면 추천만 빼고 페이지를 보여 줍니다. 전체가 죽는 것보다 훨씬 낫습니다.

고등학생토큰 버킷 — 여유를 허용하는 법

속도 제한에도 방식이 여럿입니다. 가장 널리 쓰는 것이 토큰 버킷이에요.

양동이에 토큰이 일정 속도로 찬다 — 요청은 토큰을 쓴다

동작

양동이 크기가 10개, 초당 2개씩 찬다
요청이 오면 토큰 1개를 쓴다
토큰이 없으면 거절

평소엔 초당 2번, 몰아 쓰면 한 번에 10번까지

왜 이게 좋은가

사람은 고르게 요청하지 않습니다. 가만있다가 한꺼번에 여러 번 누르죠.

방식	몰아 쓰기
엄격한 초당 2회	거절 — 불편하다
토큰 버킷	허용 (모아 둔 토큰으로)

평균은 지키되 순간의 여유는 준다

비유 — 휴대폰 데이터

한 달에 10GB 를 씁니다. 하루에 333MB 씩만 쓰라고 하면 불편하죠.

안 쓴 날의 몫을 모아 뒀다가 필요할 때 몰아 쓰는 게 자연스럽습니다.

토큰 버킷이 그 발상이다

양동이 크기가 정책입니다

크기	성격
작다	엄격 — 몰아 쓰기 불가
크다	관대 — 하지만 한꺼번에 부하가 올 수 있다

또 그 맞바꿈 — 편의와 보호 사이

🤔 확인 문제

"1분에 60회" 고정 윈도우 제한의 대표적인 허점은?

🤔 확인 문제

토큰 버킷에서 양동이 크기가 정하는 것은?

🤔 확인 문제

요청을 제한해 거절할 때 함께 내려 줘야 할 것은?