API Rate Limiting 완벽 가이드 | 알고리즘·분산 처리·HTTP 규약 실전 정리

API Rate Limiting 완벽 가이드 | 알고리즘·분산 처리·HTTP 규약 실전 정리

· 24분 읽기 · 수정 중급 가이드
API Rate Limiting 완벽 가이드 | 알고리즘·분산 처리·HTTP 규약 실전 정리

이 글의 핵심

API Rate Limiting의 필요성부터 Fixed Window·Sliding Window·Token Bucket·Leaky Bucket 알고리즘 비교, Redis를 이용한 분산 환경 구현, Nginx·미들웨어·게이트웨이 계층별 적용, 429/Retry-After 같은 HTTP 규약과 실무에서 자주 겪는 함정까지 언어에 상관없이 적용 가능한 관점으로 정리합니다.

들어가며 — API에 왜 제한이 필요한가

공개 API든 내부 마이크로서비스 간 통신이든, 클라이언트가 얼마나 자주 요청을 보낼 수 있는지에 대한 명시적인 규칙이 없다면 시스템은 언젠가 예상치 못한 방식으로 무너집니다. Rate Limiting(요청 속도 제한)은 특정 시간 창(window) 동안 클라이언트가 보낼 수 있는 요청 수를 제한하는 기법으로, 특정 언어나 프레임워크에 종속된 기능이 아니라 백엔드 아키텍처 전반에 걸친 설계 문제입니다.

이 글은 C++로 Rate Limiter를 직접 구현하는 방법을 다루는 시리즈 글과는 달리, 알고리즘의 원리, 분산 환경에서의 구현, 그리고 실제 서비스 스택(Nginx, 애플리케이션 미들웨어, HTTP 규약)에 어떻게 적용하는지를 중심으로 다룹니다. 어떤 언어를 쓰든 적용할 수 있는 개념과, 실무에서 자주 놓치는 함정을 함께 정리했습니다.

Rate Limiting이 필요한 이유는 크게 네 가지로 요약됩니다.

첫째, 남용(abuse) 방지입니다. 로그인 엔드포인트에 초당 수만 건의 요청을 보내는 무차별 대입 공격(brute force), 크롤러가 전체 카탈로그를 훑는 스크래핑, 봇넷을 이용한 분산 서비스 거부 공격(DDoS) 등은 모두 “요청 수를 제한하지 않으면” 발생하는 문제입니다. 제한이 없는 엔드포인트는 공격자에게 사실상 무제한 자원을 내어주는 것과 같습니다.

둘째, 비용 통제입니다. 클라우드 인프라는 대부분 사용량 기반 과금 구조입니다. 데이터베이스 조회, 외부 API 호출(특히 LLM API처럼 토큰당 과금되는 서비스), 아웃바운드 트래픽 모두 비용으로 직결됩니다. 제한 없는 API는 예산을 예측 불가능하게 만들고, 실수로 만든 무한 루프 클라이언트 하나가 한 달 치 클라우드 비용을 며칠 만에 소진시킬 수도 있습니다.

셋째, 공정한 사용(fair usage)입니다. 다중 테넌트 시스템에서 한 사용자나 조직이 리소스를 독점하면 다른 사용자의 경험이 나빠집니다. 무료 티어와 유료 티어를 구분하는 SaaS 서비스라면 Rate Limiting은 요금제 차별화의 핵심 수단이기도 합니다.

넷째, 다운스트림 서비스 보호입니다. API 서버 뒤에는 대개 데이터베이스, 캐시, 외부 API 등 다운스트림 의존성이 있습니다. API 서버 자체는 수평 확장이 쉬워도, 데이터베이스 커넥션 풀이나 서드파티 API의 쿼터는 쉽게 늘릴 수 없는 경우가 많습니다. 앞단의 Rate Limiting은 이런 제한된 자원을 보호하는 안전 밸브 역할을 합니다.

핵심 알고리즘 비교

