처리율 제한 장치란?

네트워크 시스템에서 처리율 제한 장치는 클라이언트 또는 서비스가 보내는 트래픽의 처리율을 제어하기 위한 장치이다. 예를 들어, 특정 기간 내에 전송되는 클라이언트의 요청 횟수(API 요청)를 제한한다. API 요청 횟수가 임계치를 넘어서면 추가로 도달한 모든 호출은 처리가 중단된다. 이런 경우 HTTP 상태 코드 429(Too many Requests)를 전송한다.

• Ex) 사용자는 초당 2회 이상 새 글을 올릴 수 없음. 같은 IP 주소로는 하루에 10개 이상의 계정을 생성할 수 없음.
  
  
  

장점

• Dos 공격에 의한 자원 고갈 방지
• 비용 절감
  • 서버를 많이 두지 않아도 됨.
  • 우선순위가 높은 API에 더 많은 자원 할당 가능
  • 제 3자 API를 사용하는 경우에 대해 과금 방지
• 서버 과부하 방지
  • 봇 or 사용자의 잘못된 이용으로 인한 트래픽 거르기
    
    
    
    

구현 방식

처리율 제한 장치를 클라이언트 측에 둘 경우

• 일반적으로 안정적이지는 않다.
• 클라이언트 요청은 쉽게 위변조 가능하기 때문.
  
  

처리율 제한 장치를 서버 측에 둘 경우

1. API 서버에 두는 경우
2. 미들웨어 형태로 클라이언트 ↔ API 서버 사이를 통제
   • 주로 API 게이트웨이라 불리는 컴포넌트에 구현됨.
   • 처리율 제한, SSL 종단, 사용자 인증, IP 허용 목록 관리 등을 지원
     

➡️ 둘 중 정답은 없다. API 서버에 두는 경우는 알고리즘을 자유롭게 선택 가능

처리율 제한 알고리즘

토큰 버킷, 누출 버킷, 고정 윈도우 카운터, 이동 윈도우 로그, 이동 윈도우 카운터 등 다양한 알고리즘이 존재하지만 본 포스팅에서는 토큰 버킷 방식에 대해서만 다루고자 한다.

토큰 버킷

• 필요한 인자
  • 버킷 크기 : 버킷에 담을 수 있는 최대 토큰 수
  • 토큰 공급률 : 초당 몇 개의 토큰이 버킷에 공급되는지
• 동작 원리
  • 지정된 용량을 갖는 컨테이너인 토큰 버킷에 설정된 양의 토큰이 주기적으로 채워진다.
    • 가득 차면 더 이상 추가하지 않고, 넘친 토큰은 삭제
  • 각 요청은 처리될 때마다 하나의 토큰을 사용한다.
    • 충분한 토큰이 있는 경우, 버킷에서 토큰 하나를 꺼낸 후 요청을 시스템에 전달
    • 충분한 토큰이 없는 경우, 해당 요청은 버려진다.
• 장점
  • 구현이 간단하다.
  • 메모리 사용 측면에서도 효율적이다.
  • 짧은 시간에 집중되는 트래픽도 처리 가능하다. 버킷에 토큰이 남아있다면, 요청은 시스템에 전달되어 처리될 것이다.
• 단점
  • 버킷 크기와 토큰 공급률을 조절하는 것이 까다로울 수 있다.

🤔 버킷을 몇 개나 사용해야 할까?

일반적으로는 API 엔드 포인트마다 별도의 버킷을 둔다. 예를 들어, 1. 사용자마다 하루에 한 번만 포스팅을 할 수 있고, 2. 친구는 150명까지 추가할 수 있고, 3. 좋아요 버튼은 다섯 번까지만 누룰 수 있다면 총 3개의 엔드 포인트가 존재하므로, 사용자마다 3개의 버킷을 두어야 할 것이다.
만약 IP 주소별로 처리율 제한을 적용해야 한다면 IP 주소마다 버킷을 하나씩 할당해야 하고, 시스템의 처리율을 초당 10,000개 요청으로 제한하고 싶다면, 모든 요청이 하나의 버킷을 공유하도록 처리해야 한다.