[Network] Rate Limit과 Throttling 이해

안녕하세요. 오늘 포스팅할 글은 오랜만에 프로그래밍이 아닌 네트워크 이론에 대해 이야기 해보고자 합니다. 백엔드 엔지니어를 하고 계신 분들이라면 서버 개발 뿐 아니라 미들웨어와 통신을 위해 네트워크 지식을 공부하고 있어야 하는데요. 자신이 개발하는 API 서버가 하나의 클라이언트가 아닌 다른 여러 마이크로서비스 혹은 소프트웨어들이 의존한다면 가장 먼저 고민해야 할 것이 바로 트래픽일 것입니다.

 

대용량 트래픽이 발생하면 어떻게 대처해야 할까요? 물론 가장 좋은 방법은 스케일 업(Scale up)이나 스케일 아웃(Scale out) 같이 리소스를 늘리는 방법이 있을 것입니다. 하지만 개발하는 서버가 외부 API의 응답 결과를 가져다 준다거나, 비용적인 문제로

리소스를 늘릴 수 없는 경우에는 매우 난감할 것입니다.

 

 

Throttling

위의 문제를 해결하기 위해 일부 자원의 이용을 제한 하는 방법이 바로 쓰로틀링(Throttling)입니다. Throttling은 일반적으로 자원의 사용을 제한하거나 조절하여 일정한 속도로 처리하는 메커니즘으로 네트워크에서 일부 클라이언트의 과도한 사용으로 트래픽 부하를 방지하고 다른 클라이언트의 QoS(서비스 품질)을 지켜낼 수 있습니다.

 

Throttling의 가장 대표적인 방법은 트래픽의 요청의 수를 제한하거나 제어함으로써 특정 사용자나 애플리케이션이 API를 과도하게 호출하는 것을 막는 것입니다. 하지만 무작정 막기만해서는 오히려 트래픽의 제어가 아닌 특정 사용자의 밴(ban)으로 이어지기 때문에 이를 적절하게 조절하는 것이 중요한데, 이를 위해 초당 허용되는 요청 수를 제한하는 방식으로 사용될 수 있습니다. 이를 우리는 RateLimit이라 하며 시스템 부하를 줄이고, 대기열이나 오버로드를 방지하는 데 도움이 됩니다.

 

 

RateLimit

RateLimit은 API 또는 웹 서비스에서 요청 속도를 제한하는 매커니즘입니다. 만약 특정 서비스 혹은 IP 주소에서 많은 트래픽을 발생시키고 있다면 다른 IP 혹은 서비스에서 자신이 개발한 애플리케이션 서버에 접속할 수 없는 서비스 장애 혹은 거부 현상이 발생할 수 있는데, 이를 양 혹은 속도로 조절함으로써 자신의 서비스의 품질을 유지시킬 수 있습니다.

 

흔한 예로 포털에서 사용하는 지도 API, 번역 API 등이 대표적인 예시가 될 수 있습니다. 여러 클라이언트들이 서로 원하는 요청을 진행하는데, 한 클라이언트가 해당 서버의 리소스를 독점해서 사용한다면 다른 클라이언트도 똑같이 지불한 비용만큼 품질을 보장받을 수 없게 됩니다. 따라서 RateLimit 기법 등을 통해 동일한 품질을 보장할 수 있도록 해줘야 합니다.

 

좀 더 이해가 쉽게 되도록 시퀀스 다이어그램으로 설명해보자면, 사용자가 HTTP API 호출을 날리면 Rate Limiter가 이 요청을 대신 받아 요청 횟수가 제한되어 있는지를 확인한 후 제한 횟수를 초과하지 않았다면 애플리케이션이 응답하고, 그렇지 않다면 Rate Limiter가 현재 상태를 응답하는 구조입니다.

 

그렇다면 이러한 Rate Limit을 어떻게 구현할 수 있을까요?

 

Rate Limit은 구현을 위해 미리 정의되어 있는 알고리즘들이 있습니다. 우리는 이를 이용하여 서비스에 맞는 Rate Limit을 구현하여 적용할 수 있고, 마이크로서비스라면 게이트웨이에서 제공해주는 Rate Limit 구현체를 이용할 수도 있습니다. 기본적으로 Rate Limit 구현체를 제공하는 프레임워크 혹은 게이트웨이는 아래와 같습니다.

 

• nginx Rate Limit
• Spring Cloud Rate Limit

 

게이트웨이를 아직 선정하지 못했거나 고려하고 있다면 위의 3가지를 고려해보는 것이 좋습니다. nginx의 Rate Limit 기능은 우리가 Rate Limit에 대해서 자세히 알고 있지 않아도 애플리케이션 앞단에 프록시를 두고 사용하여 쉽게 트래픽을 조절 시킬 수 있습니다. 

 

