Scaling

This page documents Generation 1, which has reached End of Life. Gen 1 apps use docker-compose.yml. For current documentation, see Scaling.

Convox allows you to scale your application's concurrency, memory allocation, and the resources available in the underlying Rack.

Scaling an application

Show current application scaling

$ convox scale
NAME  DESIRED  RUNNING  MEMORY
web   2        1        256
redis 1        1        256

Concurrency

$ convox scale web --count=4
NAME  DESIRED  RUNNING  MEMORY
web   2        1        256

Memory

$ convox scale web --memory=1024
NAME  DESIRED  RUNNING  MEMORY
web   2        1        1024

CPU

Each rack instance has 1,024 cpu units for every CPU core. This parameter specifies the minimum amount of CPU to reserve for a container. Containers share unallocated CPU units with other containers on the instance with the same ratio as their allocated amount.

$ convox scale web --cpu=1024
NAME  DESIRED  RUNNING  CPU
web   1        1        1024

Scaling down unused services

It's often convenient to run a service like Redis in a container locally. You can do so by defining a redis process in your docker-compose.yml. However, when you've deployed the app to your rack, you should use a hosted resource like ElastiCache. In this case, you can scale redis down and destroy the ELB which was created:

$ convox scale redis --count=-1
NAME  DESIRED  RUNNING  MEMORY
redis   -1        1        256

Note: If you scale this service back up, the ELB will be recreated, but will have a different domain name associated with it. If you want to scale a service down, but keep the ELB, you can set --count=0.

Scaling the Rack

You can define both the type and count of instances being run in your Rack.

$ convox rack scale --type=m4.xlarge --count=3
Name     demo
Status   updating
Version  20160409181028
Count    3
Type     m4.xlarge

Warning: convox rack scale --count sets the InstanceCount parameter, which has a minimum of 3. It applies only to Racks with HighAvailability set to true (the default). A Rack installed with HighAvailability=false uses NoHaInstanceCount instead, which has a minimum of 1.

Autoscale

Your Rack can scale its own instance count based on the needs of the containers it provisions. Autoscaling is enabled by default. To disable it, set the Autoscale parameter:

$ convox rack params set Autoscale=No

The autoscaler runs as a Lambda function in the Rack's stack. It writes to its own CloudWatch log group, not to convox rack logs, and the group's name starts with /aws/lambda/ and contains InstancesAutoscaler. Every few minutes, the Rack monitor writes the latest instance launch or termination by the Rack's Auto Scaling group to convox rack logs. When several start between two checks, only the latest one appears there:

$ convox rack logs --filter='"EC2/ASG"'

Under the hood

Every minute, your Rack runs an autoscale calculation to determine how many instances you need in your cluster. This calculation involves ports, memory, and CPU required by your services. When appropriate, autoscale will update your Rack instance count via a CloudFormation stack update. Autoscale will not change your instance type. It skips its run while the Rack's stack is updating, and after a Rack update that rolled back, until the next Rack update succeeds.

During a deployment, the calculation gets more nuanced, since processes from an old release and a new release will temporarily run at the same time. This is known as a rolling deployment or rolling update. In ECS terms, this translates to having tasks from both the primary (new) deployment of each service and the active deployment (the one being replaced) of each service running at the same time. Autoscaling will take into account the number of instances needed to run the processes from both releases, i.e. the tasks in both primary and active ECS service deployments.

When a deployment finishes, the old ECS tasks get terminated, and autoscale scales the Rack back down to the original instance count. One stack update can remove several instances.

Why does my Rack keep autoscaling?

If your Rack shows more autoscaling activity than expected, there are a few possible explanations.

First, note that any services with open ports you have running at scale of n will result in at least n instances plus AutoscaleExtra, or plus NoHAAutoscaleExtra on a Rack with HighAvailability set to false. With the defaults, that is n+1 on a high-availability Rack and n on one without. This is to allow for rolling deployments.

Autoscaling does not yet take the subtleties of deployment minimum/maximum into account. For example: on a Rack with HighAvailability set to true and the default AutoscaleExtra, a web service listening on port 80 with a scale count of 3 will still require 4 instances, even if it has convox.deployment.minimum=50 set.

You can also look for anomalies in the autoscaler's own log group, described in Autoscale. A line such as skipping autoscale: stack myrack is UPDATE_ROLLBACK_COMPLETE means autoscaling is paused until the next successful Rack update.

See Also

• Scaling (Gen 2)
• App Parameters
• Rolling Updates