[가상 면접 사례로 배우는 대규모 시스템 설계 기초] 4장 개략적인 규모 측정

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

처리율 제한 장치(rate limiter)

• 클라이언트 또는 서비스가 보내는 트래픽의 처리율(rate)을 제어하기 위한 장치
• 특정 기간 내에 전송되는 클라이언트의 요청 횟수를 제안한다.

 

API 요청 횟수가 제한 장치에 정의된 임계치(threshold)를 넘어서면 추가로 도달한 모든 호출은 처리가 중단(block)된다.

• 사용자는 초당 2회 이상 새 글을 올릴 수 없다.
• 같은 IP 주소로는 하루에 10개 이상의 계정을 생성할 수 없다.
• 같은 디바이스로는 주당 5회 이상 리워드(reward)를 요청할 수 없다.

 

API에 처리율 제한 장치를 두면 좋은점

• DOS(Denial of Service) 공격에 의한 자원 고갈을 방지
• 비용 절감
• 서버 과부하 방지

---

3장에서 배운 시스템 설계 4단계 접근법을 적용

1단계. 문제 이해 및 설계 범위 확정

요구사항

• 설정된 처리율을 초과하는 요청은 정확하게 제한한다.
• 낮은 응답시간 : 이 처리율 제한 장치는 HTTP 응답시간에 나쁜 영향을 주어서는 곤란하다.
• 가능한 한 적은 메모리를 써야한다.
• 분산형 처리율 제한 : 하나의 처리율 제한 장치를 여러 서버나 프로세스에서 공유할 수 있어야 한다.
• 예외 처리 : 요청이 제한되었을 때는 그 사실을 사용자에게 분명하게 보여주어야 한다.
• 높은 결함 감내성 : 제한 장치에 장애가 생기더라도 전체 시스템에 영향을 주어서는 안된다.

---

2단계. 계략적 설계안 제시 및 동의 구하기

처리율 제한 장치의 위치

• 클라이언트 측 : 위변조가 가능하여 권장하지 않는다.
• 서버 측 : 중앙화해서 관리한다.
• 미들웨어
  • 처리율 제한 장치를 API 서버에 두는 대신, 처리율 제한 미들웨어(middleware)를 만들어 해당 미들웨어로 하여금 API 서버로 가는 요청을 통제하도록 한다.
  • MSA인 경우, 처리율 제한 장치는 보통 API Gateway에 구현
  • API Gateway : 처리율 제한, SSL 종단, 사용자 인증, IP 허용 목록 관리 등

정리

• 현재 기술 스택이 서버 측에 기능 구현이 가능한 지 점검
• 상황에 맞는 알고리즘 사용. 만약 제3 사업자가 제공하는 API Gateway를 사용한다면 선택지는 제한이 될 수 있다.
• MSA에 기반하고 있는 경우, 사용자 인증이나 IP 허용목록 관리 등을 처리하기 위해 API Gateway를 이미 설계에 포함시켰다면 처리율 제한 기능 또한 Gateway에 포함시켜야 할 수도 있다.
• 충분한 인력이 없다면 상용 솔루션도 고려해보는 것이 좋다.

처리율 제한 알고리즘

• 토큰 버킷
• 누출 버킷
• 고정 윈도 카운터
• 이동 윈도 로그
• 이동 윈도 카운터

---

3단계 상세 설계

• 처리율 제한 규칙은 어떻게 만들어지고 어디에 저장되는가?
• 처리가 제한된 요청들은 어떻게 처리되는가?

처리율 제한 규칙

1. 처리율 한도 초과 트래픽 처리
   어떤 요청이 한도 제한에 걸리면 API는 HTTP 429 응답(too many requests)을 클라이언트에게 보낸다.
   경우에 따라서는 한도 제한에 걸린 메시지를 나중에 처리하기 위해 큐에 보관할 수도 있다.
   예를 들어 어떤 주문이 시스템 과부하 때문에 한도 제한에 걸린 경우, 해당 주문들은 보관했다가 나중에 처리할 수도 있다.
2. 처리율 제한 장치가 사용하는 HTTP 헤더
   클라이언트가 자기 요청이 처리율 제한에 걸리고 있는지에 대한 정보를 아래 HTTP 헤더를 통해 전달한다.

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

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

단일 서버를 지원하는 처리율 제한 장치를 구현하는 것은 어렵지 않다. 하지만 여러 대의 서버와 병렬 스레드를 지원하도록 시스템을 확장하는 것은 또 다른 문제다. 다음 2가지 어려운 문제를 풀어야한다.

• 경쟁 조건(race condition)
• 동기화(synchronization)

1. 경쟁 조건

- 처리율 제한 장치 동작 과정

1) 레디스에서 카운터의 값을 읽는다. (counter)

2) counter+1의 값이 임계치를 넘는지 본다.

3) 넘지 않는다면 레디스에 보관된 카운터 값을 1만큼 증가시킨다.

 

병행성이 심한 환경에서는 경쟁 조건 이슈가 발생할 수 있다. (그림 4-14 책 참고)

 

- 해결책

• 락(lock) : 경쟁 조건 문제를 해결하는 가장 널리 알려진 방법이지만 시스템의 성능을 상당히 떨어뜨린다.
• 루아 스크립트(Lua Script)
• 정렬 집합(Sorted Set) : 레디스 자료구조

2. 동기화

수백만 사용자를 지원하려면 한 대의 처리율 제한 장치 서버로는 충분하지 않을 수 있다.

그래서 처리율 제한 장치 서버를 여러 대 두게 되면 동기화가 필요해진다.

 

- 해결책

• 고정 세션 (sticky session)을 활용하여 같은 클라이언트로부터의 요청은 항상 같은 처리율 제한 장치로 보낼 수 있도록 하는 것 → 규묘면에서 확장 가능하지도 않고 유연하지도 않아서 비추천!
• 레디스 활용!

성능최적화

성능 최적화는 시스템 설계 면접의 단골 주제이다.

ex) 지연시간을 줄이기 위해 사용자의 트래픽을 가장 가까운 edge 서버로 전달하여 지연시간을 줄인다.

모니터링

처리율 제한 장치를 설치한 이후에는 효과적으로 동작하고 있는지 보기 위해 데이터를 모을 필요가 있다.

기본적으로 모니터링을 통해 확인하려는 것은 2가지다.

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

처리율 제한 규칙이 너무 빡빡하게 설정되었다면 많은 유효 요청이 처리되지 못하고 버려질 것이다. 규칙을 다소 완화할 필요가 있다.

깜짝 세일 같은 이벤트 때문에 트래픽이 급증할 때 처리율 제한 장치가 비효율적으로 동작한다면, 그런 트래픽 패턴을 잘 처리할 수 있도록 알고리즘을 바꾸는 것을 생각해 봐야 한다. 그런 상황에서는 토큿 버킷이 적합하다.

---

4단계 마무리

위에서 처리율 제한을 구현하는 여러 알고리즘과 장단점 이외에도 해당 알고리즘을 구현하는 아키텍쳐, 분산환경에서의 처리율 제한 장치, 성능 최적화와 모니터링 등의 주제를 살펴보았다.

 

아래와 같은 부분들도 살펴보면 좋을 것이다.

경성 또는 연성 처리율 제한

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

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

• 애플리케이션 계층(OSI 7번 계층)에서의 처리율 제한 외에도 다른 계층에서도 제어
  ex) Iptables를 사용하여 IP 주소에 처리율 제한을 적용

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

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

 

 

 

 

---

Reference

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