개발자 앱 또는 개발자가 일정 기간 동안 수행할 수 있는 API 프록시 호출 수를 제한합니다. SpikeArrest 정책은 초 또는 분과 같은 더 짧은 간격 동안의 비율 제한에 더 적합합니다. 정확한 계산이 필요하면 할당량을 사용하세요.
특정(일반적으로 짧은) 기간 동안 모든 소비자 간에 API 프록시에 대해 수행할 수 있는 API 호출 수를 제한합니다. 할당량 정책은 일, 주, 개월, 연도와 같은 더 긴 간격으로 제한을 설정하는 데 더 적합합니다.
다음과 같은 용도로 사용할 수 없습니다.
트래픽 급증으로부터 API 프록시의 대상 백엔드를 보호하기 위해 사용하지 마세요.
이를 위해 SpikeArrest 정책을 사용합니다.
특정 기간 동안 앱이 API 프록시의 대상 백엔드에 연결하는 수를 계산하고 제한하는 데 사용하지 마세요. 참고: 정확한 계산이 필요한 사용 사례의 경우 할당량 정책을 사용하세요.
계산 저장 여부
예
아니요
정책 연결 권장사항
일반적으로 사용자 인증 후 ProxyEndpoint Request PreFlow에 연결합니다.
이렇게 하면 정책이 API 프록시의 진입점에서 할당량 카운터를 확인할 수 있습니다.
일반적으로 이 흐름의 시작 부분에 있는 ProxyEndpoint Request PreFlow에 연결합니다.
이를 통해 API 프록시의 진입점에서 급증 방지 기능을 제공합니다.
한도 도달 시 HTTP 상태 코드
429(서비스를 사용할 수 없음)
429(서비스를 사용할 수 없음)
알아두면 좋은 정보
할당량 카운터는 Cassandra에 저장됩니다.
리소스를 저장하기 위해 카운터를 비동기식으로 동기화하도록 정책을 구성합니다.
비동기식 카운터 동기화는 비율 제한 응답에 지연을 일으킬 수 있으므로 설정된 한도를 약간 초과한 호출이 허용될 수 있습니다.
'평활화' 알고리즘 또는 유효 개수 알고리즘 중에서 선택할 수 있습니다. 전자는 지정된 기간 동안 발생 가능한 요청 수를 평활화하고 후자는 연속해서 전송되는 속도가 얼마나 빠른지에 관계없이 지정된 기간 동안 발생할 수 있는 총 요청 수를 제한합니다. 또한 평활화는 메시지 프로세서 간에 조정되지 않습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-08-19(UTC)"],[[["\u003cp\u003eThis content focuses on the Quota and SpikeArrest policies within Apigee and Apigee hybrid, which are used to manage request thresholds.\u003c/p\u003e\n"],["\u003cp\u003eThe Quota policy is recommended for use cases requiring precise request counting over longer durations like days, weeks, months, or years, offering accurate counting across all regions.\u003c/p\u003e\n"],["\u003cp\u003eSpikeArrest is better suited for rate limiting over short intervals, such as seconds or minutes, and for protecting backend services from sudden traffic spikes, but its request counting may not be entirely accurate due to its use of a Redis cache.\u003c/p\u003e\n"],["\u003cp\u003eBoth the Quota and SpikeArrest policies trigger a \u003ccode\u003e429\u003c/code\u003e (Service Unavailable) HTTP status code when request limits are reached, indicating a temporary denial of service.\u003c/p\u003e\n"],["\u003cp\u003eShared flows and chaining proxies can be utilized to protect slower backends without impacting API performance.\u003c/p\u003e\n"]]],[],null,["# Comparing Quota and SpikeArrest policies\n\n*This page\napplies to **Apigee** and **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\n| **Key Point:** The [Quota](/apigee/docs/api-platform/reference/policies/quota-policy) and [SpikeArrest](/apigee/docs/api-platform/reference/policies/spike-arrest-policy) policies both count requests and take action if a specified request threshold is exceeded. Be aware, however, that the mechanisms by which these policies count requests are not the same.\n|\n|\n| While SpikeArrest maintains counts with high reliability, it is designed to use a\n| [Redis\n| best-effort cache](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_protocols/redis) to store its counts. Because the cache is not replicated, there are cases where counts may be\n| lost, such as a restart of the cache servers, or other rare cases.\n|\n| For these reasons, we recommend\n| against using SpikeArrest for use cases that require accurate counting. Only the synchronous\n| Quota policy offers accurate counting across all regions in a given timeframe.\n\nUse the comparison chart below to help you decide which policy to use to\nfor your rate limiting use case:\n\n| **Tip:** You can also use the following to protect slow/sluggish backends without impacting the performance of the APIs:\n|\n| - [Creating reusable shared flows:](/apigee/docs/api-platform/fundamentals/shared-flows) Combine policies and resources into a shared flow that you can consume from multiple API proxies, and even from other shared flows.\n| - [Chaining API proxies together](/apigee/docs/api-platform/fundamentals/connecting-proxies-other-proxies): Specify that one proxy is the target endpoint of another, effectively connecting the two proxies in a proxy chain. Chaining proxies in this way can help you avoid a network hop, and so improve overall performance."]]
