배경

가상 면접 사례로 배우는 대규모 시스템 설계 기초 책을 옛날부터 구매를 했었는데 항상 언젠가는 읽어야지 하고 생각만 했었지 본격적으로 읽지 않았었다.

이제는 AI의 발전으로 코딩은 AI가 더 잘한다는 사실은 부정할 수 없다. 하지만 이 아키텍쳐 부분 특히 복잡한 요구사항을 어떤식으로 구현을 하는게 좋을지에 대한 판단하는 능력은 앞으로 더욱 중요해질것 같다는 생각이 들었다.

The Next Two Years - Addy Osmani 최근에 이 글을 읽고 공감을 많이 하게되었고 그래서 이 책을 빨리 읽으면서 직접 구현도 해보는 과정을 지금 아니면 언제할까는 생각에 읽기 시작했다.

YouTube 채널 여기서 공부 기록을 라이브 방송으로 매일 진행을 하고 있다 ㅎㅎ

계획

이 책에는 다양한 대규모 설계에 대한 사례들이 실려 있다. 해당 주제들을 실제 코드와 환경을 구축해보면서 점점 개선을 해나가는 것이 목표이고 이런 과정에서 배우고자 하는것은 다양한 도메인에서 어떤 식으로 설계를 하면 되는지를 익히고 이를 AI를 통해서 구현을 해보는 과정을 경험을 하고자 한다.

단 여기서 AI를 통해서 구현을 하지만 모든 구현 과정을 내가 이해하고 넘어가려고 한다. 딸깍으로 하려면 할 수 있겠지만 지금 제대로 배워두지 않으면 나중에 설계를 할 때 이게 지금 상황에 적합한 선택인지와 왜 이런 식으로 구현을 했는지에 대해 설명을 할 수 없을 것 같아서 이다. 위 저 링크에서도 구글 크롬 팀 리더 분 글처럼 AI를 활용하는 동시에 나의 공부 멘토로써도 사용하는 방법을 사용하려고 한다.

우선 순서는 이런식으로 진행 할 것 같다.

챕터 하나를 한번 훑어보고
AI에게 이런 이런 상황에 대한 설명과 함께 요구사항과 트래픽 등을 가정한 시나리오를 만든다
해당 요구사항을 위한 최소 구현을 한다
책에서 제시한 설계를 통해 시나리오 별로 테스트 및 개선을 한다
해당 기록을 남긴다.

Rate Limiter(처리율 제한 장치 설계)

GitHub - Byuntil/rate-limiter

1. 프로젝트 배경

운영 중인 커뮤니티 서비스에서 특정 게시글이나 인기 API에 짧은 시간 동안 요청이 몰리는 상황이 발생한다. 일부는 정상 사용자 유입이지만, 일부는 새로고침 반복이나 비정상 호출로 인해 서버 자원을 과도하게 사용한다.
이로 인해 다음 문제가 생긴다. (애플리케이션 서버 부하 증가, DB 조회량 급증, 특정 사용자의 과도한 호출로 전체 사용자 경험 저하, 로그인/비로그인 사용자 간 공정하지 않은 사용량 분배)
그래서 API 요청 수를 일정 기준으로 제한하는 처리율 제한 장치를 설계하고 구현한다.

2. 서비스 가정

서비스는 게시글 조회 기능이 있는 커뮤니티 서비스라고 가정한다.
대상 API - GET /posts/{postId}
API 특징
- 조회 요청이 매우 많다
- 인기 게시글에 트래픽이 몰릴 수 있다
- 비로그인 사용자는 IP 기준으로 식별해야 한다
- 로그인 사용자는 사용자 ID 기준으로 식별할 수 있다

3. 목표

이 프로젝트의 목표는 단순히 요청을 막는 것이 아니라, 현실적인 제약이 있는 환경에서 rate limiter를 점진적으로 설계·구현·개선하는 것이다.
최종적으로 다음을 보여주는 것을 목표로 한다.
- 단일 서버 환경에서의 기본 처리율 제한 구현
- 동시성 문제 재현 및 개선
- 다중 서버 환경에서의 한계 분석
- Redis 기반 분산 처리율 제한 장치 구현
- 알고리즘별 차이점 비교
- 부하 테스트를 통한 검증

