SDI(7)

오늘 배운 것

Rate Limiter Q&A (스터디 요약)

1) 고정 윈도 카운터의 “경계 문제”는 무엇이고 왜 생기는가?

핵심 개념

  • 고정 윈도 카운터는 시간축을 고정 간격 W(예: 10초)로 쪼개고, 각 윈도에서 요청 수를 L까지 허용함.
  • 경계 문제(boundary effect): 윈도 경계 직전·직후에 트래픽이 몰리면, 사실상 매우 짧은 시간에 2L 가까이 허용되는 현상.

왜 생기나?

  • 카운터가 윈도 경계에서 0으로 초기화되기 때문(이산화/계수의 리셋).
  • 실제 트래픽은 연속적이지만, 알고리즘이 구간 단위로 끊어서 측정하므로 경계에서 스파이크를 과허용하게 됨.

예시

  • W = 10s, L = 5일 때, t = 9.9s에 5건, t = 10.1s에 5건 → 약 0.2초 동안 10건 처리(설계 의도는 10초당 5건).

완화책

  • 윈도 크기를 더 작게 쪼개고 서브-윈도 합산(sharded fixed-window).
  • 이동 윈도(슬라이딩 윈도) 카운팅/로깅으로 전환.
  • 또는 토큰 버킷으로 평균과 버스트를 동시에 제어.

2) 토큰 버킷에서 버킷 크기 B와 보충률 r을 어떻게 정하나?

기본 의미

  • r(보충률, tokens/sec) = 평균 허용 TPS
  • B(버킷 크기) = 허용 버스트량(쌓아둘 수 있는 최대 토큰)

  • 임의의 구간 길이 t에서 허용 가능한 최대 요청 수:

  • 허용 ≤ r · t + B

튜닝 절차(실전)

  1. 다운스트림 지속 처리량을 파악: 서비스/DB/외부 API의 안정적 처리 한계 S(rps).
    • r = S(안전 마진을 두려면 r = 0.8~0.9 · S).
  2. 허용할 버스트 지속시간 T_burst를 결정(사용자 UX·사업 요구 기반).
    • 1~3초처럼 짧게 시작해 모니터링 후 조정.
  3. 버킷 크기 산정
    • 간단 근사: B ≈ r × T_burst
    • 스파이크 흡수 공식(보다 정밀): 
      스파이크 평균 도착률 A_peak (t_s 동안)를 흡수하려면
B ≥ (A_peak − r) · t_s
    • 둘을 함께 고려해 max로 선택 후, 관측 지표(p95/p99 순간 도착률·429율)로 미세조정.
  4. 가중치가 다른 작업(예: 쓰기=5, 읽기=1):
    • 요청당 토큰 차감량을 가중치로 두기(예: DECRBY cost).
  5. 스코프별 분리
    • 사용자/토큰/엔드포인트별로 독립 버킷을 두어 공정성 및 국지적 남용 억제.

예시

  • 다운스트림이 지속 200 rps 안전, 2초 버스트 허용 →
  • r = 200, B ≈ 200 × 2 = 400
  • 1초 순간 최대 허용치 ≈ r·1 + B = 600
  • 만약 특정 캠페인 순간에 1초 평균 500 rps를 2초간 감당하고 싶다면:
  • (A_peak − r) · t_s = (500 − 200) · 2 = 600 → B ≥ 600(혹은 r 상향/다운스트림 증설 검토)

3) Rate Limiter의 핵심 목적·장점, 그리고 어디에 배치하나?

핵심 목적

  • 자원 보호: 다운스트림(서비스/DB/외부 API) 과부하/고갈 방지
  • 비용 통제: 유료 API/인프라 사용량 폭주 억제
  • 공정성/품질 유지: 일부 남용이 전체 사용자 품질(SLO)을 해치지 않도록

주요 장점

  • DoS/남용 억제(자원 방어)
  • 비용 절감(한도 밖 요청 차단/지연)
  • 서버 과부하 방지(SLA/SLO 안정화)

배치 위치와 선택 기준

  • API 게이트웨이(권장 기본값)
  • 장점: 중앙집중 정책, 재사용, 서비스 간 일관성
  • 단점: 추가 홉/단일 병목 위험 → 수평 확장/캐시·분산 키 설계 필요
  • 애플리케이션 내부(라이브러리)
  • 장점: 도메인 맥락 기반의 세밀 제어, 간단 배포
  • 단점: 서비스마다 중복 구현/일관성 저하 가능
  • 사이드카/서비스 메시(Envoy 등)
  • 장점: 배포 독립성, 언어 무관, 정책 통합
  • 단점: 운영 복잡도 증가, 외부 rate-limit 서비스 필요할 수 있음
  • 에지/CDN/WAF
  • 장점: 가장 바깥에서 악성 트래픽 차단
  • 단점: 애플리케이션 맥락 인지 어려움(정교한 스코핑 제한)

운영 팁(간단)

  • 429 응답에는 Retry-After와 (X-)RateLimit-Limit/Remaining/Reset를 포함.
  • 장애 시 정책: fail-closed(비싼/위험 작업) vs fail-open(읽기/저가 작업) 비즈니스 기준으로 선택.
  • 지표: 규칙별 allowed/blocked, 429율, 버킷 고갈 빈도, p95/p99 지연/도착률.

results matching ""

    No results matching ""