3차 시나리오 : 다중 서버 환경에서의 한계 분석

이전 글에서 말한 것 처럼 서버가 만약 여러 대라면? 이라는 시나리오를 통해 다중 서버 환경에서의 한계 분석을 해보겠다

문제 상황

현재 상황은 단일 서버 환경인데 만약 서버가 여러대인 환경이라면?

1	`client -> server -> DB`

기존 count 값을 서버의 ConcurrentHashMap(JVM 메모리)에 저장을 하도록 구현이 되어있다면 아래와 같은 구성에서는 각각의 JVM 인스턴스마다 카운트 값이 독립적이된다.
같은 사용자 user:123이 limit = 100인데, 로드밸런서가 요청을 분산하면 각각의 인스턴스에 40씩 분산을 했다고 해도 각 인스턴스 기준으로는 limit를 초과를 하지 않았지만 전체 구조에서는 이미 120으로 limit를 초과를 했다 => 각 서버는 자기 카운터만 보기 때문에 전체 제한이 깨지는 문제가 있다.

Load Balancer
    ├── Server A (ConcurrentHashMap: user:123 → 40)
    ├── Server B (ConcurrentHashMap: user:123 → 40)
    └── Server C (ConcurrentHashMap: user:123 → 40)

즉 메모리 기반 rate limiter는 단일 서버에서만 유효하다.

다중 서버 문제 상황 재현

그럼 직접 테스트를 위해 다중 서버 환경일 때 어떤 일이 일어나는지 테스트 코드로 확인해봤다.

1. 메모리 기반은 전체 limit을 보장하지 못한다.

서버가 만약 3대면 limit은 지켜지는가?
순차 분배를 해봤다.

@Test  
@DisplayName("서버 3대 시뮬레이션: 메모리 기반은 전체 limit을 보장하지 못한다")  
void multi_server_exceeds_limit() {  
    int serverCount = 3;  
    int limit = 100;  
    int totalRequests = 200;  
  
    FixedWindowRateLimiterV2[] servers = new FixedWindowRateLimiterV2[serverCount];  
    int[] serverRequestCount = {0, 0, 0};  
    for (int i = 0; i < serverCount; i++) {  
        servers[i] = new FixedWindowRateLimiterV2();  
    }  
  
    int totalAllowed = 0;  
    for (int i = 0; i < totalRequests; i++) {  
        FixedWindowRateLimiterV2 server = servers[i % serverCount];  
        RateLimitResult result = server.tryAcquire("user:123", limit, 60);  
        if (result.allowed()) {  
            serverRequestCount[i % serverCount]++;  
            totalAllowed++;  
        }  
    }  
  
    for (int i = 0; i < serverCount; i++) {  
        System.out.println("server " + (i + 1) + ": " + serverRequestCount[i] + " requests");  
    }  
  
    System.out.println("[순차 분배] 전체 허용 수: " + totalAllowed + " (limit: " + limit + ")");  
  
    assertThat(totalAllowed)  
            .as("서버가 3대면 각각 독립 카운터를 가지므로 전체 limit을 초과한다")  
            .isGreaterThan(limit);  
}

로드 밸런서를 가정해서 3대의 서버에 200개의 요청을 분배를 했다.
당연히 예상대로 각각 독립된 메모리를 가지기 때문에 limit 100을 초과 하는 200개의 요청이 들어왔다.

2. 동시 요청 + 다중 서버 : 동시성까지 겹치면 더 심하게 초과한다.

동시 요청이 다중 서버에 분산되면 어떻게 되는가?

@Test  
@DisplayName("동시 요청 + 다중 서버: 동시성까지 겹치면 더 심하게 초과한다")  
void concurrent_multi_server_exceeds_limit() throws InterruptedException {  
    int serverCount = 3;  
    int limit = 100;  
    int threadCount = 300;  
  
    FixedWindowRateLimiterV2[] servers = new FixedWindowRateLimiterV2[serverCount];  
    int[] serverRequestCount = {0, 0, 0};  
    for (int i = 0; i < serverCount; i++) {  
        servers[i] = new FixedWindowRateLimiterV2();  
    }  
  
    CountDownLatch startLatch = new CountDownLatch(1);  
    CountDownLatch doneLatch = new CountDownLatch(threadCount);  
    AtomicInteger totalAllowed = new AtomicInteger(0);  
  
    ExecutorService executor = Executors.newFixedThreadPool(threadCount);  
    for (int i = 0; i < threadCount; i++) {  
        int serverIndex = i % serverCount;  
        executor.submit(() -> {  
            try {  
                startLatch.await();  
                RateLimitResult result = servers[serverIndex].tryAcquire("user:123", limit, 60);  
                if (result.allowed()) {  
                    serverRequestCount[serverIndex]++;  
                    totalAllowed.incrementAndGet();  
                }  
            } catch (InterruptedException e) {  
                Thread.currentThread().interrupt();  
            } finally {  
                doneLatch.countDown();  
            }  
        });  
    }  
  
    startLatch.countDown();  
    doneLatch.await(5, TimeUnit.SECONDS);  
    executor.shutdown();  
  
    int allowed = totalAllowed.get();  
    for (int i = 0; i < serverCount; i++) {  
        System.out.println("server " + (i + 1) + ": " + serverRequestCount[i] + " requests");  
    }  
      
    System.out.println("[동시 분배] 전체 허용 수: " + allowed + " (limit: " + limit + ")");  
  
    assertThat(allowed)  
            .as("다중 서버 환경에서 전체 limit을 초과한다")  
            .isGreaterThan(limit);  
}

