2025년 10월 30일한국어

API 보호 및 트래픽 관리를 위한 Python 속도 제한 기술을 탐구하고, 토큰 버킷과 슬라이딩 윈도우 알고리즘을 비교합니다.

Python 속도 제한: 토큰 버킷 vs. 슬라이딩 윈도우 - 종합 가이드

오늘날 상호 연결된 세상에서 견고한 API는 애플리케이션 성공에 필수적입니다. 그러나 통제되지 않은 API 액세스는 서버 과부하, 서비스 저하, 심지어 서비스 거부(DoS) 공격으로 이어질 수 있습니다. 속도 제한은 특정 시간 내에 사용자 또는 서비스가 보낼 수 있는 요청 수를 제한하여 API를 보호하는 중요한 기술입니다. 이 글에서는 Python에서 널리 사용되는 두 가지 속도 제한 알고리즘인 토큰 버킷(Token Bucket)과 슬라이딩 윈도우(Sliding Window)를 심층적으로 다루고, 포괄적인 비교와 실제 구현 예시를 제공합니다.

속도 제한이 중요한 이유

속도 제한은 다음과 같은 수많은 이점을 제공합니다:

악용 방지: 악성 사용자나 봇이 과도한 요청으로 서버를 압도하는 것을 제한합니다.
공정한 사용 보장: 사용자에게 리소스를 공정하게 분배하여 단일 사용자가 시스템을 독점하는 것을 방지합니다.
인프라 보호: 서버와 데이터베이스가 과부하로 인해 충돌하는 것을 방지합니다.
비용 제어: 예상치 못한 리소스 사용량 급증을 방지하여 비용 절감 효과를 가져옵니다.
성능 향상: 리소스 고갈을 방지하고 일관된 응답 시간을 보장하여 안정적인 성능을 유지합니다.

속도 제한 알고리즘 이해

여러 속도 제한 알고리즘이 존재하며, 각기 장단점을 가지고 있습니다. 이 글에서는 가장 일반적으로 사용되는 두 가지 알고리즘인 토큰 버킷과 슬라이딩 윈도우에 초점을 맞출 것입니다.

1. 토큰 버킷 알고리즘

토큰 버킷 알고리즘은 간단하고 널리 사용되는 속도 제한 기술입니다. 토큰을 담는 "버킷"을 유지하여 작동합니다. 각 토큰은 하나의 요청을 보낼 수 있는 권한을 나타냅니다. 버킷은 최대 용량을 가지며, 토큰은 고정된 속도로 버킷에 추가됩니다.

요청이 도착하면 속도 제한기는 버킷에 충분한 토큰이 있는지 확인합니다. 토큰이 충분하면 요청이 허용되고, 해당 개수의 토큰이 버킷에서 제거됩니다. 버킷이 비어 있으면 충분한 토큰이 사용 가능해질 때까지 요청이 거부되거나 지연됩니다.

Python에서의 토큰 버킷 구현

다음은 threading 모듈을 사용하여 동시성을 관리하는 토큰 버킷 알고리즘의 기본적인 Python 구현입니다:


import time
import threading

class TokenBucket:
    def __init__(self, capacity, fill_rate):
        self.capacity = float(capacity)
        self._tokens = float(capacity)
        self.fill_rate = float(fill_rate)
        self.last_refill = time.monotonic()
        self.lock = threading.Lock()

    def _refill(self):
        now = time.monotonic()
        delta = now - self.last_refill
        tokens_to_add = delta * self.fill_rate
        self._tokens = min(self.capacity, self._tokens + tokens_to_add)
        self.last_refill = now

    def consume(self, tokens):
        with self.lock:
            self._refill()
            if self._tokens >= tokens:
                self._tokens -= tokens
                return True
            return False

# 예시 사용법
bucket = TokenBucket(capacity=10, fill_rate=2)  # 토큰 10개, 초당 2개 토큰으로 채워짐

for i in range(15):
    if bucket.consume(1):
        print(f"요청 {i+1}: 허용됨")
    else:
        print(f"요청 {i+1}: 속도 제한됨")
    time.sleep(0.2)

설명:

TokenBucket(capacity, fill_rate): 최대 용량과 채우기 속도(초당 토큰 수)로 버킷을 초기화합니다.
_refill(): 마지막 채우기 이후 경과된 시간을 기준으로 버킷을 토큰으로 채웁니다.
consume(tokens): 지정된 수의 토큰을 소비하려고 시도합니다. 성공하면 (요청 허용) True를 반환하고, 그렇지 않으면 (요청 속도 제한) False를 반환합니다.
스레딩 락: 동시성 환경에서 스레드 안전성을 보장하기 위해 스레딩 락(self.lock)을 사용합니다.

토큰 버킷의 장점

구현 용이성: 이해하고 구현하기 비교적 간단합니다.
버스트 처리: 버킷에 충분한 토큰이 있는 한, 가끔 발생하는 트래픽 버스트를 처리할 수 있습니다.
구성 가능: 용량과 채우기 속도는 특정 요구 사항에 맞춰 쉽게 조정할 수 있습니다.

토큰 버킷의 단점

완벽한 정확성 부족: 재충전 메커니즘으로 인해 구성된 속도보다 약간 더 많은 요청을 허용할 수 있습니다.
매개변수 튜닝: 원하는 속도 제한 동작을 달성하려면 용량과 채우기 속도를 신중하게 선택해야 합니다.

2. 슬라이딩 윈도우 알고리즘

슬라이딩 윈도우 알고리즘은 시간을 고정된 크기의 윈도우로 나누는 보다 정확한 속도 제한 기술입니다. 각 윈도우 내에서 이루어진 요청 수를 추적합니다. 새 요청이 도착하면 알고리즘은 현재 윈도우 내의 요청 수가 제한을 초과하는지 확인합니다. 초과하면 요청은 거부되거나 지연됩니다.

"슬라이딩"이라는 측면은 새 요청이 도착함에 따라 윈도우가 시간상으로 앞으로 이동한다는 사실에서 비롯됩니다. 현재 윈도우가 끝나면 새 윈도우가 시작되고 카운터는 재설정됩니다. 슬라이딩 윈도우 알고리즘에는 두 가지 주요 변형이 있습니다: 슬라이딩 로그(Sliding Log)와 고정 윈도우 카운터(Fixed Window Counter).

2.1. 슬라이딩 로그

슬라이딩 로그 알고리즘은 특정 시간 윈도우 내에서 이루어진 모든 요청의 타임스탬프가 찍힌 로그를 유지합니다. 새 요청이 들어오면 윈도우 내에 속하는 로그의 모든 요청을 합산하여 속도 제한과 비교합니다. 이 방식은 정확하지만, 메모리 및 처리 능력 측면에서 비용이 많이 들 수 있습니다.

2.2. 고정 윈도우 카운터

고정 윈도우 카운터 알고리즘은 시간을 고정된 윈도우로 나누고 각 윈도우에 대한 카운터를 유지합니다. 새 요청이 도착하면 알고리즘은 현재 윈도우에 대한 카운터를 증가시킵니다. 카운터가 제한을 초과하면 요청은 거부됩니다. 이 방식은 슬라이딩 로그보다 간단하지만, 두 윈도우의 경계에서 요청 버스트를 허용할 수 있습니다.

Python에서의 슬라이딩 윈도우 구현 (고정 윈도우 카운터)

다음은 고정 윈도우 카운터 방식을 사용하는 슬라이딩 윈도우 알고리즘의 Python 구현입니다:


import time
import threading

class SlidingWindowCounter:
    def __init__(self, window_size, max_requests):
        self.window_size = window_size  # 초
        self.max_requests = max_requests
        self.request_counts = {}
        self.lock = threading.Lock()

    def is_allowed(self, client_id):
        with self.lock:
            current_time = int(time.time())
            window_start = current_time - self.window_size

            # 오래된 요청 정리
            self.request_counts = {ts: count for ts, count in self.request_counts.items() if ts > window_start}

            total_requests = sum(self.request_counts.values())

            if total_requests < self.max_requests:
                self.request_counts[current_time] = self.request_counts.get(current_time, 0) + 1
                return True
            else:
                return False


# 예시 사용법
window_size = 60  # 60초
max_requests = 10  # 분당 10개 요청
rate_limiter = SlidingWindowCounter(window_size, max_requests)

client_id = "user123"

for i in range(15):
    if rate_limiter.is_allowed(client_id):
        print(f"요청 {i+1}: 허용됨")
    else:
        print(f"요청 {i+1}: 속도 제한됨")
    time.sleep(5)