Rate Limiting을 구현하는 방법은 여러 가지가 있지만, 실무에서 반복적으로 등장하는 다섯 가지 알고리즘의 동작 원리와 트레이드오프를 이해하면 상황에 맞는 선택을 할 수 있습니다.

Fixed Window Counter (고정 윈도우 카운터)

가장 단순한 방식입니다. 시간을 일정한 크기(예: 1분)의 창으로 나누고, 각 창마다 카운터를 하나 둡니다. 요청이 들어올 때마다 현재 창의 카운터를 증가시키고, 한도를 넘으면 거부합니다. 창이 바뀌면 카운터는 0으로 리셋됩니다.

# 의사 코드 - 언어 무관
def is_allowed(user_id, limit=100, window_seconds=60):
    current_window = int(time.now() / window_seconds)
    key = f"{user_id}:{current_window}"

    count = cache.increment(key)  # 없으면 1로 생성, 있으면 +1
    if count == 1:
        cache.expire(key, window_seconds)  # 창이 끝나면 자동 삭제

    return count <= limit

이 코드는 사용자별로 “현재 시간이 속한 창”을 키로 사용해 카운터를 증가시키고, 처음 생성될 때만 TTL(만료 시간)을 설정합니다. 구현이 매우 간단하고 메모리 사용량도 사용자 수에 비례할 뿐 요청 수와는 무관해 저비용이라는 장점이 있습니다.

하지만 치명적인 약점이 있습니다. 바로 경계 버스트(boundary burst) 문제입니다. 예를 들어 분당 100회 제한이라면, 사용자가 0분 59초에 100건, 1분 00초에 다시 100건을 보내면 단 2초 사이에 200건이 통과됩니다. 창 경계에서는 이론상 한도의 최대 2배까지 트래픽이 몰릴 수 있다는 뜻입니다. 정밀한 제어가 필요 없고 대략적인 남용 방지만 목적이라면 충분하지만, 정확한 보장이 필요한 결제 API 같은 곳에는 부적합합니다.

Sliding Window Log (슬라이딩 윈도우 로그)

Fixed Window의 부정확성을 해결하기 위한 방식입니다. 각 요청의 타임스탬프를 모두 기록해 두고, 매 요청마다 “현재 시각 - 윈도우 크기”보다 오래된 타임스탬프를 제거한 뒤 남은 개수를 한도와 비교합니다.

def is_allowed(user_id, limit=100, window_seconds=60):
    now = time.now()
    key = f"log:{user_id}"

    # 윈도우를 벗어난 오래된 타임스탬프 제거
    cache.remove_older_than(key, now - window_seconds)

    if cache.count(key) >= limit:
        return False

    cache.add_timestamp(key, now)
    return True

이 방식은 “지난 60초 동안 정확히 몇 건이었는가”를 항상 정확하게 계산하므로 경계 버스트 문제가 전혀 없습니다. 대신 대가가 있습니다. 사용자마다 최대 limit개의 타임스탬프를 저장해야 하므로 트래픽이 많은 서비스에서는 메모리 사용량이 빠르게 늘어나고, 매 요청마다 오래된 항목을 정리하는 연산 비용도 발생합니다. 정확도가 최우선이고 트래픽 규모가 감당 가능한 수준일 때 적합합니다.

Sliding Window Counter (슬라이딩 윈도우 카운터)

Fixed Window의 저비용과 Sliding Window Log의 정확도 사이의 절충안입니다. 이전 창과 현재 창의 카운트를 모두 유지하되, 현재 시점이 현재 창에서 얼마나 진행되었는지에 비례해 이전 창의 카운트를 가중치로 반영합니다.

추정 요청 수 = 이전 창 카운트 × (1 - 현재 창 경과 비율) + 현재 창 카운트

