What are the correct Cloudwatch / Autoscale settings for extremely short traffic on Amazon Web Services?

Question

I have an Amazon elastic beanstalk website with the following traffic pattern:

• ~ 50 simultaneously working users.
• ~ 2000 concurrent users in 1/2 minutes when a message is sent to a Facebook page.

Amazon web services claim they can scale quickly to such issues, but setting “cloudy” for “Greater than x more than 1 minute” doesn't seem to be fast enough for this traffic pattern?

Usually, within a few seconds, all instances of ec2 crashes, killing all cloud indicators and the entire site drops by 4/6 minutes. So far, I have not yet found a configuration that works for this senario.

Here is a graph of a smaller event that also killed the site:

Answer 1

The AWS proposal was as follows:

We always try to make our systems more responsive, but this is an automatic provision of virtual servers with a response time of a few seconds, as you think, your use case. perhaps there is a workaround that responds more quickly or more when requests begin to increase.

Have you observed if a site works better if you use a larger instance type or more instances in steady state? This may be one way to be resistant to the rapid increase in incoming requests. Although I admit that this is not the most economical, you may find that it is a quick fix.

Another approach might be to set up an alarm to use a threshold or metric that more likely reflects (or predicts) your increase in demand. For example, you can see better performance if you install add instances after you exceed 75 or 100 users. Perhaps you are already doing this. In addition, your precedent may have another indicator that predicts an increase in demand, for example, placement on your Facebook page may be preceded by a significant increase in the request in a few seconds or even minutes. Using CloudWatch custom metrics to monitor this value, and then setting an alarm for auto-scale on it, can also be a potential solution.

Therefore, I believe that the best answer is to run more instances with lower traffic and use custom metrics to predict traffic from an external source. I am going to try, for example, to follow Facebook and Twitter for messages with links to the site and quickly scale.

Answer 2

Are these links predictable? If so, you can use Scheduled Scaling , or alternatively you can change the RIGIDITY-POWER value in the Automatic Scaling group or even run as-execute-policy to scale right before sending the link.

Did you know that in one group there can be several scaling policies? Thus, you may have a special auto-scaling policy for your case, something like SCALE_OUT_HIGH , which adds, for example, another 10 instances. Take a look at the as-put-scaling-policy command.

In addition, you need to check your code and find the neck of the bottle.

What HTTPD are you using? Consider switching to Nginx as it is much faster and less resource-intensive software than Apache. Try using Memcache ... NoSQL, like Redis, for reading and writing in high quality is also a great option.