Redis 타임아웃
공유 카운터를 읽지 못해 모든 요청 판정이 지연됩니다.
대응 · 로컬 Emergency Bucket + 정책별 Fail Open/Closed
분산 레이트 리미터 설계
요청 폭주와 서비스 남용을 막으면서, 여러 API 서버가 하나의 제한 상태를 안전하게 공유하는 구조를 설계합니다.
3분 요약
개념 이해
면접 답변
실무 확장
진도 저장 ✓
30초 핵심 요약
레이트 리미터는 일정 시간 동안 허용할 요청 수를 제한합니다. 단일 서버에서는 메모리 카운터로 충분하지만, 여러 서버가 동시에 요청을 처리하면 공유 상태와 원자적 갱신이 필요합니다. 이 설계에서는 API Gateway 뒤에 분산 레이트 리미터를 두고 Redis Lua Script로 토큰 차감을 원자적으로 처리합니다.
예시 목표 처리량 (설계 가정)1,200,000 req/s
판정 지연 목표 (설계 가정)P99 < 10ms
일관성 우선순위중복 허용보다 과금 보호
01 · REQUIREMENTS
# 요구사항무엇을 제한할 것인가?
사용자, API Key, IP, 조직, 엔드포인트별로 서로 다른 정책을 적용하고, 제한 판정은 애플리케이션 요청보다 먼저 끝나야 합니다.
F1다중 정책
사용자·조직·API별 제한량과 윈도우를 설정합니다.
F2빠른 판정
정상 요청 경로에 추가되는 지연을 최소화합니다.
F3분산 공유
여러 서버가 동일한 사용량 상태를 확인합니다.
F4정확한 응답
429와 남은 횟수·재시도 시각을 전달합니다.
02 · HIGH-LEVEL DESIGN
# 아키텍처고수준 아키텍처
요청은 Gateway에서 인증된 뒤 레이트 리미터로 전달됩니다. 정책과 사용량은 분리해 캐시하며, 판정 결과와 오류율은 관측 시스템으로 전송합니다.
분산 레이트 리미터 · 요청 판정 흐름 SVG DIAGRAM · 확대 가능
◉ClientWeb · Mobile · SDK
⇄API Gateway인증 · 정책 키 추출
⚡Rate Limiter정책 조회 · 토큰 차감 · 429 응답
Token BucketLua Script
▦Redis Cluster공유 카운터 · 정책 캐시
▤Application허용된 요청 처리
↗Observability허용률 · 거부율 · P99
설계 포인트 — Redis 장애 시 모든 요청을 차단할지(Fail Closed), 임시로 허용할지(Fail Open)는 API의 위험도와 비용 구조에 따라 정책별로 결정합니다.
03 · REQUEST FLOW
# 처리 흐름요청은 어떻게 판정되는가?
1제한 키 생성
userId + endpoint + policyVersion으로 키를 만듭니다.
2정책 조회
로컬 캐시에서 용량과 보충률을 확인합니다.
3원자적 차감
Lua Script로 토큰 확인과 감소를 한 번에 수행합니다.
4응답·관측
허용 또는 429를 반환하고 메트릭을 기록합니다.
04 · ALGORITHM
# 트레이드오프알고리즘 비교
서비스 특성에 따라 버스트 허용 여부와 메모리 비용이 달라집니다. 기본안은 Token Bucket이며, 엄격한 균등 처리에는 Leaky Bucket을 고려합니다.
알고리즘
버스트 허용
메모리
추천 상황
Token Bucket
가능
낮음
일반 API · 모바일 트래픽
Leaky Bucket
제한적
낮음
균등한 처리량이 중요한 큐
Fixed Window Counter
창 경계 취약
낮음
단순·대규모 정책
Sliding Window Log
정확
높음
소규모·정확성 우선 정책
Sliding Window Counter
근사
중간
대규모·정확도와 비용 균형
05 · FAILURE MODES
# 장애 대응장애 시나리오와 대응
중복 요청
클라이언트 재시도로 동일한 비즈니스 요청이 여러 번 전달됩니다.
대응 · 제한 판정과 업무 멱등 키를 별도 관리
Hot Key
단일 유명 API Key에 트래픽이 집중되어 한 샤드가 과부하됩니다.
대응 · 키 분할, 로컬 선차감, 비동기 합산
리전 단절
리전 간 상태 동기화가 끊겨 전역 제한량이 초과될 수 있습니다.
대응 · 리전별 예산 할당 + 여유분 중앙 조정
06 · OPERATIONS
# 운영보안·관측·비용·출처
면접 모드 · 추가 질문05:00
“전 세계 사용자에게 하나의 전역 제한량을 정확히 적용해야 한다면 지연 시간과 일관성을 어떻게 조정하시겠습니까?”
답변 구조 보기힌트 1개예상 꼬리 질문
NEXT CASE STUDY분산 Key-Value Store 설계
EDITORIAL NOTES
작성·검토·참고 자료
참고 자료
- RFC 6585: Additional HTTP Status Codes — 429 Too Many Requests 응답의 의미를 검토했다.
- Redis: Scripting with Lua — 여러 연산을 원자적으로 실행하는 Redis 스크립트의 경계를 검토했다.
- IETF HTTPAPI RateLimit header fields draft — RateLimit 정책/잔여 한도 헤더의 최신 표준화 진행 상태를 확인했다. 이는 현재 Internet-Draft이며 확정 RFC로 가정하지 않는다.
- 본 문서의 처리량·지연·비용 수치는 `설계 가정` 또는 `계산 결과`이며 제품 사실이 아니다.
사실 오류·출처 정정은 문의·정정 페이지로 알려 주세요.