처리율 제한 장치

• 클라이언트가 보내는 트래픽을 처리하는 처리율을 제한하기 위한 장치

  ⇒ 임의로 설정한 처리율을 넘어가는 트래픽을 받으면, 해당 트래픽을 추후에 처리하거나 버리는 등의 역할을 한다.

처리율 제한 장치 필요성

1. DoS 공격에 의한 자원 고갈 방지
   • ip 등의 기준에 대한 트래픽 제한 기능을 갖고 있기 때문에 DoS 공격에 의한 자원 고갈을 어느정도 막을 수 있다.
2. 비용 절감
   • 비용이 들어가는 API 등에 대한 추가 요청을 제한할 수 있기에 비용 절감 효과가 있다.
3. 서비스 과부하 방지
   • 봇에 의한 트래픽이나 사용자의 잘못된 사용에 의한 대규모 트래픽을 방지할 수 있다.

처리율 제한 장치 설계시 고려사항

• 아래 요소들에 대해서 고려해야 한다.
  1. 설정된 처리율을 초과하는 요청은 어떻게 관리할것인가?
  2. 처리율 제한 장치가 HTTP 응답 시간에 나쁜 영향을 주지는 않는가?
  3. 메모리를 많이 사용하지는 않는가?
  4. 하나의 처리율 제한 장치를 여러 프로세스에서 공유하는가?
  5. 트래픽 제한 장치로 인해 요청이 제한되었을 때 사용자에게 그 사실을 명확히 보여주는가?
  6. 제한 장치의 장애가 전체 시스템에 악영향을 주는가?

처리율 제한장치의 개략적 설계

처리율 제한장치의 위치

• 클라이언트, 서버, 미들웨어 중 한 부분에 놓을 수 있다.
• 클라이언트의 처리율 제한 장치
  • 안정적으로 처리율 제한을 할 수 있지 않다. 클라이언트 요청은 쉽게 위변조 할 수 있기 때문이다.
• 미들웨어의 처리율 제한 장치
  • 클라우드 마이크로서비스에서는 API 게이트웨이라는 미들웨어에 처리율 제한 장치를 구현한다.
  • API 게이트웨이에서 제공하는 처리율 제한 알고리즘이 현재 서비스에 부합하다면, 미들웨어에 설치하는 것을 고려해볼 수 있다.
• 서버의 처리율 제한 장치
  • 서버에서 처리율을 제한하는 방법이다.
  • 현재 나에게 필요한 처리율 제한 장치를 API 미들웨어에서 제공해주지 않는다면, 직접 처리율 제한 장치를 구현하는 것도 고려해볼 수 있다.

처리율 제한 알고리즘

1. 토큰 버킷 알고리즘
   • 아마존이나 스트라이프 등의 기업들이 API 요청을 통제하기 위해 토큰 버킷 알고리즘을 활용한다.
   • 아래와 같은 방식으로 동작한다.
     1. 일정 시간마다 특정 개수의 토큰을 버킷에 추가한다. 이때 버킷의 용량을 초과하는 경우, 초과하는 토큰은 버린다.
     2. 요청을 처리할 때마다 버킷에서 토큰 하나를 버린다. 만약, 버킷에 토큰이 없다면, 해당 요청은 버린다.
   • 아래 2개의 인자를 활용한다.
     • 버킷의 크기
     • 단위 시간당 토큰 공급률
   • 통상적으로는 API 엔드포인트마다 별도의 버킷을 둔다. 해당 버킷은 사용자마다 갖고 있어야 하기에 {API 엔드 포인트 수 * 사용자}만큼의 버킷이 필요하다.
   • IP 주소별 처리율 제한을 하기 위해서 IP 주소별로 버킷을 둘 수도 있다.
   • 시스템의 처리율을 제한하고 싶다면, 모든 요청이 하나의 버킷을 공유하도록 할 수 있다.
   • 장점
     • 구현이 쉽고 메모리 사용측면에서 효율적임
     • 토큰이 없으면 요청이 처리되지 않기에 짧은 시간에 집중되는 트래픽을 처리하기에도 좋다.
   • 단점
     • 두 인자(버킷 크기, 토큰 공급률)를 적절하게 조정하기 어렵다.
     • 인자값이 너무 작으면 버려지는 요청이 많을 것이고, 버킷이 너무 크면 서버에 부하가 올 수 있다.
2. 누출 버킷 알고리즘
   • 아래와 같은 방식으로 동작한다.
     • 요청이 도착하면 큐에 요청을 저장한다. 만약 큐에 공간이 없다면 요청을 버린다.
     • 일정 시간마다 FIFO 방식으로 큐에서 요청을 꺼내서 처리한다.
   • 아래 2개의 인자를 활용한다
     • 버킷 크기(큐의 크기)
     • 처리율 : 단위 시간당 큐에서 꺼내서 처리할 요청 수
   • 장점
     • 큐의 크기가 제한되어 있기에 메모리 사용 측면에서 효율적임
     • 고정된 처리율을 갖고 있기에 안정적 출력을 보장함
   • 단점
     • 트래픽이 집중되면, 오래된 요청이 쌓이기에 최신 요청이 버려진다.
     • 두 인자를 적절하게 조정하기 어렵다.
3. 고정 윈도 카운터 알고리즘
   • 아래와 같은 방식으로 동작한다.
     • 타임라인(시간선)을 고정된 간격의 윈도로 나누고 각 윈도마다 카운터를 할당함.
     • 현재 시간에 접수된 요청은 현재 윈도의 카운터 값을 1 증가시킴
     • 카운터 값이 임계치에 도달하면, 다음 윈도가 열리기 전까지 버려짐.
   • 장점
     • 윈도가 닫히는 시점에 카운터를 초기화하기에 특정 트래픽 패턴을 처리하기 좋음
     • 메모리 효율이 좋음
   • 단점
     • 윈도 경계 부근에서 일시적으로 많은 트래픽이 집중되면, 기대했던 단위 시간당 트래픽 처리율보다 많은 요청을 처리하기 됨
       • ex) 윈도가 열리기 직전에 3개, 열리고 나서 바로 2개의 요청이 처리되는 꼴로 트래픽이 몰렸고, 하나의 윈도에서 최대 3개를 처리할 수 있다면, 결국 5개의 요청을 하나의 윈도에서 처리하는 것과 다름이 없다.