처리율 제한 장치(Rate Limiter) 설계

[가상 면접 사례로 배우는 대규모 시스템 설계]를 읽고 작성하는 포스트입니다.

 

틀린 내용이 있을 수도 있습니다! 

틀린 내용이 있다면 댓글로 달아주시면 감사하겠습니다!

 

이번 포스팅은 처리율 제한 장치의 개념, 설계할 때 고려해야 할 부분 등에 대한 내용을 정리한다.

 

처리율 제한 장치(Rate Limiter)란?

- 처리율 제한 장치는 클라이언트 또는 서비스가 보내는 트래픽의 처리율을 제어하기 위한 장치다. 

- 특정 기간 동안 전송되는 클라이언트의 요청을 제한하는 장치다. 

- 정의된 임계치를 넘어가면 이후에 들어온 모든 요청들의 처리를 중단한다.  

 

구체적으로 다음과 같은 경우들을 예로 들 수 있다.  

- 사용자는 초당 2회 이상의 새 글을 올릴 수 없음

- 같은 IP 주소로 하루에 10개 이상의 계정을 생성할 수 없음

- 같은 디바이스로 주당 5회 이상 리워드를 요청할 수 없음

 

처리율 제한 장치의 장점 

- 임계치 이상의 요청이 들어왔을 때 처리를 중단함으로써 Dos 공격을 방지할 수 있다. 

- 여러 가지 방면에서 비용을 절감의 효과를 볼 수 있다. 예를 들면, 클라이언트가 접속하려는 서비스가 외부 API를 사용하는 경우, 클라이언트의 호출을 어느 정도 제한함으로써 외부 API 호출을 줄일 수 있기 때문이다.(외부 API 호출은 비용이 들기 때문에) 또한 서버 과부하를 어느 정도 예측할 수 있기 때문에 서버 유지 비용을 줄일 수 있다! 

 

처리율 제한 장치를 만들 때 고려해야 할 부분

1. 처리율을 클라이언트 측에서 제한할 것인가? 서버 측에서 제한할 것인가?

1) 클라이언트 측에 두는 방식 

일반적으로 클라이언트 측에 두는 방식은 좋지 않다.

클라이언트의 요청은 쉽게 위변조가 가능하므로 모든 클라이언트를 관리하기 힘들기 때문이다.  

 

2) 서버 측에 두는 방식 

서버 측에 두는 경우, 서버와 함께 두거나 서버 앞단의 미들웨어를 거치도록 하는 방식을 이용할 수 있다.

MSA 구조를 사용하는 경우, 주로 API 게이트웨이 컴포넌트를 따로 두어서 처리율 제한 기능을 사용할 수 있다.  

이외에도 API 게이트웨이는 처리율 제한, SSL Termination, 사용자 인증, whitelist 관리 등의 기능을 제공할 수 있다.   

 

참고로 위 방식들 중에는 정답은 없으며, 이는 현재 회사의 기술 스택이나 엔지니어링 인력, 우선순위, 목표에 따라 달라질 수 있다. 

 

2. 어떤 처리율 제어 규칙을 사용할 것인가?

처리율 제한 규칙은 다음과 같은 것들이 될 수 있다.

- 사용자는 초당 2회 이상의 새 글을 올릴 수 없음

- 같은 IP 주소로 하루에 10개 이상의 계정을 생성할 수 없음

- 같은 디바이스로 주당 5회 이상 리워드를 요청할 수 없음

 

이러한 처리율 제어 규칙들은 보통 설정 파일로 디스크에 저장되며 사용할 때는 캐시에 저장해놓고 사용한다. 

 

그리고  사용자의 응답이 처리율 규칙에 의해 처리율 한도에 걸렸을 때 사용자에 대한 응답 또한 고려해야 한다. 

이는 response header를 통해서 처리할 수 있다. 

HTTP 429 status(too many request)와 다음과 같은 헤더를 포함해서 사용자에게 보낸다. 

X-Ratelimit-Remaining:  window 내에 남은 처리 가능 요청 수

X-Ratelimit-Limit: window 마다 클라이언트가 전송할 수 있는 요청 수

X-Ratelimit-Retry-After: 한도 제한에 걸리지 않으려면 몇 초 뒤에 요청을 보내야 하는지

 

3. 어떤 처리율 제한 알고리즘을 사용할 것인가?

처리율을 제한하는 알고리즘은 다음과 같이 여러 가지가 있는데, 각기 다른 장단점을 가지고 있기 때문에 알고리즘의 특성들을 알고 용례에 맞게 사용해야 한다. 

1) 토큰 버킷(Token bucket)

2) 누출 버킷(Leaky bucket)

3) 고정 윈도 카운터(Fixed window counter)

4) 이동 윈도 로그(Sliding window log)

5) 이동 윈도 카운터(Sliding window counter)

 

알고리즘들의 특성은 나중에 다른 포스팅으로 정리해야겠다. 

지금은 다른 분이 정리해놓으신 포스팅에서 봅시다. 

대규모 시스템 설계 기초 - 처리율 제한 장치

 