설명:

SlidingWindowCounter(window_size, max_requests): 윈도우 크기(초 단위)와 윈도우 내에서 허용되는 최대 요청 수를 초기화합니다.
is_allowed(client_id): 클라이언트가 요청을 보낼 수 있는지 확인합니다. 윈도우 밖의 오래된 요청을 정리하고, 남아있는 요청을 합산하며, 제한이 초과되지 않은 경우 현재 윈도우의 카운트를 증가시킵니다.
self.request_counts: 요청 타임스탬프와 그 카운트를 저장하는 딕셔너리로, 오래된 요청을 집계하고 정리할 수 있습니다.
스레딩 락: 동시성 환경에서 스레드 안전성을 보장하기 위해 스레딩 락(self.lock)을 사용합니다.

슬라이딩 윈도우의 장점

더 높은 정확성: 특히 슬라이딩 로그 구현의 경우 토큰 버킷보다 더 정확한 속도 제한을 제공합니다.
경계 버스트 방지: 두 시간 윈도우 경계에서 버스트 발생 가능성을 줄입니다 (슬라이딩 로그에서 더 효과적).

슬라이딩 윈도우의 단점

더 복잡함: 토큰 버킷에 비해 구현하고 이해하기 더 복잡합니다.
더 높은 오버헤드: 요청 로그를 저장하고 처리해야 하므로 특히 슬라이딩 로그 구현에서 오버헤드가 더 높을 수 있습니다.

토큰 버킷 vs. 슬라이딩 윈도우: 상세 비교

다음은 토큰 버킷과 슬라이딩 윈도우 알고리즘 간의 주요 차이점을 요약한 표입니다:

특징	토큰 버킷	슬라이딩 윈도우
복잡성	더 간단함	더 복잡함
정확성	덜 정확함	더 정확함
버스트 처리	좋음	좋음 (특히 슬라이딩 로그)
오버헤드	더 낮음	더 높음 (특히 슬라이딩 로그)
구현 노력	더 쉬움	더 어려움

올바른 알고리즘 선택

토큰 버킷과 슬라이딩 윈도우 중 어떤 것을 선택할지는 특정 요구 사항과 우선순위에 따라 달라집니다. 다음 요소를 고려하십시오:

정확성: 매우 정확한 속도 제한이 필요한 경우, 슬라이딩 윈도우 알고리즘이 일반적으로 선호됩니다.
복잡성: 단순성이 우선이라면, 토큰 버킷 알고리즘이 좋은 선택입니다.
성능: 성능이 중요하다면, 슬라이딩 윈도우 알고리즘, 특히 슬라이딩 로그 구현의 오버헤드를 신중하게 고려하십시오.
버스트 처리: 두 알고리즘 모두 트래픽 버스트를 처리할 수 있지만, 슬라이딩 윈도우(슬라이딩 로그)는 버스트 상황에서 더 일관된 속도 제한을 제공합니다.
확장성: 고도로 확장 가능한 시스템의 경우, 분산 속도 제한 기술(아래에서 논의됨) 사용을 고려하십시오.

많은 경우에 토큰 버킷 알고리즘은 비교적 낮은 구현 비용으로 충분한 수준의 속도 제한을 제공합니다. 그러나 더 정확한 속도 제한이 필요하고 증가된 복잡성을 감수할 수 있는 애플리케이션의 경우, 슬라이딩 윈도우 알고리즘이 더 나은 선택입니다.

분산 속도 제한

여러 서버가 요청을 처리하는 분산 시스템에서는 모든 서버에 걸쳐 일관된 속도 제한을 보장하기 위해 중앙 집중식 속도 제한 메커니즘이 종종 필요합니다. 분산 속도 제한에는 여러 접근 방식이 사용될 수 있습니다:

