[가상 면접 사례로 배우는 대규모 시스템 설계 기초] 처리율 제한 장치의 설계

가상 면접 사례로 배우는 대규모 시스템 설계 기초 책을 읽다가 처리율 제한 장치의 설계 파트를 공부하게 되었다.

실제로 회사에서도 이벤트로 인해 사용자가 몰리는 상황에 처리율 제한을 하지 않아 사용자에게 빈 화면이 보이는 이슈가 있었던 적이 있었으며, 이를 방지하고자 서버를 증설한 경험이 있었다. 만일 처리율 제한 장치를 설정함으로써 임계치를 두고 사용자당 이를 넘지 않는 요청에 대해선 응답할 수 있게 처리해도 좋았을 거 같다. 물론 여기에는 트레이드 오프가 따르기 때문에 상황에 알맞은 알고리즘을 적용할 수 있도록 논의가 중요한 거 같다.

또한 면접 상황에서 대규모 시스템 설계에 대해 질문받았을 때, 사용자 처리율 제한을 시키고자 하는 방법에 대해 구체적으로 답변하길 바랐던 적이 있어서 이 파트를 읽으면서 더욱 되새김질할 수 있게 되었다.

서론이 길었는데, 처리율 제한 장치란 무엇인지, 알고리즘의 종류를 먼저 알아보고, 내가 공부하면서 유독 궁금했던 부분을 좀 더 자세하게 다뤄보고자 한다. 그 후, 분산 환경에서의 처리율 제한 장치는 어떻게 처리해야 하는지를 알아보고자 한다.

처리율 제한 장치 ?

처리율 제한 장치란 클라이언트 또는 서비스가 보내는 트래픽의 처리율을 제어하기 위한 장치이다. 특정 기간 내 전송되는 클라이언트 요청 횟수를 제한한다. API 요청 횟수가 임계치를 넘어서면 추가로 도달한 모든 호출은 처리가 중단된다.

장점

1. DOS 공격으로 인한 자원 고갈을 방지할 수 있다.
2. 비용을 절감한다.
   추가 요청에 대한 처리를 제한하면 서버를 제한선에서 둘 수 있을 것이고, API 요청할 때마다 과금이 필요한 경우, 과도한 호출로 인해 비용이 낭비되는 상황을 방지할 수 있을 것이다.
3. 서버 과부하를 막는다.
   1과 같은 맥락으로 사용자의 과도한 요청에 대한 트래픽을 막아낼 수 있다.

고려할 만한 요구사항

기존 시스템에 효율적으로 설계하자

• 처리율 제한 장치가 응답시간에 적은 영향을 줄 수 있도록 고려해야 한다.
• 가능한 한 적은 메모리를 사용해야 한다.
• 장치에 장애가 생기더라도 전체 시스템에 영향을 주어서는 안 된다.
• 하나의 처리율 제한 장치를 여러 서버나 프로세스에서 공유해야 한다.

사용자 친화적으로 처리하자

• 요청이 제한되었을 때 그 사실을 사용자에게 분명하게 보여줘야 한다.

알고리즘의 종류

1. 토큰 버킷
2. 누출 버킷
3. 고정 윈도 카운터
4. 이동 윈도 로그
5. 이동 윈도 카운터

* 해당 알고리즘에 대한 설명은 책에 자세히 나와있으니 책을 참고하도록 하자

의문이 들었던 이동 윈도 로그 알고리즘

이 알고리즘의 단점으론 거부된 요청의 타임스탬프도 보관해야 한다는 것인데, 분당 2번의 요청은 허가한다고 가정한다고 처리 제한 둔다고 가정해보자. 아래와 같은 케이스가 지속할 경우, 처음 두 번은 요청을 처리하는데, 그 이후부턴 지속해서 응답할 수 없게 된다.

1:00:00 응답 O

1:00:01 응답 O

1:00:30 응답 X

1:00:50 응답 X

1:00:51 응답 X

1:00:52 응답 X
1:01:00 응답 X

1:01:10 응답 X (1:00:10~1:01:10)

...

의도한 바는 분 당 2번의 요청을 허가하는 것인데 의도와 달라지는 것이 아닌가..? 싶어서 검색하다가 reddit을 보게됐다.

출처: https://www.reddit.com/r/AskComputerScience/comments/xktn2j/rate_limiting_why_log_rejected_requests/?rdt=62390

분산 환경에서의 처리율 제한 장치 구현 - 경쟁 조건 해결

위 코멘트는 해당 사이트를 제시하며 원자성이 필요하기 때문에 처리 제한으로 응답을 방지했던 요청의 타임스탬프도 기록해야 한다고 했다.

https://engineering.classdojo.com/blog/2015/02/06/rolling-rate-limiter/

위 문서는 책에서도  분산 환경에서 처리율 제한 장치를 구현하기 위해 발생할 수 있는 어려움인 경쟁 조건을 해결하는 방법으로 주석처리 해뒀던 사이트였다. lock을 사용하는 대신 redis의 sorted set로 처리한다고 했다.

가상 면접 사례로 배우는 대규모 시스템 설계 기초 ) 그림 4-14

그런데 위와 같은 경쟁 상황을 방지하기 위해 모든 타임스탬프를 쌓는 것은 비효율적인 것 같기도 하다. ㅠㅠ

이런 상황은 단시간에 사용자가 몰리게 되는 이벤트 상황에서 사용하면 안 될 거 같고(초기에만 요청에 응답하고 그 이후에는 계속 응답하지 못할 수 있기에), 사용자가 적게 접속하는 환경이고, 상용 시스템을 운영할 수 있는 서버가 부족한 환경에 적합한 알고리즘인 거 같다.