처리율 제한 장치

특정 시간 동안 네트워크를 통해 전송되는 데이터의 양이나 서비스에 대한 요청 수를 제한하는 장치나 소프트웨어를 의미한다. 

  • 🚫 DoS/DDoS 공격 방지
  • 💸 과금 API 남용 방지 → 비용 절감
  • 🔐 보안 유지 (비정상 트래픽 차단)
  • ⚙️ 서버 안정성 확보
  • 🧠 클라이언트에게 명확한 피드백 제공 (429, Retry-After)

시스템 설계 4단계 접근법을 적용

1단계 문제 이해 및 설계 범위 확정 

요구사항 

  • 요청 수 제한
  • 낮은 응답시간 유지
  • 메모리 효율성
  • 장애 허용성
  • 여러 인스턴스 간 공유 가능

2단계: 아키텍처 위치 결정

Client 위변조 가능, 비추천 요청 줄일 수는 있음
Server 중앙 집중 관리 가장 흔한 방식
Middleware (API Gateway) MSA 구조에서 주로 사용 인증, 로깅, 제한 등 통합

토큰 버킷 알고리즘 

  • 구조: 일정 시간마다 버킷에 토큰 충전 → 요청 시 토큰 소비
  • 장점: 버스트 트래픽 허용, 메모리 효율
  • 단점: 버킷 크기 및 토큰 생성률 튜닝 필요

AWS API Gateway, Google API에서 사용됨

AWS 와 같은 기업에서도 API Gateway 를 생성할 때 보편적으로 사용하는 알고리즘 이라는 사실을 알 수 있다. 

시스템 처리율이 제한되어 있는 상황에서는 초당 발생한 요청은 하나의 버킷을 공유해야 한다. 

AWS 개발자 안내서에 나온 처리량 향상 목적으로 토큰 버킷 알고리즘을 활용

누출 버킷 (Leaky Bucket)

  • 구조: 큐에 요청 저장 → 고정 속도로 처리
  • 장점: 일정 처리율 보장
  • 단점: 급증 트래픽 시 최근 요청 손실

고정 윈도우 카운터

  • 구조: 시간 단위를 정해 count 누적
  • 장점: 구현 간단, 명확
  • 단점: 윈도우 경계 트래픽 몰림

슬라이딩 윈도우 (보완용)

  • 구조: 시간 간격을 슬라이딩하면서 요청 카운트 추적
  • 장점: 경계 트래픽 처리 균형
  • 단점: 성능 오버헤드 있음

실무 적용 예시

로그인 API 무차별 대입 공격 방지
결제 API 중복 결제 방지
검색 트래픽 집중 시 과금 방어
이메일 발송 스팸 방지, 벤더 제한 초과 방지

분산 환경 처리 전략

  • Redis + Lua 스크립트로 race condition 방지
  • Sticky Session으로 클라이언트 요청 고정화
  • Fallback 전략: 제한 장치 장애 시 시스템 영향 최소화

HTTP 응답 및 헤더

X-RateLimit-Limit 요청 한도
X-RateLimit-Remaining 남은 요청 수
X-RateLimit-Retry-After 재요청까지 대기 시간
429 Too Many Requests 제한 초과 응답

 우아한 실패 전략 (재시도, 서킷 브레이커)

  • 지수 백오프 (Exponential Backoff) 전략
  • 서킷 브레이커로 일정 실패율 초과 시 요청 차단
  • 캐시 전략으로 호출 수 줄이기
  • 요청이 실패한 원인을 사용자에게 명확히 알림

4단계 마무리

처리율 제한은 단순한 요청 제어가 아니라,
서비스의 생존성, 사용자 신뢰, 비용 최적화를 위한 핵심 설계 포인트입니다.

시스템은 예상치 못한 순간에 죽는다.
처리율 제한 장치는 그 죽음을 한 발 앞서 막는 보호막이다.