기존 처리율 제한 장치 구현 변경 이유

기존 처리율 제한 장치는 컨트롤러 메서드에 Spring AOP 애노테이션을 적용하여 과도한 요청을 제한하는 방식이었다.

📖 《가상 면접 사례로 배우는 대규모 시스템 설계 기초》 4장에서 다룬 처리율 제한 장치 설계를 참고하여, 보다 효율적인 방식으로 변경하고자 한다.

현재 프로젝트는 대규모 환경은 아니지만, 해당 챕터를 통해 처리율 제한 알고리즘, 캐시 활용법, 제한 장치의 위치 선정에 대한 개념을 학습하였고, 이를 적용하여 기존 구조를 개선하려 한다.

기존 방식

@Aspect
@Component
public class RateLimitAspect {

    private final Cache<String, Integer> requestCountsPerIpAddress = CacheBuilder.newBuilder()
            .expireAfterWrite(1, TimeUnit.MINUTES) // 기본 1분 만료
            .build();

    private final HttpServletRequest request;

    public RateLimitAspect(HttpServletRequest request) {
        this.request = request;
    }

    @Around("@annotation(rateLimit)") // @RateLimit 어노테이션이 있는 메서드에 적용
    public Object rateLimit(ProceedingJoinPoint joinPoint, RateLimit rateLimit) throws Throwable {
        String clientIp = getClientIP();
        int maxRequests = rateLimit.maxRequests();
        int timeWindow = rateLimit.timeWindow();

        // 요청 횟수 확인 및 업데이트
        Integer requests = requestCountsPerIpAddress.getIfPresent(clientIp);
        if (requests == null) {
            requestCountsPerIpAddress.put(clientIp, 1);
        } else if (requests >= maxRequests) {
            throw new ResponseStatusException(HttpStatus.TOO_MANY_REQUESTS, "Too many requests. Try again later.");
        } else {
            requestCountsPerIpAddress.put(clientIp, requests + 1);
        }

        // 요청 허용
        return joinPoint.proceed();
    }

    // 클라이언트 IP 주소 추출
    private String getClientIP() {
        String xfHeader = request.getHeader("X-Forwarded-For");
        if (xfHeader == null) {
            return request.getRemoteAddr();
        }
        return xfHeader.split(",")[0];
    }
}

기존 방식의 경우 Spring AOP로 구성되었다. 이에 대한 문제를 짚어보자.

처리율 제한 장치 요구사항

1. 공정한 요청 처리
2. 서비스 거부 공격(DDoS) 방어
3. 효율적인 트래픽 제어 (Rate Control)
4. 빠른 응답과 낮은 오버헤드
5. 유연한 정책 적용

처리율 제한 장치의 계층 선택

책에서 언급하는 처리율 제한 장치의 위치는 클라이언트, 서버, 클라이언트-서버 사이(미들웨어)를 언급하였다.

🚨 클라이언트 측 처리율 제한의 단점

클라이언트에서 처리율 제한을 적용하면 서버 부하를 줄일 수 없고, 사용자가 제한을 우회할 가능성이 크다. 예를 들어, 브라우저나 앱에서 요청 빈도를 제한해도, 클라이언트 코드를 수정하거나 요청을 조작하면 무력화될 수 있다. 또한, DDoS 공격을 방어할 수 없으며, 각기 다른 클라이언트가 다른 제한 정책을 적용할 수 있어 일관성이 부족하다.

🚨 서버 측 처리율 제한의 단점

서버에서 처리율 제한을 수행하면 중앙에서 요청을 제어할 수 있지만, 부하가 발생한 후에야 감지되어 리소스 낭비가 발생할 수 있다. 또한, 분산 환경에서는 서버별로 제한 정책이 다르게 동작할 수 있어 일관된 제한을 적용하기 어렵다. 이를 해결하려면 Redis 같은 분산 캐시를 사용해야 하지만, 추가적인 개발 및 운영 부담이 발생한다.

