반응형
rate limit을 두는 이유?
- 잠재적인 brute force attacks에 대비한 추가 보안 계층 역할
- 트래픽 급증을 방지하여 안정적인 서버 확보
- 사용자의 tier에 따라 service를 제한하는 역할 (ex) download )
Siege를 이용해 server에 load testing
$ apt-get install siege
# siege -v -r 2 -c 5 https:///thumb.png
c5 * r2 = 10 requests
- r: request test 수
- c: concurrent connection
limit_req_zone $request_uri zone=MYZONE:10m rate=1r/s
- limit_req_zone: rate limit을 적용할 zone을 정의
- $server_name (서버에 들어오는 모든 요청)
- $binary_remote_addr (user당)
- $request_uri (URI 당)
- zone: rate limit 을 적용할 zone의 이름과 memory에 저장할 zone의 size를 정의 (메모리는 뭘까)
- rate: limit rate을 정의하고 초당 1개의 requests를 초과하지 않도록 제한
rate limit을 적용하면 처음 1개의 request만 성공, 나머지는 모두 503 (Service Unavailable)
burst
- burst를 적용하면 rate limit을 초과하는 connect을 즉시 reject하지 않고 기다리게 만들 수 있음
limit_req_zone $request_uri zone=MYZONE:10m rate=10r/s burst=5
- 1 + 5burst = 6 connection을 가질 수 있음. 하지만 5개는 바로 response하진 않음
- 약간의 버퍼를 제공하고 요청 속도는 늦쳐짐
- 내부적으로 간단한 queue를 사용 (https://www.nginx.com/blog/rate-limiting-nginx/)
- 첫 요청은 바로 처리, 나머지는 4개는 순차적으로 1r/s에 맞춰 처리
- 다음 5개의 연결이 전송되면 동일하게 처리됨, 하지만 9.33초 걸림
burst를 초과하도록 요청하면,
- 한번에 15개를 요청하면, 1 + 5burst 이외에 9개는 즉시 503 error 발생
- 나머지 5burst는 순차적으로 처리됨
nodelay : 허용된 버스트 요청을 가능한 빨리 처리
- burst를 적용한 zone에 적용 가능
limit_req zone=MYZONE burst=5 nodelay;
- burst 수 만큼의 connection은 rate limit 무시하고 즉시 처리
- 즉시 response되었어도 다음 새로운 request에서는 여전히 동일한 rate limit 적용 받음
- 첫 6개의 요청은 모두 성공
- 2초 정도 머문 후 다음 요청을 했다고 가정하면, 2개의 요청만 처리가능한 시간이 지났으므로 나머지는 모두 503 error
Reference
반응형