Redis 기반 Distributed Rate Limiting을 통한 API 가용성 및 보안 확보

Rate Limiting Isn't Optional Here How to Actually Implement It in Node.js

Sandeep Bansod2026년 5월 1일11분intermediate

AI 요약

Context

단일 서버 환경의 In-Memory 카운터 방식은 Load Balancer 도입 시 인스턴스별 개별 카운팅으로 인해 전체 제한 수치가 서버 대수만큼 배수로 증가하는 설계적 결함 존재. 서버 재시작 시 모든 데이터가 소실되어 Rate Limit 정책의 일관성 유지가 불가능한 구조적 한계 직면.

Technical Solution

Redis 기반의 Shared Store를 도입하여 분산 환경에서도 모든 서버 인스턴스가 단일한 카운터를 공유하는 아키텍처 설계
trust proxy 설정을 통한 Proxy 서버의 내부 IP가 아닌 실제 Client IP 식별 체계 구축
인증 경로에 한해 IP 주소 대신 User ID를 Key로 사용하여 동일 네트워크 내 다수 사용자의 차단 문제를 해결한 세밀한 제한 전략 적용
Fixed Window의 경계 지점 트래픽 폭주 문제를 해결하기 위해 Sliding Window 또는 Token Bucket 알고리즘 채택
429 Too Many Requests 응답 시 Retry-After 헤더를 포함하여 클라이언트의 재시도 간격을 제어하는 통신 규약 설계

실천 포인트

1. 분산 환경에서는 반드시 Redis 등 외부 저장소를 활용한 Shared Store 구조인지 확인

2. L4/L7 로드밸런서 사용 시 `trust proxy` 설정으로 실제 Client IP를 수집하는지 검증

3. 로그인 사용자에게는 IP가 아닌 User ID 기반의 Key Generator를 적용하여 오차 범위 축소

4. API 성격에 따라 Auth(엄격) 및 General(완만) 경로별로 서로 다른 Rate Limit 임계치 설정

5. `autocannon` 등 부하 테스트 도구를 통해 설정한 임계치에서 429 응답이 정상 동작하는지 확인

태그

#Redis #Distributed System #Node.js #Rate Limiting #Token Bucket

원문 읽기