중앙 집중식 데이터 저장소: Redis 또는 Memcached와 같은 중앙 집중식 데이터 저장소를 사용하여 속도 제한 상태(예: 토큰 수 또는 요청 로그)를 저장합니다. 모든 서버는 공유 데이터 저장소에 액세스하고 업데이트하여 속도 제한을 적용합니다.
로드 밸런서 속도 제한: IP 주소, 사용자 ID 또는 기타 기준에 따라 속도 제한을 수행하도록 로드 밸런서를 구성합니다. 이 접근 방식은 애플리케이션 서버에서 속도 제한 작업을 오프로드할 수 있습니다.
전용 속도 제한 서비스: 모든 속도 제한 요청을 처리하는 전용 속도 제한 서비스를 생성합니다. 이 서비스는 독립적으로 확장하고 성능에 최적화될 수 있습니다.
클라이언트 측 속도 제한: 주요 방어책은 아니지만, HTTP 헤더(예: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset)를 통해 클라이언트에게 속도 제한을 알려줍니다. 이는 클라이언트가 자체적으로 스로틀링하고 불필요한 요청을 줄이도록 장려할 수 있습니다.

다음은 분산 속도 제한을 위해 Redis와 토큰 버킷 알고리즘을 사용하는 예시입니다:


import redis
import time

class RedisTokenBucket:
    def __init__(self, redis_client, bucket_key, capacity, fill_rate):
        self.redis_client = redis_client
        self.bucket_key = bucket_key
        self.capacity = capacity
        self.fill_rate = fill_rate

    def consume(self, tokens):
        now = time.time()
        capacity = self.capacity
        fill_rate = self.fill_rate

        # Redis에서 토큰 버킷을 원자적으로 업데이트하기 위한 Lua 스크립트
        script = '''
        local bucket_key = KEYS[1]
        local capacity = tonumber(ARGV[1])
        local fill_rate = tonumber(ARGV[2])
        local tokens_to_consume = tonumber(ARGV[3])
        local now = tonumber(ARGV[4])

        local last_refill = redis.call('get', bucket_key .. ':last_refill')
        if not last_refill then
            last_refill = now
            redis.call('set', bucket_key .. ':last_refill', now)
        else
            last_refill = tonumber(last_refill)
        end

        local tokens = redis.call('get', bucket_key .. ':tokens')
        if not tokens then
            tokens = capacity
            redis.call('set', bucket_key .. ':tokens', capacity)
        else
            tokens = tonumber(tokens)
        end

        -- 버킷 채우기
        local time_since_last_refill = now - last_refill
        local tokens_to_add = time_since_last_refill * fill_rate
        tokens = math.min(capacity, tokens + tokens_to_add)

        -- 토큰 소비
        if tokens >= tokens_to_consume then
            tokens = tokens - tokens_to_consume
            redis.call('set', bucket_key .. ':tokens', tokens)
            redis.call('set', bucket_key .. ':last_refill', now)
            return 1  -- 성공
        else
            return 0  -- 속도 제한됨
        end
        '''

        # Lua 스크립트 실행
        consume_script = self.redis_client.register_script(script)
        result = consume_script(keys=[self.bucket_key], args=[capacity, fill_rate, tokens, now])
        return result == 1


# 예시 사용법
redis_client = redis.StrictRedis(host='localhost', port=6379, db=0)
bucket = RedisTokenBucket(redis_client, bucket_key='my_api:user123', capacity=10, fill_rate=2)

for i in range(15):
    if bucket.consume(1):
        print(f"요청 {i+1}: 허용됨")
    else:
        print(f"요청 {i+1}: 속도 제한됨")
    time.sleep(0.2)

분산 시스템을 위한 중요한 고려 사항:

원자성: 경쟁 조건을 방지하기 위해 토큰 소비 또는 요청 카운팅 작업이 원자적으로 이루어지도록 보장합니다. Redis Lua 스크립트는 원자적 연산을 제공합니다.
지연 시간: 중앙 집중식 데이터 저장소에 액세스할 때 네트워크 지연 시간을 최소화합니다.
확장성: 예상되는 부하를 처리할 수 있도록 확장 가능한 데이터 저장소를 선택하십시오.
데이터 일관성: 분산 환경에서 발생할 수 있는 데이터 일관성 문제를 해결합니다.

속도 제한을 위한 모범 사례

속도 제한을 구현할 때 따라야 할 몇 가지 모범 사례는 다음과 같습니다:

속도 제한 요구 사항 식별: 사용 패턴 및 리소스 소비를 기반으로 다양한 API 엔드포인트 및 사용자 그룹에 대한 적절한 속도 제한을 결정합니다. 구독 수준에 따라 계층화된 액세스를 제공하는 것을 고려하십시오.
의미 있는 HTTP 상태 코드 사용: 429 Too Many Requests와 같이 속도 제한을 나타내는 적절한 HTTP 상태 코드를 반환합니다.
속도 제한 헤더 포함: API 응답에 속도 제한 헤더를 포함하여 클라이언트에게 현재 속도 제한 상태(예: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset)를 알립니다.
명확한 오류 메시지 제공: 클라이언트가 속도 제한될 때, 이유를 설명하고 문제를 해결하는 방법을 제안하는 유용한 오류 메시지를 제공합니다. 지원을 위한 연락처 정보를 제공하십시오.
점진적 성능 저하 구현: 속도 제한이 적용될 때, 요청을 완전히 차단하는 대신 저하된 서비스를 제공하는 것을 고려하십시오. 예를 들어, 캐시된 데이터를 제공하거나 기능 일부를 축소할 수 있습니다.
속도 제한 모니터링 및 분석: 속도 제한 시스템을 모니터링하여 잠재적인 문제를 식별하고 성능을 최적화합니다. 사용 패턴을 분석하여 필요에 따라 속도 제한을 조정합니다.
속도 제한 보안: 요청을 검증하고 적절한 보안 조치를 구현하여 사용자가 속도 제한을 우회하는 것을 방지합니다.
속도 제한 문서화: API 문서에 속도 제한 정책을 명확하게 문서화합니다. 클라이언트가 속도 제한을 처리하는 방법을 보여주는 예시 코드를 제공합니다.
구현 테스트: 다양한 부하 조건에서 속도 제한 구현을 철저히 테스트하여 올바르게 작동하는지 확인합니다.
지역적 차이 고려: 전역적으로 배포할 때 네트워크 지연 시간 및 사용자 행동의 지역적 차이를 고려하십시오. 지역에 따라 속도 제한을 조정해야 할 수 있습니다. 예를 들어, 인도와 같은 모바일 우선 시장은 한국과 같은 고대역폭 지역에 비해 다른 속도 제한을 요구할 수 있습니다.

실제 사례

트위터(Twitter): 트위터는 API를 남용으로부터 보호하고 공정한 사용을 보장하기 위해 속도 제한을 광범위하게 사용합니다. 그들은 속도 제한에 대한 자세한 문서를 제공하고 HTTP 헤더를 사용하여 개발자에게 속도 제한 상태를 알립니다.
깃허브(GitHub): 깃허브 또한 API 남용을 방지하고 안정성을 유지하기 위해 속도 제한을 적용합니다. 그들은 IP 기반 및 사용자 기반 속도 제한을 조합하여 사용합니다.
스트라이프(Stripe): 스트라이프는 결제 처리 API를 사기성 활동으로부터 보호하고 고객에게 안정적인 서비스를 보장하기 위해 속도 제한을 사용합니다.
전자상거래 플랫폼: 많은 전자상거래 플랫폼은 제품 정보를 스크랩하거나 플래시 세일 중 서비스 거부 공격을 시도하는 봇 공격으로부터 보호하기 위해 속도 제한을 사용합니다.
금융 기관: 금융 기관은 민감한 금융 데이터에 대한 무단 액세스를 방지하고 규제 요구 사항을 준수하기 위해 API에 속도 제한을 구현합니다.

결론

속도 제한은 API를 보호하고 애플리케이션의 안정성과 신뢰성을 보장하는 필수적인 기술입니다. 토큰 버킷과 슬라이딩 윈도우 알고리즘은 각기 장단점을 가진 두 가지 인기 있는 옵션입니다. 이러한 알고리즘을 이해하고 모범 사례를 따르면 Python 애플리케이션에서 속도 제한을 효과적으로 구현하고 더 탄력적이고 안전한 시스템을 구축할 수 있습니다. 특정 요구 사항을 고려하고, 적절한 알고리즘을 신중하게 선택하며, 구현이 요구 사항을 충족하는지 모니터링하는 것을 잊지 마십시오. 애플리케이션이 확장됨에 따라 모든 서버에서 일관된 속도 제한을 유지하기 위해 분산 속도 제한 기술을 채택하는 것을 고려하십시오. 속도 제한 헤더와 유익한 오류 메시지를 통해 API 소비자들과 명확하게 소통하는 것의 중요성을 간과하지 마십시오.