여기도 역시 예상대로 동시에 300 요청을 분배를 해도 limit를 초과하는 결과가 나왔다.

3. 단일 서버 vs 다중 서버: 같은 요청 수인데 결과가 다르게 나온다.

같은 200개의 요청인데 왜 결과가 다를까?

@Test  
@DisplayName("단일 서버 vs 다중 서버: 같은 요청 수인데 결과가 다르다")  
void single_vs_multi_server_comparison() {  
    int limit = 100;  
    int totalRequests = 200;  
  
    // 단일 서버  
    FixedWindowRateLimiterV2 singleServer = new FixedWindowRateLimiterV2();  
    int singleAllowed = 0;  
    for (int i = 0; i < totalRequests; i++) {  
        RateLimitResult result = singleServer.tryAcquire("user:single", limit, 60);  
        if (result.allowed()) {  
            singleAllowed++;  
        }  
    }  
  
    // 다중 서버 (3대)  
    FixedWindowRateLimiterV2[] multiServers = {  
            new FixedWindowRateLimiterV2(),  
            new FixedWindowRateLimiterV2(),  
            new FixedWindowRateLimiterV2()  
    };  
    int multiAllowed = 0;  
    for (int i = 0; i < totalRequests; i++) {  
        if (multiServers[i % 3].tryAcquire("user:123", limit, 60).allowed()) {  
            multiAllowed++;  
        }  
    }  
  
    System.out.println("단일 서버 허용: " + singleAllowed);  
    System.out.println("다중 서버 허용: " + multiAllowed);  
  
    assertThat(singleAllowed).isEqualTo(limit);  
    assertThat(multiAllowed).isGreaterThan(limit);  
}

위의 3개의 테스트를 통해 문제상황을 검증 해봤다.

4차 시나리오 : Redis 기반 Fixed Window

결국 서로 다른 메모리 영역에 count를 저장하기 때문에 생기는 문제이다.
해결책은 간단한데 공통된 영역에서 count를 관리(공유 저장소)하면 될것이다.
이 공유 저장소에서 Redis를 사용할 것이다.
“왜?? Redis를 사용하죠 공유 저장소를 만드는 거면 그냥 DB 사용해도 되는거 아닌가여?”
- 그렇다 그냥 공유 저장소 역할을 할거면 그냥 DB를 사용해도 될것이다.
- 하지만 지금 이 도메인 특성상 rate limiter 즉 제한 시간동안 제한된 허용 값 보다 초과된 경우를 막기 위해 휘발성인 특징이 있는 count를 관리해야 한다.
- 추가로 만약 Mysql 같은 DB를 사용을 한다면 읽기와 쓰기가 빈번한 상황에서는 좋은 선택지가 아니다. Redis는 메모리 기반으로 매우 빠른 속도가 필요한 지금 상황에 적합하다고 볼 수 있다.
- 추가로 Redis를 사용하면 원자적인 연산인 INCR을 제공하기 때문에 동시성 제어도 편안하다는 장점이 있다.

public RateLimitResult tryAcquire(String key, int limit, int windowSeconds) {  
    String now = LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyyMMddHHmm"));  
    String redisKey = "rate_limit:" + key + ":" + now;  
  
    Long count = redisTemplate.opsForValue().increment(redisKey);  
  
    if (count != null && count == 1) {  
        redisTemplate.expire(redisKey, Duration.ofSeconds(windowSeconds));  
    }  
  
    long resetAt = LocalDateTime.now()  
            .withSecond(0).withNano(0)  
            .plusMinutes(1)  
            .toEpochSecond(ZoneOffset.UTC);  
  
    if (count != null && count <= limit) {  
        return RateLimitResult.allowed(limit, (int) (limit - count), resetAt);  
    } else {  
        return RateLimitResult.blocked(limit, resetAt);  
    }  
}

