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

이번 포스트는 제 4장 처리율 제한 장치의 설계에 대해 정리하고 스터디할 예정입니다.

feat. 가상 면접 사례로 배우는 대규모 시스템 설계 기초 1권

 

오늘의 주제 : 처리율 제한 장치

 

처리율 제한 장치란?

네트워크 시스템에서 클라이언트나 서비스가 보내는 트래픽의 처리율을 제어하기 위한 장치. 

처리율을 제어하기 위해서는 특정 기간동안의 한계치를 정해놓고, 그 이상이 넘어가는 요청 횟수를 제어하는 방식으로 처리한다.

 

 

특징

• 장점
  1. DOS 공격에 의한 자원 고갈 방지
  2. 비용 절감
  3. 서버 과부하 방지 
• 설계 위치
  1. 클라이언트
  2. 서버
  3. 미들웨어

 

미들웨어에 처리율 제어 장치를 설치했다고 가정하자.

 

클라이언트에서 요청 한계를 넘은 번째의 요청을 했을 때, 클라이언트로 HTTP 상태 코드 429가 반환 된다. 

* HTTP 상태 코드 429 = Too many requests

 

처리율 제한 장치는 보통 api gateway에 구현된다. (참고. api gateway는 ssl 종단, 사용자 인증 등을 구현한다.)

 

 

처리율 제한 알고리즘

- 토큰 버킷

- 누출 버킷

- 고정 윈도 카운터

- 이동 윈도 로그

- 이동 윈도 카운터

 

1. 토큰 버킷 알고리즘
   - 가장 보편적인 알고리즘
   - 토큰 버킷 = 용량이 정해져있는 컨테이너
   - 일정한 양의 토큰이 주기적으로 채워지고 요청이 처리될 때마다 하나의 토큰 사용.
   - 토큰이 있으면 요청을 한 시스템에 전달하고, 아닐 경우 해당 요청은 버려진다.
   - API 엔드포인트마다 별도의 버킷
   - 구현이 쉽지만 버킷 크기와 토큰 공급률을 적절하게 튜닝하는 것이 까다롭다.
   
   
2. 누출 버킷 알고리즘
   - 토큰 버킷 알고리즘과 비슷
   - 요청 처리율이 고정 -> 안정적인 출력
   - FIFO 큐로 구현
   - 버킷 크기, 처리율 2개의 인자.
   - 단시간에 트래픽이 몰릴 경우, 요청을 제때 처리 못하면 최신 요청들이 버려지게 됨. 
   
   
3. 고정 윈도 카운터 알고리즘
   - 타임라인 중심으로 고정된 간격의 윈도로 나우고, 각 윈도마다 카운터를 붙인다.
   - 요청이 올 때마다 카운터 +1
   - 임계치에 도달하면, 새 윈도가 열릴 때까지 요청이 버려짐.
   - 메모리 효율이 좋지만 윈도 경계 부근에서 트래픽이 몰릴 경우, 처리 한도보다 많은 양의 요청을 처리하게 됨.
   
   
4. 이동 윈도 로깅 알고리즘
   - 고정 윈도 카운터 알고리즘의 단점을 해결하기 위해 등장.
   - 요청의 타임스탬프 추적 -> 타임 스탬프 데이터 (레디스, 정렬 집합 - 캐시에 보관)
   - 다량의 메모리 사용
   
   
5. 이동 윈도 카운터 알고리즘
   - 고정 윈도 카운터 알고리즘 + 이동 윈터 로깅 알고리즘
   - 이전 시간대의 평균 처리율에 따라 현재 윈도 상태를 계산 -> 트래픽에 잘 대응
   - 메모리 효율이 좋음
   - 추정치는, 요청이 균등하게 분포되어 있다고 가정하고 계산. ( 치명적인 단점은 아님.)

카운터 보관은 캐시가 가장 적절. 일반적으로 Redis를 많이 사용.

 

 

• 처리율 제한 장치가 사용하는 HTTP 헤더
  - X-Ratelimit-Remaining
  - X-Ratelimit-Limit
  - X-Ratelimit-Retry-After -> 429
• 처리율 제한 규칙 -> 디스크 보관 -> 캐시 저장

 

여러 대의 서버와 병렬 스레드 지원하기

시스템을 확장하려면, 1. 경쟁 조건 2. 동기화 문제를 해결해야 한다.

1. 경쟁 조건
경쟁 조건을 해결하기 위한 방법 중 가장 널리 알려진 것은 lock이다. 2, 3번째는 레디스의 자료구조이다.
- 락
- 루아 스크립트
- 정렬 집합.

2. 동기화 이슈

- 처리율 제한 장치 서버를 여러 대 둘 때.

- Sticky session 활용. 같은 클라이언트로부터의 요청은 같은 처리율 제한 장치로 보내기. ( 추천 x)

- 레디스 같은 중앙 집중형 데이터 저장소 사용

 

성능 최적화

1. 데이터 센터 지원 - 엣지 서버

2. 일관성 모델 사용

 

클라이언트 설계

- 클라이언트 쪽 캐시 사용
- 임계치 이해 하고 짧은 시간 동안 많은 메시지를 보내지 않도록

- 예외, 에러 처리 코드 강화 -> 복구 

- 재시도는 충분한 백오프 뒤!

 

 

마무리하며.

처리율 처리를 제한을 두는 것은 서비스 흐름 상 당연하지만, 그것은 클라이언트나 서버 어느 한쪽이 책임질 일은 아니다. 양쪽다 충분히 고려하면 반드시 해결책과 적절한 알고리즘을 선택할 수 있게 될 것이다.