필수사항
여러 전문 소스에 따르면 적절하게 구현된 분산 속도 제한기(원자 계산, 로컬 폴백 캐시)는 일반적으로 요청당 1밀리초 미만을 추가합니다. Aurabase 게이트웨이는 로컬 안티 DoS를 위한 governor 크레이트, 인스턴스 간 분산 계산을 위한 원자적 Lua Redis 스크립트, Redis를 사용할 수 없는 경우 폴백 moka 캐시와 같은 패턴을 정확하게 따릅니다. 차단기 회로는 장애 발생 시 지연 시간을 추가하는 대신 인지된 지연 시간을 줄여 완전한 시간 초과에 대한 대기 시간을 단축합니다. Aurabase 대기 시간 수치는 현재까지 공개되지 않았습니다. 그 이유와 메커니즘이 실제로 작동하는 방식은 다음과 같습니다.
Anti-DoS 및 Anti-Cascading 오류, 서로 다른 두 가지 문제
속도 제한은 합법적이든 아니든 과도한 트래픽으로부터 백엔드를 보호합니다. 이는 "이 발신자가 지금 이 요청을 보낼 권리가 있습니까?"라는 질문에 대답합니다. ". 회로 차단기는 이미 다운된 다운스트림 서비스로부터 백엔드를 보호합니다. "이 서비스가 응답하지 않는 것으로 나타난 적이 있습니까? 시도해야 합니까?"에 응답합니다. ". 그것들을 혼동하면 둘 중 하나의 크기가 작아집니다.
Aurabase 게이트웨이에서는 둘 다 동일한 미들웨어 스택에 있지만 서로 다른 층에 있습니다. IP 속도 제한은 인증 전에 실행되며(순수한 DoS 방지, 인증되지 않은 트래픽에 대해 청구 SQL 쿼리가 실행되지 않음), 회로 차단기는 내부 서비스 또는 LLM 공급자로 나가는 호출을 보호합니다.
비용은 원칙이 아닌 구현에 전적으로 달려있습니다.
Tyk 및 APISIX 생태계 가이드에 따르면 Redis(원자 연산, Lua 스크립트, 기본 TTL)에서 잘 설계된 분산 계산은 일반적으로 1~3ms의 대기 시간을 추가하며 가장 최적화된 경우 p99에 미치는 영향은 밀리초 미만입니다. 반대로 Zuplo는 잘못 배치된 중앙 집중식 비율 제한기가 각 요청에 수십 밀리초를 추가할 수 있다고 문서화합니다. 이러한 불일치는 p99에 직접 반영됩니다.
이러한 범위는 일반적인 측정 프로토콜이 아닌 공개 기술 가이드(Tyk, Zuplo, Apache APISIX 생태계)에서 제공됩니다. 이는 규모의 순서와 아키텍처 원리(동기식 및 중앙 집중식이 아닌 원자 및 지역 계산)를 나타내며 다른 인프라에서 있는 것처럼 재현할 수 있는 수치가 아닙니다.
aura-gateway에서 속도 제한이 실제로 작동하는 방식
Aurabase 게이트웨이는 governor 상자(토큰 버킷 알고리즘)를 로컬 폴백 리미터로 사용하고 Redis를 통한 분산 계산과 결합하여 게이트웨이의 여러 인스턴스 간에 상태를 공유합니다. 분산 계산은 동시성 창을 도입하는 읽기-쓰기 왕복을 통하지 않고 Redis 측(단일 네트워크 작업에서INCRBY + EXPIRE)에서 원자적으로 실행되는 Lua 스크립트를 통해 수행됩니다.
Redis를 사용할 수 없게 되면 게이트웨이는 캐시 moka(최대 1,000,000개 항목, 비활성 300초에 만료)를 사용하여 로컬 제한기 governor로 자동 전환하여 각 요청에 제한기가 다시 생성되지 않도록 합니다. 이 폴백은 관찰 가능합니다. 각 토글은 전용 Prometheus 카운터를 증가시키므로 팀은 유효 한도가 N 인스턴스 × 한도가 다시 되는 시기를 알 수 있습니다(그렇지 않은 경우 자동 인스턴스 간 격리 성능 저하).
게이트웨이는 IP(인증 전)에 의한 DoS 방지 속도 제한과 프로젝트/API 키/사용자 할당량(인증 후, JWT 클레임 사용 가능)에 따른 속도 제한을 구별합니다. 스택에 두 개의 개별 미들웨어가 있으며 각각 고유한 세부 수준이 있습니다.
회로 차단기: 세 가지 상태, 슬라이딩 창
Aurabase 차단기 회로(aura_core::circuit_breaker, 게이트웨이와 LLM 공급자 간 폴백을 위한 aura-ai 간에 공유)는 절대 재설정되지 않는 카운터가 아닌 슬라이딩 시간 창에 대한 실패 횟수를 포함하는 세 가지 기본 상태(Closed, Open, HalfOpen)를 따릅니다.
프로덕션에서 중요한 구현 세부 사항: HalfOpen로 전환하면 한 번에 하나의 프로브 요청만 허용됩니다(천둥 방지). 이 가드가 없으면 보류 중인 모든 요청이 방금 다시 열린 서비스로 동시에 돌진하여 피하려고 했던 오류가 즉시 재현됩니다.
이러한 미들웨어가 게이트웨이에서 실행되는 위치
Aurabase 게이트웨이 미들웨어 스택은 요청 식별자 → 액세스 로그 → IP에 의한 속도 제한 → 인증 → 행위자/할당량에 의한 속도 제한 → 회로 차단기 → 대상 서비스에 대한 프록시 등 코드에서 확인된 정확한 순서를 따릅니다. 각 단계에서는 다운스트림에 더 높은 처리 비용이 발생하기 전에 가능한 한 빨리 원치 않는 트래픽을 거부합니다.
Aurabase 수치가 여기에 게시되지 않는 이유
구현은 게이트웨이 소스 코드에서 한 줄씩 확인됩니다. 그러나 재현 가능한 측정 프로토콜은 아직 이 특정 인프라에서 실행 및 게시되지 않았습니다. 측정되지 않은 수치를 게시하는 것은 우리가 재현을 거부하는 출처가 없는 마케팅 수치의 실수를 반복하는 것입니다. 성능 수치를 공개하기 전에 필요한 사항은 전체 벤치마크 방법론을 참조하세요.