2024.10.08 Duplicate Requests, Throttling Design Pattern

 

 

Rest API: How to Prevent Duplicate Requests Effectively

 

중복 request를 어떻게 처리할지에 대한 글이다.

이전에도 동일한 주제의 글을 읽었었는데 그때는 UUID를 UK로 사용해 중복을 방지했고 이번에는 본문의 일부를 해쉬 해서 사용한다.

전자의 경우는 페이지 새로고침을 하면 UUID 새로 발급되어서, 어떻게 보면 중복 요청을 완벽히 막지는 않는다. (새로고침을 했다면 이걸 중복으로 봐야 할까?)

후자는 본문의 일부를 해쉬 하고 UK로 만들기 때문에 UK를 저장하는 매체에 따라 중복 요청을 계속해서 막을 수 있게 된다.

 

더 추가한다면 user id나 request url 힌트를 넣어도 될 것 같다.

이런 의미로 optinalValues가 있는 것 같기도 하고..

 

그냥 haProxy나 lb자체 기능을 사용해도 될 듯. 유저 정보로 커스텀한 동작을 하고 싶다면 어플리케이션까지 가야하고.

 

Sample Code

GitHub - ChoiGiSung/prevent-duplicate-requests

 

 

 

Throttling Design Pattern to Handle an Extreme Load

Throttling pattern - Azure Architecture Center

 

많은 요청이 온다면 어찌해야 할까.

단순히 서버를 많이 늘리고 오토 스케일링 설정을 킨다? 

기존 서버들이 부하로 정상작동을 하지 않고 새롭게 뜬 서버에 모든 트래픽이 집중된다면?

임계치를 낮게 설정해 빠르게 부하를 감지해 서버를 늘리는 것도 방법이 될 수 있겠지만, 여기서 소개하는 방법은 다음과 같다.

리소스의 한도를 정하고 요청을 거부한다. 과거 글로 썼던 rate limit의 개념이다. 사실 Throttling과 rate limit의 차이가 있다고 하는데 잘 이해가 가지 않는다. 뭐 둘 다 요청을 제한하는 거긴 하다.

 

글의 내용을 보면 단일 사용자의 중복 요청 무시, 중요한 고객의 요청을 먼저 처리(우선순위 패턴을 쓴다고 한다).

가장 중요한 것은 서버의 상태를 보고 빠르게 limit를 걸어야 하는 것이다. 부하가 적어지면 빠르게 해제해야 한다.

어떻게 구현할 건지에 대한 이야기는 없는데, limit는 애플리케이션이나 네트워크단(LB)에서 할 수 있기 때문에, 거기서 하지 않을까 생각한다.