예를 들어 분당 100회 제한에서 현재 창이 30% 지났고 이전 창에 80건, 현재 창에 20건이 기록되어 있다면, 추정치는 80 × 0.7 + 20 = 76이 됩니다. 완벽하게 정확하지는 않지만(트래픽이 균등하게 분포한다고 가정) 실제 요청 패턴에서는 근사치가 충분히 정확하면서도 카운터 두 개만 유지하면 되므로 메모리 비용이 낮습니다. Fixed Window의 단순함과 Sliding Window Log의 정확도 사이에서 가장 실용적인 절충점으로, Cloudflare 등 대형 서비스에서 실제로 채택한 방식으로 알려져 있습니다.

Token Bucket (토큰 버킷)

버킷(양동이)에 일정한 속도로 토큰이 채워지고, 요청이 들어올 때마다 토큰을 하나씩 소비합니다. 토큰이 없으면 요청은 거부됩니다. 버킷의 용량(capacity)만큼 토큰을 미리 쌓아둘 수 있어 순간적인 버스트 트래픽을 자연스럽게 흡수한다는 점이 다른 알고리즘과의 가장 큰 차이입니다.

class TokenBucket:
    def __init__(self, capacity, refill_rate):
        self.capacity = capacity          # 버킷 최대 용량
        self.refill_rate = refill_rate    # 초당 채워지는 토큰 수
        self.tokens = capacity
        self.last_refill = time.now()

    def is_allowed(self, cost=1):
        now = time.now()
        elapsed = now - self.last_refill
        # 경과 시간만큼 토큰을 채우되 용량을 넘지 않게 함
        self.tokens = min(self.capacity, self.tokens + elapsed * self.refill_rate)
        self.last_refill = now

        if self.tokens >= cost:
            self.tokens -= cost
            return True
        return False

이 구현에서 핵심은 “요청이 올 때마다 실제로 경과한 시간만큼만 토큰을 보충한다”는 지연 계산(lazy refill) 방식입니다. 별도의 백그라운드 타이머 없이도 정확한 토큰 양을 계산할 수 있어 구현이 간결합니다. 평균적으로는 refill_rate만큼의 처리율을 유지하면서도, 한동안 요청이 없었다면 그 사이 쌓인 토큰만큼 버스트를 허용합니다. 예를 들어 초당 10개 토큰이 채워지고 용량이 50이라면, 5초간 요청이 없었을 때 순간적으로 50건까지 몰려도 통과시킬 수 있습니다. API 게이트웨이나 공개 API에서 가장 널리 쓰이는 이유가 바로 이 “평균은 제어하되 짧은 버스트는 허용한다”는 유연성 때문입니다.

Leaky Bucket (리키 버킷)

Token Bucket과 자주 비교되지만 동작 방식은 반대에 가깝습니다. 요청이 들어오면 큐(양동이)에 쌓이고, 일정한 속도로 큐에서 꺼내 처리합니다. 물이 일정한 속도로 새어 나가는 양동이에 비유해서 이름이 붙었습니다. 큐가 가득 차면 새 요청은 거부되거나 대기합니다.

Token Bucket이 “버스트를 허용하되 평균 처리율은 제한”한다면, Leaky Bucket은 “출력 속도를 항상 일정하게 유지”하는 데 초점이 있습니다. 즉 Token Bucket은 순간적으로 여러 요청을 한꺼번에 통과시킬 수 있지만, Leaky Bucket은 큐에 쌓인 요청도 결국 일정한 속도로만 내보내므로 다운스트림 시스템이 받는 트래픽이 훨씬 평탄합니다. 트래픽 셰이핑(shaping)이 중요한 네트워크 장비나, Nginx의 limit_req 모듈이 이 방식에 가깝습니다.

알고리즘 선택 기준 요약

