INSIGHTS · Technology
여러 서버에서 외부 API 요청을 위한 Redis 기반 Rate Limiter 설계 방안
BLICT · 2026. 10. 20. · 수정 2026. 10. 20.
외부 API의 초당 요청 제한을 고려하여 Redis 기반의 전역 Rate Limiter와 작업 큐를 설계하는 방법을 다룹니다. 429 응답 처리와 재시도, 지수 백오프 기법도 포함됩니다.
Redis 기반 Rate Limiter의 필요성
외부 API와의 통신 시, 각 API마다 정해진 요청 수 제한이 있습니다. 예를 들어, 초당 10회의 요청을 허용하는 API가 있다고 가정할 때, 여러 서버에서 동시에 요청을 보낼 경우, 이 제한에 쉽게 도달할 수 있습니다. 이 상황에서 Redis 기반의 전역 Rate Limiter를 설계하는 것은 필수적입니다. Redis는 빠른 메모리 기반의 데이터 저장소로, 여러 서버 간의 상태를 공유하고 관리하는 데 적합합니다.
Redis를 활용하면 각 서버가 상태를 동기화하여 중앙 집중식으로 요청 수를 관리할 수 있습니다. 이를 통해 제한을 초과하지 않도록 요청을 조절할 수 있으며, 서버 간의 처리량을 고르게 분배할 수 있습니다. 이러한 방식은 API 호출의 효율성을 높이고, 429 응답을 최소화하는 데 기여합니다.
Redis Rate Limiter 설계
Redis를 활용한 Rate Limiter를 설계하는 첫 단계는 키를 설정하는 것입니다. 각 API 요청에 대해 Redis에 저장되는 키를 생성합니다. 예를 들어, rate_limit:{api_key}:{user_id} 형식의 키를 사용하여 사용자의 요청 수를 기록할 수 있습니다. 이 키에 대해 초당 요청 수를 카운트하도록 설정하고, 이 카운트가 10을 초과하는 경우 더 이상 요청을 보내지 않도록 로직을 구현합니다.
다음 단계로는, Redis의 INCR 명령어를 사용하여 요청 수를 증가시키고, 만약 초과된다면 429 응답을 반환하도록 합니다. 요청 수를 증가시킬 때, TTL(Time To Live) 값을 설정하여 일정 시간 후에 자동으로 카운트를 초기화할 수 있습니다. 이 과정을 통해 요청 수를 관리하고, Rate Limiter를 효과적으로 구현할 수 있습니다.
작업 큐와 비동기 처리
Rate Limiter의 설계에서 중요한 부분은 작업 큐를 도입하는 것입니다. 요청이 초과되었을 경우, 즉시 429 응답을 반환하는 대신 요청을 작업 큐에 저장합니다. 이를 통해 요청을 재시도할 수 있는 기회를 제공하며, 이 과정에서 지수 백오프 기법을 적용할 수 있습니다.
지수 백오프는 요청이 실패할 경우 대기 시간을 점진적으로 늘려가며 재시도하는 방법입니다. 예를 들어, 첫 번째 재시도는 1초 후, 두 번째는 2초 후, 세 번째는 4초 후처럼 지수적으로 대기 시간을 늘려 요청을 재전송할 수 있습니다. 이러한 방식은 API 서버에 부하를 줄여주는 효과가 있으며, 전체적인 시스템의 안정성을 높이는 데 기여합니다.
429 응답 처리 및 재시도 로직
429 응답을 처리하는 로직은 Rate Limiter의 핵심입니다. 서버가 429 응답을 받을 경우, 클라이언트는 요청을 즉시 재시도하는 대신, 일정 대기 시간을 두고 재요청하도록 설계해야 합니다. 이때, 클라이언트는 대기 시간과 재시도 횟수를 설정할 수 있는 옵션을 제공받아야 합니다.
Redis에 저장된 카운트와 TTL 값을 활용하여 대기 시간을 동적으로 조정할 수도 있습니다. 예를 들어, 사용자의 요청 수가 7회인 경우, 남은 요청 가능 횟수를 기반으로 대기 시간을 계산할 수 있습니다. 이로 인해 서버는 불필요한 요청을 줄이고, API 사용 효율성을 높일 수 있습니다.
서버별 처리량 조정
여러 서버에서 호출하는 경우 각 서버의 처리량을 조정하는 것이 중요합니다. Redis Rate Limiter를 통해 각 서버의 요청 수를 모니터링하고, 특정 서버가 과도하게 요청을 보내는 경우 이를 감지할 수 있습니다. 이를 통해 서버별로 요청 제한을 설정하고, 균형 잡힌 API 호출을 유지할 수 있습니다.
서버별 처리량을 조정하는 방법으로는, 요청 수를 기준으로 가중치를 두어 각 서버의 요청 한계를 다르게 설정할 수 있습니다. 예를 들어, 서버 A는 초당 5회, 서버 B는 초당 3회로 설정하여 요청을 분산시킬 수 있습니다. 이러한 방식은 서버의 부하를 줄이고, API 사용 시 발생하는 오류를 최소화하는 데 도움이 됩니다.
체크리스트
- Redis Rate Limiter 설계를 위한 키 형식 정의
- 요청 수 카운트를 위한 TTL 설정
- 작업 큐와 비동기 처리 구현
- 429 응답 처리 및 재시도 로직 설계
- 서버별 처리량 조정 및 모니터링 시스템 구축