Ch04. 처리율 제한 장치의 설계 - 상세 설계

1) 처리율 제한 규칙은 어떻게 만들어지고, 어디에 저장되는지?

2) 처리가 제한된 요청들은 어떻게 처리되는지??

 

처리율 제한 규칙

Lyft( 미국과 캐나다에서 주로 서비스를 제공하는 승차 공유 기업) 같은 경우 오픈 소스를 사용하고 있으며 아래와 같은 규칙을 사용한다.

domain: {domain-name}
descriptors:
	- key: {message-key}
      value: {message-value}
      rate-limit:
	  	unit: day
        requests_per_unit: {count}

• Config 설정 파일 형태로 디스크에 저장된다.

처리율 한도 초과 트래픽의 처리

어떤 요청이 한도 제한에 걸릴 경우 API는 Http 429 응답을 클라이언트에게 보내거나, Queue에 보관해 나중에 처리할 수도 있다.

 

그렇다면 Client는 자기 요청이 처리율 제한에 걸리고 있는지를 어떻게 감지할 수 있을까??

처리율 제한 장치는 Http 응답 헤더에 아래와 같은 Header를 추가해서 전달한다.

• X-Ratelimit-Remaining: 윈도 내에 남은 처리 가능 요청 수
• X-Ratelimit-Limit: 매 윈도마다 클라이언트가 전송할 수 있는 요청 수
• X-Ratelimit-Retry-After: 한도 제한에 걸리지 않으려면 몇 초 뒤에 요청을 다시 보낼지 알려주는 알람

사용자가 많은 요청을 보내면 429 오류를 X-Ratelimit 헤더와 함께 반환하자

상세 설계

• 처리율 제한 규칙은 디스크에 보관한다.
  • 작업 프로세스는 수시로 규칙을 디스크에서 읽어 캐시에 저장한다.
• 클라이언트가 요청을 서버에 보내면 요청은 처리율 제한 미들웨어에 도달한다.
• 처리율 제한 미들웨어는 제한 규칙을 캐시에서 가져온다.
• 카운터 및 마지막 요청의 타임 스태프를 레디스 캐시에서 읽어온다.
• 가져온 값들을 토대로 결정
  • 해당 요청이 처리율 제한에 걸리지 않을 경우 API 서버로 요청을 보낸다.
  • 해당 요청이 처리율 제한에 걸렸을 경우 429 에러를 클라이언트에 보낸다.
    • 요청을 버릴 수도 있고, 큐에 보관할 수도 있다.

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

1) 경쟁 조건

• 처리율 제한 장치는 레디스에서 카운터 값을 읽는다
• 카운터 값 + 1이 임계치를 넘는지 확인한다.
• 넘지 않는다면 레디스에 보관된 카운터 값을 1 증가시킨다

이는 병렬로 처리하게 될 경우 동시성 이슈가 발생할 수 있으며, 레디스 기반에서 해결하는 방법으로 가장 널리 알려진 해결책은 Lock이다.

하지만 Lock은 성능이 떨어지는 문제가 있어, 루아 스크립트로 대체하거나, 정렬 집합이라 불리는 레디스 자료 구조를 사용하면 된다.

 

2) 동기화 이슈

처리율 제한 장치를 여러 대 두게 되면 동기화가 필요해진다. 동기화를 하지 않는다면 클라이언트에 대한 정보를 모르고 처리율 장치가 동작하기 때문이다. 

이를 해결하는 방법으로 유명한 것은 고정 세션 전략이다. 같은 클라이언트로서의 요청은 같은 처리율 제한 장치로 보낼 수 있게 하는 것이다.

-> 단, 이는 확장 불가능하며 유연하지 못하다.

다른 해결책으로는 레디스와 같은 중앙 집중형 데이터 저장소를 사용하는 것이다.

 

3) 성능 최적화

• 여러 데이터 센터를 지원
  • 데이터 센터에서 멀리 떨어진 사용자에게는 지연시간이 증가할 수밖에 없기 때문에, 에지 서버를 심어 두고 사용자의 트래픽을 가장 가까운 에지 서버로 전달한다.
• 처리율 제한 장치 간 데이터 동기화 시, 최종 일관성 모델을 사용
  • 모든 장치가 항상 동일한 카운터를 볼 필요는 없으며, 시간이 지나면 결국 같은 상태로 맞춰지면 된다
  • 즉, 처리량과 가용성을 위해 일관성을 약간 희생하는 전략

 

4) 모니터링

• 채택된 처리율 제한 알고리즘이 효과적인지?
• 정의한 처리율 제한 규칙이 효과적인지?

처리율 제한 장치를 설치한 이후 효과적으로 동작하고 있는지 모니터링을 통해 확인이 필요하다.