정확도가 크게 중요하지 않고 구현을 최대한 단순하게 하고 싶다면 Fixed Window Counter, 완벽한 정확도가 필요하고 트래픽 규모가 감당할 만하다면 Sliding Window Log, 이 둘의 절충이 필요하다면 Sliding Window Counter를 선택합니다. 순간적인 버스트를 허용하면서 장기 평균을 제어하고 싶다면 Token Bucket이 실무에서 가장 흔한 선택이며, 다운스트림으로 나가는 트래픽을 항상 일정한 속도로 평탄화하고 싶다면 Leaky Bucket이 적합합니다.

분산 환경에서의 Rate Limiting — Redis 활용

단일 서버라면 메모리 내 변수로 충분하지만, 서버가 여러 대로 스케일 아웃되면 이야기가 달라집니다. 로드 밸런서 뒤에 서버가 5대 있고 각 서버가 독립적으로 “분당 100회”를 카운트한다면, 사용자는 이론상 로드 밸런싱 알고리즘에 따라 분산 요청을 보내 최대 500회까지 통과시킬 수 있습니다. 이 문제를 해결하려면 모든 서버가 공유하는 중앙 상태 저장소가 필요하며, 이 역할에 가장 널리 쓰이는 것이 Redis입니다.

INCR + EXPIRE 패턴

가장 단순한 분산 구현은 Fixed Window Counter를 Redis로 옮기는 것입니다.

// Node.js + ioredis 예시
async function isAllowed(redis, userId, limit = 100, windowSeconds = 60) {
  const window = Math.floor(Date.now() / 1000 / windowSeconds);
  const key = `rate:${userId}:${window}`;

  const count = await redis.incr(key);
  if (count === 1) {
    // 이 키가 처음 생성된 경우에만 만료 시간을 설정
    await redis.expire(key, windowSeconds);
  }

  return count <= limit;
}

INCR은 Redis에서 원자적(atomic) 연산이므로 여러 서버가 동시에 같은 키를 증가시켜도 카운트가 정확합니다. 다만 이 코드에는 미묘한 경쟁 조건(race condition)이 하나 남아 있습니다. INCR이 성공한 직후, EXPIRE를 호출하기 전에 프로세스가 죽거나 네트워크 문제가 생기면 해당 키에 TTL이 영영 설정되지 않아 메모리에 계속 남는 “고아 키(orphan key)“가 발생할 수 있습니다. 트래픽이 많은 서비스에서는 이런 키가 누적되어 Redis 메모리를 서서히 잠식할 수 있으므로, 별도의 정리 배치를 두거나 다음에 설명할 Lua 스크립트 방식으로 원자성을 보장하는 것이 안전합니다.

Lua 스크립트로 원자성 보장하기

INCR과 EXPIRE를 하나의 원자적 단위로 묶으려면 Redis의 Lua 스크립팅 기능(EVAL)을 사용합니다. Redis는 Lua 스크립트를 단일 명령처럼 실행하므로, 스크립트 내부의 모든 연산이 다른 클라이언트의 명령과 끼어들 틈 없이 원자적으로 처리됩니다.

-- rate_limit.lua
-- KEYS[1]: 카운터 키
-- ARGV[1]: 제한 횟수(limit)
-- ARGV[2]: 윈도우 크기(초)
local current = redis.call("INCR", KEYS[1])
if current == 1 then
    redis.call("EXPIRE", KEYS[1], ARGV[2])
end

if current > tonumber(ARGV[1]) then
    return 0  -- 거부
else
    return 1  -- 허용
end
const script = fs.readFileSync('rate_limit.lua', 'utf8');
const scriptSha = await redis.script('LOAD', script);

async function isAllowedAtomic(redis, userId, limit = 100, windowSeconds = 60) {
  const window = Math.floor(Date.now() / 1000 / windowSeconds);
  const key = `rate:${userId}:${window}`;

  const result = await redis.evalsha(scriptSha, 1, key, limit, windowSeconds);
  return result === 1;
}

