View a markdown version of this page

속도 제한 모범 사례 - Amazon Bedrock AgentCore

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

속도 제한 모범 사례

이 주제에서는 게이트웨이의 효과적인 설계, 배포 및 운영 속도 제한에 대한 지침을 제공합니다.

패턴 설계

계층형 액세스

차원 키($.context.jwt.sub 또는 $.context.jwt.tier)는 동일하지만 티어마다 항목이 다른 여러 속도 제한을 생성합니다. 알려진 프리미엄 사용자의 정확한 항목과 * 항목을 기본 티어로 사용합니다.

심층 방어

여러 세부 수준에서 계층 속도 제한. 예를 들어, 대상별 RPS 제한(백엔드 용량 보호)을 호출자별 RPM 제한(개별 침해 방지) 및 도구별 토큰 제한(비용 제어)과 결합합니다.

BatchPut을 사용한 코드형 인프라

BatchPutGatewayRateLimits를 사용하여 속도 제한 구성을 선언적으로 관리합니다. 배치 배치는 업서트 의미 체계를 사용하므로 CI/CD 파이프라인 또는 인프라 템플릿에서 반복적으로 실행할 수 있습니다.

점진적 롤아웃

관대한 속도 제한으로 시작하고 관찰된 트래픽 패턴에 따라 시간이 지남에 따라 속도를 높입니다. 제한을 줄이기 전에 aws.agentcore.gateway.throttle.customer.decision OTEL 스팬 속성과 429 응답 속도를 모니터링합니다.

비상 블록

rate: 0 항목을 사용하여 인시던트 발생 시 특정 호출자, 대상 또는 도구를 차단합니다. 블록은 전파가 완료되면 적용됩니다(최대 30초).

차원 키 선택 지침

제한되고 예측 가능한 비율 버킷 수를 생성하는 차원 키를 선택합니다.

차원 키 카디널리티 권장 사항

targetName

낮음(알려진 집합)

탁월한 선택입니다. 대상별 보호에 사용합니다.

toolName

낮음-중간

알려진 도구 세트가 있는 MCP 게이트웨이에 적합한 선택입니다.

qualifiedModelId

낮음(알려진 집합)

추론 게이트웨이에 적합합니다.

$.context.jwt.sub

중간-높음

사용자당 한도에 적합합니다. 사용자 기반에 따라 경계가 지정된 카디널리티입니다.

$.context.jwt.team

낮음

팀당 할당량에 적합합니다.

$.context.iam.principal

중간

IAM 인증 설정의 역할별 제한에 적합합니다.

$.context.jwt.jti

경계 없음

사용하지 않습니다. 토큰당 고유한 버킷을 생성합니다.

$.context.jwt.nonce

경계 없음

사용하지 않습니다. 요청당 고유한 버킷을 생성합니다.

주의

제한 없는 차원 키(예: $.context.jwt.jti 또는 요청 범위 클레임)는 무제한 수의 속도 버킷을 생성합니다. 이렇게 하면 메모리가 낭비되고 성능이 저하되며 각 요청이 자체 버킷을 가져오고 제한되지 않으므로 속도 제한이 효과적으로 비활성화됩니다.

토큰 속도 제한 고려 사항

토큰 속도 제한은 예산 기반 적용 모델로 인해 특별한 고려가 필요합니다.

  • 예산 사용률: 게이트웨이는 전달 전에 입력 토큰을 추정하고 응답 후 실제 사용량을 기록합니다. 수명이 짧은 버스트는 구성된 속도를 일시적으로 초과할 수 있습니다.

  • 스트림 옵션: 스트리밍 채팅 완료 요청(/v1/chat/completions)의 경우 토큰 속도 제한이 활성 상태이고 옵션이 아직 없는 경우 게이트웨이가 "stream_options": {"include_usage": true} 요청 본문에 자동으로 추가됩니다. 이렇게 하면 TPM 적용을 정확하게 설명할 수 있습니다.

  • 지원되는 경로: 토큰 속도 제한은 알려진 추론 경로(/v1/chat/completions, /v1/messages, )에 대한 요청에만 적용됩니다/v1/responses. 다른 경로에 대한 요청에는 토큰 제한이 적용되지 않습니다.

  • 패스스루 대상: 알려진 추론 경로를 사용하지 않고 대상에서 모델 공급자로 프록시하는 경우 토큰 속도 제한이 적용되지 않습니다. 요청 속도 제한을 사용하거나 대상을 재구성하여 지원되는 경로를 사용하는 것이 좋습니다.

