처리율 제한 장치의 설계

4장 처리율 제한 장치의 설계

처리율 제한 장치 (rate limiter) 클라이언트 또는 서비스가 보내는 트래픽의 처리율을 제어하기 위한 장치 API 요청 횟수가 제한 장치에 정의된 임계치를 넘어서면 추가로 도달한 모든 호출은 처리가 block 된다.

예시) 사용자는 초당 2회 이상 새 글을 올릴 수 없다. 같은 IP 주소로는 하루에 10개 이상의 계정을 생성할 수 없다.

 

장점

• Dos(Denial of Service) 공격에 의한 자원 고갈을 방지할 수 있다.
• 비용을 절감할 수 있다. 우선순위가 높은 API에 더 많은 자원을 할당할 수 있다.
• 서버 과부하를 막는다. 봇에서 오는 트래픽이나 사용자의 잘못된 이용 패턴으로 유발된 트래픽을 걸러낼 수 이다.

1단계) 문제 이해 및 설계 범위 확정

문제를 이해하기 위한 몇가지 질문을 통해서 설계에 대해 구체화해보자.

 

다양한 형태의 제어 규칙을 정의할 수 있도록 해야할까?

=> 그렇다. 유연한 제한 장치를 설계해야 한다. 대규모 요청 처리 가능, 분산 환경에서 동작해야 한다.

 

제한되었다는 사실을 클라이언트가 알아야할까?

=> 제한된 경우 그 사실을 알려주어야 한다.

 

설계 요규사항을 정리하면 다음과 같다.

• 분산형처리율 제한 : 하나의 처리율 제한 장치를 여러 서버나 프로세스에서 공유할 수 있어야 한다.
• 예외 처리 : 요청이 제한되었을 때는 그 사실을 사용자에게 분명하게 보여주어야 한다.
• 높은 결함 감내성 : 제한 장치에 장애가 생기더라도 전체 시스탬에 영향을 주어서는 안된다.

2단계 개략적 설계안 제시 및 동의 구하기

• 배경지식
  • 클라우드 마이크로서비스의 경우 처리율 제한 장치는 보통 API 게이트웨이에 구현된다. API 게이트웨이는 처리율 제한, SSL 종단, 사용자 인증, IP 허용 목록 관리 등을 지원하는 위탁관리형 서비스다.
• 확인사항
  • 현재 사용하고 있는 기술 스택이 서버 측 구현을 지원하기 충분한 정도로 효율이 높은지 확인
  • 사업 필요에 맞는 처리율 제한 알고리즘을 선택, 제 3 사업자가 제공하는 게이트웨이를 사용한다면 제한될수도 있다.
  • 이미 API 게이트웨이를 사용하고 있다면 이곳에, 충분한 인력이 없다면 상용 API 게이트웨이를 쓰는 것이 좋다.

처리율 제한 알고리즘

• 토큰 버킷 알고리즘
  • 토큰 버킷이란? 토큰 버킷은 지정된 용량을 갖는 컨테이너, 토큰이 꽉 차면 더 이상 추가되지 않는다. 토큰 공급기는 매초 2개의 토큰을 추가한다. 버킷이 가득 차면 overflow된다.
  • 하나의 요청은 처리될 때마다 하나의 토큰을 사용한다. 충분한 토큰이 있는 경우, 버킷에서 토큰 하나를 꺼내 요청을 시스템에 전달한다. 충분한 토큰이 없다면 해당 요청은 버려진다.
  • 버킷을 어디에 둘껀지? 버킷 크기 얼마나? 토큰 공급률은 얼마나?
  • 장점 구현이 쉽고, 메모리 사용에서도 효율적이다. 짧은 시간 집중되는 트래픽 처리 가능
  • 단점 버킷 크기와 토큰 공급율이라는 두 개 인자를 적절하게 튜닝하는 것은 까다롭다
• 누출 버킷 알고리즘
  • 토큰 버킷 알고리즘과 비슷하지만 요청 처리율이 고정되어 있다
  • FIFO 큐로 구현한다. 빈 자리가 있는 경우에는 큐에 요청을 추가하고, 큐가 가득 차 있는 경우에 새 요청은 버린다.
  • 장점 고정된 처리율을 갖고 있기 때문에 안정적 출력이 필요한 경우에 적합하다.
  • 단점 단 시간에 많은 트래픽이 몰리는 경우 큐에는 오래된 요청들이 쌓이게 되고, 제때 처리 못하면 최신 요청들은 버려지게 된다.