EVALSHA는 스크립트 본문 대신 해시값만 전송하므로 매번 전체 스크립트를 네트워크로 보내는 것보다 효율적입니다. 이 방식의 핵심 이점은 INCR과 EXPIRE 판단, 그리고 한도 비교까지 전부 Redis 서버 내부에서 단일 명령처럼 실행되어 경쟁 조건이 원천적으로 차단된다는 점입니다. Token Bucket처럼 더 복잡한 알고리즘도 같은 방식으로 Lua 스크립트에 토큰 계산 로직을 넣어 원자적으로 구현할 수 있습니다. 실무에서 Redis 기반 Rate Limiter를 만든다면, 성능과 정확성 모두를 고려할 때 단순 명령 조합보다는 Lua 스크립트 방식을 우선 검토하는 것이 좋습니다.

Redis 자체가 병목이 되지 않으려면

모든 요청마다 Redis를 호출하면 API 서버의 지연 시간에 네트워크 왕복(RTT)이 추가됩니다. 트래픽이 매우 많은 서비스에서는 로컬 캐시와 배치 동기화를 조합하거나, Redis Cluster로 키를 샤딩해 단일 노드에 부하가 몰리지 않도록 분산하는 접근을 함께 고려해야 합니다. Redis를 캐시로 활용하는 일반적인 패턴과 운영 고려사항은 캐싱 전략을 다룬 글에서 더 자세히 확인할 수 있습니다.

어디에서 제한을 걸어야 하는가

Rate Limiting은 하나의 계층에서만 처리하는 것이 아니라, 여러 계층에 걸쳐 역할을 분담하는 것이 실무에서 흔한 구성입니다.

API 게이트웨이 / 리버스 프록시 계층

Nginx 같은 리버스 프록시는 애플리케이션 코드에 도달하기 전 단계에서 트래픽을 걸러내는 가장 저렴한 방어선입니다. Nginx의 limit_req 모듈은 Leaky Bucket 방식으로 동작합니다.

# nginx.conf
http {
    # 존 이름 mylimit, 클라이언트 IP당 상태 저장, 1MB 메모리에 약 16000개 IP 추적, 초당 10회 제한
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

    server {
        location /api/ {
            # burst: 순간적으로 초과 허용할 요청 수, nodelay: 큐잉 없이 즉시 처리 또는 거부
            limit_req zone=mylimit burst=20 nodelay;
            proxy_pass http://backend;
        }
    }
}

rate=10r/s는 평균 초당 10건까지 허용한다는 뜻이고, burst=20은 순간적으로 최대 20건까지 큐에 쌓아 처리할 수 있음을 의미합니다. nodelay 옵션이 없으면 burst 만큼의 요청이 큐에 쌓인 채로 지연 처리되고, nodelay를 붙이면 burst 한도 내에서는 즉시 처리하되 한도를 넘으면 바로 거부합니다. 이 계층에서 걸러지는 트래픽은 애플리케이션 서버, 데이터베이스, 외부 API 호출까지 전혀 도달하지 않으므로 리소스 소모가 거의 없다는 것이 가장 큰 장점입니다. Nginx의 전반적인 설정 구조와 리버스 프록시 구성은 별도의 Nginx 가이드에서 더 폭넓게 다루고 있습니다.

애플리케이션 미들웨어 계층

게이트웨이 계층은 IP 기반의 단순한 제한에는 적합하지만, “이 API 키는 프리미엄 등급이라 분당 1000회, 무료 등급은 분당 10회” 같은 비즈니스 로직이 섞인 제한은 애플리케이션 코드에서 처리하는 것이 자연스럽습니다.

// Express 미들웨어 예시
function rateLimitMiddleware(redis) {
  return async (req, res, next) => {
    const apiKey = req.headers['x-api-key'];
    const tier = await getTierForApiKey(apiKey); // free | premium
    const limit = tier === 'premium' ? 1000 : 10;

    const allowed = await isAllowedAtomic(redis, apiKey, limit, 60);

    if (!allowed) {
      res.set('Retry-After', '60');
      return res.status(429).json({ error: 'Too Many Requests' });
    }

    next();
  };
}

