4장 처리율 제한 장치의 설계 (3)

가상 면접 사례로 배우는 대규모 시스템 설계 기초 – System Design Interview

 

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

4장 처리율 제한 장치의 설계 (1)
4장 처리율 제한 장치의 설계 (2) – 알고리즘 정리

에서 이어지는 글입니다.

---

3단계 상세 설계

더 생각 해봐야 할 부분들

- 처리율 제한 규칙은 어떻게 만들어지고 어디에 저장되는가?
- 처리가 된 요청들은 어떻게 처리되는가?
- 분산 환경에서는 어떻게 처리할 것인가?

처리율 제한 규칙

처리율 제한 규칙은 보통 설정 파일 형태로 디스크에 저장된다.

리프트(Lyft, 미국의 승차 공유 서비스기업이다.)는 처리율 제한에 오픈 소스를 사용하고 있다.

https://github.com/envoyproxy/ratelimit (Lyft 의 repository 였는데 envoyproxy로 옮겨졌다., envoy에 대한 소개는 https://arisu1000.tistory.com/27864 여기에서 확인할 수 있다.)

아래는 규칙의 예시이다.

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

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

요청이 한도 제한에 걸리면 API는 HTTP 429 응답 (too many request)을 클라이언트에게 보낸다.

여기서 그냥 마무리 지을 수 있지만 나중에 처리하기 위해 큐에 보관할 수도 있다.

 

클라이언트는
처리율 제한에 걸리고 있는지를 어떻게 감지할 수 있나?
처리율 제한에 걸리기 까지 얼마나 요청을 보낼 수 있는지 어떻게 알 수 있나?

이러한 것들을 알 수 있도록 HTTP 응답 헤더 (response header)에 정보를 담아주면 좋다.

 

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

 

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

상세설계

- 처리율 제한 규칙은 디스크에 보관한다. 작업 프로세스(workers)는 수시로 규칙을 디스크에서 읽어 캐시에 저장한다.

- 클라이언트가 요청을 서버에 보내면 요청은 먼저 처리율 제한 미들웨어에 도달한다.

- 처리율 제한 미들웨어는 제한 규칙을 캐시에서 가져온다. 아울러 카운터 및 마지막 요청의 타임스탬프(timestamp)를 레디스 캐시에서 가져온다. 가져온 값들에 근거하여 해당 미들웨어는 다음과 같은 결정을 내린다.

- 해당 요청이 처리율 제한에 걸리지 않은 경우에는 API 서버로 보낸다.

- 해당 요청이 처리율 제한에 걸렸다면 429 too many requests 에러를 클라이언트에 보낸다. 한편 해당 요청은 그대로 버릴 수도 있고 메시지 큐에 보관할 수도 있다.

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

경쟁 조건

락을 하면 해결될 수 있으나, 시스템 성능을 상당히 떨어트림

루아 스크립트나 정렬 집합이라 불리는 레디스 자료구조를 써서 해결할 수 있다.
https://engineering.linecorp.com/ko/blog/atomic-cache-stampede-redis-lua-script
* 루아 스크립트는 레디스 서버 내에서 실행 가능한다.

동기화

고정 세션을 활용하여 해결할 수 있으나 확장에 유연하지 않으므로 추천하지 않음.

레디스와 같은 중앙 집중형 데이터 저장소를 사용하는걸 추천

레디스도 분산처리한다면? 

성능 최적화

- 에지 서버
- 최종 일관성 모델 사용 (6장에서 나올 예정)

모니터링

모니터링을 통해 확인하려는 것은 다음 두 가지이다.
- 채택된 처리율 제한 알고리즘이 효과적이다.
- 정의한 처리율 제한 규칙이 효과적이다.

4단계 마무리

시간이 허락된다면 다음과 같은 부부을 언급해보면 도움이 될 것이다.

 

경성(soft) 또는 연성(hard) 처리율 제한

경성 처리율 제한: 요청의 개수는 임계치를 절대 넘어설 수 없다.
연성 처리율 제한: 요청의 개수는 잠시 동안은 임계치를 넘어설 수 있다.

 

다양한 계층에서의 처리율 제한

지금까지의 설명은 OSI 7계층의 애플리케이션 계층을 기준으로 설명한 것이다.
다른 계층에서도 처리율 제한이 가능하다.

(ex. OSI 3번 계층, iptables를 사용하여 IP주소에 처리율 제한을 적용할 수 있음.)

 

OSI 계층
- 1 물리
- 2 데이터 링크
- 3 네트워크
- 4 전송
- 5 세션
- 6 표현(presentation)
- 7 애플리케이션

 

처리율 제한을 회피하는 방법. 클라이언트를 어떻게 설계하는 것이 최선인가.

- 클라이언트 측 캐시를 사용하여 API 호출 횟수를 줄인다.
- 처리율 제한의 임계치를 이해하고, 짧은 시간 동안 너무 많은 메시지를 보내지 않도록 한다.
- 예외나 에러를 처리하는 코드를 도입하여 클라이언트가 예외적 상황으로부터 우아하게(gracefully) 복구될 수 있도록 한다.
- 재시도(retry) 로직을 구현할 때는 충분한 백오프(back-off, 지연) 시간을 둔다.