[대규모 시스템 설계 기초] 4장. 처리율 제한 장치의 설계 - 1

 

들어가기

처리율 제한 장치가 뭘까? 클라이언트가 서버에 보낼 수 있는 요청의 빈도(초당/분당 횟수 등)를 제한하는 장치이다. 이게 왜 필요할까? 

솔직히 “처리율 제한기(Rate Limiter)” 하나만 잘 넣어도 얻는 게 되게 많아진다. 

---

첫 번째, 시스템 보호용 방패처럼 쓸 수 있다.
누가 API를 미친 듯이 때리면(봇, 스팸, DDoS 이런 거) 서버 바로 맛가는경우가 꽤 많다.. 
근데 Rate Limiter가 “야, 너무 많이 보낸다? 잠깐 멈춰!” 하고 요청을 잘라주거나 늦춰줘서 전체 시스템이 터지는 걸 막아주게 된다. 
실제로 Google Docs API도 “1분에 300번 이상 호출? 그럼 거절!” 이런 식으로 쓰고 있는거 같다. (이건 책에서 소개해줌)

두 번째, 서비스 전체가 느려지는 걸 막아준다.
트래픽이 한쪽 API로 확 몰리면 CPU, DB 커넥션, 스레드 이런 게 싹 다 잡아먹혀서 “왜 이 API만 느린 게 아니라 전체가 느리지?” 이런 상황이 나올 수 있게 된다. 
Rate Limiter가 “들어올 때부터 적당히 줄 세워!” 해주니까 부하가 고르게 퍼져서 훨씬 안정적이다.

세 번째, 돈 아낄 수 있다. (매우 중요함)
클라우드나 외부 API는 호출하면 할수록 돈이 나가잖아? (pay-per-use) 괜히 불필요한 호출 막아주면 진짜 비용 절감됨.
그리고 “중요한 API는 더 많이, 덜 중요한 API는 적게” 이런 식으로 우선순위도 줄 수 있어서 리소스를 비즈니스적으로 똑똑하게 쓸 수 있게 된다. 

 

문제 이해 및 설계범위 확정

많은 개발이 증상만 보고 바로 해결책을 만든 다음 실패하는 경우가 많다. 이 단계를 거쳐 요구사항을 명확히 해야 설계 방향이 정해진다. 

정해둔 요청 수는 정확하게 지켜야 한다

“초당 100개까지만!” 이렇게 정해놓고 실제로는 120개까지 들어오면 무의미하다. 그래서 Rate Limiter는 설정된 허용량을 정확하게 지켜주는 게 중요하다. (API 정책, 과금, 보안 때문)

응답은 빨라야 한다 (거의 0.x ms 수준)

Rate Limiter는 모든 요청 앞단에서 항상 실행된다. 즉, 이게 느리면 전체 서비스가 느려진다는 뜻이다. 그래서 제한 판단 로직은 “생각하는 순간 끝남” 수준으로 빨라야 한다.

메모리는 최소한으로 사용해야 한다

요청 기록을 다 쌓다 보면 메모리 터진다. 그래서 보통은 오래된 기록을 잘라내거나(Trim), 시간 윈도우 기반 카운팅 or TTL을 사용해서 자동 정리하게 된다. 특히 Redis/Memcached 같은 외부 저장소 쓰면 = 메모리 = 돈 이라 더 신경 써야 한다.

여러 서버에서 같이 쓸 수 있어야 한다 (분산 지원)

서버가 1대만 있는 시대는 끝났다. A 서버에서는 제한 걸렸는데 B 서버는 모르면 의미가 없어진다. 그래서 여러 인스턴스가 같은 제한 데이터를 공유할 수 있어야 한다 (ex. Redis, 분산 카운터)

요청이 차단되면 사용자도 알아야 한다

“왜 안 되지?”라고 사용자만 멍하게 만들면 안 됨. 429 Too Many Requests 같은 상태코드나 메시지로 “지금 요청 너무 많아서 잠깐 멈춰야 해요”라고 명확하게 알려줘야 한다.

Rate Limiter가 죽어도 서비스는 살아 있어야 한다 (Fault Tolerant)

제한기 하나 장애났다고 전체 서비스가 같이 터지는 건 최악이다. 장애 시에는 “일단 제한 안 걸고 통과” 같은 fallback도 고려해야 한다.
Rate Limiter는 보호 장치이지, 장애 유발 장치는 아니어야 한다.

 

개략적 설계안 제시 및 동의 구하기

