Spike Arrest policy : Rate limiting value per resource with out re deploy any changes

[vamsipabbisetty]

As per link mentioned below Apigee indicates to have “Attach it to the ProxyEndpoint Request PreFlow, generally at the very beginning of the flow.” but in such cases we will have to put arrest rate hardcoded inside Spike Arrest policy or drive through Java script policy but needs to redeploy the proxy if we want to change the value in future.

Link : https://docs.apigee.com/api-platform/develop/comparing-quota-spike-arrest-and-concurrent-rate-limit-...

In case if I need to configure the arrest rate to product (to make the arrest rate configurable) then I need to keep Spike Arrest policy after the OAuth token verification in to get the product level values values but as per suggestion Spike Arrest policy should be first policy to execute.

Also we are planned to drive from KVM but end of with maintaining many variables if rate is unique for each proxy.

Do we have any technique or recommendations to achieve this scenario?

[dknezic]

If you intend on using the KVM anyway, you can store your value there.. Use a kvm policy to retrieve it, then refer to that variable in your Spike Arrest policy.

[vamsipabbisetty]

Thanks for your reply

[cjking]

It sounds like you probably want to use a SpikeArrest together with a Quota policy.

The point of SpikeArrest is to stop absurd, massively overwhelming levels of traffic due to DoS attacks, crazy misconfigured clients (while(1) ...) and so on. Ideally it would be set to a very high level, well above what you consider 'unusually high' levels of traffic. SpikeArrest needs to be very, very fast to successfully do this and adding things like KVM lookups or other policies in front of it risks the load of the KVM lookup or other policies overwhelming your message processors and defeating the purpose of the SpikeArrest.

Quota policies are better at enforcing more fine-grained levels like what you're considering. I'd suggest a configuration something like:

Spike Arrest Policy (@1000TPS) ; KVM Lookup ; Quota Policy (@ between 10 and 100TPS, depending on lookup)

Obviously you'd need to decide appropriate numbers for your situation, but so long as you set the Spike Arrest Policy to a large value well in excess of your largest Quota Policy you can reap both the protection of the Spike Arrest Policy and the fine-grained configurability of the quota policy at the same time without compromising on either.

[abiramradhakris]

@Christian King Thanks for detailed information, when I review this post have following queries.

Overall understanding is if Spike arrest need to be configurable will have two technique.

1.Looking value from KVM for Spike will have overwhelming your message processors, is a valid point.

2. In case if I need to configure the Spike arrest rate to product (to make the arrest rate configurable) then I need to keep Spike Arrest policy after the OAuth token verification in to get the product level values, but in this case Spike Arrest is not front facing.

Looking @ your comments looks like, if Spike arrest need to be front facing, then only way is to have the values inside policy (Like a static value inside policy, not configurable in KVM).

I don't recall Product documentation anything indicating about " policies overwhelming your message processors" when looking from KVM configuration for Spike arrest

Let me know if I am missing anything

[cjking]

@Abiram Radhakrishnan - The comparison page here: https://docs.apigee.com/api-platform/develop/comparing-quota-spike-arrest-and-concurrent-rate-limit-... mentions putting spike arrest at the very front of the flow, but does not explain why.

Basically, the Spike arrest policy and everything in front of it need to be executed even in a DoS attack scenario. The more policies you put there, the more message processors need to work in order to drop the traffic. The message processor capacity to handle the load should be higher than your backend but it isn't infinite, and if it runs out you'll experience an outage the same way you would if your backend was overwhelmed.

[vamsipabbisetty]

Thanks @Christian King. We considered your points for implementation

[6493]

@vamsipabbisetty @cjking - Understand the intent of spike arrest is to protect the target back end

1. What would be a good place to store the spike rate - KVM's?

2. Also whats the suitable identifier the SA should be grouped - TargetServer name?