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

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

사례

- 사용자는 초당 2회 이상 새 글을 올릴 수 없다.
- 같은 IP 주소로 하루에 10개 이상의 계정을 생성할 수   없다.
- 같은 디바이스로 똑같은 글에 추천을 할 수 없다

처리율 제한 장치를 적용한다면

• DoS에 의한 자원 고갈 방지
• 서버를 많이 두지 않아도 되며, 우선순위가 높은 API에 자원 할당이 더 자유로워 질수 있으므로 비용절감
• 서버 과부화 방지

처리율 제한 장치의 위치선정

• API 서버와 같은 위치

• 중간에 미들웨어 처리 제한 장치를 두기
  • 보통 클라우드 MSA경우 해당 위치의 API 게이트웨이 라고 불리는 컴포넌트에 구현
  • 처리율 제한, SSL 종단, 사용자 인증, IP 허용목록, 관리의 기능을 담당
   

​

처리율 제한 알고리즘

토큰 버킷

• 버킷에 담을 수 있는 토큰의 개수는 개발자의 설정 값이며 1개의 Requst당 1개의 토큰을 점유 한다. 그 이상의 Request는 버린다. 모든 토큰이 소진시 토큰 공급률 에 의해서 0부터 다시 토큰이 채워진다.
• 2개의 인자 버킷 크기, 토큰 공급률

 

장점

• 구현이 쉽다
• 메모리 사용 측면에서 효율적
• 짧은 시간에 집중되는 트래픽 처리 가능, 버킷에 남아있는 토큰이 있기만 하면 요청은 시스템에 전달된다.

단점

• 버킷 크기와 토큰 공급률을 적절히 튜닝하는 것이 엄청 까다로울것이다.

누출 버킷

• 토큰 버킷과 비슷함. 요청 처리율이 고정되어 있는것이 차이점, 보통 FIFO 큐로 구현

 

• 2개의 인자: 버킷 크기: 큐 사이즈와 같은 값, 처리율: 지정된 시간당 몇 개의 항목을 처리할지 지정하는 값, 보통 초로 표현
• 대표적으로 Shopify 기업에서 이 알고리즘을 사용
• 장점
  • 큐 크기가 제한되 있어 메모리 사용량 측면에서 효율적
  • 고정된 체리율 갖고 있기 때문에 안정적 출력이 필요한 경우 적합
• 단점
  • 단시간에 트래픽이 몰리는 경우 제때 처리하지 못하면 최신 트래픽은 버려진다
  • 2개의 인자를 올바르게 튜닝하기 힘듬

고정 윈도 카운터

• 타임라인을 고정된 간격의 윈도로 나누고, 각 윈도 마다 카운터를 추가한다.
• 요청이 접수될 때마다 이 카운터 값은 1씩 증가
• 카운터 값이 설정한 임계치에 다다르면 새 요청은 새 윈도가 열릴 때까지 버려진다

• 장점
  • 메모리 효율이 좋다
  • 이해하기 쉽다
  • 윈도가 닫히는 시점에 카운터를 초기화하는 방식은 특정한 트래픽 패턴을 처리하기에 적합
• 단점
  • 윈도 경계 부근에서 일시적으로 많은 트래픽이 몰려드는 경우, 기대했던 처리 한도 보다 더 많은 양의 요청을 처리하게 된다.
  •  

이동 윈도 로그

• 이동 윈도 로그는 고정 윈도 카운터의 경계 부근에서의 더 많은 트래픽을 처리하는 문제를 해결한다.
• 이동 윈도 로그는 타임스탬프를 추적, 보통 타임스탬프 는 레디스의 정렬 집합 같은 캐시에 보관
• 새 요청이 오면 만료된 타임스탬프는 제거, 만료된 경우는 현재 윈도 시작 시점보다 오래된 타임 스탬프를 의미
• 새 요청의 타임스탬프를 로그에 추가
• 로그 크기가 허용치 보다 작거나 같으면 요청을 시스템에 전달, 그렇지 않으면 처리 거부

