fuzzysound
commented
1 year ago 느낀점
아마 현재의 rate limiter는 대부분 api gateway로 구현하는 게 정석이 되지 않았을까 싶다. 최근에는 서비스에 api gateway를 두는 게 필수적인 패턴이기 때문이다.
정리
- 처리율 제한 장치 (rate limiter): 트래픽 처리율을 제어하기 위한 장치. Dos 방어, 비용 절감, 서버 과부하 방지를 위해 사용한다.
- 처리율 제한 장치 설계시 고려할 사항
- 제어 기준 (IP 주소, 사용자 등)
- 장치의 위치 (클라이언트 / 서버)
- 알고리즘
- 예외처리 방식
- 분산 환경
- 성능 최적화 방법
- 처리율 제한 알고리즘의 종률
- 토큰 버킷: 일정 시간마다 토큰을 발급해 토큰마다 요청을 처리할 수 있도록 한다.
- 누출 버킷: FIFO 큐를 이용해 요청을 처리한다. 요청은 고정된 속도로 처리된다.
- 고정 윈도 카운터: 일정 시간 윈도우마다 요청 처리 한계치를 두고 처리한다.
- 이동 윈도 로깅: 각 요청의 타임스탬프를 저장하며 매번 윈도우를 새로 설정한다.
- 이동 윈도 카운터: 현재 윈도우와 직전 윈도우를 비율적으로 고려해 요청을 카운팅한다.
- 처리율 제한 규칙의 저장: config 파일 형태로 디스크에 저장된다.
- 한도 초과 요청의 처리: 처리율 제한 관련 헤더들과 함께 429 응답을 보낸다.
- 분산 환경에서의 구현: race condition과 동기화 문제를 해결해야 한다.
- race condition: 레디스에서 루아 스크립트나 sorted set을 이용해 해결할 수 있다.
- 동기화: 레디스와 같은 중앙 집중형 데이터 저장소를 사용한다.
몰랐던 내용
처리율 제한 알고리즘에 대해 처음 알았다.
더 알아본 내용
- 레디스 sorted set의 내부 자료구조 skip list: http://redisgate.kr/redis/configuration/internal_skiplist.php
- skip list: linked list를 개선하여 탐색과 삽입을 빠르게 할 수 있는 자료구조 (메모리를 희생)
- sorted set이 어떻게 실시간으로 빠르게 정렬하면서도 멤버 수에 따른 오버헤드가 커지지 않는지 알 수 있다.
- 토큰 버킷 알고리즘에서 sorted set을 이용한 race condition 해결 방법: https://engineering.classdojo.com/blog/2015/02/06/rolling-rate-limiter/
- 각 유저마다 sorted set을 하나씩 둔다. score는 요청 시간 timestamp이다.
- 새 요청이 들어오면
MULTI를 사용해 아래 연산을 atomic하게 처리한다. ZREMRANGEBYSCORE를 사용해 (새 요청의 timestamp - 토큰 발급 interval) 이전 엘리먼트들을 모두 삭제한다.ZRANGE(0, -1)을 사용해 sorted set의 모든 엘리먼트를 카운팅한다.ZADD를 사용해 새 요청의 timestamp를 sorted set에 추가한다.- 토큰 발급 인터벌만큼 TTL을 설정한다. (
EXPIRE) - 위 연산이 끝난 후 카운팅된 엘리먼트 수가 제한 건수를 넘어섰는지 비교하여 요청을 받을지 말지를 결정한다.
- Nginx의 rate limiter: https://www.nginx.com/blog/rate-limiting-nginx/
- 누출 버킷 알고리즘을 사용한다.
- 2-stage rate limiting: 요청이 많이 들어올 때, 일정 수준까지는 딜레이 없이 처리 / 그 이후 일정 수준까진 딜레이를 두고 처리 / 그 이외에는 거부
질문
- MSA에서 가장 앞단의 api gateway 말고도 각 마이크로서비스별로 rate limit을 설정하는 것의 의의?
- 모든 rate limiter가 단일 저장소를 사용한다면, 단일 저장소가 SPOF가 되지 않기 위해서 어떻게 해야 할까? -> redis cluster?
xodhx4
HaeUlNam
Template
느낀점
정리
몰랐던 내용
더 알아본 내용
질문