처리율 제한 장치(rate limiter)는 클라이언트 또는 서비스가 보내는 트래픽의 처리율(rate)을 제어하기 위한 장치다.
처리율 제한 장치를 두면 좋은 점
- DoS(Denial of Service) 공격에 의한 자원 고갈을 방지할 수 있다.
- 비용 절감
- 서버 과부하 방지
- 클라이언트 측 : 일반적으로 클라이언트는 처리율 제한을 안정적으로 걸 수 있는 장소가 못 된다. 클라이언트 요청은 쉽게 위변조가 가능
- 서버 측 : api 서버 또는 미들웨어를 구축해서 둔다.
상황에 따라서 알맞게 선택해라
-
지정된 용량을 갖는 컨테이너
-
버킷에는 사전 설정된 용량의 토큰이 주기적으로 채워진다.
-
각 요청은 처리될 때마다 하나의 토큰을 사용한다
-
요청을 처리할 토큰이 없는 경우 요청은 버려진다.
토큰 버킷 알고리즘은 두 개의 인자를 받는다
- 버킷 크기 : 버킷에 담을 수 있는 토큰의 최대 갯수
- 토큰 공급률 : 초당 몇개의 토큰이 버킷에 공급되는가
장점
- 구현이 쉽다
- 메모리 사용 측면에서도 효율적이다
- 짧은 시간에 집중되는 트래픽도 처리 가능하다. 버킷에 남은 토큰이 있기만 하면 요청은 시스템에 전달된다.
단점
- 버킷 크기와 토큰 공급률을 적절하게 튜닝하는게 까다롭다.
토큰 버킷 알고리즘과 비슷하지만 요청 처리율이 고정되어 있다는점이 다르다.
FIFO 큐로 구현한다.
누출 버킷 알고리즘은 두 개의 인자를 받는다
- 버킷 크기 : 큐 사이즈와 같은 값이다. 큐에는 처리될 항목들이 보관된다
- 처리율 : 지정된 시간당 몇 개의 항목을 처리할지 지정하는 값
장점
- 큐의 크기가 제한되어 있어 메모리 사용량 측면에서 효율적
- 고정된 처리율을 갖고 있기 때문에 안정적 출력이 필요한 경우 적합
단점
- 단시간에 많은 트래픽이 몰리는 경우 큐에 오래된 요청들이 쌓이게 되고, 그 요청들을 제때 처리 못하면 최신 요청들은 버려지게 된다.
- 두 개 인자를 갖고 있는데, 이들을 올바르게 튜닝하기가 까다로울 수 있다.
- 타임라인을 고정된 간격의 윈도로 나누고, 각 윈도마다 카운터를 붙인다.
- 요청이 접수될 때마다 이 카운터의 값은 1씩 증가한다.
- 이 카운터의 값이 사전에 설정된 임계치에 도달하면 새로운 요청은 새 윈도가 열릴때까지 버려진다.
장점
- 메모리 효율이 좋다
- 이해하기 쉽다
- 윈도가 닫히는 시점에 카운터를 초기화하는 방식은 특정한 트래픽 패턴을 처리하기에 적합하다.
단점
- 윈도 경계 부근에서 임시적으로 많은 트래픽이 몰려드는 경우, 기대했던 시스템 처리 한도보다 많은 양의 요청을 처리하게 된다.
p.63 잘 이해 안됨
왜 보관하지?
장점
- 정교하게 구현 가능
단점
- 거부된 요청의 타임스탬프로 보관하므로 다량의 메모리를 사용한다.
장점
- 이전 시간대의 평균 처리율에 따라 현재 윈도의 상태를 계산하므로 짧은 시간에 몰리는 트래픽에도 잘 대응한다.
- 메모리 호율이 좋다
단점
- 직전 시간대에 도착한 요청이 균등하게 분포되어 있다고 가정한 상태에서 추정치를 계산하기 때문에 다소 느슨하다.
어떤 요청이 한도 제한에 걸리면 API는 HTTP 429(too many request)를 보낸다.
처리율 제한 장치가 사용하는 HTTP 헤더
- X-Ratelimit-Remaining : 윈도 내에 남은 처리 가능한 요청의 수
- X-Ratelimit-Limit : 매 윈도마다 클라이언트가 전송할 수 있는 요청의 수
- X-Ratelimit-Retry-After : 한도 제한에 걸리지 않으려면 몇 초 뒤에 요청을 다시 보내야 하는지 알림
사용자가 너무 많은 요청을 보내면 429 too may request 오류를 X-Ratelimit-Retry-After 헤더와 함께 반환한다.
q1. DOS 와 DDOS 의 차이?