Golang - Rate Limit

이 글에서는

이 글에서는 golang을 활용한 rate limit에 대해서 다룹니다.
최근에 회사 업무에서 tcp 100으로 고정하고 유저 정보를 등록하는 batch job을 개발했었는데,
golang에서 제공하는 rate limit 패키지를 활용했습니다.

그래서 관련해서 내용을 정리해보려고 해요!
이 글을 읽는 사람들은 다음과 같은 지식을 얻어가길 기대합니다

• 처리율 제한(rate limit)이란?
• golang rate package

 

주의*

제가 경험한 케이스는 단일 batch job을 kubernetes cronjob으로 동작시킨 경우입니다.
분산 시스템에서의 rate limiter는 또 다른 고민거리들이 존재합니다.
그 고민거리에 대한 이야기는 글 후반부에 다룹니다.

 

처리율 제한(rate limit)이란?

rate limit은 말 그대로 사용량 제어를 의미합니다. 네트워크 시스템에서 처리율(rate)을 제어하기 위해 활용해요.
이렇게 말하면 이해하기 어려울 수 있으니 다음과 같이 간단한 사례를 들어보겠습니다.

• Dos(Denial of Service) 공격에 의한 자원 고갈(resource starvation) 방지
• 비용 절감
  
  • third-part API 사용량에 따라 비용을 지불해야하는경우 절약 가능
• 서버 과부하 방지
  • 봇에서 오는 트래픽이나 사용자의 잘못된 이용 패털으로 유발된 트래픽을 차단
• 외부 서비스로부터의 트래픽 제어 요청
  • 협력사) 저희 서비스에 tps 100 정도로 요청을 보내주세요.
    -> 실제로 제가 겪었던 상황이 이 케이스!

이 외에도 다양한 사례가 있을 수 있습니다.

처리율 제한 알고리즘?

rate limit을 구현하는 데에는 다양한 방법이 있고 또한 아래와 같이 다양한 처리율 제한 알고리즘이 존재합니다.

• 토큰 버킷 알고리즘(token bucket)
• 누출 버킷 알고리즘(leaky bucket)
• 고정 윈도우 카운터(fixed window counter)
• 이동 윈도우 로그(sliding window log)
• 이동 윈도우 카운터(sliding window counter)

이 글에서는 위 많은 알고리즘 중 토큰 버킷 알고리즘을 활용한 케이스를 다룹니다!

토큰 버킷 알고리즘

토큰 버킷 알고리즘은 이름에서도 알 수 있듯이 토큰(token), 버킷(bucket) 이 두가지 요소를 활용해 구현하는 알고리즘입니다.

토큰 버킷 알고리즘의 큰 범위에서의 플로우는 아래와 같이 구성됩니다

1. 일정 시간(r)마다 토큰이 생성되는 버킷(바구니)이 존재하고
2. 요청이 올때 버킷에서 토큰을 하나 꺼내서 소모하며 (이 버킷은 일정 사이즈(b)를 가집니다)
3. 버킷에 토큰이 0개가 되면 가져갈 토큰이 없으므로 요청을 drop (이후 토큰이 채워질 때까지 기다려야함)

https://www.researchgate.net/figure/Diagram-representing-token-bucket-algorithm_fig1_351452059

 

토큰 버킷 알고리즘을 활용해 rate limit을 구현하기 위한 지식을 간략하게 알아봤으니 이제 실제 사례를 살펴보겠습니다

Golang rate package를 활용한 rate limit

아래 코드는 golang golang.org/x/time/rate 패키지를 활용해 초당 100 건의 연산을 수행하도록 rate limit을 구현한 코드입니다.
지금은 이해하기 어려울 수 있지만 아래 코드에서 활용된 지식들을 이 글에서 알아보죠!

package main

import (
	"context"
	"fmt"
	"golang.org/x/time/rate"
	"time"
)

func main() {
	ctx := context.Background()

	// rate limiter 생성
	// r(rate tokens per seconds): 100
	// b(bucket size): 100
	rateLimiter := rate.NewLimiter(100, 100)

	// 반복 동작할 대상으로 단순하게 size 1000의 배열 생성
	values := make([]int64, 1000, 1000)
	for i := range values {
		values[i] = int64(1 + i)
	}

	now := time.Now()

	for _, v := range values {
		if err := rateLimiter.Wait(ctx); err != nil {
			fmt.Println(err)
		}

		fmt.Println(v)
	}

	since := time.Since(now)
    	// 9.007893291s
	fmt.Println(since)
}

 

golang.org/x/time/rate 패키지

golang.org/x/time/rate 패키지에서도 rate limit을 토큰 버킷 알고리즘으로 구현하고 있습니다.

https://pkg.go.dev/golang.org/x/time/rate

실제로 안쪽 코드를 살펴보러 들어가면 wait()함수 안에 아래와 같이 구성되어 있는 걸 확인할 수 있습니다.

 

 

분산 시스템에서의 처리율 제한 장치?

분산 시스템에서 처리율 제한 장치는 또 다른 고민이 필요합니다. 분산 시스템하면 떠오르는 대표적인 동시성 문제들을 해결해야하죠.
대표적인 고민들은 다음과 같습니다.

• 경쟁 조건(race condition)
  • DB에서도 마찬가지지만 여러 요청이 들어오는 상황에서 경쟁 조건은 항상 고민입니다.
    경쟁 조건은 lock, Lua script 그리고 redis의 sorted set을 활용해서 해결해볼 수 있습니다.
  • redis는 single thread로 동작하기 때문에 보다 쉽게 활용해볼 수 있습니다.
  • lock을 결 경우 관리 포인트가 늘어나는 부작용도 있습니다.
  • 물론 비용을 적절하게 고민해서 해결 방법을 선택하는 것도 중요합니다.
• 동기화 이슈
  • 트래픽이 늘어나면 한 대의 처리율 제한 장치 서버로는 충분하지 않을 수 있습니다.
    처리율 제한 장치도 스케일링해야하는 시점이 오면 각 처리율 제한 장치 간의 동기화 문제도 고민해야합니다.
  • 이 경우 sticky session혹은 redis와 같은 별도의 영속성 layer를 활용해볼 수 있습니다. redis cluster에 위임할 수도 있죠

 

결국 트레이드오프

결국은 모든 기술 선택은 각 상황에 맞게 트레이드오프를 잘 고려해야합니다.

저의 경우에는 하나의 배치잡 파이프라인에서 로직을 동작시켰기 때문에 간단하게 application level에서 rate limit을 활용해볼 수 있었습니다.
여러분들의 사례에서는 어떤 인프라를 활용하나요? 정말 rate limit이 필요한 요구사항인가요? 다르게 푸는 방법은 없을까요? 

바라보는 시각을 전환하여 어려운 문제를 간단한 문제로 치환하거나 작은 문제로 나눠서 간단하게 풀어내는 것도 엔지니어의 중요한 역량인 것 같습니다.

추가로 https://github.com/uber-go/ratelimit 라는 우버에서 rate limit을 위해 만든 패키지도 존재합니다.
이 패키지는 간단한 API와 비교적 적은 오버헤드를 제공합니다.
오늘 소개한 rate 패키지는 좀 더 디테일하게 설정할 수 있고 반대로 간단한 요구사항이라면 해당 패키지를 활용해봐도 좋을 것 같습니다!

 

Action item

우리 모두 항상 트레이드오프를 잘 고려해서 현실적으로 선택하는 엔지니어링을 하기 위해 깨어있으려 노력하기