미들웨어에 구성하자.

클라우드를 이용시 API GateWay를 이용할 수 있고, Spring의 경우 SpringFilter로 요청이 dispatcherServlet로 가는 것을 막을 수 있다.

분산 환경이 아니기 때문에 내 프로젝트에서는 API Gateway까지는 구성하지 않았다. 그렇기에 Filter로의 구현이 필요할 것 같다.

그렇다면 현재 AOP로 구성한 것은 무엇이 잘못되었을까?

API Gateway vs AOP vs Filter :: 생명주기 관점에서

요구사항	API Gateway	Spring Filter	Spring AOP
공정한 요청 처리	✅ 분산 환경에서도 일관된 요청 제한 가능	⚠ 단일 서버 기준으로 적용 (분산 환경에서는 추가 구성 필요)	⚠ 개별 메서드 호출 단위로 적용되므로 요청 단위 제한이 어려움
DDoS 방어	✅ WAF(Web Application Firewall) 및 Rate Limiting 기능 제공	⚠ 개별 서버에서 적용되므로 전체 시스템 차원의 방어는 어려움	❌ DDoS 공격을 효과적으로 방어하기 어려움
효율적인 트래픽 제어 (Rate Control)	✅ Redis 기반의 글로벌 Rate Limit 지원	✅ 요청 단위로 필터링 가능	⚠ 요청이 아니라 메서드 실행 단위로 제한됨 (API 수준 제한이 아님)
빠른 응답과 낮은 오버헤드	✅ 외부 서비스에서 요청 차단 → 애플리케이션 리소스 소비 최소화	✅ 요청 초기에 필터링 가능 → 애플리케이션 리소스 사용 최소화	❌ 요청이 이미 컨트롤러에 도달한 후 차단되므로 리소스 낭비 가능
유연한 정책 적용	✅ API 별, 사용자 별, IP 별로 설정 가능	✅ 특정 URL 패턴에 대해 적용 가능	⚠ 특정 메서드별 적용 가능하지만, API 수준의 정책 적용은 어려움

위 표를 참고하면 단일(개별) 서버에 적용한다면 SpringFilter로의 개발이 나쁘지 않음을 알 수 있다.

위 표를 이해하기 위해 필터와 AOP의 생명주기를 그림으로 이해해보자.

filter의 경우 Spring으로 요청이 전달되기 전에 제한규칙에 따라 제한되었다면 요청을 쫓아낸다. 하지만 AOP의 경우 스프링 내의 서비스 및 리포지토리 계층까지의 접근은 막을지 몰라도 스프링까지 요청이 들어오기에 빠른 응답과 낮은 오버헤드의 관점에서 불합격이다. 이에 따라 당연히 DDOS 방어에도 불만족스럽다.

🏋️ 실세계 비유로 접근해보자

어느 헬스장은 회원들의 일일 이용을 "한 번"으로 제한한다.
일반적인 구현 방식이라면, 입구에서 회원번호를 입력하면 즉시 이용 가능 여부를 확인하고,
이미 이용한 경우 "금일 입장 불가" 응답(필터 처리)을 받아 입장이 차단된다.

---

하지만 기존 AOP 방식에서는 누구나 입구를 통과할 수 있다.
사용자는 헬스복으로 환복하고, 물을 한잔 마시고, 아령을 들려고 할 때야 비로소
"금일 헬스장 이용 불가" 응답(AOP 처리)을 받는다.

---

🛠 핵심:
AOP → Filter로 변경한 이유는 "어차피 나가야 할 사람을 안까지 불러들여 걸러내지?" 라는 문제를 해결하기 위함이다.
불필요한 자원 낭비 없이 입구에서 제한하는 것이 더 합리적이다.

필터 구현

@Slf4j
@Order(1) // 인증 필터보다 먼저 실행
public class RateLimitingFilter extends OncePerRequestFilter {