토큰 속도 제한 FAQ

이 섹션에서는 TPM(token-per-minute) 적용이 실제로 어떻게 작동하는지에 대한 일반적인 질문에 답변합니다.

TPM 적용은 어떻게 작동하나요?

게이트웨이는 예산 기반 적용 모델을 사용합니다. 요청이 도착하면 게이트웨이는 입력 토큰 수를 추정하고 구성된 TPM 예산에서 해당 금액을 예약합니다. 견적이 나머지 예산을 초과하면 요청이 모델에 도달하기 전에 HTTP 429 응답과 함께 거부됩니다. 요청이 성공적으로 완료되면 게이트웨이는 초기 추정치를 모델 공급자가 보고한 실제 토큰 사용량(입력 + 출력 토큰)으로 대체하여 예산을 조정합니다.

TPM은 프롬프트 캐싱에서 어떻게 작동하나요?

게이트웨이는 모델 공급자가 추론 응답에서 반환하는 input_tokens 및 output_tokens 값을 기반으로 토큰을 설명합니다. 게이트웨이는 프롬프트 캐싱을 위해 독립적으로 추적하거나 조정하지 않습니다. 캐시된 토큰이에 포함되는지 여부는 모델 공급자가 사용량을 보고하는 방법에 input_tokens 따라 달라집니다.이 동작은 공급자마다 다릅니다. 모델 공급자의 설명서를 참조하여 프롬프트 캐싱이 보고된 토큰 수와 효과적인 TPM 소비에 미치는 영향을 이해합니다.

TPM 한도가 50이고 토큰화기가 51개의 입력 토큰을 추정하는 경우 요청이 제한되나요?

예. 게이트웨이는 요청을 전달하기 전에 나머지 TPM 예산과 비교하여 토큰화기의 추정치를 평가합니다. 견적이 사용 가능한 예산을 초과하면 HTTP 429 응답과 함께 요청이 거부됩니다. 응답에는 충분한 예산을 사용할 수 있는 시기를 나타내는 retryAfter 필드가 포함됩니다.

장기 실행 요청이 처음에 예상한 것보다 더 많은 토큰을 소비하는 경우 응답이 제한되나요?

아니요. 게이트웨이가 요청을 수락하고 전달하면 응답이 항상 완전히 전달됩니다. 게이트웨이는 요청 시간에 예상 토큰을 예약하며, 다른 요청은 요청이 진행되는 동안 나머지 예산에 대해 계속 평가됩니다. 응답이 완료되면 게이트웨이는 실제 사용량을 추정치와 조정합니다. 실제 사용량이 더 높으면 예산이 조정됩니다. 이로 인해 후속 요청이 제한될 수 있지만 원래 응답은 중단되지 않습니다.

토큰 회계는 스트리밍 응답에서 어떻게 작동하나요?

게이트웨이는 최종 응답 청크를 토큰 조정의 정확한 소스로 사용합니다. 모든 모델 공급자가 스트리밍된 모든 청크에서 토큰 사용량을 보고하는 것은 아닙니다. 일부 공급자는 최종 청크에만 토큰 사용량을 포함합니다. 게이트웨이는 TPM 예산을 조정하기 전에 전체 응답을 기다립니다. OpenAI Chat Completions 스트리밍의 경우 토큰 속도 제한이 활성 상태이고이 옵션이 아직 없는 경우 게이트웨이가 요청 본문에 자동으로 "stream_options": {"include_usage": true}를 추가하여 최종 청크에서 정확한 토큰 수를 사용할 수 있도록 합니다.

