4장 : 처리율 제한 장치의 설계
네트워크 시스템에서 처리율 제한 장치(rate limiter)는 클라이언트 또는 서비스가 보내는 트래픽의 처리율(rate)을 제어하기 위한 장치다. HTTP를 예로 들면이 장치는 특정 기간 내에 전송되는 클라이언트의 요청 횟수를 제한한다. API 요청 횟수가 제한 장치에 정의된 임계치(threshold)를 넘어서면 추가로 도달한 모든 호출 은 처리가 중(block)된다.
사용자는 초당 2회 이상 새 글을 올릴 수 없다.
같은 IP 주소로는 하루에 10개 이상의 계정을 생성할 수 없다.
같은 디바이스로는 주당 5회 이상 리워드(reward)를 요청할 수 없다.
처리율 제한 장치 설계
DoS(Denial of Service) 공격에 의한 자원 고갈을 방지할 수 있다.
비용을 절감한다.
서버 과부하를 막는다.
1단계 : 문제 이해 및 설계 범위 확정
요구사항
설정된 처리율을 초과하는 요청은 정확하게 제한한다.
낮은 응답시간 : 이 처리율 제한 장치는 HTTP 응답시간에 나쁜 영향을 주어서는 곤란하다.
가능한 한 적은 메모리를 써야 한다.
분산형 처리율 제한(disributed rate limiting) : 하나의 처리율 제한 장치를 여러 서버나 프로세스에서 공유할 수 있어야 한다.
예외 처리 : 요청이 제한되었을 때는 그 사실을 사용자에게 분명하게 보여주어야 한다.
높은 결함 감내성(fault tolerance) : 제한 장치에 장애가 생기더라도 전체 시스템에 영향을 주어서는 안 된다.
2단계 : 개략적 설계안 제시 및 동의 구하기
일단 일은 너무 복잡하게 만드는 것은 피하고, 기본적인 클라이언트-서버 통신 모델을 사용하도록 하자.
처리율 제한 장치는 어디에 둘 것인가 ?
클라이언트 측에 둔다면 : 일반적으로 클라이언트 요청은 쉽게 위변조가 가능해서다. 모든 클라이언트의 구현을 통제하는 것도 어려울 수 있다.
서버 측에 둔다면 :
case 1
case 2
폭넓게 채택된 기술인 클라우드 마이크로서비스의 경우, 처리율 제한 장치는 보통 API 게이트웨이라 불리는 컴포넌트에 구현된다. API 게이트웨이는 처리율 제한, SSL 종단(termination), 사용자 인증(authentication), IP 허용 목록(whitelist) 관리 등을 지원하는 완전 위탁관리형 서비스(fully managed), 즉 클라우드 업체가 유지 보수를 담당하는 서비스다. 하지만 일단은 API 게이트웨이가 처리융ㄹ 제한을 지원하는 미들웨어라는 점만 기억하도록 하자.
처리율 제한 장치 위치를 정할 때 고려 사항
프로그래밍 언어, 캐시 서비스 등 현재 사용하고 있는 기술 스택 점검
필요에 맞는 처리율 제한 알고리즘 찾기
설계가 마이크로서비스에 기반하고 있고, 사용자 인증이나 IP 허용목록 관리 등을 처리하기 위해 API 게이트웨이를 이미 설계에 포함시켰다면 처리율 제한 기능 또한 게이트웨이에 포함시켜야 할 수도 있다.
처리율 제한 서비스를 직접 만드는 데는 시간이 든다. 처리율 제한 장치를 구현하기에 충분한 인력이 없다면 상용 API 게이트웨이를 쓰는 것이 바람직한 방법일 것이다.
처리율 제한 알고리즘 종류
토큰 버킷
누출 버킷
고정 윈도 카운터
이동 윈도 로그
이동 윈도 카운터
개략적인 아키텍처
처리율 제한 알고리즘의 기본 아이디어는 단순하다. 얼마나 많은 요청이 접수되었는지를 추적할 수 있는 카운터를 추적 대상별로 두고(사용자별로 추적할 것인가 ? 아니면 IP 주소별로 ? 아니면 API 엔드포인트나 서비스 단위로 ? ) 이 카운터의 값이 어떤 한도를 넘어서면 한도를 넘어 도착한 요청은 거부하는 것이다.
클라이언트가 처리율 제한 미들웨어에게 요청을 보낸다.
처리율 제한 미들웨어는 레디스의 지정 버킷에서 카운터를 가져와서 한도에 도달했는지 아닌지를 검사한다.
한도에 도달했다면 요청은 거부된다.
한도에 도달하지 않았다면 요청을 API 서버로 전달된다. 한편 미들웨어는 카운터의 값을 증가시킨 후 다시 레디스에 저장한다.
3단계 : 상세 설계
분산 환경에서의 처리율 제한 장치의 구현
경쟁 조건
락(lock) -> 성능을 떨어뜨림
루아 스크립트
정렬 집합(sorted set)
동기화 이슈
고정 세션(sticky session)
레디스와 같은 중앙 집중현 데이터 저장소 사용
성능 최적화
모니터링
모니터링 요소
채택된 처리율 제한 알고리즘이 효과적인지
정의한 처리율 제한 규칙이 효과적인지
4단계 : 마무리
deep dive
경성(hard) 또는 연성(soft) 처리율 제한
다양한 계층에서의 처리율 제한
처리율 제한을 회피하는 방법. 클라이언트를 어떻게 설계하는 것이 최선인가 ?
클라이언트 측 캐시를 사용하여 API 호출 횟수를 줄인다.
처리율 제한의 임계치를 이해하고, 짧은 시간 동안 너무 많은 메시지를 보내지 않도록 한다.
예외나 에러를 처리하는 코드를 도입하여 클라이언트가 예외적 상황으로부터 우아하게 (gracefully) 복구될 수 있도록 한다.
재시도(retry) 로직을 구현할 때는 충분한 백오프(back-off) 시간을 둔다.
Last updated
