[대규모 시스템 설계 기초]4장. 처리율 제한 장치 설계

in Various on Tech-Book

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

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

처리율 제한 장치? 클라이엍느 또는 서비스가 보내는 트래픽을 처리율을 제어하기 위한 장치

장점 : 자원 고갈 방지, 비용 절감, 서버 과부하 방지

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

  • 어디서 처리할 것인가 : 클라이언트 or 서버
    • 서버에 두는 경우 처리율 제한 장치를 위한 미들 웨어를 적용 : 일반적으로 API gateway 컴포넌트에 적용
  • 제어 기준 : IP주소, 사용자ID 또는 그 외 기준
  • 환경 : 단일 or 분산 환경

처리율 제한 알고리즘 5가지

1. 토큰 버킷 (Token Bucket)

  • 요청 당 하나의 토큰 사용. 만약 토큰이 없을 경우 해당 요청 버림(429 too many requests). 토큰은 일정 시간마다 충전됨
  • 설정 필요 값 2가지
    • 버킷 크기 : 버킷에 담을 수 있는 토큰의 최대 개수
    • 토큰 공급률(refill rate) : 초당 몇 개의 토큰이 버킷에 공급되는가
  • 장점
    • 구현 쉬움
    • 메모리 효율 사용
    • 짧은 시간 집중 트래픽 처리 가능
  • 단점
    • 적절한 값 세팅 어려움

2. 누출 버킷 (Leaky Bucket)

  • 토큰 버킷과 유사하나, 요청 처리율이 고정. 보통 FIFO 큐로 구현.
  • 요청 시 큐 확인. 큐 자리 있을 경우 큐에 추가. 지정된 시간마다 큐에서 요청을 꺼내어 처리
  • 설정 필요 값 2가지
    • 버킷 크기 : 큐 사이즈.
    • 처리율(outflow rate) : 지정된 시간당 몇 개의 항목을 처리할지 지정하는 값. 보통 초 단위 표현
  • 장점
    • 메모리 효율 사용 : 큐 크기 제한
    • 안정적 출력에 적합 : 고정된 처리율
  • 단점
    • 단시간 많은 트래픽 제대로 처리 X
    • 다음 처리 시간까지 기다려야 함

시스템의 안정적인 가용성이 더 중요할 때?

3. 고정 윈도 카운터 (Fixed Window Counter)

  • 타임라인을 고정 간격의 윈도우로 나눔. 각 윈도우마다 카운터를 붙임. 요청 때마다 +1 처리.
  • 장점
    • 메모리 효율
    • 이해 쉬움
    • 특정한 트래픽 패턴 처리에 적합
  • 단점
    • 윈도 경계 사이 일시적 많은 요청이 발생할 경우 기대했던 처리량보다 더 많이 처리될 수 있음.

      4. 이동 윈도 로그 (Sliding Window Log)

  • 요청의 타임스탬프를 추적하는 방식. (일반적으로 Redis의 Sorted Set에 저장)
  • 요청의 타임 스탬프를 로그에 쌓고 로그의 크기 확인을 통해 제어
  • 장점
    • 정교함
  • 단점
    • 다량의 메모리 : 거부된 요청의 타임 스탬프도 저장

      5. 이동 윈도 카운터 (Sliding Window Counter)

  • 고정 윈도 카운터 + 이동 윈도 로깅 조합
  • 장점
    • 짧은 시간에 몰리는 트래픽 대응 가능
    • 메모리 효율
  • 단점
    • 직전 시간대 도착 요청 균등 분포 가정 -> 다소 느슨 : but 오류를 걱정할 정도는 아님.

분산 환경에서의 상세 설계

1. 경쟁 조건

  • Redis 사용하는 경우 Lua script 사용 혹은 Sorted Set을 사용

    2. 동기화

  • 고정 세션통해 해결 가능 : 확장 및 유연성이 떨어지는 문제. 비추천
  • Redis와 같은 중앙 집중형 저장소 사용

성능 최적화

  • 만약 여러 데이터 센터 지원 시 사용자 트래픽을 가까운 에지 서버로 전달
  • 데이터 동기화는 최정 일관성 모델 사용

모니터링

모니터링 기본적인 요소 두 가지

  1. 채택된 처리율 제한 알고리즘의 효과
  2. 정의한 처리율 제한 규칙의 효과

그 외 고려 사항

  1. 경성 또는 연성 처리율 제한
    • 경성 : 요청의 개수는 절대 임계치 초과 불가
    • 연성 : 잠시 동안은 임계치 초과 가능
  2. 다양한 계층에서의 처리율 제한
    • OSI의 다양한 계층에서도 가능
  3. 처리율 제한 회피 방법 (클라이언트 설계)
    • 클라이언트 측 캐시 사용 : API 호출 줄임
    • 처리율 제한 임계치 이해, 짧은 시간 동안 너무 많은 메시지 전송 X
    • 예외, 에러 처리 코드 도입 통해 클라이언트가 예외적 상황으로부터 우아하게 복구될 수 있도록 함
    • Retry 로직 구현 시 충분한 back-off 시간을 둠

참조