가상 면접 사례로 배우는 대규모 시스템 설계 기초 中 4장. 처리율 제한 장치의 설계를 읽으며 기록한 포스팅입니다.
들어가며
Resilience4j Rate Limiter를 사용해 보면서 ip당 특정 엔드포인트 처리율 제한을 구현한 적이 있었다.
Rate Limiter에는 어떤 종류가 있고, 어떤 사례에서 쓰이는지 알아보고 싶던 때에 좋은 책에 필요한 목차가 있어 해당 내용을 정리하였다.
처리율 제한(Rate Limiter)
서버의 부하를 제어하기 위해 단위 시간당 허용 가능한 요청 수를 제한하는 기술이다.
예를 들어 다음과 같은 제한을 둘 수 있다.
- SNS 서비스에서 하루 글쓰기 횟수 제한
- 친구 추가, 팔로우 요청 횟수 제한
- API 호출 횟수 제한
이러한 제한을 두지 않으면 서비스는 짧은 시간 내에 부하가 급격히 증가하거나, 악의적인 요청(ex.DDoS 공격)으로 인해 장애가 발생할 수 있다.
대부분의 경우, 처리율 제한은 애플리케이션 내부가 아니라 미들웨어 계층(API Gateway)에서 수행된다.
Client → [Middleware (API Gateway)] → API Server
이때 미들웨어는 단순한 트래픽 제한뿐 아니라 다음과 같은 역할도 함께 수행할 수 있다
SSL 종단 처리 (SSL termination)
인증(Authentication) 및 인가(Authorization)
IP 화이트리스트 / 블랙리스트 관리
요청 라우팅 및 로깅
처리율 제한 알고리즘
토큰 버킷
토큰 버킷 알고리즘은 네트워크나 서버 등에서 요청 처리율(rate limiting)을 제한하기 위해 가장 널리 사용되는 알고리즘이다.
그 이름처럼 🪣 '버킷'(양동이)과 🪙 '토큰'(요청 처리 티켓) 개념을 기반으로 동작한다.
동작 원리
1. 토큰 생성
토큰 생성기가 일정한 속도로 토큰을 생성한다.
이 토큰은 요청 하나를 처리할 수 있는 권한(티켓) 역할을 한다.
2. 버킷에 토큰 저장
생성된 토큰은 버킷에 저장된다.
단, 버킷의 최대 용량(임계치)을 넘으면 초과된 토큰은 버려진다(overflow)
3. 요청 처리
클라이언트 요청이 들어오면, 버킷에 남아있는 토큰을 하나 소비하여 요청을 처리한다.
버킷 내 토큰이 부족하면 요청은 버려진다.
주요 파라미터
토큰 공급률: 토큰이 생성되는 속도 (예: 초당 10,000개)
버킷 크기: 버킷이 보유할 수 있는 최대 토큰 수
예시
ex1) 전체 시스템에 대한 처리율 제한
시스템 전체에서 초당 최대 10,000개의 요청만 처리 가능해야 한다면, 1개의 버킷을 구성하면 된다.
• 토큰 공급률: 10,000 tokens/sec
• 버킷 수: 1개 (시스템 전체용)
이 설정은 모든 요청에 대해 글로벌 처리량 제한을 적용하는 형태다.
ex2) 사용자별 요청 제한
유저별로 하루에 100개 포스팅, 1,000개 댓글을 허용하려면, 유저별로 개별 버킷을 따로 구성해야 한다.
따라서 1명의 유저에
• posting 버킷 (100개/day)
• comment 버킷 (1,000개/day)
버킷을 필요로 하게 된다.
만일 유저가 200명이라면, 총 400개의 버킷이 필요하다.
누출 버킷
토큰 버킷과 유사하지만 요청 처리율의 안정적인 출력을 위하여 FIFO Queue를 사용한다.
버킷으로 큐를 사용하고, 큐에 있는 요청을 들어온 순서대로 처리율에 맞게 시스템에 전달한다.
큐(버킷)이 가득 찼다면 추가 요청은 버려진다.
주요 파라미터
버킷 크기: 큐의 크기
처리율: 토큰을 처리하는 속도
장/단점
장점 : 큐의 사용으로 인해 안정적인 처리율을 보장한다
단점 : 단시간에 트래픽이 몰려 큐에 요청이 쌓였으나 적절히 처리되지 않을 때, 신규 요청이 버려질 수 있다.
고정 윈도 카운터
시간축을 고정 간격 윈도로 나누고, 카운터를 생성해 임계치까지만 받고 나머지를 버리는 알고리즘
순간적으로 특정 윈도의 경계에 트래픽이 집중된 경우, 많은 요청을 처리해야 하는 경우가 생길 수 있음
주요 파라미터
윈도우 크기: 1초, 1분 등 시간 단위
임계치: 해당 시간 블록 내에서 허용할 최대 요청 수
장/단점
장점 : 구현이 매우 간단하고, 메모리 효율적
단점 : 윈도 경계에 트래픽이 몰릴 경우, 순간적인 폭증이 허용될 수 있다
이동 윈도 로깅
모든 요청의 타임스탬프를 로그에 저장
지정된 기간 이내의 요청만 필터링하여 개수 계산(즉 요청 자체의 시간만 카운트)
임계값을 넘은 타임스탬프를 처리하지 않는다
장/단점
장점 : 가장 정확한 제한이 가능 (진짜 지난 1분간 요청 수를 정확히 반영)
단점 : 요청이 많을수록 로그가 많아지기에 성능/메모리 부담 증가
이동 윈도 카운터
고정 윈도 카운터를 보완한 방식
1분간의 요청 수 = 직전 1분간 요청 수 * 이동 윈도와 직전 1분이 겹치는 비율
을 계산하여 임계치를 넘으면 처리하지 않는 알고리즘
장/단점
장점 : Sliding Window Log보다 메모리 사용량 적으며, 정밀도-성능의 균형이 좋다.
단점 : 구현이 다소 복잡하며, 시간 동기화 및 처리 시점 계산 로직 필요