이 미들웨어는 요청 헤더에서 API 키를 추출해 사용자 등급을 조회한 뒤, 등급에 맞는 한도로 앞서 만든 Redis 기반 함수를 호출합니다. 한도를 초과하면 429 상태 코드와 Retry-After 헤더를 함께 반환합니다. 이렇게 게이트웨이에서 대규모 남용을 1차로 걸러내고, 미들웨어에서 사용자별·API 키별 세밀한 정책을 적용하는 이중 구조가 안정성과 유연성을 동시에 확보하는 방법입니다.

별도 서비스로 분리하는 경우

마이크로서비스가 많아지고 여러 서비스가 동일한 Rate Limiting 정책을 공유해야 한다면, 각 서비스마다 로직을 중복 구현하는 대신 별도의 Rate Limiting 서비스나 사이드카(예: Envoy의 Rate Limit 필터)로 분리하는 것을 고려할 수 있습니다. 이 경우 정책 변경이 한 곳에서만 이루어지고, 모든 서비스가 동일한 규칙을 일관되게 적용받는다는 장점이 있지만, 그만큼 네트워크 홉이 하나 늘어나므로 지연 시간과 가용성 트레이드오프를 함께 평가해야 합니다.

HTTP 규약 — 클라이언트와 올바르게 소통하기

Rate Limiting을 구현할 때 서버 내부 로직만큼 중요한 것이 클라이언트에게 상태를 명확히 알리는 것입니다. 잘 설계된 API는 클라이언트가 제한에 걸렸을 때 무작정 재시도하지 않고 적절히 대응할 수 있도록 표준화된 신호를 제공합니다.

429 Too Many Requests는 요청이 한도를 초과했을 때 반환해야 하는 표준 HTTP 상태 코드입니다. 500번대 서버 오류와 구분해서 사용해야 클라이언트가 “내 요청 방식에 문제가 있다”는 것을 명확히 인지할 수 있습니다.

Retry-After 헤더는 클라이언트가 얼마나 기다린 후 재시도해야 하는지를 알려줍니다. 초 단위 정수(Retry-After: 60) 또는 HTTP 날짜 형식(Retry-After: Wed, 21 Oct 2026 07:28:00 GMT) 두 가지 형식을 모두 사용할 수 있습니다.

X-RateLimit-* 헤더 계열은 비공식이지만 사실상의 업계 표준으로 널리 쓰입니다.

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 42
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1717027200

{"error": "Too Many Requests", "message": "요청 한도를 초과했습니다. 42초 후 다시 시도해 주세요."}

X-RateLimit-Limit은 현재 창에서 허용되는 최대 요청 수, X-RateLimit-Remaining은 남은 요청 수, X-RateLimit-Reset은 한도가 초기화되는 시각(주로 유닉스 타임스탬프)을 나타냅니다. 이 헤더는 성공 응답(200)에도 함께 포함시켜, 클라이언트가 한도에 도달하기 전에 미리 요청 속도를 조절할 수 있게 하는 것이 좋은 관행입니다. 일부 API는 IETF 초안으로 논의되어 온 RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset 형태(접두어 X- 없이)를 채택하기 시작했으므로, 새로 설계하는 API라면 이 표준화 흐름을 참고하는 것도 좋습니다.

흔히 겪는 함정들

시계 오차(clock skew)

분산 시스템에서 각 노드의 시스템 시계가 정확히 동기화되어 있지 않으면, 시간 기반 알고리즘(특히 Fixed Window, Sliding Window)의 계산이 노드마다 미묘하게 달라질 수 있습니다. Redis처럼 중앙 저장소를 사용하는 구조에서는 시간 계산을 애플리케이션 서버의 로컬 시계가 아니라 Redis 서버의 시각(TIME 명령) 기준으로 통일하거나, NTP로 모든 서버의 시계를 철저히 동기화하는 것이 안전합니다. 특히 여러 리전에 서버가 분산된 경우 이 문제가 더 두드러지므로, 리전 간 시계 오차가 실제로 정책에 영향을 줄 수 있는 수준인지 사전에 점검할 필요가 있습니다.

