서버, 클라이언트 모두 가능하겠지만, 클라이언트는 위변조가 가능하기 때문에 servier side
application server에 직접 구현하거나, 미들 웨어로 rate limiter를 두어서 요청을 제한
일반적으로 rate limiter는 API gateway에 구축하는 편 - API gateway = 클라이언트의 API 요청을 적절한 서비스로 라우팅 - API Gateway가 고유한 기술이라는 오해 - API Gateway는 다양한 유형의 프록시(가장 일반적으로 ADC 또는 로드 밸런서 및 리버스 프록시, 그리고 점점 더 Ingress Controller 또는 Service Mesh)를 통해 구현될 수 있는 일련의 사용 사례 - Rate limiting도 API Gateway의 일반적인 사용 사례
rate limit 적용한 상세 설계
클라이언트가 요청을 서버에 보내면 요청은 먼저 처리율 제한 미들웨어에 도달
처리율 제한 미들웨어는 제한 규칙을 캐시에서 가져옴
카운터 및 마지막 요청의 타임스탬프를 레디스 캐시에서 가져옴 - 해당 요청이 처리율 제한에 걸리지 않은 경우 API를 서버로 보냄 - 제한범위 이상의 Request를 보낸 경우 HTTP 상태코드 429(Too many request)로 응답
제한된 요청은 버릴 수도 있고, 메시지 큐에 보관할 수도 있다.
header에 추가적인 정보를 줄 수 있다. - X-Ratelimit-Remaining : 윈도 내 남은 처리 가능 요청 수 - X-Ratelimit-Limit : 매 윈도마다 클라이언트가 전송할 수 있는 요청의 수 - X-Ratelimit-Retry-After : 한도 제한에 걸리지 않기 위해 몇 초 뒤에 요청을 다시 보내야 하는지 알림
One of the most useful, but often misunderstood and misconfigured, features of NGINX is rate limiting. (가장 유용하지만, 종종 오해되고 잘못 구성되는 NGINX 기능 중 하나는 처리율 제한입니다.) https://www.nginx.com/blog/rate-limiting-nginx/
동일한 기능의 설정이 annotation과 configmap 양쪽에 있으면 annotation이 우선 작동
nginx.ingress.kubernetes.io/limit-rps: "1"
- 주어진 IP로부터 초당 수락된 요청 수
버스트 제한은 이 제한에 버스트 승수를 곱한 값으로 설정, 기본 승수는 5
nginx.ingress.kubernetes.io/limit-burst-multiplier: "1"
- 버스트 크기에 대한 제한 속도의 승수. 기본 버스트 배율은 5