사실 대부분 시스템은 “클라이언트 ↔ 서버” 구조로 동작하는 경우 많다. 그래서 Rate Limiter(처리율 제한기)를 어디에 둘지가 진짜 중요하다. 크게 보면 위치는 두 가지이다.

클라이언트 쪽, 서버(또는 서버 앞 인프라) 쪽

각 위치마다 장단점이 완전히 달라서, 실무에서는 이 선택이 시스템 구조에 영향을 줄 정도로 중요하다.

클라이언트 측에 Rate Limiter를 둘 경우

장점

각 클라이언트가 “나 너무 많이 보내고 있나?” 하고 스스로 조절함 결과적으로 서버가 덜 힘들어함. 모바일/웹 SDK에 넣어두면 UI에서 바로 안내 가능 “잠시 후 다시 시도해주세요” 같은 메시지도 예쁘게 띄울 수 있을거 같다. 아예 네트워크 타기 전에 요청을 줄여버리니까 트래픽 자체를 줄일 수 있어 효율적이다. 

단점

신뢰 불가능하다. 클라이언트는 코드 수정하면 끝이기 때문에 악성 사용자나 봇은 그냥 무시하고 계속 호출 가능하다. 또, 우리가 통제 못 하는 클라이언트가 너무 많다. 외부 파트너, 오픈 API, 웹 스크래핑 등은 우리가 막을 수 없다. 결과적으로 착한 사용자만 조심하고, 진짜 문제 유발자는 그대로 놔두는 꼴…이 될수도 있다. 

서버 측(백엔드 또는 인프라)에 Rate Limiter를 둘 경우

그럼 정확히 어디에 둘 수 있을까? 생각보다 선택지가 다양하다.

• 애플리케이션 내부
  • Filter, Interceptor, AOP 같은 레이어에서 직접 구현
• API Gateway
  • Nginx, Kong, Spring Cloud Gateway 등에서 정책으로 설정
• Load Balancer / CDN 단
  • AWS ALB, CloudFront, Cloudflare 같은 인프라 레벨에서 제한

코드 내부부터 인프라 바깥쪽까지 원하는 레벨에서 걸 수 있다.

장점

모든 요청을 한곳에서 통제 가능 클라이언트가 누가 됐든, 어떤 브라우저든, 어떤 디바이스든 서버 앞에서 한 번에 다 잡아버림. 제일 확실하다.

악성 트래픽도 진짜로 차단 가능이 있다. 클라이언트 쪽 제어는 봇이 무시하면 끝이지만, 서버 앞에 있으면 봇, 스팸, 스캐너, DDoS까지도 방어 가능하다.

트래픽 흐름을 정확하게 볼 수 있음 요청 로그가 전부 여기로 모이니까 어떤 API에 트래픽이 몰리는지, 누가 계속 호출하는지 다 파악 가능하다. 그러면 더 똑똑한 정책을 만들 수 있다.

우선순위 기반 제어 가능 로그인/결제 같은 중요한 API는 더 널널하게, 부가 기능 API는 더 빡세게 이렇게 비즈니스 중요도에 따라 처리율을 다르게 설정 가능하다.

 

서버 내부 vs 서버 앞단(미들웨어)

Rate Limiter는 서버 내부에 둘 수도 있고,
서버 앞단의 독립된 미들웨어(API Gateway 등)로 구성할 수도 있다.

서버 내부에 둘 경우

• 애플리케이션 코드에서 직접 제한
• API 별, 사용자별 세밀한 정책 적용 쉬움
• 하지만 서버마다 따로 실행되므로 분산 환경에서 카운트 공유가 필요

서버 앞단(미들웨어, Gateway)에 둘 경우

• 모든 요청을 가장 먼저 필터링
• 공통 정책을 일괄 적용 가능
• 서버가 다운되기 전에 트래픽 방어 가능
• 단, 이 계층 자체가 단일 실패 지점(SPOF)이 되지 않도록 HA 구성 필요
  • 사용자 요청을 보낼 경우 시스템보호 목적으로 HTTP 상태 코드 429를 보낼 수 밖에없다. 

어디에 Rate Limiter를 둘 것인가?는 이론적으로도 깊이가 있고, 실무에서는 잘못 선택하면 장애로 이어지는 핵심 설계 요소입니다.

다음 글에서는 각 레이어별 실제 구현 방법과 실무 사례, 그리고 선택 기준을 더 깊게 파헤쳐보겠습니다.