• 장점
  • 메커니즘이 정교, 어느 순간의 윈도를 봐도 허용 요청 개수는 시스템의 처리 한도를 넘지 않음
• 단점
  • 거부된 요청의 타임스탬프도 보관하기 때문에 다량이 메모리의 사용

이동 윈도 카운

• 고정 윈도 카운터 + 이동 윈도 로깅을 결합한 것

• 현재 1분간의 요청 수 + 직전 1분간의 요청 수 * 이동 윈도와 직전 1분이 겹치는 비율
• 공식에 의해 현재 윈도에 들어있는 요청은 3+5*7

장점

• 짧은 시간에 몰리는 트래픽에도 잘 대응
• 메모리 효율이 좋다

단점

• 직전 시간대에 도착한 요청이 균등하게 분포되어 있다고 가정한 상태에서 추정치를 계산하기 때문에 다소 느슨하다
• 클라우드플레어의 실험결과에 따르면 초과허용되거나 버려진 요청은 0.003%에 불과

개략적 구조

• 시간에 기반한 만료 정책을 지원하기에 빠른 메모리 기반 솔루션이 적합
• 처리율 제한 미들웨어는 레디스의 지정 버킷에서 카운터를 가져와 한도에 도달했는지 아닌지 검사
• 도달했다면 요청은 거부, 아니면 API서버로 전달, 그후 미들웨어는 카운터의 값을 증가하여 레디스에 저장

상세설계

처리율 제한 장치가 사용하는 HTTP 헤더

요청 한도 제한이 걸리면 HTTP 429(too many request)를 클라이언트에게 보냄

클라이언트가 자기 요청이 제한이 걸리고 있는 것을 HTTP 응답 헤더로 판단

• X-Ratelimit-Remaining: 윈도 내에 남은 처리 가능 요청의 수
• X-Ratelimit-Limit: 매 윈도마다 클라이언트가 전송할 수 있는 요청의 수
• X-Ratelimit-Retry-After: 한도 제한에 걸리지 않으려면 몇 초 뒤에 요청을 다시 보내야 하는지 알려줌
• 너무 많은 요청을 보내면 429 오류를 X-Ratelimit-Retry-After헤더와 함께 보낸다

아키텍처

• 처리율 제한 미들웨어는 제한 규칙을 캐시에서 가져온다, 아울러 카운터 및 마지막 요청의 타임스탬프를 레디스 캐시에서 가져온다.
• 해당 요청이 처리율 제한에 걸리지 않은 경우 API서버로 전송
• 제한에 걸리면 429 에러를 클라이언트에게 보낸다, 해당 요청은 버리거나 메시지 큐에 보관할 수도 있다.

분산 환경에서의 처리율 제한 장치의 구현

고민거리

• 경쟁 조건
  • 락(시스템의 성능을 상당히 떨어뜨림)
  • 루아 스크립트 ,또는 레디스의 정렬 집합을 사용하자
• 동기화
  • 레디스와 같은 중잦 집중형 데이터 저장소를 사용하자
   

 

• 성능 최적화
  • 여러 데이터 센터에서의 최종 일관성 모델
• 모니터링

마무리

추가 고민거리

• 경성/연성 처리율 제한
  • 경성 처리율 제한: 요청의 개수는 임계치를 절대 넘어설 수 없다.
  • 연성 처리율 제한: 요청 개수는 잠시 동안은 임계치를 넘어설 수 있다.
• 다양한 계층에서의 처리율 제한
  • OSI 7계층에서의 제한
• 클라이언트에서의 설계
  • 클라이언트에서 캐시를 이용한 API 호출 횟수를 줄인다.
  • 처리율 제한 임계치를 이해하고 많은 메시지를 보내지 않는다
  • 예외 에러 발생시 우하하게 복구
  • 재시도 로직시 백오프 시간을 둔다.