리셋 시점의 썬더링 허드(thundering herd)

모든 사용자의 카운터가 정확히 같은 시각(예: 매 분 0초)에 리셋되는 구조라면, 리셋 직후 대기 중이던 요청들이 한꺼번에 몰려드는 현상이 발생할 수 있습니다. 특히 재시도 로직이 있는 클라이언트가 많을 때 이 문제가 두드러집니다. 완화 방법으로는 사용자별로 윈도우 시작 시각에 약간의 지터(jitter)를 부여해 리셋 시점을 분산시키거나, 클라이언트 쪽 재시도 로직에 지수 백오프와 무작위 지연을 반드시 포함시키는 것이 있습니다.

키 선택 — IP vs 사용자 vs API 키

무엇을 기준으로 카운트를 나눌지는 정책 설계에서 가장 중요한 결정 중 하나입니다. IP 기준은 인증되지 않은 엔드포인트(로그인, 회원가입)에는 필수적이지만, NAT나 사내망을 공유하는 다수의 사용자가 같은 공인 IP로 접속하는 환경에서는 정상 사용자들이 서로의 트래픽 때문에 함께 차단당하는 부작용이 생길 수 있습니다. 사용자 ID 기준은 인증된 요청에는 정확하지만, 인증 이전 단계(로그인 시도 자체)에는 적용할 수 없습니다. API 키 기준은 서드파티 개발자에게 API를 제공할 때 가장 합리적이며, 요금제별 차등 적용도 자연스럽습니다. 실무에서는 이 세 가지를 조합해서, 인증 이전에는 IP 기준으로 느슨하게, 인증 이후에는 사용자·API 키 기준으로 정교하게 제한하는 다층 전략을 쓰는 경우가 많습니다.

실패 시 열림(fail-open) vs 닫힘(fail-closed)

Redis 같은 중앙 저장소가 일시적으로 응답하지 않을 때 Rate Limiter는 어떻게 동작해야 할까요? 무조건 요청을 거부하는 fail-closed 방식은 안전하지만 Redis 장애가 곧 전체 API 장애로 이어지는 위험이 있고, 무조건 허용하는 fail-open 방식은 가용성은 지키지만 그 순간에는 제한이 무력화된다는 위험이 있습니다. 대부분의 프로덕션 시스템은 짧은 타임아웃과 함께 fail-open을 기본값으로 채택하되, 모니터링과 알림을 통해 저장소 장애를 즉시 인지하고 대응하는 방식을 선호합니다. 어느 쪽을 선택하든 이 결정은 명시적으로 문서화해 두어야 팀 전체가 장애 상황에서 같은 기대를 가질 수 있습니다.

마치며

API Rate Limiting은 단순히 “카운터를 세고 초과하면 막는” 문제처럼 보이지만, 실제로는 알고리즘 선택, 분산 환경에서의 일관성 보장, 여러 계층에 걸친 역할 분담, 그리고 클라이언트와의 명확한 소통까지 포함하는 복합적인 설계 문제입니다. 트래픽 규모가 작을 때는 Fixed Window Counter나 단일 서버 메모리 기반 구현으로 충분하지만, 서비스가 성장하면서 서버가 여러 대로 늘어나고 사용자 등급이 다양해지면 Redis 기반의 원자적 분산 처리와 계층별 정책 분리가 필수가 됩니다. 어떤 알고리즘과 아키텍처를 선택하든, 429 응답과 표준 헤더를 통해 클라이언트가 스스로 트래픽을 조절할 수 있게 돕는 것이 안정적인 API 생태계를 만드는 핵심입니다.

같이 보면 좋은 글 (내부 링크)

이 주제와 연결되는 다른 글입니다.