처리율 제한 장치(ratelimter) 구현 방법 5가지

🎯 1. 토큰 버킷 (Token Bucket) 토큰 버킷 방식은 일정한 비율로 토큰이 버킷에 채워집니다. 요청이 있을 때마다 토큰이 사용되며, 토큰이 없으면 요청이 거부됩니다. 👍 장점: 유연한 처리율 제한이 가능하며, 트래픽의 버스트를 어느 정도 허용할 수 있습니다. 👎 단점: 초기 구성이 복잡할 수 있습니다. 실제 요청률이 토큰 생성률보다 훨씬 낮을 경우 토큰이 낭비될 수 있습니다. 🎯 2. 누출 버킷 (Leaky Bucket) 데이터나 요청이 버킷에 차곡차곡 쌓이고, 일정한 속도로 "누출"됩니다. 버킷이 가득 차면 새로운 요청은 거부됩니다. 👍 장점: 일정한 요청률을 유지할 수 있습니다. 구현이 단순합니다. 👎 단점: 버스트 트래픽을 잘 처리하지 못합니다. 🎯 3. 고정 윈도 카운터 (Fixed Window Counter) 시간을 고정된 윈도우로 나누고, 각 윈도우마다 요청 수를 계산합니다. 윈도우 내에서 제한을 초과하면 요청을 거부합니다. 👍 장점: 구현이 간단합니다. 시간 윈도우가 확실하게 구분됩니다. 👎 단점: 윈도우 경계에서의 요청 버스트는 시스템에 부담을 줄 수 있습니다. 🎯 4. 이동 윈도 로그 (Sliding Window Log) 최근 N 초 동안의 모든 요청을 로그로 기록합니다. 로그의 요청 수가 제한을 초과하면 요청을 거부합니다. 👍 장점: 유연한 처리율 제한이 가능합니다. 버스트 트래픽 처리 능력이 좋습니다. 👎 단점: 메모리 사용량이 높을 수 있습니다. 로그 관리가 필요합니다. 🎯 5. 이동 윈도 카운터 (Sliding Window Counter) 현재 시간으로부터 과거 N 초 동안의 요청 수를 카운트합니다. 요청이 제한을 초과하면 거부됩니다. 👍 장점: 이동 윈도 로그보다 메모리 효율이 좋습니다. 버스트 트래픽 처리 능력이 좋습니다. 👎 단점: 구현이 다소 복잡합니다. 정확한 타이밍을 위한 추가 로직이 필요합니다. 같이보면 좋은 글 처리율 제한 장치는 언제 사용할까? https://careerly.co.kr/comments/90829