처리율 제한 장치(rate limiter)란,
클라이언트 또는 서비스가 보내는 트래픽의 처리율(rate)을 제어하기 위한 장치e.g) 특정 기간 내에 전송되는 클라이언트의 요청 횟수르 제한한다. API 요청 횟수가 임계치를 넘어서면 추가 요청은 처리가 중단된다.
API에 처리율 제한 장치를 두면 좋은 점
- DoS 공격에 의한 자원 고갈을 방지할 수 있다.
- 비용을 절감한다.
- 적은 서버, 자원의 효율적 분배, API 호출로 인한 과금 방지
- 서버 과부하를 막는다.
1단계: 문제 이해 및 설계 범위 확정
면접관과 소통하며 어떤 제한 장치를 구현해야 하는지 명확히 해라!
⇒ 어떤 알고리즘을 선택할 것인지
요구사항 예시
- 설정된 처리율을 초과하는 요청은 정확하게 제한한다
- 낮은 응답시간 : 이 처리율 제한 장치는 HTTP 응답시간에 나쁜 영향을 주어서는 곤란하다.
- 가능한 한 적은 메모리를 써야 하낟.
- 분산형 처리율 제한 : 하나의 처리율 제한 장치를 여러 서버나 프로세스에서 공유할 수 있어야 한다.
- 예외 처리 : 요청이 제한되었을 때는 그 사실을 사용자에게 분명하게 보여주어야 한다.
- 높은 결함 감내성 : 제한 장치에 장애가 생기더라도 전체 시스템에 영향을 주어서는 안 된다.
2단계: 개략적 설계안 제시 및 동의 구하기
처리율 제한 장치를 어디에 둘 것인지, 처리율 제한 알고리즘은 어떤 것을 사용할 것인지 생각해봐야 한다!
처리율 제한 장치는 어디에 둘 것인가?
- 클라이언트 측
- 클라이언트 요청은 위변조가 가능하여 권장하지 않는다.
- 서버 측
- 중앙화해서 관리한다.
- 미들웨어
- 요청이 서버로 들어오기 전, 미들웨어에서 먼저 처리
- 제한된 요쳥이라면, 미들웨어에 의해 가로막히고
429(Too many requests)반환 - MSA 인 경우, 처리율 제한 장치는 보통 API Gateway 에 구현
- API Gateway: 처리율 제한, SSL 종단, 사용자 인증, IP 허용 목록 관리 등
고려해야 할 사항
- 기술 스택을 점검하여, 서버 측 구현이 가능한지 점검
- 적절한 처리율 제한 알고리즘 찾기 (만약 제3 사업자가 제공하는 게이트웨이를 사용한다면 선택지는 제한)
- 만약 MSA + 이미 API 게이트웨이를 설계에 포함시켰다면, 처리율 제한 기능 또한 게이트웨이에 포함
- 시간 없으면 상용 API 게이트웨이 사용하기
처리율 제한 알고리즘
- 토큰 버킷 (Token bucket)
- 누출 버킷 (Leaky bucket)
- 고정 윈도 카운터 (Fixed window counter)
- 이동 윈도 로그 (Sliding window log)
- 이동 윈도 카운터 (Sliding window counter)
카운터는 어디에 보관할 것인가?
- 얼마나 많은 요청이 접수되었는지를 추적할 수 있는 카운터를 추적 대상별로 두고, 이 카운터의 값이 어떤 한도를 넘어서면 한도를 넘어 도착한 요청은 거부한다.
- 사용자별로 or IP 주소별로 or API 엔드포인트나 서비스 단위로 추적할지 선택
- 이러한 카운터는 빠르고 시간에 기반한 만료 정책을 제공하는 캐시가 바람직하다.
3단계: 상세 설계
처리율 제한 규칙
- 처리율 한도 초과 트래픽의 처리
- 한도 제한 →
HTTP 429 (too many requests)응답 - 경우에 따라, 한도 제한에 걸린 메시지를 큐에 보관하여 나중에 처리할 수도 있다.
- 한도 제한 →
- 처리율 제한 장치가 사용하는 HTTP 헤더
- 클라이언트가 처리율 제한을 감지하는 법?! 👉 HTTP 응답 헤더를 통해!
- X-Ratelimit-Remaining: 윈도 내에 남은 처리 가능 요청의 수
- X-Ratelimit-Limit: 매 윈도마다 클라이언트가 전송할 수 있는 요청의 수
- X-Ratelimit-Retry-After: 한도 제한에 걸리지 않으려면 몇 초 뒤에 요청을 다시 보내야 하는지 알림
분산 환경에서의 처리율 제한 장치의 구현
여러 대의 서버와 병렬 스레드를 지원하기 때문에 아래와 같은 문제를 고려해야 한다.
- 경쟁 조건
- 분산 환경에서 동시에 카운터 값에 접근하여 업데이트를 하면, 경쟁 조건 이슈가 발생할 수 있다.
- Lock을 통해 해결하는 것이 가장 쉽지만, 성능이슈..! 다른 해결법은 아래와 같다.
- 루아 스크립트
- redis의 sorted set 자료구조
- 동기화 이슈
- 웹 계층은 state-less하기 때문에, 클라이언트의 요청이 매번 다른 제한 장치로 가게 된다면 처리율 제한을 올바르게 수행할 수 없게 된다.
- 같은 클라이언트로부터의 요청은 항상 같은 장치로 보내는 고정 세션 방식은 있으나, 확장 가능성이나 유연성이 떨어져 비추한다.
- 대신 redis와 같은 중앙 집중형 데이터 저장소를 추천한다!
성능 최적화
- 데이터 센터 지원으로 latency 높아질 수도.. → 에지 서버 사용
- 제한 장치 간에 데이터를 동기화할 때 최종 일관성 모델 사용
4단계: 마무리
경성(hard) 또는 연성(soft) 처리율 제한
- 경성 처리율 제한 : 요청의 개수는 임계치를 절대 넘어설 수 없다.
- 연성 처리율 제한 : 요청 개수는 잠시 동안은 임계치를 넘어설 수 있다.
다양한 계층에서의 처리율 제한
- 애플리케이션 계층(7번 계층)에서의 처리율 제한 외에도 다른 계층에서 제어를 사용하여 IP 주소에 처리율 제한을 적용
처리율 제한을 회피하는 방법
- 클라이언트 측 캐시를 사용하여 API 호출 횟수 줄이기
- 예외나 에러를 처리하는 코드를 도입하클라이언트가 예외적 상황으로부터 우아하게 복구될 수 있도록 한다.
- 재시도 로직을 구현할 때는 충분한 백오프 시간을 두도록 한다.
