ECS Managed Scaling

Checking the application

So far we have created the service and this has started procuring capacity accordingly and exposing the service through the load balancer that we attached to the workload. Before we proceed with scaling out and down the application, let’s check the application and what it does.

Exercise: How can I get check get access to the web application deployed?

To get access to the application you need to find the URL associated with the service. The URL has been associated to the Load Balancer that was created as part of the CloudFormation stack. There are a few ways you could get the URL; you could perhaps review AWS console sections like CloudFormation, or the LoadBalancer section in EC2.

Click here to show the answer

ECS Managed Scaling (CAS) in Action

As we explained earlier, ECS offers two different type of scaling:

  • Service Auto Scaling - as the ability to increase or decrease the desired count of tasks in your Amazon ECS service automatically

  • Cluster Auto Scaling (CAS) - as the ability to manage the scaling actions of Auto Scaling group asociated to Capacity Providers.

In this section we will simulate a Service Auto Scaling, by changing manually the number of tasks on the service. We will see how ECS Managed Cluster Auto Scaling calculates the CapacityProviderReservation metric for different Capacity Providers, and procures capacity accordingly. So far we have deployed our initial 10 tasks, you can check the status in the ECS Console by clicking on Cluster EcsSpotWorkshop and then ec2-service-split or alternatively click here to take you to the right console.:

Capacity Provider

Let’s increase manually the number of tasks on the service and increase them up to 22. Execute the following on Cloud9

aws ecs update-service --cluster EcsSpotWorkshop --service ec2-service-split --desired-count 22 --output table

The change in the numbers of desired tasks should result in a change to the metrics CapacityProviderReservation associated with the Capacity Providers. If you recall from previous sections, calculation of the CapacityProviderReservation is done with the following formula CapacityProviderReservation = ( M / N ) * 100.

Exercise: Answers the following questions

    1. What will be the task distribution Spot vs OnDemand?
    1. Can you guess how many new instances will be created?
    1. What is the maximum value we should expect for both the Spot and OnDemand CapacityProviderReservation metric?
    1. Can you find which CloudWatch Alarms are trigger when CapacityProviderReservation increases?
Click here to show the answer

Optional Exercises

Some of this exercises will take time for CAS to scale up and down. If you are running this workshop at a AWS event or with limited time, we recommend to come back to this section once you have completed the workshop, and before getting into the cleanup section.

In this section we propose additional exercises you can do at your own pace to get a better understanding of Capacity Providers, Managed Scaling and Spot instances best practices. We recommend users adopting spot in Test and Production workloads to complete the exercises below to get a better understanding of the different attributes they can change when setting up their cluster configuration. Note we are not providing a solution to this exercises however, you should be able to reach the solutions with with the skills acquired in the previous sections.

  • Scale down the number of desired tasks back to 10. Answer the following questions: a) How long do you expect the trigger to scale down instances to take? b) Can you predict how many instances you will end up with? Tip : read about placement strategies

  • The Service definition we have used so far has used the BinPack strategy as the way to define how tasks are placed. a) What would be the effect of changing the placement strategy on the service and repeating the Scale-out & Scale-in exercises we’ve done so far? b) Would the number of instances be the same ? c) In which situations you may want to use Spread vs BinPack and what are the pros / cons of each placement strategy ? Tip: read about placement strategies

  • So far in the Spot Auto Scaling Group, we have used a Mixed Instance Group (MIG) of instances with the same number of vCPU’s and Memory. This has made our calculations and understanding of CAS simple, but it limits the number of pools we diversify Spot instances on. a) Edit the Spot Auto Scaling Group and add instances of different sizes that still respect the vCPU to Memory ratio for example m5.xlarge, m5a.xlarge ,m4.xlarge. b) Can you explain what are the benefits of this configuration? c) Repeat the scaling exercises above and check if this time around you can predict how many instances will be used? d) Can you explain the trade-offs of this configuration? Tip: refresh your spot best Practices knowledge, Read about Spot Capacity optimized allocation Strategy, read how ECS Managed Cluster works with mixed instance sizes

Site Info