• 고정 윈도 카운터 알고리즘
  • 타임라인을 고정된 간격의 윈도로 나누고 각 윈도마다 카운터를 붙인다, 요청이 접수될 때마다 카운터가 증가하고, 임계치에 도달하면 새 윈도가 열릴때까지 버려진다.
  • 장점 메모리 효율이 좋다, 이해하기 쉽다, 윈도가 닫히는 시점에 카운터를 초기화하는 방식은 특정한 트래픽 패턴을 처리하기에 적합하다
  • 단점 윈도 경계 부근에 일시적으로 많은 트래픽이 몰려드는 경우, 기대했던 시스템의 처리 한도보다 많은 양의 요청을 처리하게 된다.
• 이동 윈도 로깅 알고리즘
  • timestamp를 추적한다. 레디스의 정렬 집합 같은 캐시에 보관한다. 새 요청이 오면 만료된 타임스탬프는 제거한다. 로그의 크기가 혀용치보다 같거나 작으면 요청을 시스템에 전달하고, 그렇지 않으면 처리를 거부한다.
  • 장점 어느 순간의 윈도를 보더라도 허용되는 요청의 개수는 시스템의 처리율 한도를 넘지 않는다
  • 단점 거부된 요청의 타임스탬프도 보관하기 때문에 다량의 메모리를 사용한다
• 이동 윈도 카운터 알고리즘
  • 장점 이전 시간대의 평균 처리율에 따라 현재 윈도의 상태를 계산하므로 짧은 시간에 몰리는 트래픽에도 잘 대응한다
  • 단점 직전 시간대에 도착한 요청이 균등하게 분포되어 있다고 가정한 상태에서 추정치를 계산하기 때문에 다소 느슨하다. 하지만 이 문제는 별로 안 심각하다.

개략적인 아키텍처 정하기

• 카운터는 어디에 보관할 것인지?
  • 데이터베이스는 디스크 접근 때문에 느리니까 안될 것이다. 메모리상 동작하는 캐시가 바람직한데, 레디스를 주로 많이 쓴다.
• 처리율 제한 미들웨어, 레디스에서 카운터를 가져와서, 한도에 도달했다면 거부, 도달하지 않았다면 API 서버로 요청 전달

3단계 상세 설계

• 처리율 제한 규칙은 config 파일로 관리한다.
• 처리율 한도 초과 트래픽의 처리
  • 429 Too many Requests를 보내거나, 큐에 보관했다가 나중에 처리한다.
  • HTTP 응답 헤더에 X-Ratelimit-Limit 처럼 전송할 수 있는 요청의 수, 몇초 뒤에 다시 보내야하는 지를 함께 반환하자
• 상세 설계
  • 처리율 제한 규칙은 디스크에서 읽어 캐시에 저장한다
  • 클라이언트가 유청을 보내면 먼저 처리율 제한 미들웨어에 도달한다
  • 카운터 및 타임스탬프를 레디스 캐시에서 가져온다.
  • 처리율 제한에 걸렸다면 429를 보내고, 아니라면 API 서버로 보낸다.
• 분산 환경에서의 처리율 제한 장치의 구현
  • 경쟁 조건
    • 스레드가 각각 병렬로 counter값을 기록하고 +1을 할 때, 락을 한다면 시스템 성능을 상당히 떨어트린다.
  • 동기화 이슈
    • 처리율 제한 장치 서버를 여러 대 두면 동기화가 필요하다.
      • sticky session을 써서 같은 클라이언트로부터의 요청은 항상 같은 처리율 제한 장치로 가도록 하면 어떨까? => 이것은 규모면에서 확장 가능하지도 않고 유연하지도 않다.
      • 레디스와 같은 중앙 집중형 데이터 저장소를 쓰는 것을 추천한다.
  • 성능 최적화
    • 여러 데이터 센터를 지원하자. 사용자의 트래픽을 가장 가까운 에지 서버로 전달하여 지연시간을 줄인다.
  • 모니터링
    • 처리율 제한 규칙이 너무 빡빡해서 많은 요청이 버려지고 있지 않은지?
    • 트래픽이 급증할 때 처리율 제한 장치가 효율적으로 동작하는 지? ⇒ 이 경우에는 알고리즘을 바꾸는 것은 어떨까? 토큰 버킷이 적합할 것이다.

4단계 마무리

다음과 같은 문제들을 추가적으로 고려하여 설명하면 좋다.

• 경성(hard) 처리율 제한 : 요청의 개수는 임계치를 절대 넘어설 수 없다.
• 연성(soft) 처리율 제한 : 요청 개수는 잠시 동안은 임계치를 넘어설 수 있다
• 애플리케이션 계층에서의 처리율 제한이 아니라 다른 계층에서도 제한 적용 가능하다.
• 처리율 제한을 회피하려면 클라이언트를 어떻게 설계하는 것이 좋을까?
  • 캐시를 사용하여 API 호출 횟수를 줄이도록, 재시도 로직을 구현할 때는 충분한 back-off 시간을 두도록

 

* 가망 면접 사례로 배우는 대규모 시스템 설계 기초 4장을 정리한 내용입니다