6차 시나리오 : Sliding Window Counter

기본 개념은 현재 윈도우의 카운트만 보는 대신, 이전 윈도우의 카운트를 경과 비율로 감소시켜 함께 반영 하는거라고 하는데 말로보면 조금 어렵다.
만약 처리율 제한 장치의 한도가 분당 7개 요청으로 설정 되어있으면 이전 1분동안 5개의 요청(보라색 네모), 그리고 현재 시점에 3개의 요청이 와 있는 상태이다.
현재의 1분의 30% 시점에 도달한 시점에 도착한 새 요청의 경우, 현재 윈도에 몇개 요청이 온것으로 보고 처리해야할까?
- 현재 1분간의 요청 수 + 직전 1분간의 요청수 x 이동 윈도와 직전 1분이 겹치는 비율
- 그러니까 현재 윈도에 들어 있는 요청은 공식에 따르면 6.5개이다. (반올림 or 반내림)
- => 결국 처리율 한도가 분당 7개이니까 30% 딱 도달한 현재 이후에는 한도 초과에 달성해서 더이상 요청은 받을 수 없다..
결국 이전 시간대의 평균 처리율에 따라 현재 윈도의 상태를 계산한다는 특징이 있어서 기존 고정 윈도우와 달리 짧은 시간에 burst 되는 트래픽에도 잘 대응할 수 있다는 장점이 있다.

구현

String currentWindowKey = "rate_limit:" + key + ":" +  
        now.format(DateTimeFormatter.ofPattern("yyyyMMddHHmm"));  
String previousWindowKey = "rate_limit:" + key + ":" +  
        now.minusMinutes(1).format(DateTimeFormatter.ofPattern("yyyyMMddHHmm"));  
  
String prevCountStr = redisTemplate.opsForValue().get(previousWindowKey);  
long previousCount = (prevCountStr != null) ? Long.parseLong(prevCountStr) : 0;  
  
String currCountStr = redisTemplate.opsForValue().get(currentWindowKey);  
long currentCount = (currCountStr != null) ? Long.parseLong(currCountStr) : 0;  
  
// 가중 평균 = 이전 윈도우 카운트 × (1 - 경과 비율) + 현재 윈도우 카운트  
double elapsedRatio = currentSecond / (double) windowSeconds;  
double weightedCount = previousCount * (1 - elapsedRatio) + currentCount;  
  
long resetAt = now.withSecond(0).withNano(0)  
        .plusMinutes(1)  
        .toEpochSecond(ZoneOffset.UTC);  
  
if (weightedCount >= limit) {  
    return RateLimitResult.blocked(limit, resetAt);  
}  
  
Long newCount = redisTemplate.opsForValue().increment(currentWindowKey);  
if (newCount != null && newCount == 1) {  
    redisTemplate.expire(currentWindowKey, Duration.ofSeconds(windowSeconds * 2L));  
}  
  
int remaining = (int) Math.max(0, limit - (weightedCount + 1));  
return RateLimitResult.allowed(limit, remaining, resetAt);

현재와 이전 window를 만들고 각각 정해진 공식으로 가중값을 계산한다음 가중 평균 값이 한계 값보다 크면 차단하도록 구현을 했다.
아래는 5차시나리오에서 작성했던 테스트 코드에서 RedisSlidingWindowCounterRateLimiter를 적용했을 때의 결과다 5차 시나리오에서는 12:30:59와 12:31:00 1초 차이가 되도록 고정한 후 각각 100회씩 요청을 했을때 1초 사이에 총 200회가 허용이 되었던 반면 지금은 정확히 limit만 허용되는걸 확인할 수 있다.

한계

물론 아직 한계는 있다. 이전 윈도우 요청이 균등하게 분포했다고 가정한 상태에서 추정치를 계산하기 때문에 다소 느슨하다는 단점이 있다.
하지만 이 한계는 심각한건 아니라고 한다. 클라우드플레어에서 실시했던 실험에 따르면 40억개의 요청 가운데 시스템의 실제 상태와 맞지 않게 허용되거나 버려진 요청은 0.003%에 불과했다고 한다.

후기

한 챕터를 읽으면서 이해하고 코드로 옮기는 과정까지 심도 있게 공부를 해봤다
이 선택에 대한 의도를 파악하면서 한계를 개선해 나가면서 단계별로 구현을 한 경험은 다소 시간이 걸렸지만 코드 이해 뿐만이 아니라 사고하는 과정도 배울 수 있어서 좋았던것 같다.
앞으로 2권까지 하면 너무 많은 챕터가 남아있는데 몇 시간을 했는지는 정확히 세어보지는 않았는데 일자로는 하루에 2시간 정도해서 4일정도 했던것 같다.
모든 챕터를 순서대로 하기 보다는 재밌어 보이고 나에게 도움이 많이 될만한 주제로 우선순위를 정해서 천천히 해볼 생각이다.
그래도 한 챕터이지만 끝까지 완주해서 기분이 좋다.