내 서버를 지키는 방패: API Rate Limiting 구현

Rate Limiting이란 무엇인가?

Rate Limiting(처리율 제한)은 특정 사용자나 IP가 정해진 시간 동안 서버에 요청할 수 있는 횟수를 제한하는 기술입니다.

"1분에 10회까지만 비밀번호 찾기 가능", "IP당 하루 1,000번까지만 API 호출 가능" 같은 규칙이 대표적인 예입니다. 이를 통해 무차별 대입 공격(Brute Force)을 막고, 소수의 사용자가 서버 자원을 독점하는 것을 방지합니다.

왜 Rate Limiting을 메인 DB에서 하지 않을까?

Rate Limiting을 구현하려면 "이 IP가 최근 1분 동안 몇 번 요청했는지"를 계속 기록하고 세어야 합니다. 만약 이 작업을 PostgreSQL 같은 메인 데이터베이스에서 한다면 어떤 일이 발생할까요?

요청이 들어올 때마다 메인 DB에 카운트를 업데이트하고 조회해야 하므로, 트래픽이 몰릴 때 오히려 Rate Limiting 시스템 자체가 병목을 일으켜 서비스 장애의 원인이 될 수 있습니다.

반면 Redis는 메모리 기반이라 카운트를 올리는 속도가 비교할 수 없이 빠릅니다. 트래픽의 최전선에서 방패 역할을 하려면 압도적으로 빠른 Redis가 필수적입니다.

고정 윈도우(Fixed Window) 카운터 패턴

가장 단순하면서도 실무에서 널리 쓰이는 Rate Limiting 패턴입니다. 시간 단위를 쪼개서(예: 1분) 해당 시간 단위마다 카운터를 만드는 방식입니다.

예를 들어 IP `192.168.0.1`의 "2026-07-12 10:15" 1분 동안의 요청 횟수를 제한한다면, 키 이름에 시간 정보를 포함시킵니다.

async function checkRateLimit(ip) {
  // 현재 시간의 '분' 단위까지만 추출 (예: 2026-07-12T10:15)
  const currentMinute = getCurrentMinuteString();
  const key = `ratelimit:ip:${ip}:${currentMinute}`;
  
  // Redis의 INCR 명령어: 값이 없으면 1로 생성, 있으면 1 증가시킴 (아주 빠름!)
  const count = await redis.incr(key);
  
  // 카운터가 메모리에 영원히 남지 않도록 2분 후 자동 삭제 (TTL 설정)
  if (count === 1) {
    await redis.expire(key, 120); 
  }
  
  if (count > 60) {
    return false; // 1분에 60회 초과 시 차단
  }
  return true; // 정상 요청 허용
}

서버 여러 대 환경에서의 Rate Limiting

웹 서버를 메모리 제한용으로 쓰면 안 되는 이유를 이전 에피소드에서 세션을 다루며 배웠습니다. Rate Limiting도 마찬가지입니다. 서버 A에 30번, 서버 B에 40번 요청을 분산해서 보내면 개별 서버는 제한을 넘지 않은 것으로 착각할 수 있습니다.

따라서 Rate Limiting도 모든 웹 서버가 중앙의 Redis 하나를 바라보고 횟수를 확인하도록 아키텍처를 설계해야 정확한 트래픽 제어가 가능합니다.