https://www.nginx.com/blog/rate-limiting-nginx/

NGINX Rate Limiting

위 페이지를 통해 nginx에서 Rate Limit을 이용하는 데 많은 도움을 받을 수 있습니다. limit_req_zone 코드를 이용하여 IP 주소별로 트래픽 호출량을 조절시킬 수 있고, 초당 제한량을 지정하는 등 간단한 코드로 쉽게 요청 제한을 구현할 수 있습니다. 이 외에도 순간 트래픽(짧은 시간 내 들어오는 트래픽)을 제어하기 위한 Handling Bursts 기능 등을 제공하여 더 많은 트래픽에서도 유연하게 대처할 수 있는 구현체를 제공합니다.

 

하지만 nginx를 사용할 때는 지정된 헤더를 사용해야 한다는 한계점이 있습니다. 물론 사용하려는 클라이언트 측에서 헤더 값을 지정할 수 있다면 좋겠지만 그렇지 못하는 경우라면 각 서비스에서 들어오는 트래픽들이 로드 밸런싱 등으로 분산되어 있을 때 적절히 제어하기 위해 트래픽 양을 유동적으로 계산하여 설정해야 한다는 관리 부담이 커집니다. 이런 경우에는 기본적인 웹 서버 기능을 제공하는 게이트웨이 보다는 웹 애플리케이션 서버 형태의 게이트웨이를 통해 추가적인 요구 사항을 개발할 수 있는 게이트웨이가 있다면 좋을 것입니다.

 

https://spring.io/blog/2021/04/05/api-rate-limiting-with-spring-cloud-gateway

API Rate Limiting with Spring Cloud Gateway

그런 경우라면 프로그래밍 언어에서 제공하는 프레임워크를 사용하는 것이 좋습니다. 그 중에서도 Spring Cloud Gateway는 Spring 프레임워크에 맞춰 RateLimit 인터페이스를 제공하며 이들 구현체에는 Redis를 이용한 Rate Limit 구현체를 제공합니다. Spring Webflux를 바탕으로 구현되어 있기 때문에 Spring Webflux로 되어 있는 애플리케이션 서버에 Rate Limit을 구현하고자 한다면 좋은 선택이 될 것입니다.

 

Spring Cloud 스택을 사용하는 경우 두 가지 방법을 생각해 볼 수 있습니다. 한 가지는 Spring Cloud Gateway를 애플리케이션 서버 앞단에 두고, 트래픽을 받아 제어하는 방법과 직접 애플리케이션 서버에 구현하여 직접 트래픽을 받아 Filter 등을 활용하여 제어하는 방법이 있습니다.

 

Spring Cloud Gateway를 애플리케이션 서버 앞단에 두게 된다면 클라이언트는 Spring Cloud Gateway 주소를 호출하게 될 것이며 여기서 Rate Limit 구현체를 사용하여 트래픽을 조절할 수 있습니다. 앞서 nginx에서 각 사용자별 서비스 트래픽 관리를 위해 관계형 데이터베이스 등을 통하여 사용자 식별 정보를 미리 사전에 저장해두어 Redis로는 현재 트래픽 호출량을 제어하고, 관계형 데이터베이스로는 사용자에게 할당한 초기 트래픽 조절량과 설정값을 관리하는 데 사용하도록 구현할 수 있습니다.

 

mix

만약 이미 애플리케이션이 Spring 기반으로 구현되어 있다면 직접 Spring Cloud의 RateLimit 구현체를 애플리케이션에서 구현하여 사용할 수도 있습니다. 이렇게 하면 Filter 내지 Interceptor 등으로 요청을 한 번 받은 다음 현재 트래픽 호출량 등을 고려하여 트래픽을 조절할 수 있습니다.

 

 

 

마치며...

아주 간단하게 Throttling과 Rate Limit을 우리가 자주 접하는 기술 스택으로 개념을 접해봤습니다. 당장 Rate Limit을 현업에 적용해야 한다면 이미 잘 만들어진 구현체를 사용하여 서비스에 녹이는 것도 하나의 방법입니다. 

 

만약 Spring Cloud Gateway를 사용해야 했을 때 애플리케이션에 직접 Rate Limit을 구현하여 사용하고자 하는 경우 반드시 Spring 스택이 Spring Webflux 스택이어야 합니다. 왜냐하면 해당 구현체가 Netty 기반으로 구현되어 있어 Spring MVC와 호환되지 않기 때문입니다.

 

다음 포스트에서는 Rate Limit의 여러 알고리즘에 대해 알아보도록 하겠습니다.