AI 요약관련 정보

• 레이트 리미터는 API 요청을 제어하여 시스템 과부하를 방지하고 정당한 사용자에게 공정한 접근을 보장합니다. 🛡️
• 주요 요구사항은 구성 가능한 규칙 기반 제한, HTTP 429 응답 및 관련 헤더 제공, 3ms 미만의 낮은 지연 시간, 높은 가용성입니다. 🎯
• 가장 간단한 '고정 윈도우 카운팅' 방식은 시간(예: 1분)을 고정된 구간으로 나누고 각 사용자에게 카운터를 할당하지만, 윈도우 경계에서 발생하는 버스트 트래픽 문제에 취약합니다. ⏳
• 고정 윈도우 카운팅의 카운터 저장은 Redis와 같은 인메모리 데이터 스토어를 사용하여 여러 서버 간에 공유하고 빠른 처리를 보장해야 합니다. 🚀
• '토큰 버킷' 알고리즘은 고정 윈도우의 한계를 해결하는 업계 표준 방식으로, 토큰이 꾸준히 채워지는 버킷에서 요청마다 토큰을 소모하며, 토큰이 없으면 요청을 거부합니다. 🪣
• 토큰 버킷은 조용한 기간 동안 토큰을 축적하여 합법적인 트래픽 버스트를 허용하면서도 전체적인 요청 속도를 유지하며, 버킷 용량과 리필 속도 두 가지 매개변수를 사용합니다. 💰
• 레이트 리미터 구현 위치는 클라이언트 측(신뢰 불가), 서버 측(비즈니스 로직 혼합), 미들웨어(API 게이트웨이 등)로 나뉘며, 대부분의 경우 미들웨어 방식이 제어와 운영 단순성 면에서 가장 균형 잡힌 선택입니다. 🛣️
• 미들웨어 기반 아키텍처에서는 설정 서비스에 규칙을 저장하고, 미들웨어가 Redis에 토큰 버킷 상태를 관리하며 요청을 처리합니다. 🏗️
• 여러 서버로 확장 시 발생하는 카운터 손실(경쟁 조건) 문제는 Redis Lua 스크립트와 같은 '원자적 연산'을 사용하여 읽기, 확인, 증가 작업을 단일 단위로 묶어 해결할 수 있습니다. ⚛️
• 이 외에도 다중 지역 배포 시 지리적 지연, 핫 키 처리, 서버 재시작 없는 규칙 업로드, 시스템 장애 시 동작 방식 등 고려할 흥미로운 주제들이 있습니다. 🌐