처리율 제한 장치 상세 설계

처리율 제한 규칙

domain: auth
descriptors:
	- key: auth_type
      Value: login
      rate_limit:
          unit: minute
          requests_per_unit: 5

 

상세 설계 그림

클라이언트가 요청을 보내면 먼저 처리율 제한 미들웨어를 통하고 제한 규칙을 캐시에서 가져온다(빈번한 요청이 생김으로 캐시에 보관)

처리율 제한이 걸리면 429 too many requests, 아니면 API 서버로 동작

 

분산 환경에서 구현

단일 서버의 경우는 쉽겠지만 여러 대의 서버와 병렬 스레드의 경우 경쟁조건과 동기화의 문제가 있다

경쟁 조건

위와 같이 병행성이 심한 경우에서 경쟁 조건 이슈가 발생한다

해결 방안으로

1. 락을 건다(시스템 성능을 상당히 떨어뜨리기에 비추)

2. 루아 스크립트

3. 정렬 집합 레디스 자료구조를 쓰는 것이다

<추후 공부 예정>

동기화 이슈

웹 계층은 무상태 이므로(?) 클라이언트는 요청을 각기 다른 처리율 제한 장치로 보낼 수 있다. 그러면 다른 제한 장치는 클라이언트 2에 대해 아무것도 모르기에 처리율 제한을 올바르게 수행 할 수 없다

해결 방안으로

1. 고정 세션을 활용(규모면에서 확장 가능하지 않고 유연하지 않음): 같은 클라이언트를 항상 같은 처리율 제한 장치로

2. 레디스와 같은 중앙 집중형DB 사용 (레디스는 빠르니까 계속해서 요청해서 처리율 제한장치만 다루게)

 

위 서버를 통한 제한 외에도 스터디에서 같이 논의한 흥미로운 내용이 있다

다양한 계층에서 처리율 제한인데

1. 물리 계층에서 서버의 온도가 뜨거우면(많은 처리를 요청하기에 cpu 온도 상승) 스위치를 끄거나 다른 서버로 이동

2. 클라이언트 측 에서 버튼을 몇 번 누를 시 버튼을 disable 하거나 클라이언트가 데이터를 보관 후 마지막 버튼 클릭을 멈췄을 시 데이터를 한번 요청하는 등의 방법등 을 생각했다