Rate Limiter - boostcampwm-2024/refactor-web36-QLAB GitHub Wiki

Rate Limiting은 서버의 안정성을 유지하고, 자원의 남용을 방지하며, 보안 강화를 위해 사용됩니다. 클라이언트, API Gateway, 서버 등 다양한 위치에서 구현할 수 있습니다.

사용사례

💡사용자는 초당 2회 이상의 새 글을 올릴 수 없다

  같은 IP 주소로는 하루에 10개 이상의 계정을 생성할 수 없다

  같은 디바이스로는 주당 5회 이상 리워드를 요청할 수 없다

Rate Limiting의 주요 목적

1. DOS 공격 방지

• 악의적인 트래픽으로부터 서버를 보호.

1. API 과금 절약

• 제3자(Third-party) API 사용량을 제한하여 비용 절감.

1. 서버 과부하 방지

• 트래픽 폭증으로 인해 서버가 다운되지 않도록 예방.

구현 위치

1. 클라이언트

• 사용자의 애플리케이션에서 요청 횟수를 직접 제어.
• 구현이 쉬우나 신뢰도가 낮음(클라이언트가 제한을 우회할 수 있음).

1. 미들웨어(API Gateway)

• API Gateway 수준에서 트래픽 제어.
• 클라이언트와 서버 간의 중간 지점으로 높은 신뢰도와 관리 용이성 제공.

1. 서버

• 서버에서 요청을 처리하며 제한 적용.
• 가장 신뢰할 수 있으나 부하가 더 커질 수 있음.

알고리즘

토큰 버킷(token buket)

• 제한된 크기의 버킷에 일정 주기마다 일정 개수의 토큰을 주입한다
• 요청이 오면 토큰을 소모하며 버킷이 비어있으면 요청을 거부한다
• 버킷의 크기는 최대 감당할 수 있는 트래픽의 양
• 토큰 생성속도는 평균으로 처리할 수 있는 트래픽의 양
  • 해당 API는 초당 최대 2번까지 실행되어야 서비스가 원활히 돌아감
  • 좋아요는 한 유저당 하루에 5개씩 까지만 누를 수 있음

장점

• 구현이 쉽다.
• 짧은 시간안에 집중되는 트래픽에 대해 제한이 가능하다(버킷의 최대 크기)

단점

• 적절한 버킷의 크기와 토큰 생성속도를 튜닝하기 어렵다

누출 버킷(leaky buket)

• 큐를 기반으로 처리율을 조절한다
• 요청이 오면 큐에 삽입하고 일정 시간단위로 처리한다
• 큐가 가득찬 경우 새 요청에 대해서는 거부한다.

장점

• 고정된 처리율을 가지고 있어 안정적이다.

단점

• 유연성이 부족하여 단 기간에 트래픽이 몰리는 경우 최신 요청에 대해서는 응답할 수 없다.

고정 윈도우 카운터(fixed window counter)

• 고정된 윈도우(간격)마다 최대 요청을 지정한다.
• 요청이 올때 마다 해당 윈도우의 카운터를 증가 시킨다.

장점

• 구현이 쉽고 직관적이다.

단점

• 윈도우 경계부분에 대해 많은 트래픽이 몰려들 경우 처리가 원활하지 못하다
  • 초단위로 counter를 3개로했을때 0.51에 3번 11.5에 3번 요청할 경우 1초간격에 6번의 요청을 받아야한다.

이동 윈도우 로그(sliding window log)

• 고정 윈도우 카운터의 단점을 보완
• 요청 마다 timestamp를 로깅한다
• 고정된 윈도우 크기를 설정하고 요청 받은 시점기준 만료된 로깅은 제거한다.
• 유효한 로깅의 개수를 통해 제한한다.
• 개수를 초과하였으면 요청을 처리하지는 않고 로깅엔 저장한다.

장점

• 정교하게 트래픽을 제한할 수 있다

단점

• 메모리 사용량이 크다

이동 윈도우 카운터(sliding window counter)

• 요청이 올때 해당 윈도우의 카운터를 증가한다
• 요청 거절에 대해서는 현재 윈도우 카운터 + 이전 윈도우 카운터*(간격 비율) 을 기준으로 한다.
  • 만약 윈도우 크기가 1초이고 1.3초에 요청이 왔을때 전 윈도우는 70%만큼 차지하므로 전 윈도우 카운터*0.7로 한다

장점

• 메모리 사용량이 이동 윈도우 로그에 비해 적음

단점

• 비율로 하는 것은 균등하다고 가정하는 것 이기에 약간 느슨하지만 크진 않다.