운영상의 고려 사항

전파 타이밍

속도 제한 변경 사항이 전파되는 데 최대 30초가 걸립니다. 인시던트 발생 시이 지연을 계획합니다. 블록 항목(rate: 0)은 즉시 실행되지 않습니다.

속도 제로 동작

속도가 0이면 일치하는 모든 트래픽이 차단됩니다. 긴급 차단을 위해 의도적으로 사용합니다. 합법적인 트래픽을 실수로 차단하지 rate: 0 않도록 설정하기 전에 항목 차원 값을 다시 확인합니다.

변경할 수 없는 차원 키

기존 속도 제한dimensionKeys의는 변경할 수 없습니다. 다른 차원이 필요한 경우 기존 속도 제한을 삭제하고 새 차원을 생성합니다. 프로덕션 속도 제한을 생성하기 전에 차원 키 구조를 계획합니다.

중요

속도 제한은 페일 오픈 동작을 사용합니다. 속도 제한 서비스를 일시적으로 사용할 수 없는 경우를 통해 트래픽이 허용됩니다. 속도 제한을 유일한 보안 메커니즘으로 사용하지 마세요. 심층 방어를 위해 인증, 권한 부여, 게이트웨이 규칙 및 WAF와 결합합니다.

모니터링

다음 신호를 사용하여 속도 제한 효과를 모니터링합니다.

제한 응답 신호:

  • 게이트웨이의 HTTP 429 응답을 모니터링합니다.

  • 제한된 응답의 limitKey 필드를 구문 분석하여 트리거되는 속도 제한을 식별합니다.

  • retryAfter 값을 사용하여 적용 기간을 이해합니다.

OpenTelemetry 스팬 속성:

속성 모니터링할 항목

aws.agentcore.gateway.throttle.customer.decision = throttled

제한된 요청 수입니다. 예기치 않은 스파이크에 대한 알림입니다.

aws.agentcore.gateway.throttle.customer.limit_key

어떤 속도 제한이 가장 활성 상태인지 식별합니다. 적용이 불균형한지 확인합니다.

aws.agentcore.gateway.throttle.customer.metric

요청, 토큰 또는 연결이 병목 현상인지 확인합니다.

aws.agentcore.gateway.throttle.customer.matched_entry

어떤 호출자 또는 대상이 제한에 가장 자주 도달하는지 식별합니다.

aws.agentcore.gateway.throttle.customer.evaluated

확인된 모든 버킷의 정렬된 목록입니다. 특정 요청에 적용되는 제한을 이해하는 데 유용합니다.

모니터링 쿼리의 예:

aws/spans 로그 그룹에서 Amazon CloudWatch Logs Insights를 사용하여 게이트웨이의 OTEL 범위를 쿼리합니다. 다음 예제는 제한 패턴을 식별하는 데 도움이 됩니다.

속도 제한별로 제한된 요청 수 계산:

filter attributes.`aws.agentcore.gateway.throttle.customer.decision` = "throttled" | stats count(*) as throttle_count by attributes.`aws.agentcore.gateway.throttle.customer.limit_key` | sort throttle_count desc

어떤 호출자가 가장 병목 현상을 겪고 있는지 식별합니다.

filter attributes.`aws.agentcore.gateway.throttle.customer.decision` = "throttled" | stats count(*) as throttle_count by attributes.`aws.agentcore.gateway.throttle.customer.matched_entry` | sort throttle_count desc | limit 20

시간 경과에 따라 허용되는 요청과 제한된 요청을 비교합니다.

filter ispresent(attributes.`aws.agentcore.gateway.throttle.customer.decision`) | stats count(*) as total, sum(attributes.`aws.agentcore.gateway.throttle.customer.decision` = "throttled") as throttled by bin(5m)

단일 속도 제한이 대부분의 스로틀 이벤트를 차지하는 경우 구성된 속도가 너무 제한적인지 또는 트래픽 패턴이 남용을 나타내는지 고려합니다.

