[Backend Guide] 고성능 분산 환경에서의 API Rate Limiting 구현 전략

1. 개요 (Introduction)

대규모 트래픽을 처리하는 엔터프라이즈 플랫폼에서 API Rate Limiting(속도 제한)은 선택이 아닌 필수 생존 전략입니다.

특정 IP나 계정에서 과도한 요청이 발생할 경우, 전체 시스템의 가용성(Availability)을 해칠 수 있습니다. 본 문서는 PowerSoft가 적용 중인 'Sliding Window' 알고리즘 기반의 트래픽 제어 구현 방법을 기술합니다.

핵심 목표

• DDoS 방어: 비정상적인 트래픽 패턴 차단

• 리소스 공정성: 특정 유저의 리소스 독점 방지

• 비용 절감: 불필요한 API 호출로 인한 인프라 비용 제어

---

2. 알고리즘 선정: Sliding Window vs Token Bucket

PowerSoft는 정교한 트래픽 제어를 위해 Sliding Window Log 방식을 개량하여 사용합니다.

알고리즘	장점	단점	PowerSoft 채택 여부
Fixed Window	구현이 매우 간단함	윈도우 경계에서 트래픽 2배 허용(Burst) 문제	❌
Leaky Bucket	일정한 처리 속도 보장	급격한 트래픽(Burst) 처리에 취약	❌
Sliding Window	매우 정교한 제어 가능	메모리 사용량이 상대적으로 많음	✅ (Redis 최적화)

Note: 우리는 Redis의 Sorted Set(ZSET)을 활용하여 Sliding Window를 구현함으로써, 메모리 효율과 정밀도를 동시에 확보했습니다.

---

3. 구현 상세 (Implementation)

분산 환경에서 Rate Limiting을 구현할 때 가장 중요한 것은 원자성(Atomicity) 보장입니다. 애플리케이션 레벨에서 체크하면 경쟁 상태(Race Condition)가 발생할 수 있습니다.

따라서 우리는 Redis + Lua Script를 사용하여 Check-And-Set 작업을 원자적으로 수행합니다.

3.1. Lua Script 예시

아래 스크립트는 1초에 N회의 요청만 허용하는 로직입니다.

Lua

-- keys[1]: rate_limit:{ip}
-- argv[1]: limit_count (e.g., 10)
-- argv[2]: window_size_in_seconds (e.g., 1)
-- argv[3]: current_timestamp

local key = keys[1]
local limit = tonumber(argv[1])
local window = tonumber(argv[2])
local now = tonumber(argv[3])

-- 1. 윈도우 범위를 벗어난 오래된 기록 삭제
redis.call('ZREMRANGEBYSCORE', key, '-inf', now - window)

-- 2. 현재 윈도우 내의 요청 수 조회
local count = redis.call('ZCARD', key)

-- 3. 제한 초과 여부 확인
if count < limit then
    -- 통과: 현재 요청 타임스탬프 추가
    redis.call('ZADD', key, now, now)
    redis.call('EXPIRE', key, window) -- 키 만료 시간 갱신
    return 1 -- Allowed
else
    return 0 -- Rejected (429 Too Many Requests)
end

3.2. Spring Boot 적용 (Pseudo Code)

Java

public boolean tryAcquire(String ip) {
    long now = System.currentTimeMillis();
    Long result = redisTemplate.execute(redisScript, 
        Collections.singletonList("rate_limit:" + ip), 
        10,  // limit
        1000, // window size (ms)
        now
    );
    return result != null && result == 1;
}

---

4. 인프라 아키텍처 관점 (Architecture View)

단순한 코드 구현을 넘어, 글로벌 리전(Global Region) 간의 레이턴시를 고려한 Geo-Distributed Rate Limiting 전략이 필요합니다.

PowerSoft는 엣지(Edge) 단계에서 1차 필터링을 수행하고, 백엔드 코어에서 2차 정밀 제어를 수행하는 이중화 구조를 채택하고 있습니다.

이러한 거시적인 인프라 아키텍처와 로드 밸런싱(L7) 전략에 대한 상세한 내용은 아래 기술 블로그에서 심도 있게 다루고 있습니다.

[Tech Blog] PowerSoft 아키텍처 심층 분석