어떻게 데이터 처리 파이프에서 속도 제한 알고리즘을 사용합니까

안녕하세요. 저는 발레리오입니다. 창시자 겸 수석기술관입니다. 전화: Inspector.
API 사용과 관련된 속도 제한에 대해서는 이미 알고 계실 것입니다.본고에서, 나는 이 구성 요소의 더욱 복잡한 사용법을 보여 드리며, 이를 사용하여 데이터 섭취 파이프를 조율할 것입니다.
Building Inspector는 내부 구조에서 가장 중요한 구성 요소 중 하나인 데이터 집약형 어플리케이션에 대한 지식을 많이 배웠습니다.
데이터 집약형 어플리케이션의 아키텍처는 다음과 같은 방식으로 단순화할 수 있습니다.

대량의 예측할 수 없는 전송 데이터는 양호한 데이터 처리 파이프를 설계하여 이 데이터를 수신해야 하며, 매번 전송된 데이터의 최고치가 될 때마다 전체 시스템을 중단하지 않는다.
섭취 노드와 섭취 파이프라인은 클라우드 플랫폼(Google cloud, AWS, Azure 또는 Digital Ocean, 이 기능 제공)의'자동축척'구성을 통해 손쉽게 수평 축척을 하거나, 현대의 서버 없는 인프라를 활용한 데이터 저장이 가능하지만 쉽지 않다.
데이터베이스는 통상적으로 데이터 집약형 시스템의 진정한 병목이다. 왜냐하면 그들은 초당 대량의 쓰기 요청을 지원해야 하기 때문이다.
쓰기 요청은 확장하기 어렵다.
나는 최근의 한 문장에서 데이터베이스 신축성에 대해 이야기했다. https://inspector.dev/how-i-handled-the-scalability-of-the-sql-database-at-inspector/
그렇습니다. 많은 기술들이 무한한 규모의 능력을 가지고 있다고 주장합니다.Elastic, Scilla DB, Single Store, Rockset, MongodB 등을 생각해 보세요.아마도 기술적으로 그들은 이 일을 아무런 문제 없이 완성할 수 있을 것이다. 그러나 원가가 당신의 업무 제한과 일치하는지는 아직 분명하지 않다.
금리 제한기가 왔다.

무엇이 속도 제한이고 데이터 처리 파이프에서 그것을 어떻게 사용합니까?
Inspector에서 속도 제한기는 응용 프로그램이 데이터를 저장하고 감시하는 속도를 제한함으로써 데이터 저장이 의외나 악의적으로 과도하게 사용되지 않도록 보호한다.
속도 제한이 없는 상황에서 모든 응용 프로그램이 마음대로 요청을 할 수 있기 때문에 요청이 급증하고 다른 소비자들이 굶주리게 된다.사용이 설정되면 데이터 저장소에 대해 초당 고정 수의 쓰기 요청만 수행할 수 있습니다.속도 제한 알고리즘은 이 과정을 자동화하는 데 도움이 된다.

하지만 모니터링 시스템은 데이터를 잃어버리면 안 된다.이는 거짓 지표가 생기는 것을 의미할 것이다.그러나 합리적인 비용으로 시스템 전체를 파괴하지 않고 모든 데이터를 저장할 수 있어야 한다.
따라서 제한을 초과한 요청은 잃어버리지 않지만 메시지 대기열로 다시 스케줄링되어 빈 용량이 있는 시간 창을 기다립니다.

고정 창
고정 창 알고리즘은 시간선을 고정 크기의 창으로 나누고 창마다 계수기를 분배합니다.
모든 요청은 도착 시간에 따라 창에 비칩니다.창의 카운터가 제한에 도달했다면, 이 창에 떨어진 요청을 거부해야 합니다.
현재 시간 스탬프는 보통 창을 정의하기 때문에 창 크기를 1분으로 설정합니다.그 다음은 (12:00~12:01:00), (12:01:00~12:02:00) 등입니다.
분당 2 개의 요청으로 제한된다고 가정합니다.

00:00:24와 00:00:36에서 창 카운터를 2로 늘려 달라고 요청합니다.00:00:49에 나타난 다음 요청은 카운터가 제한을 초과했기 때문에 재배치되었습니다.그리고 00:01:12에 도착을 요청합니다. 새 창에 속하기 때문에 서비스를 제공할 수 있습니다.
이 알고리즘은 두 가지 주요 단점이 있다.
많은 소비자들이 리셋 창을 기다리고 있다
만약 어떤 창이 너무 바쁘다면 전체 용량이 1초 안에 소모되어 시스템이 과부하될 수 있다(예를 들어 금요일 판매와 같은 러시아워).
창 경계 부근에서 발생하는 데이터 돌발은 처리 요청의 속도를 배로 증가시킬 수 있다
카운터가 비어 있고 10개의 요청 최고치가 00:00:59에 도착한다고 가정하면 받아들여지고 10개의 요청 최고치가 다시 00:01:00에 도착한다. 이것은 새로운 창이기 때문에 이 창의 카운터는 0으로 설정된다.이러한 요청이 수락되더라도 서버는 현재 분당 10개가 아닌 20개의 요청을 몇 초 안에 처리합니다.

슬라이딩 창
슬라이딩 창 카운터는 고정된 창 카운터와 유사하지만, 이전 창의 가중 계수를 현재 창의 계수와 합쳐서 경계 부근의 돌발 유량을 부드럽게 합니다.
내가 너에게 진실한 예를 하나 보여 주겠다.

새로운 요청이 "1:15"에 도착한다고 가정하십시오.우리가 이 요구를 받아들여야 할지 거절해야 할지는 근사치에 따라 결정될 것이다.
현재 이율의 계산은 다음과 같은 가중치와

limit = 100 requests/hour

rate = 84 * ((60-15)/60) + 36
     = 84 * 0.75 + 36
     = 99

rate < 100
    hence, the request will be accepted.

결론
본고에서 논의한 바와 같이 우리는 공공 API의 전송 데이터를 제어하기 위해 속도 제한을 사용하지 않고 내부에서 데이터 저장이 데이터의 돌발적인 영향을 받지 않도록 보호한다.
우리는 고정된 창부터 슬라이딩 창 알고리즘으로 전환해서 개발자가 계기판에서 사용할 수 있는 데이터를 보는 속도를 높인다.

새로 온 감독?
서버 레벨에 물건을 설치하는 것이 아니라 코드 드라이브의 모니터링 도구를 찾고 있습니까?
소프트웨어 개발자를 위한 모니터링 환경을 구축하여 서버나 인프라 시설의 배치를 피한다.
Inspector 덕분에 서버 레벨에 물건을 설치하지 않을 뿐만 아니라 클라우드 인프라에서 복잡한 설정을 하지 않을 것입니다.
Inspector는 경량급 소프트웨어 라이브러리를 사용하여 다른 의존항과 같이 응용 프로그램에 설치할 수 있습니다.GitHub에서 지원되는 기술을 확인하십시오.
자세한 내용은 웹 사이트 https://inspector.dev을 참조하십시오.