Fixed Window Counter

이 알고리즘의 핵심 아이디어는,

“정해진 시간 구간(Window)마다 요청 횟수를 카운트하고, 그 횟수가 정해진 한도(Limit)를 넘지 못하게 막는 것” 이다.

가장 간단하게 비유하자면, "시간제 출입문" 과 같을 수 있다.

• 고정된 시간 구간 (Window): 출입문이 열려있는 시간. (예: 매 1분)

• 카운터 (Counter): 그 시간 동안 통과한 사람의 수를 센다. (예: 1분 동안 10명)

• 제한 (Limit): 정해진 인원(10명)이 모두 통과하면, 다음 시간이 될 때까지 문을 닫는다.

동작 방식

1. 시간 구간 설정: 먼저 시간을 고정된 크기로 나눈다. 예를 들어, 1분, 10분, 1시간 단위로 나눌 수 있다.

2. 카운터 초기화: 새로운 시간 구간이 시작되면, 해당 구간의 카운터를 0으로 초기화한다.

3. 요청 처리 및 카운트 증가: 요청이 들어오면, 현재 시간 구간의 카운터를 1 증가시킨다.

4. 한도 확인: 카운터 값이 미리 설정된 한도보다 작은지 확인한다.

   • 허용 (Allow): 한도 이내라면 요청을 처리한다.

   • 거부 (Deny): 한도를 초과했다면 요청을 거부한다.

5. 윈도우 리셋: 현재 시간 구간이 끝나고 다음 시간 구간이 시작되면, 이전 기록은 모두 무시하고 2번 단계로 돌아가 카운터를 다시 0으로 초기화한다.

• 매우 단순함: 로직이 간단해서 이해하고 구현하기 쉽다.

• 메모리 효율적: 특정 키(사용자, IP 등)에 대해 현재 카운터 값 하나만 저장하면 되므로 메모리 사용량이 적다.

👎 치명적인 단점: 윈도우 경계 문제 (Window Boundary Problem)

이 알고리즘의 가장 큰 문제점은 시간 구간이 바뀌는 경계 지점에서 설정된 한도의 최대 2배까지 요청이 몰릴 수 있다는 점이다.

예시: 1분당 10개의 요청을 허용하는 경우

• 윈도우 크기 = 1분

• Limit = 10번 요청 허용

• 12:00:00 ~ 12:00:59 → 최대 10개 허용

• 12:01:00 ~ 12:01:59 → 최대 10개 허용

• 12:02:00 ~ 12:02:59 → 최대 10개 허용 ...

• 윈도우 1 (12:00:00 ~ 12:00:59)

  • 사용자가 12:00:59 이 마지막 순간에 10개 요청을 보낸다.

    → 이 10개 요청은 모두 허용된다.

• 윈도우 2 (12:01:00 ~ 12:01:59)

  • 바로 1초 후인 12:01:00 에 또 10개 요청을 보낸다.

    → 새 윈도우가 시작되었으므로, 또 10개 요청이 모두 허용된다.

• 실제로는 1초(12:00:59 ~ 12:01:00 사이) 동안 20개의 요청이 들어왔는데,

• Fixed Window Counter는 “분 단위로만 자르기 때문에” 20개를 모두 허용해버린다.

• 이게 바로 Burst 문제이다.

💥 결과: 서버 입장에서는, 즉 실질적인 1분 동안 20개의 요청을 받게 되어 순간적으로 과부하가 발생할 수 있다.

이러한 경계 문제 때문에, 이 알고리즘은 정밀한 제어가 필요 없는 간단한 상황에서 사용되거나, 더 정교한 Sliding Window나 Token Bucket 알고리즘의 개념을 이해하기 위한 기초로 주로 언급된다.