    private static final int MAX_REQUESTS = 10; // 분당 최대 요청 수

    private final Cache requestCounts;


    public RateLimitingFilter(CacheManager cacheManager) {
        this.requestCounts = cacheManager.getCache("rateLimitCache");
    }

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
            throws ServletException, IOException {

        String key = getRateLimitKey(request);
        Integer count = requestCounts.get(key, Integer.class);

        if (count == null) {
            requestCounts.put(key, 1);
        } else if (count >= MAX_REQUESTS) {
            response.setStatus(HttpStatus.TOO_MANY_REQUESTS.value());
            response.getWriter().write("Too Many Requests");
            log.warn("Rate limit exceeded for {}", key);
            return;
        } else {
            requestCounts.put(key, count + 1);
        }

        filterChain.doFilter(request, response);
    }

    /**
     * IP 기반 Rate Limit 키 생성
     * - `X-Forwarded-For` 헤더가 존재하면 첫 번째 IP를 사용 (프록시 환경 고려)
     * - 없다면 `request.getRemoteAddr()` 사용
     */
    private String getRateLimitKey(HttpServletRequest request) {
        String ip = getClientIp(request);
        return ip + ":" + request.getRequestURI();
    }

    /**
     * 클라이언트의 실제 IP 주소 반환
     * - `X-Forwarded-For` 헤더가 존재하면 첫 번째 IP 사용 (프록시 환경 고려)
     * - 없다면 `request.getRemoteAddr()` 사용
     */
    private String getClientIp(HttpServletRequest request) {
        String forwardedFor = request.getHeader("X-Forwarded-For");
        if (forwardedFor != null && !forwardedFor.isEmpty()) {
            return forwardedFor.split(",")[0].trim(); // 여러 개의 IP가 있을 경우 첫 번째 사용
        }
        return request.getRemoteAddr();
    }
}

처리율 제한 방식: 고정 윈도우 카운터

동작 방식

1️⃣ 요청이 들어오면 ➝ 캐시(ehcache)에서 카운트를 +1 증가 ⬆️
2️⃣ 최대 요청 수 ➝ 10개까지 허용
3️⃣ 캐시 만료 시간 ➝ 새로 생성된 캐시는 1분간 유지 ⌛ (고정 윈도우 방식)
4️⃣ 요청 횟수가 10을 초과하면 ➝ TOO_MANY_REQUESTS 응답 반환 ⚠️

---

📌 특징

• 구현이 간단함 ➝ 요청 수를 카운팅하고 제한하는 방식
• 약간 느슨한 규칙 적용 ➝ 윈도우 경계 문제(Burst Traffic 가능성) 존재
• 고정된 시간(1분)마다 초기화 ➝ 새로운 윈도우에서 카운트 리셋

---

🚨 고정 윈도우 카운터 방식의 단점

📌 예시 (버킷 max 값 = 5)

• 2:00:00 → 캐시가 초기화됨
• 2:00:58 → 5개의 요청이 들어옴 (제한 내 요청)
• 2초 뒤(2:01:00) → 캐시가 초기화됨
• 2:01:01 → 다시 5개의 요청이 들어옴

➡ 약 3초 동안 총 10개의 요청이 처리됨
➡ 하지만 버킷 max 값은 5이므로, 원래는 허용되지 않아야 하는 요청이 허용됨

---

⚠ 이 방식의 한계

• 시간 경계(윈도우 리셋) 문제 발생 → 짧은 시간 동안 많은 요청이 허용될 수 있음
• 정확한 요청 제한이 필요할 경우 적합하지 않음

---

✅ 내 프로젝트에서는?

📌 처리율 제한이 아주 정밀할 필요는 없으므로, 구현이 쉬운 고정 윈도우 카운터 방식을 선택
📌 보다 정확한 제한이 필요하다면 슬라이딩 윈도우 방식 고려 가능