이전 시나리오와 유사하지만 redis라는 공유 저장소를 적용한 차이가 있다.
Long count = redisTemplate.opsForValue().increment(redisKey);
- 원자적으로 count값 가져오기 count값 증가 시키기
redisTemplate.expire(redisKey, Duration.ofSeconds(windowSeconds));
- 만료 시간 초과 되면 redis 키 만료 시키기

1. Redis 기반 : 서버 3대에서 요청해도 limit를 지킨다

3차 시나리오에서 테스트 한 결과와 달리 서버가 달라도 공유 저장소를 사용하기 때문에 순차 분배 했을 때 정확히 limit를 지키는 모습

2. Redis 기반 : 동시 요청 + 다중 서버에서도 limit 지킨다

역시 이 부분도 3차 시나리오 테스트 한 결과와 다르게 동시 요청에도 limit를 정확히 지키는 모습
지금 까지 Fixed Window 기반으로 rate를 제한 하고 있었다.
하지만 Fixed Window는 명확한 단점이 있는데 경계값에서 비정상적으로 많은 요청을 허용할 수 있는 문제가 있다.

5차 시나리오: Fixed Window 경계값 문제 재현

Fixed Window의 경계값 한계 :
- 지금 현재 fixed window는 고정된 시간을 기준으로 window를 나누고 있어서 key를 만들때 rate_limiter:user:2025:03:22:01:21 이런식으로 분 단위로 타임스탬프를 만들기 때문에 윈도우가 바뀌면 카운터가 0에서 다시 시작을 한다. 이전 윈도우에서 얼마나 썼는지를 전혀 고려하지 않는다.
그림 처럼 파란 네모가 한 윈도우 크기인데 이 한 윈도우 마다 100회 제한을 걸어뒀지만 이 경계값에 요청이 몰리면 12:00:59초에 100회 요청하면 (12:00~12:00:59)윈도우의 limit 이내니까 전부 허용을 하고 12:01:00에 100회 요청하면 (12:01~12:01:59)윈도우의 limit 이내니까 전부 허용을 한다 즉 1~2초 사이에 200회가 통과 돼버리는 문제가 생긴다
1분의 100회 허용 -> 1초의 200회 허용 이 되어버리는 치명적인 문제가 생긴다

경계값 문제 재현

윈도우 경계 1초 사이에 limit의 2배가 허용된다

@Test  
@DisplayName("윈도우 경계 1초 사이에 limit의 2배가 허용된다")  
void boundary_burst_with_clock() {  
  int limit = 100;  
  
  // 12:30:59 시점의 Clock (윈도우 1 끝)  
  Clock clock1 = Clock.fixed(  
          LocalDateTime.of(2026, 3, 22, 12, 30, 59).toInstant(ZoneOffset.UTC),  
          ZoneOffset.UTC  
  );  
  TestableRedisFixedWindowRateLimiter limiter1 = new TestableRedisFixedWindowRateLimiter(redisTemplate, clock1);  
  
  // 12:31:00 시점의 Clock (윈도우 2 시작, 1초 후)  
  Clock clock2 = Clock.fixed(  
          LocalDateTime.of(2026, 3, 22, 12, 31, 0).toInstant(ZoneOffset.UTC),  
          ZoneOffset.UTC  
  );  
  TestableRedisFixedWindowRateLimiter limiter2 = new TestableRedisFixedWindowRateLimiter(redisTemplate, clock2);  
  
  // 윈도우 1에서 100회 요청  
  int allowed1 = 0;  
  for (int i = 0; i < limit; i++) {  
      if (limiter1.tryAcquire("user:burst", limit, 60).allowed()) {  
          allowed1++;  
      }  
  }  
  
  // 윈도우 2에서 100회 요청 (1초 후)  
  int allowed2 = 0;  
  for (int i = 0; i < limit; i++) {  
      if (limiter2.tryAcquire("user:burst", limit, 60).allowed()) {  
          allowed2++;  
      }  
  }  
  
  int totalAllowed = allowed1 + allowed2;  
  
  System.out.println("윈도우 1 허용: " + allowed1);  
  System.out.println("윈도우 2 허용: " + allowed2);  
  System.out.println("1초 사이 총 허용: " + totalAllowed + " (limit: " + limit + ")");  
  
  assertThat(allowed1).isEqualTo(limit);  
  assertThat(allowed2).isEqualTo(limit);  
  assertThat(totalAllowed)  
          .as("경계에서 limit의 2배가 허용된다")  
          .isEqualTo(limit * 2);  
}

Clock을 사용해서 12:30:59와 12:31:00 1초 차이가 되도록 고정한 후 각각 100회씩 요청을 했는데 -> 결국 아래 사진처럼 1초 사이에 총 200회가 허용이 되는 모습을 볼 수 있다.

다음 편

5차 시나리오를 개선하기 위해 여러 전략중 Sliding Window Counter를 사용해서 경계값 burst 문제를 해결해보려고 한다.