개요
- 네트워크 시스템에서 처리율 제한 장치는 클라이언트 또는 서비스가 보내는 트래픽의 처리율을 제어하기 위한 장치
- API 요청 횟수가 제한 장치에 정의된 임계치를 넘어서면 추가로 도달한 모든 호출은 처리가 중단(block)됨
rate limiter의 장점
- DoS 공격에 의한 자원고갈을 방지
- 비용을 절감(외부 API 호출에 의한 과금)
- 서버 과부하를 막음
rate limiter 설계 시 중요하게 따져야 하는 것 과 몇가지 지침
처리율 제한 장치는 어디에 두어야 하나? 서버에 두어야 하나 아니면 게이트웨이에 두어야 하나
정답은 없다. 현재 기술 스택이나 엔지니어링 인력, 우선순위, 목표에 따라 달라질 수 있기에
일반적 지침
- 프로그래밍 언어, 캐시 서비스 등 현재 사용하고 있는 기술 스택을 점검하라. 현재 사용하는 프로그래밍 언어가 서버 측 구현을 지원하기 충분할 정도로 효율이 높은지 확인하라
- 여러분의 사업 필요에 맞는 처리율 제한 알고리즘을 찾아라
- 여러분의 설계가 마이크로서비스에 기반하고 있고, 사용자 인증이나 IP 허용목록 관리 등을 처리하기 위해 API 게이트웨이를 이미 설계에 포함시켰다면 처리율 제한 기능 또한 게이트웨이에 포함시켜야 할 수도 있다
- 처리율 제한 장치를 구현하는 데 시간이 걸리기에, 충분한 인력이 없다면 상용 API 게이트웨이를 쓰는 것이 바람직한 방법
처리율 제한 알고리즘
- 토큰 버킷
- 누출 버킷
- 고정 윈도 카운터
- 이동 윈도 로그
- 이동 윈도 카운터
개략적 아키텍처
처리율 제한 알고리즘의 기본 아이디어는 단순하다.
얼마나 많은 요청이 접수되었는지를 추적할 수 있는 카운터를 추적 대상별(사용자별로 추적할 것인가? 아니면 IP 주소별로? 아니면 API 엔드포인트나 서비스 단위로?)로 두고 이 카운터의 값이 어떤 한도를 넘어서면 한도를 넘어 도착한 요청은 거부하는 것
상세설계
처리율 제한 장치가 사용하는 HTTP 헤더
- X-Ratelimit-Remaining: 윈도 내에 남은 처리 가능 요청의 수
- X-Ratelimit-Limit : 매 윈도마다 클라이언트가 전송할 수 있는 요청의 수
- X-Ratelimit-Retry-After : 한도 제한에 걸리지 않으려면 몇초 뒤에 요청을 다시 보내야 하는지 알림.
사용자가 너무 많은 요청을 보내면 429 Too many requests 오류를 X-Ratelimit-Retry-After 헤더와 함께 반환하도록 한다.
상세 설계
- 처리율 제한 규칙은 디스크에 보관한다. 작업 프로세스는 수시로 규칙을 디스크에서 읽어 캐시에 저장한다.
- 클라이언트가 요청을 서버에 보내면 요청은 먼저 처리율 제한 미들웨어에 도달한다.
- 처리율 제한 미들웨어는 제한 규칙을 캐시에서 가져온다. 아울러 카운터 및 마지막 요청의 타임스탬프를 레디스 캐시에서 가져온다. 아울러 카운터 및 마지막 요청의 타임스탬프를 레디스 캐시에서 가져온다. 가져온 값들에 근거하여 해당 미들웨어는 다음과 같은 결정을 내린다.
- 해당 요청이 처리율 제한에 걸리지 않은 경우에는 API 서버로 보낸다
- 해당 요청이 처리율 제한에 걸렸다면 429 too many requests 에러를 클라이언트에게 보낸다. 한편 해당 요청은 그대로 버릴 수도 있고 메시지 큐에 보관할 수도 있다.
분산 환경에서의 처리율 제한 장치의 구현
- 경쟁 조건
- 경쟁 조건 문제를 해결하는 가장 널리 알려진 해결책은 락(lock)이다.
- 하지만 락은 시스템의 성능을 상당히 떨어뜨린다는 문제가 있다.
- 위 설계의 경우 락 대신 쓸수 있는 해결책이 두가지가 있는데, 하나는 루아 스크립트 이고 다른 하나는 정렬 집합(sorted set)이라 불리는 레디스 자료구조를 쓰는 것이다.
- 동기화 이슈
- 수백만 사용자를 지원하려면 한 대의 처리율 제한 장치 서버로는 충분하지 않을 수 있다. 그래서 처리율 제한 장치 서버를 여러 대 두게 되면 동기화가 필요해진다. → 중앙 집중형 데이터 저장소를 쓰는 것
- 성능 최적화
- 여러 데이터센터를 지원하는 문제는 처리율 제한 장치에 매우 중요한 문제임. 멀리 떨어진 사용자를 지원하려다 보면 지연시간이 증가할 수밖에 없기 때문에.
- 대부분의 클라우드 서비스 사업자는 세계 곳곳에 에지 서버를 심어놓고 있음
- 클라우드플레어(Cloudflare)는 지역적으로 분산된 194곳의 위치에 에지 서버를 설치해 두고 있다. 사용자의 트래픽을 가장 가까운 에지 서버로 전달하여 지연시간을 줄임
- 제한 장치 간에 데이터를 동기화할 때 최종 일관성 모델(eventual consistency model)을 사용하는 것
구현 선택 사항
- 처리율 제한만을 따로 뺄 것인지, 애플리케이션에 포함시킬 것인지
- 알고리즘 종류
- 추적 대상을 무엇으로 할지(ip, api 엔드포인트, 등등)
- 처리율 제한 규칙 conf 파일로 디스크에 관리
- 분산환경(race condition, syncronization)
- race condition → Lua script, redis sorted set
- syncronization → 최종 일관성 모델 사용