4. 요구사항

기능 요구사항
- 비로그인 사용자는 IP 기준으로 요청 횟수를 제한한다
- 로그인 사용자는 사용자 ID 기준으로 요청 횟수를 제한한다
- 관리자는 제한 대상에서 제외한다
- 제한 초과 시 429 Too Many Requests 를 반환한다
- 응답 헤더에 남은 요청 수와 제한 정보를 포함한다
정책 요구사항
- 비로그인 사용자: 1분에 30회
- 관리자: 제한 없음
비기능 요구사항
- 동시 요청 상황에서도 가능한 한 정확해야 한다
- 서버가 여러 대여도 동일한 제한 정책이 적용되어야 한다
- 추후 다른 API에도 확장 가능해야 한다
- 알고리즘 교체가 가능하도록 구조를 분리해야 한다

1차 시나리오 : 단일 서버 + 메모리 기반 Fixed Window

가장 단순한 방식
사용자별 key 생성 -> 현재 1분 윈도우 내 요청 수를 저장한다 -> 제한 횟수를 넘으면 차단한다
ex) user:123 -> 1분동안 100회, ip:10.0.0.1 -> 1분 동안 30회

@Component  
public class FixedWindowRateLimiter implements RateLimiter {  
  
    private final Map<String, Integer> request = new HashMap<>();  
  
    @Override  
    public RateLimitResult tryAcquire(String key, int limit, int windowSeconds) {  
        String now = LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyyMMddHHmm"));  
        String value = key + ":" + now;  
  
        int count = request.getOrDefault(value, 0) + 1;  
        request.put(value, count);  
  
        long resetAt = LocalDateTime.now()  
                .withSecond(0).withNano(0)  
                .plusMinutes(1)  
                .toEpochSecond(ZoneOffset.UTC);  
  
        if (count <= limit) {  
            return RateLimitResult.allowed(limit, limit - count, resetAt);  
        } else {  
            return RateLimitResult.blocked(limit, resetAt);  
        }  
    }  
    
    @Scheduled(fixedRate = 60_000)  
    public void cleanUp() {  
        String currentWindow = LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyyMMddHHmm"));  
        request.entrySet().removeIf(e -> !e.getKey().contains(":" + currentWindow));  
    }

해당 필터를 인터셉터에서 사용하여 rateLimiter.tryAcquire() HTTP 요청을 가로채서 rate limit를 하도록 구현을 했다.
HashMap 사용 이유?
- 사용자별 요청 횟수를 key-value로 저장하기 위해 HashMap을 선택했다.
- 1차에서는 동시성을 고려하지 않고, 가장 직관적인 방식(getOrDefault + put)으로 구현했다.
Interceptor 선택한 이유?
- spring mvc는 다음과 같은 순서를 가진다
- HTTP 요청 -> Filter -> DispatcherServlet -> Interceptor -> Controller
- 근데 Filter에 비해 Interceptor는 더 spring mvc에 구조에 특화된 필터 기능을 제공을 한다. spring bean을 자연스럽게 의존성 주입할 수 있는것이 가장 큰 특징이다.
- 그래서 FixedWindowRateLimiter는 스프링 빈에 의존하므로 사용을 했다.

RateLimitInterceptor 흐름

preHandle 진입
    │
    ▼
관리자 여부 확인 (isAdmin)
    │ YES → return true (통과)
    │ NO
    ▼
클라이언트 키 추출 (resolve)
    │ 로그인: "user:123"
    │ 비로그인: "ip:127.0.0.1"
    ▼
limit 결정
    │ 로그인: defaultLimit (100)
    │ 비로그인: anonymousLimit (30)
    ▼
RateLimiter.tryAcquire(key, limit, windowSize)
    │
    ├─ allowed=true → 헤더 추가 후 return true
    │
    └─ allowed=false → 429 JSON 응답 후 return false

2차 시나리오: 동시성 문제 재현 및 개선

목표

1차 구현(FixedWindowRateLimiter)에서 동시 요청 시 limit을 초과한 요청이 허용되는 현상을 재현하고, 원인을 분석한 뒤 개선해보자

현재 구현의 문제

@Component  
public class FixedWindowRateLimiter implements RateLimiter {  
  
