We've released the ability of scaling app/down application instances by leveraing AWS Autoscaling feature. In this way, the same policies that can be defined on AWS can be applied to app instances, with the EYCloud platform taking care of automatically configuring them as if they were provisioned manually through our UI or API.
Things to take into account:
- As it stands, this feature is for scaling application instances only. If you need to scale other type of instances, open a ticket with our Support Team to discuss other options.
- Autoscaling is a per-environment configuration. On EYCloud, a single autoscaling policy can't provision/terminate instances across environments.
- Autoscaling is only possible on instances that live in a VPC. If your app instances don't live in or are classiclinked to one then you'll need to migrate them to a VPC. Contact our Support Team for assistance on how this can be achieved.
- Time-based scaling is not avaible yet through the UI.
- New instances will be created from fresh EBS volumes. Given the nature of how AWS autoscaling provisions new instances and how EYCloud handles snapshots, having the former use the last snapshot is essentially not possible. If your environments rely on snapshots to bring up new app instances, contact our Support Team to evaluate which alternatives are possible.
To have the ability to use autoscaling on all environments, enable the feature by going to the 'Tools' menu, selecting 'Early access'
and enabling 'Autoscaling'
Creating an autoscaling group for an environment
To actually use autoscaling on a given environment, an autoscaling group has to be created at the environment level. Go to the 'More Options' section, find 'Autoscaling'
and select it. A new window will appear:
(Do not mind about dynamic scaling policies just yet. It will be covered below)
The default settings for an autoscaling group will have one app instance as the minimum and 10 as the maximum. Alter those as desired, as well as the 'health check grace' and 'default cooldown' values.
It's to note that the app_master is not on the autoscaling group to avoid mistakenly terminating it, which will result on the app being down.
Click on 'Create Autoscaling Group' and wait a bit until EYCloud provisions and configures the autoscaling group. The following screen will show up:
give it some time, and reload the page to find a message like the one below:
At this point the autoscaling group is provisioned and active. A new setting appears, 'Desired capacity', which by default matches 'Minimum number of servers'. If you have left the defaults values then a new app instance will be added to the environment as soon as AWS triggers it.
Defining autoscaling policies
The autoscale policies in EYCloud are very similar to the ones in AWS. While it's not necessarily required to know them in details, consider having a read of the AWS docs on the matter.
Click on 'Add New' got start working with policies
Every policy has three sections:
- The policy type and its name. Define here which type of on-demand scaling you'll be using, and give a name to the policy. The linked AWS doc provides a good explanation of the different on-demand types of scaling.
- What will trigger the policy (or its 'alarm'). Here keep in mind that 'metric' is 'aggregated' for 'numbers of periods' across all the instances that at already part of the autoscaling group. And will trigger if the result matches the 'trigger value' according to the 'operand'. In this context, 'period length' is how long the event will take place, which in EYCloud is related to the time it takes for an instance to be provisioned/terminated.
- The action to happen when the policy is triggered. Special attention has to be put here on the value for 'cooldown', which is how long the autoscaling engine will wait until trigger another action. This is related with how long it takes to provision a fully working instance in your environment, or to terminate it.
Click on 'Create' to create the policy, and then on 'Update Auto Scaling Group' to have changes be put in place in AWS. A common mistake here is to forget to 'Update', in which case you'll need to redo the changes on the policy.
As it is with changes that involve major parts of the infrastructre, we advise to test policies on a non-production environment first. Pay special attention to provision and termination times for your application and adjust the 'period length' and 'cooldown' accordingly.
Define a healtcheck path for your application. This value will be used by the load balancer (HAProxy or AWS's xLB) to mark the instance as healthy and start sending traffic towards it. If an app's related healtcheck is not defined, the default will be for the load balancer to check at the TCP level if Nginx is responding. Hence, the load balancer may start sending traffic over before the app behind Nginx is ready to process it, generating 500s and such.