속도 제한 범위에서 경보 생성

속도 제한 OTEL 범위 속성을 CloudWatch 지표 및 경보로 변환하여 제한 동작을 사전에 모니터링할 수 있습니다. 이를 위해서는 게이트웨이 관찰성을 활성화해야 합니다( AgentCore 게이트웨이 리소스에 대한 관찰성 활성화 참조).

1단계: 게이트웨이 범위 활성화

게이트웨이에 관찰성이 활성화되어 있는지 확인합니다. 게이트웨이 스팬은 CloudWatch로 내보내지고 CloudWatch 트랜잭션 검색 및 생성형 AI 관찰성 페이지에서 볼 수 있습니다.

2단계: CloudWatch 지표 필터 생성

aws/spans 로그 그룹에 지표 필터를 생성하여 스로틀 이벤트를 사용자 지정 지표로 추출합니다. 다음 예제에서는 속도 제한당 제한된 요청을 계산하는 지표를 생성합니다.

{ "filterPattern": "{ $.attributes.aws\\.agentcore\\.gateway\\.throttle\\.customer\\.decision = \"throttled\" }", "metricTransformations": [ { "metricName": "GatewayRateLimitThrottleCount", "metricNamespace": "AgentCore/Gateway/RateLimits", "metricValue": "1", "defaultValue": 0, "dimensions": { "LimitKey": "$.attributes.aws\\.agentcore\\.gateway\\.throttle\\.customer\\.limit_key" } } ] }

3단계: CloudWatch 경보 생성

지표 필터가 배치되면 스로틀 속도가 임계값을 초과할 때 트리거되는 경보를 생성합니다.

예
AWS CLI
  1. 다음 명령을 실행합니다.

    aws cloudwatch put-metric-alarm \ --alarm-name "GatewayRateLimitThrottleSpike" \ --namespace "AgentCore/Gateway/RateLimits" \ --metric-name "GatewayRateLimitThrottleCount" \ --statistic Sum \ --period 300 \ --evaluation-periods 1 \ --threshold 100 \ --comparison-operator GreaterThanThreshold \ --alarm-description "Alert when rate limit throttles exceed 100 in 5 minutes" \ --alarm-actions "arn:aws:sns:us-west-2:123456789012:my-alarm-topic"
AWS Python SDK (Boto3)
  1. import boto3 cloudwatch = boto3.client("cloudwatch", region_name="us-west-2") cloudwatch.put_metric_alarm( AlarmName="GatewayRateLimitThrottleSpike", Namespace="AgentCore/Gateway/RateLimits", MetricName="GatewayRateLimitThrottleCount", Statistic="Sum", Period=300, EvaluationPeriods=1, Threshold=100, ComparisonOperator="GreaterThanThreshold", AlarmDescription="Alert when rate limit throttles exceed 100 in 5 minutes", AlarmActions=["arn:aws:sns:us-west-2:123456789012:my-alarm-topic"], ) print("Alarm created successfully")

4단계: 대시보드 구축

CloudWatch 대시보드를 생성하여 시간 경과에 따른 조절률을 시각화합니다. 다음 위젯 구성은 속도 제한별로 그룹화된 스로틀 수를 보여줍니다.

{ "metrics": [ [ "AgentCore/Gateway/RateLimits", "GatewayRateLimitThrottleCount", "LimitKey", "per-target-rps" ], [ "AgentCore/Gateway/RateLimits", "GatewayRateLimitThrottleCount", "LimitKey", "per-caller-rpm" ] ], "period": 60, "stat": "Sum", "title": "Rate Limit Throttles by Limit" }
작은 정보

또한 기본 제공 Throttles 지표(게이트웨이 호출 지표에서 기본적으로 사용 가능)를 사용하여 제한별 세부 수준 없이 총 스로틀 수를 계산할 수 있습니다. 한도당 또는 호출자당 가시성이 필요한 경우 범위 속성에 사용자 지정 지표 필터를 사용합니다.