    private final Map<String, Integer> request = new HashMap<>();

int count = request.getOrDefault(value, 0) + 1; //읽기
request.put(value, count); //쓰기

if (count <= limit) {
    return RateLimitResult.allowed(...);
} else {
    return RateLimitResult.blocked(...);
}

만약 200개 스레드가 동시에 요청하면 허용 수가 limit를 초과할까?
- 실제 테스트 코드를 돌려본 결과 allow 된 수가 limit로 설정한 100보다 큰 경우가 생기는 걸 알 수 있다. 이유가 뭘까?
현재 상태
- 지금 FixedWindowRateLimiter 같은 경우 @Component이므로 싱글톤 빈 하나만 존재를 해서 모든 스레드가 HashMap을 공유하고 있다.
- getOrDefault() 읽기와 request.put() 쓰기가 분리되어 있다.
- 단일 스레드에서는 문제가 없지만, 동시 요청 시 여러 스레드가 같은 값을 읽고 같은 값을 쓸 수 있다
  - 예를 들어 스레드 A,B,C가 있으면 count가 현재 99라고 가정을 하면 A 스레드가 읽고 쓰는 사이에 스레드 B와 C도 현재 count 값을 읽으면 여전히 99이다. 그래서 3개의 스레드 모두 허용이 되는 매직~~ 이 발생한다.
  - 그래서 위 사진과 같이 허용된 요청 수가 limit 보다 더 커지는 경우가 생기는 것이다. 이미 초과 허용된 B와 C는 되돌릴 수 없다

개선

그렇다면 어떻게 개선할 수 있을까? 결론 부터 말하면 ConcurrentHashMap + AtomicInteger

private final ConcurrentHashMap<String, AtomicInteger> request = new ConcurrentHashMap<>();  
  
@Override  
public RateLimitResult tryAcquire(String key, int limit, int windowSeconds) {  
    String now = LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyyMMddHHmm"));  
    String value = key + ":" + now;  
  
    int count = request.computeIfAbsent(value, k -> new AtomicInteger(0)).incrementAndGet();

ConcurrentHashMap과 AtomicInteger사용 이유?
- ConcurrentHashMap은 동시성 컬렉션의 한 종류로 HashMap에 개선 버전이라고 볼 수 있는데 여러 스레드가 동시 에 같은 Map에 접근할 때 데이터 정합성을 보장한다.
  - HashMap같은 경우에는 동시 접근 시 내부 구조가 깨질 수 있지만 ConcurrentHashMap은 내부적으로 버킷 단위 락을 사용해서 이를 방지한다.
- AtomicInteger 같은 경우에는 카운트의 읽기 + 증가 + 쓰기를 하나의 원자적 연산으로 incrementAndGet()으로 처리한다. CAS연산을 사용하기 때문에 두 스레드가 동시에 호출해도 반드시 다른 값을 반환한다. 그래서 같은 값을 읽고 같은 값을 쓰는 문제를 차단한다.
  - int count = request.computeIfAbsent(value, k -> new AtomicInteger(0)).incrementAndGet(); 이 연산 자체가 원자적으로 진행되는 것이다.
- 이제 여러 스레드가 동시에 요청해도 허용수가 limit를 초과하지 않고 정확히 100에서 멈추게 되었다.

다음 편

이제 단일 서버에서 생길수 있는 동시성은 해결했지만, 서버가 만약 여러 대라면? 각 서버의 독립적이 counter가 생기는데 일관성을 유지할 수없게 된다.
결국 어떤 공유 저장소가 필요한것인데 다음편에서 어떻게 해결 해 볼 수 있을지에 대해 다뤄보자