Foundry
API 설계
중급

Rate Limiting과 백프레셔

들어오는 양을 막을지, 못 버틴다고 알릴지

Rate Limiting과 백프레셔

알고리즘

알고리즘동작특징
고정 윈도우구간별 카운트단순, 경계에서 버스트 2배
슬라이딩 윈도우최근 N초 기준정확, 비용 높음
토큰 버킷토큰 충전과 소비평균 제한 + 버스트 허용
Leaky bucket일정 속도로 유출처리량 평탄화

초과 응답 규약

429 Too Many Requests
Retry-After: 30

한도의 기준을 먼저 정한다. 사용자, API 키, IP 중 무엇인가. IP 기준은 NAT 뒤 다수 사용자를 한 덩어리로 묶는다.

백프레셔와의 차이

  • Rate limiting은 외부 유입량을 정책으로 제한한다
  • 백프레셔는 내부 처리 능력을 초과한 부하를 상류로 되밀어낸다
  • 수단: 큐 길이 상한, 커넥션과 스레드풀 상한, 타임아웃, 부하 차단(load shedding)

실무 포인트

  • 무한 큐는 지연을 무한히 키운다. 큐를 두면 상한과 초과 시 정책을 같이 정한다
  • 분산 환경의 카운터는 공유 저장소에 둔다. 인스턴스별 카운트는 실제 한도가 인스턴스 수만큼 커진다
  • 서버의 Retry-After와 클라이언트의 지터 백오프는 짝이다. 한쪽만 있으면 재시도 폭주가 남는다
  • 제한을 걸기 전에 어떤 트래픽이 얼마나 오는지 계측한다. 근거 없는 한도는 정상 사용자를 자른다
면접에서 이렇게 나옵니다

Q.특정 고객사 트래픽이 전체 API를 마비시켰습니다. 어떤 제어 장치를 넣겠습니까?

답변을 준비하고 있어요. 우선 위 본문에서 근거를 찾아보세요.

Q.토큰 버킷과 고정 윈도우 중 무엇을 택하고 왜 그런가요?

답변을 준비하고 있어요. 우선 위 본문에서 근거를 찾아보세요.

Q.서버 인스턴스가 여러 대일 때 rate limit을 어떻게 정확히 적용하나요?

답변을 준비하고 있어요. 우선 위 본문에서 근거를 찾아보세요.

Q.큐를 늘리는 것이 근본 해결이 아닌 이유를 설명해주세요

답변을 준비하고 있어요. 우선 위 본문에서 근거를 찾아보세요.

먼저 스스로 답해보고 아래 답변과 견줘보세요. 막히는 부분은 문제로 확인할 수 있어요.

읽었으면 문제로 확인해보세요

API 설계 문제를 풀면 틀린 문제가 자동으로 노트에 쌓입니다. 가입 없이 5문제를 먼저 풀어볼 수도 있어요.