4. 분산 환경에서 처리율 제한 장치를 구현해야 하는가?

대규모 트래픽을 다루어야 하는 경우, 분산 환경 아키텍처에 대한 고려가 필요하기 때문에 이에 대한 처리율 장치에 대한 고려 또한 필요하다. 단일 서버를 지원하는 처리율 제한 장치 구현은 어렵지 않지만, 여러 대의 서버를 지원하는 처리율 제한 장치를 구현하기는 어렵기 때문이다. 

분산 환경에서 처리율 제한 장치를 구현해야 하는 경우, 경쟁 조건과 동기화 이슈 문제가 발생할 수 있기 때문이다. 

 

1) 처리율 제한 장치에서 멀티스레드 사용 시 경쟁 조건 발생 가능성 

(책에서 말하고 있는 상황은 한 대의 처리율 제한 서버에서 멀티 스레드를 사용하는 상황을 의미하는 것 같다.) 

처리율 제한 장치는 레디스와 같은 인메모리 DB에서 count 값을 읽고, count 값이 임계치를 넘는지 확인한 후, 요청을 처리한다. 

이때 2개의 스레드가 count 값을 처리할 때, 경쟁 조건이 발생할 수 있다. 경쟁 조건을 해결하기 위해 lock을 사용할 수 있지만, 이는 시스템 성능을 떨어뜨리기 때문에 루아 스크립트나 레디스의 자료구조인 정렬 집합을 이용하여 이를 해결할 수 있다. 

 

2) 여러 대의 처리율 제한 장치에서 동기화 이슈

한대의 처리율 제한 장치로는 부족할 수 있기 때문에 여러 대의 처리율 제한 장치에 대한 고려가 필요하다. 

클라이언트는 여러대의 처리율 제한 장치로 요청을 보내는 상황이 생기게 되고, 이때 동기화 문제가 발생할 수 있다.

예를 들면, 클라이언트 1, 2와 처리율 제한 장치 1, 2로 구성된 상황을 가정해보자.

클라이언트 1은 처리율 제한 장치 1에서 count 임계치를 넘겨 429 응답과 함께 요청이 제한되었다. 하지만 처리율 제한 장치 2에서는 count 임계치가 걸리지 않아서 처리율 제한 장치 2가 요청을 수용할 수 있게 되는 상황이 발생한다. 

이를 해결하기 위해서는 스티키 세션과 같은 방법을 이용해서 클라이언트 요청이 한 처리율 제한 장치로 향하게 하여 해결할 수는 있지만, 이는 분산 환경에서는 좋지 않은 방법이다.

더 나은 방법으로 레디스와 같은 인메모리 DB를 중앙 집중형 저장소로 사용하여 문제를 해결할 수 있다.

 

 

처리율 제한 장치 플로우 동작

 

 

1. 클라이언트가 요청을 보내면 요청은 처리율 제한 미들웨어로 도달한다.

2. 처리율 제한 장치는 처리율 제한 규칙을 캐시에서 가져온다. 

3. 카운터 및 마지막 요청의 타임스탬프를 레디스에서 가져와 다음과 같이 처리한다. 

1) 처리율 제한에 걸리는 경우, 클라이언트에게 429 response을 보내고, 요청을 버리거나 메시 지큐에 저장해놓는다.  

2) 처리율 제한에 걸리지 않는 경우, API 서버에게 요청을 전송한다. 

 

모니터링 하기

모니터링을 통해서 현재 채택한 처리율 제한 알고리즘과 처리율 제한 규칙이 효율적인지 판단해야 한다.  

처리율 제한 규칙이 엄격할수록, 유효 요청들이 처리되지 못할 것이고, 

알고리즘에 문제가 있을 경우, 트래픽이 급증할 때 문제가 발생할 것이기 때문이다. 

참고로 트래픽이 급증하는 경우, 일정 시간 동안 정해진 크기만큼 처리할 수 있는 토큰 버킷 알고리즘이 적합하다. 

 

추가적으로 고려할 부분 

1. 처리율 제한을 hard하게 할 것인가? soft하게 할 것인가?

1) 처리율 제한을 hard하게 한 경우

요청의 개수가 임계치를 절대 넘을 수 없다.

 

2) 처리율 제한을 soft하게 한 경우

요청의 개수가 잠시 임계치를 넘을 수 있다.

 

2. 다양한 계층의 처리율 제한 

여러 가지 OSI 계층에서도 처리율 제한을 할 수 있다. 

예를 들어, 특정 URI를 기반으로 처리하면 L7에서의 처리율 제한이고, 

Iptables를 이용하면 L3에서의 처리율 제한을 할 수 있는 것이다.

 

3. 처리율 제한을 회피하는 방법, 클라이언트는 어떻게 설계하는 좋을까?

클라이언트가 불필요한 요청을 보내지 않도록, 클라이언트가 보내는 API 요청을 캐시 하도록 설계하는 방법이 있다. 

또한 재시도 로직을 구현할 때 backoff 시간을 두어서 구현함으로써, 유효한 요청을 보내도록 하는 방법이 있다.