처리율 제한 장치에 대해

머리말

처리율 제한 장치란 무엇일까? 그리고 그것은 왜 필요할까? 오늘도 책에서 본 흥미로운 주제를 가져왔다. 요즘 짬짬히 보고 있는 책이다. <가상 면접 사례로 배우는 대규모 시스템 설계 기초 1>이다.

처리율 제한?

먼저, 처리율(rate)은 일정 시간 동안 처리할 수 있는 요청의 양을 의미하며, 서버가 수신하는 트래픽과도 같다. Rate limiter는 이런 요청의 빈도(요청률)를 제어하는 장치다.

왜?

그럼 처리율은 왜 제한해야 할까? 그리고 언제 필요할까?

대규모의 대고객 서비스를 경험한 개발자라면 그 필요성의 이유는 말하지 않아도 알 것이다. 수많은 고객들의 행동은 서버에 많은 요청을 발생시키고, 이를 원활하게 처리할 수 있는 Backend의 중요성은 날이 갈수록 중요해지고 있다. 일부 악의적인 사용자들은 버튼을 연타 하거나, 페이지를 반복적으로 호출해 서비스에 나쁜 영향을 주기도 한다.

물론, 사람이 수행하는 정도(따위)의 부하로 서버는 전혀 고통 받지 않는다. 그럼에도 불구하고, 불필요한 요청을 서버가 감수해야 할 이유 역시 없다. (1) 서버가 그러한 불필요한 부하를 견뎌야 할 이유가 없기 때문이다.

그리고 요즘은 대부분 클라우드 환경에서 서버를 운영하고 있다. 클라우드 서비스는 사용한 만큼 비용이 발생하게 되는데, 그 사용량의 기준이 되는 CPU, 메모리 등의 자원 또는 호출 횟수 등이 결국은 트래픽에 기반하기 때문이다. 그렇다면 역시 (1)번과 같은 맥락에서 (2) 불필요한 비용이 발생하는 것을 막아야 한다.

그리고 마지막으로 가장 중요한 이유인데, (3) 공격에 대비하기 위함이다. 2000년대 초-중반까지는 DDoS(Distributed Denial of Service) 공격(attack)이라는 것이 흔하지는 않았다. 나만 그랬나? 아무튼 2025년을 살고 있는 우리에게 ‘DDoS 공격’이란 이제는 매우 익숙한 키워드다. 그러니 자세한 설명은 아래에 위임한다(?).

DDoS란? → MDN 문서 보기

자, 다시 처음으로 돌아가 rate limiter의 목적을 정의하자면, 공격자의 악의적인 공격에 대비하거나, 일반 사용자의 무분별한 요청을 제한하기 위한 장치라고 이해하면 되겠다. 그 과정에서 과도한 비용이 발생할 여지를 제한할 수도 있다.

사례

웹 서핑 중에, 이미 우리는 종종 “비슷한” 기능을 경험했다. 대표적으로 구글의 reCaptcha가 있다. 보통은 그림을 보고 내는 문제를 맞추는 식이다.

물론 이는 bot과 사람을 구분하기 위한 수단이라, 엄밀히 말하자면 rate limiter라고 말하기 모호하다. 이런 기능은 일반적으로 Challenge라고 표현한다. 하지만 bot이 아닌, 사람이라면 짧은 시간 내에 서버에 부하를 줄만큼의 공격을 하지 못한다. 그런 측면에서 bot을 감지하고 막을 수 있다면, rate limiter를 도와주는 보조 수단이라 볼 수 있겠다.

그렇다. 사실 처리율 제한 장치는 일반적으로 사용자(클라이언트) 눈에 드러나지 않는 경우가 많다. 대부분의 클라이언트에서는 이미 요청이 전달된 상태일 때 버튼을 비활성화 처리하는 정도의 기능이거나, 어떤 요청이 실패해 서버 다시 요청하는 경우에 재시도 간격을 조절하는 전략으로 지수 백오프를 적용하는 정도가 있겠다. 하지만 클라이언트는 변조되거나, 위장한 상태로 서버를 공격할 수 있기에 처리율을 완벽하게 제한할 수 없다.

집밥 vs 밀키트

자, 그럼 이상적으로 처리율을 제한하기 위해서는 Backend에서 할 일이 많다는 것을 이해했다. 그렇다면 이제 다음으로 고려할 것은 처리율 제한 장치(rate limiter)를 직접 구현할 것 인지, 아니면 다른 서비스를 이용할 것 인지에 대한 것이다.

집밥은 재료를 하나하나 구매해서 손질하고 요리하기 때문에 건강하거나, 안전하다는 생각이 많다. 나도 그렇게 생각하긴 하지만 정말 건강한 지는 잘 모르겠다. 소금을 많이 쳐서… 그리고 마트에 가서 장을 보는 비용이 생각보다 크게 나간다.

그런데 요즘 밀키트가 참 잘 나온다. 진짜 잘 나온다. 요리하기도 간편한데 맛도 있다. 몇 년 전까지 자취했을 때만 해도 이 정도는 아니었는데, 지금은 맛도 좋고 가격도 그다지 비싸지 않아서, 우리 집의 주력(?) 메뉴다.

책에서도 비슷한 이야기를 한다. 처리율 제한 장치(rate limiter)를 직접 만드는 데는 많은 비용이 들어간다는 것이다. 그런 면에서, 현재 시스템의 기술 스택을 점검하고, 별도로 구현하지 않아도 적용할 수 있다면 그렇게 하는 것을 권장한다. 마치 밀키트처럼 말이다.

대표적인 밀키트

대표적인 밀키 아니 매니지드 서비스를 알아보자

1. WAF (Web Application Firewall)

2. Reverse Proxy

3. API Gateway

먼저, 서버 레벨의 가장 앞 단에서 WAF를 통해 제어할 수 있다. 특정 IP가 일정 시간 내 요청을 N회 이상 요청하면 차단하게 만드는 Rule을 적용할 수 있다. 특히 AWS를 사용한다면 WAF 보다 앞서 Shield가 적용된다. Standard는 기본 제공이나, Advanced는 비용을 지불하고 별도로 활성화해야 한다. Advanced의 특징으로는 DDoS 전문 대응 팀이 상시 대기하며, Application Layer(L7)까지 보호된다고 한다. (일반적으로 Shield는 L3, L4에 집중)

Nginx나 HAProxy로 구축된 Reverse Proxy 서버가 있다면 이미 rate limiter가 적용되어있을 가능성이 있다. 마찬가지로 API Gateway에서 IP별 초당 요청 수를 제한할 수 있으며, API Gateway가 HTTP 429를 응답한다. 참고로 API Gateway는 AWS는 물론이고, Google, Azure, Kong, Tyk, Spring Cloud Gateway 등 여러가지 서비스가 존재한다.

정리

사실 여기까지는 책에서 언급하는 초반 부분 밖에 안 된다. 앞서 이야기했듯, 책에서도 현재 기술 스택에 맞는 서비스를 선택할 것을 권장했다. 충분한 비용(시간, 인력 등)이 없는 경우에 말이다. 그에 따른 선택지들을 간단하게 살펴봤다. 아무래도 너무 간단한 것 같아서, 다음 포스팅은 책에서 설명하는 처리율 제한 장치 알고리즘을 정리하려고 한다.