Ecs cluster autoscaling

Ecs cluster autoscaling DEFAULT

AWS ECS cluster auto-scaling vs service auto-scaling

this is my first time using amazon ecs service.

I have searched online for awhile to understand auto-scaling with ecs services.

I found there are two options to auto-scale my application. But, There are some I don't understand.

First is Service auto scaling which track the cpu/memory metric from cloudWatch and increase the task number accordingly.

Second is cluster auto scaling which needs to create auto scaling resource, create capacity provider and so on. But, in Tutorial: Using cluster auto scaling, it can run the task definition without service. But it also seems increasing the task number in the end.

So what's the different and 'pros and cons' between them?

asked Jan 18 at 11:55

ZoediaZoedia

24522 silver badges1212 bronze badges

Sours: https://stackoverflow.com/questions/65774071/aws-ecs-cluster-auto-scaling-vs-service-auto-scaling

Auto Scaling

As you experienced in 5. Container Monitoring, Amazon ECS publishes CloudWatch metrics with your service’s average CPU and memory usage. You can use these and other CloudWatch metrics to automatically adjusts capacity to maintain steady, predictable performance at the lowest possible cost. With ECS Cluster Auto Scaling, your ECS clusters running on EC2 can automatically scale as needed to meet the resource demands of all tasks and services in your cluster. You will learn how those two kinds of auto scaling work.

Amazon ECS Service Auto Scale

ServiceAutoScale You can use CloudWatch metrics and others to scale out your service (add more tasks) to deal with high demand at peak times, and to scale in your service (run fewer tasks) to reduce costs during periods of low utilization.

Amazon ECS Cluster Auto Scale

ClusterAutoScale With ECS Cluster Auto Scaling, your ECS clusters running on EC2 can automatically scale as needed to meet the resource demands of all tasks and services in your cluster.

ECS Cluster Auto Scaling uses ECS Capacity Provider construct to manage Amazon EC2 Auto Scaling Groups (ASG) on your behalf. You can configure the Capacity Provider to enable managed scaling of the ASG, reserve excess capacity in the ASG, and also to manage termination of instances in the ASG.

Previously, ECS did not have the ability to directly manage the scaling of ASG. Instead, you had to set up scaling policies on your ASG manually outside of ECS, and the metrics available for scaling did not account for the desired task count, only the tasks already running.

Sours: https://ecs-cats-dogs.workshop.aws/en/autoscale.html
  1. Twin frozr 7
  2. Silverado bumper replacement
  3. Watters world 2016
  4. Easy kalimba songs 7 note

Deploy ECS Cluster Auto Scaling

Enable EC2 capacity on the cluster

Navigate back to the repo where we create and manage the platform.

In the app.py, uncomment the code under the section of code that says . It should look like this:

Now, update the cluster using the cdk.

By adding that small section of code, all of the necessary components to add EC2 instances to the cluster will be created. This includes an Auto Scaling Group, Launch Configuration, ECS Optimized AMI, etc. For more information, see the official cdk documentation.

Once the deployment is complete, let’s move back to the capacity provider demo repo and start work on setting up cluster auto scaling.

Enable Cluster Auto Scaling

As we did in the previous section, we are going to once again create a capacity provider. This time; however, it will be a capacity provider backed by EC2 and we’ll enable managed cluster auto scaling. Let’s do that now.

If you get an error that the capacity provider already exists because you’ve created it in the workshop before, just move on to the next step.

  • In order to create a capacity provider with cluster auto scaling enabled, we need to have an auto scaling group created prior. We did this earlier in this section when we added the EC2 capacity to the ECS cluster. We run a couple of cli calls to get the Auto Scaling group details which is required for the next command where we create the capacity provider.

  • The next command is creating a capacity provider via the AWS CLI. Let’s look at the parameters and explain what their purpose:

    • : This is the human readable name for the capacity provider that we are creating.

    • : There is quite a bit here, let’s unpack one by one:

      • : The ARN of the Auto Scaling group for the cluster autoscaler to use.
      • : This is where we enable/disable cluster auto scaling. We also set , which determines at what point in cluster utilization do we want the auto scaler to take action.
      • : Enable this parameter if you want to ensure that prior to an EC2 instance being terminated (for scale-in actions), the auto scaler will only terminate instances that are not running tasks.

Now that we have a capacity provider created, we need to associate it with the ECS Cluster.

You will get a json response indicating that the cluster update has been applied, now it’s time to deploy a service and test this functionality out!

Deploy an EC2 backed ECS service

First, as we’ve done previously, we will run a on what presently exists, and what will be deployed via the cdk.

Review the changes, you should see all new resources being created for this service as it hasn’t been deployed yet. So on that note, let’s deploy it!

Once the service is deployed, take note of the load balancer URL output. Copy that and paste it into the browser.

Examine the current deployment

What we did above was deploy a service that runs one task. With the current EC2 instances that are registered to the cluster, there is more than enough capacity to run our service.

Navigate to the console, and select the container-demo cluster. Click the ECS Instances tab, and review the current capacity.

clustercapacity

As you can see, we have plenty of capacity to support a few more tasks. But what happens if we need to run more tasks than what we have current capacity to run?

  • As operators of the cluster, we have to think about how to scale the backend EC2 infrastructure that runs our tasks (of course, this is for EC2 backed tasks, with Fargate, this is not a concern of the operator as the EC2 backend is obfuscated).
  • We also have to be mindful of scaling the application. It’s a good practice to enable autoscaling on the services to ensure the application can meet the demand of it’s end users.

This poses a challenge when operating an EC2 backed cluster, as scaling needs to be considered in two places. With the cluster autoscaling being enabled, now the orchestrator will scale the backend infrastucture to meet the demand of the application. This empowers teams that need EC2 backed tasks, to think “application first”, rather than think about scaling the infrastructure.

Scale the service beyond the current capacity available

We’ll do it live! Go back into the deployment configuration (), and do the following:

Change the desired_count parameter from to .

Now, save the changes, and let’s deploy.

Let’s walk through what we did and what is happening.

  • We are modifying our task count for the service to go from one, to ten. This will stretch us beyond the capacity that presently exists for the cluster.
  • The capacity provider assigned to the cluster will recognize that the target capacity of the total cluster resources is above 80%. This will trigger an autoscaling event to scale EC2 to get the capacity back to 80% or under.

If you navigate to the ECS console for the container-demo cluster, you’ll notice that there are ten tasks attempting to run.

clustercapacity

Next, when you select the tab, you will see that there are only two instances running. Looking at the however, we see that there are four tasks waiting to be scheduled. This is due to lack of resource availability.

clustercapacity

Over the course of the next couple of minutes, behind the scenes a target tracking scaling policy is triggering a Cloudwatch alarm to enable the auto scale group to scale out. Shortly after, we will begin to see new EC2 instances register to the cluster. This will then be followed by the tasks getting scheduled on to those instances.

Once done, the console should now look something like below:

All tasks should be in a state. running

More EC2 instances are registered to the ECS Cluster. ec2

Scale the service back down to one

Now that we’ve seen cluster auto scaling scale out the backend EC2 infrastructure, let’s drop the count back to one and watch as it will scale our infrastructure back in.

We’ll do it live! Go back into the deployment configuration (), and do the following:

Change the desired_count parameter from to .

Now, save the changes, and let’s deploy.

That’s it. Now, over the course of the next few minutes, the cluster auto scaling will recognize that we are well above capacity requirements, and will scale the EC2 instances back in.

Review

What we accomplished in this section of the workshop is the following:

  • Created a capacity provider for EC2 backed tasks that has managed cluster auto scaling enabled.
  • We deployed a service with one task and plenty of backend capacity, and then scaled out to ten tasks. This caused the managed cluster auto scaling to trigger a scale out event to have the backend infrastructure meet the availability requirements of the tasks.
  • We then scaled the service back to one, and watched as the cluster auto scaling scaled the EC2 instances back in to ensure that we weren’t over provisioned.

Up Next

In the next section, we’re going to:

  • Add EC2 Spot instances to our cluster.
  • Create a capacity provider for the Spot instances, then enable Cluster Auto Scaling on the new capacity provider.
  • Add the new capacity provider to the default cluster capacity provider strategy.
  • Deploy the service across both On-Demand and Spot capacity providers with the new strategy to spread our tasks across them. With this strategy, we optimize costs while scaling out our service using Spot Instances.
  • Scale the service out and in to see how the strategy spreads the tasks across capacity providers and cluster autoscaling takes care of scaling the underlying EC2 instances.
Sours: https://ecsworkshop.com/capacity_providers/ec2/
Amazon ECS Cluster Auto Scaling with a Capacity Provider

Amazon ECS cluster auto scaling

Amazon ECS cluster auto scaling enables you to have more control over how you scale the Amazon EC2 instances within a cluster. When creating an Auto Scaling group capacity provider with managed scaling enabled, Amazon ECS manages the scale-in and scale-out actions of the Auto Scaling group used when creating the capacity provider. On your behalf, Amazon ECS creates an AWS Auto Scaling scaling plan with a target tracking scaling policy based on the target capacity value you specify. Amazon ECS then associates this scaling plan with your Auto Scaling group.

For each of the Auto Scaling group capacity providers with managed scaling enabled, an Amazon ECS managed CloudWatch metric with the prefix is created along with two CloudWatch alarms. The CloudWatch metrics and alarms are used to monitor the Amazon EC2 instance capacity in your Auto Scaling groups and will trigger the Auto Scaling group to scale in and scale out as needed.

Each cluster has one or more Auto Scaling group capacity providers and an optional default capacity provider strategy. The capacity providers determine the infrastructure to use for the tasks, and the capacity provider strategy determines how the tasks are spread across the capacity providers. When you run a task or create a service, you may either use the cluster's default capacity provider strategy or specify a capacity provider strategy that overrides the cluster's default strategy. For more information about capacity providers, see Amazon ECS capacity providers.

The following should be considered when using cluster auto scaling:

  • Amazon ECS uses the service-linked IAM role for the permissions it requires to call AWS Auto Scaling, on your behalf. For more information on using and creating Amazon ECS service-linked IAM roles, see Service-linked role for Amazon ECS.

  • Cluster auto scaling is not available in the Asia Pacific (Osaka) Region.

  • When using capacity providers with Auto Scaling groups, the IAM user creating the capacity providers, needs the permission. This is because Amazon ECS adds a tag to the Auto Scaling group when it associates it with the capacity provider.

    Important

    Ensure any tooling you use does not remove the tag from the Auto Scaling group. If this tag is removed, Amazon ECS is not able to manage it when scaling your cluster.

  • Managed scaling works best if your Auto Scaling group uses the same or similar instance types. For more information, see Managed scale-out behavior.

  • When using an Auto Scaling group with On-Demand instances and multiple instance types, place the larger instance types higher in the priority list and don't specify a weight. Specifying a weight is not supported at this time. For more information, see Auto Scaling groups with multiple instance types in the AWS Auto Scaling User Guide.

  • When creating a service, specifying a task placement strategy that spreads across Availability Zones or a binpack strategy based on CPU or memory works best. Don't use an instance spread strategy as scaling works slower with that strategy type.

  • The desired capacity for the Auto Scaling group associated with a capacity provider shouldn't be changed or managed by any scaling policies other than the one Amazon ECS manages.

Managed scale-out behavior

When using Auto Scaling group capacity providers with managed scaling enabled, Amazon ECS estimates the lower bound on the optimal number of instances to add to your cluster and uses this value to determine how many instances to request. The following describes the scale-out behavior in more detail.

  1. Group all of the provisioning tasks so that each group has the same exact resource requirements.

  2. When multiple instance types are used, the instances in the Auto Scaling group are sorted by their attributes, such as vCPU, memory, elastic network interface (ENI), ports, and GPUs and the largest instance types for each attribute are selected.

  3. For each group of tasks, the number of instances required to run the unplaced tasks is calculated. This calculation uses a strategy which accounts for the vCPU, memory, elastic network interfaces (ENI), ports, and GPUs requirements of the tasks and the resource availability of the Amazon EC2 instances. This value will be treated as the maximum calculated instance count.

    Note

    This calculation takes into account any task placement constraints that are defined, but we recommend only using the task placement constraint.

  4. Amazon ECS will then launch either the , if the maximum calculated instance count is less than the minimum scaling step size, or the lower of either the or the maximum calculated instance count value.

For a more detailed explanation of how this logic works, see Deep dive on Amazon ECS cluster auto scaling.

Document Conventions

Deleting an Auto Scaling group capacity provider

Using Local Zones, Wavelength Zones, and AWS Outposts

Sours: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-auto-scaling.html

Cluster autoscaling ecs

Tutorial: Using cluster auto scaling with the AWS Management Console

This tutorial walks you through creating the resources for cluster auto scaling using the AWS Management Console. Where resources require a name, we will use the prefix to ensure they all have unique names and to make them easy to locate.

Prerequisites

This tutorial assumes that the following prerequisites have been completed:

Step 1: Create an Amazon ECS cluster

Use the following steps to create an Amazon ECS cluster. This tutorial uses an empty cluster so that we can manually create the Auto Scaling resources. When you use the AWS Management Console to create a non-empty cluster, Amazon ECS creates an AWS CloudFormation stack along with Auto Scaling resources. We want to avoid creating this AWS CloudFormation stack when using the cluster auto scaling feature.

To create an empty cluster

  1. Open the Amazon ECS console at https://console.aws.amazon.com/ecs/.

  2. On the navigation bar at the top of the screen, select the US West (Oregon) Region.

  3. In the navigation pane, choose Clusters.

  4. On the Clusters page, choose Create Cluster.

  5. For Select cluster compatibility, choose EC2 Linux + Networking and then choose Next step.

  6. For Cluster name, enter for the cluster name.

  7. Select Create an empty cluster and then choose Create.

Step 2: Create the Auto Scaling resources

Use the following steps to create an Amazon EC2 launch template and Auto Scaling group.

To create an Amazon EC2 launch template

  1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.

  2. On the navigation bar at the top of the screen, select the US West (Oregon) Region.

  3. On the navigation pane, under Instances, choose Launch Templates.

  4. On the next page, choose Create launch template.

  5. On the Create launch template page, complete the following steps.

    1. For Launch template name, enter .

    2. For Template version description, provide a description for the launch template.

    3. For Amazon Machine Image (AMI), search for the latest Amazon ECS-optimized AMI. The AMI ID can be retrieved using the following link: View AMI ID. For more information, see Retrieving Amazon ECS-Optimized AMI metadata.

    4. For Instance type, select an instance type. For the purposes of this tutorial, the instance type works.

    5. For Security groups, select one or more security groups.

    6. Expand the Advanced Details section to specify the IAM instance profile and user data for your Amazon ECS container instances.

      1. For IAM instance profile, select your container instance IAM role. For more information, see Amazon ECS container instance IAM role.

      2. For User data, paste the following script into the field. The cluster was created in the first step.

  6. Choose Create launch template.

Next, create an Auto Scaling group using that launch template.

To create an Auto Scaling group

  1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.

  2. On the navigation bar at the top of the screen, select the US West (Oregon) Region.

  3. On the navigation pane, under Auto Scaling, choose Auto Scaling Groups, Create Auto Scaling group.

  4. On the Create Auto Scaling group page, complete the following steps.

    1. For Auto Scaling group name, enter for the Auto Scaling group name.

    2. For Launch template, select the launch template.

    3. Review the contents of the launch template, then choose Next.

    4. On the Configure settings step, under Network, select a VPC and one or more Subnets to use and then choose Next.

    5. On the Configure advanced options step, choose Next.

    6. On the Configure group size and scaling policies step, for Desired capacity, enter . This tutorial uses Amazon ECS managed scaling so there is no need to have the Auto Scaling group launch any initial instances. For Minimum capacity, enter . For Maximum capacity, enter .

    7. For Instance scale-in protection, select Enable instance scale-in protection and then choose Next. This enables you to use managed termination protection for the instances in the Auto Scaling group, which prevents your container instances that contain tasks from being terminated during scale-in actions.

    8. On the Add notifications and Add tags steps, choose Next.

    9. On the Review step, review the Auto Scaling group settings and then choose Create Auto Scaling group.

  5. Repeat steps 3 and 4 to create a second Auto Scaling group. For Auto Scaling group name use and when setting the group size, set the Desired capacity and Minimum capacity to and the Maximum capacity to .

Step 3: Create a capacity provider

Use the following steps to create an Amazon ECS capacity provider. See for more information.

To create a capacity provider

  1. Open the Amazon ECS console at https://console.aws.amazon.com/ecs/.

  2. On the navigation bar at the top of the screen, select the US West (Oregon) Region.

  3. In the navigation pane, choose Clusters.

  4. On the Clusters page, select your cluster.

  5. On the Capacity Providers tab, choose Create.

  6. On the Create Capacity Provider page, complete the following steps.

    1. For Capacity provider name, enter for the name.

    2. For Auto Scaling group, select the Auto Scaling group you created.

    3. For Managed scaling, choose Enabled. This enables Amazon ECS to manage the scale-in and scale-out actions for the capacity provider.

    4. For Target capacity %, enter .

    5. For Managed termination protection, choose Enabled. This prevents your container instances that contain tasks and that are in the Auto Scaling group from being terminated during a scale-in action.

    6. Choose Create.

    7. Choose View in cluster to see your new capacity provider.

    8. Repeat steps 4 to 6, creating a second capacity provider with name with your Auto Scaling group.

Step 4: Set a default capacity provider strategy for the cluster

When running a task or creating a service, the Amazon ECS console uses the default capacity provider strategy for the cluster. The default capacity provider strategy can be defined by updating the cluster.

To define a default capacity provider strategy

  1. Open the Amazon ECS console at https://console.aws.amazon.com/ecs/.

  2. On the navigation bar at the top of the screen, select the US West (Oregon) Region.

  3. In the navigation pane, choose Clusters.

  4. On the Clusters page, select your cluster.

  5. On the Cluster : ConsoleTutorial-cluster page, choose Update Cluster.

  6. For Default capacity provider strategy choose, Add provider.

  7. Select your capacity provider.

  8. Choose Add provider, select your capacity provider.

  9. For Provider 1, leave the Base value at and leave the Weight value at .

  10. Choose Update. This will add the capacity providers to the default capacity provider strategy for the cluster.

  11. Choose View cluster.

Step 5: Register a task definition

Before you can run a task on your cluster, you must register a task definition. Task definitions are lists of containers grouped together. The following example is a simple task definition that uses an image from Docker Hub and simply sleeps. For more information about the available task definition parameters, see Amazon ECS task definitions.

To register a task definition

  1. Open the Amazon ECS console at https://console.aws.amazon.com/ecs/.

  2. On the navigation bar at the top of the screen, select the US West (Oregon) Region.

  3. In the navigation pane, choose Task Definitions, Create new Task Definition.

  4. On the Create new Task Definition page, select EC2, Next step.

  5. Choose Configure via JSON and copy and paste the following contents and then choose Save, Create.

Step 6: Run a task

After you have registered a task definition for your account, you can run a task in the cluster. For this tutorial, you run five instances of the task definition in your cluster.

To run a task

  1. Open the Amazon ECS console at https://console.aws.amazon.com/ecs/.

  2. On the navigation bar at the top of the screen, select the US West (Oregon) Region.

  3. In the navigation pane, choose Task Definitions.

  4. Select your ConsoleTutorial-taskdef task definition.

  5. From the Actions menu, choose Run Task.

  6. Use the following steps to complete the run task workflow.

    1. For Capacity provider strategy, the default capacity provider strategy for the cluster must be selected.

    2. For Cluster, select your ConsoleTutorial-cluster cluster.

    3. For Number of tasks, enter .

    4. For Placement Templates, choose BinPack.

    5. Choose Run Task.

Step 7: Verify

At this point in the tutorial, you should have two Auto Scaling groups with one capacity provider for each of them. The capacity providers have Amazon ECS managed scaling enabled. A cluster was created and five tasks are running.

We can verify that everything is working properly by viewing the CloudWatch metrics, the Auto Scaling group settings, and finally the Amazon ECS cluster task count.

To view the CloudWatch metrics for your cluster

  1. Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.

  2. On the navigation bar at the top of the screen, select the US West (Oregon) Region.

  3. On the navigation pane, choose Metrics.

  4. On the All metrics tab, choose .

  5. Choose CapacityProviderName, ClusterName.

  6. Choose the metric that corresponds to the ConsoleTutorial-capacityprovider capacity provider.

  7. On the Graphed metrics tab, change Period to 30 seconds and Statistic to Maximum.

    The value displayed in the graph shows the target capacity value for the capacity provider. It should begin at , which was the target capacity percent we set. You should see it scale up to , which will trigger an alarm for the target tracking scaling policy. The alarm will then trigger the Auto Scaling group to scale out.

  8. Steps 5 to 6 can be repeated for your ConsoleTutorial-capacityprovider-burst metric.

Use the following steps to view your Auto Scaling group details to confirm that the scale-out action occurred.

To verify the Auto Scaling group scaled out

  1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.

  2. On the navigation bar at the top of the screen, select the US West (Oregon) Region.

  3. On the navigation pane, under Auto Scaling, choose Auto Scaling Groups.

  4. For each of your Auto Scaling groups, view the values in the Instances and Desired columns to confirm your group scaled out to two instances for each group.

Use the following steps to view your Amazon ECS cluster to confirm that the Amazon EC2 instances were registered with the cluster and your tasks transitioned to a status.

To verify the Auto Scaling group scaled out

  1. Open the Amazon ECS console at https://console.aws.amazon.com/ecs/.

  2. On the navigation bar at the top of the screen, select the US West (Oregon) Region.

  3. In the navigation pane, choose Clusters.

  4. On the Clusters page, select your cluster.

  5. On the ECS Instances tab, confirm you see four instances registered, which matches your Auto Scaling group values.

  6. On the Tasks tab, confirm you see five tasks in status.

Step 8: Clean up

When you have finished this tutorial, clean up the resources associated with it to avoid incurring charges for resources that you aren't using. Deleting capacity providers and task definitions are not supported, but there is no cost associated with these resources.

To clean up the tutorial resources

  1. Open the Amazon ECS console at https://console.aws.amazon.com/ecs/.

  2. On the navigation bar at the top of the screen, select the US West (Oregon) Region.

  3. In the navigation pane, choose Clusters.

  4. On the Clusters page, select your cluster.

  5. From the Tasks tab, choose Stop All. Enter the verification and choose Stop all again.

  6. Delete the Auto Scaling groups using the following steps.

    1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.

    2. On the navigation bar at the top of the screen, select the US West (Oregon) Region.

    3. On the navigation pane, under Auto Scaling, choose Auto Scaling Groups.

    4. Select your ConsoleTutorial-ASG Auto Scaling group, then from the Actions menu choose Delete.

    5. Select your ConsoleTutorial-ASG-burst Auto Scaling group, then from the Actions menu choose Delete.

  7. Open the Amazon ECS console at https://console.aws.amazon.com/ecs/.

  8. On the navigation bar at the top of the screen, select the US West (Oregon) Region.

  9. In the navigation pane, choose Clusters.

  10. On the Clusters page, select your cluster.

  11. Choose Delete Cluster, enter the confirmation phrase, and choose Delete.

Document Conventions

Tutorial: Creating a VPC

Tutorial: Specifying sensitive data using Secrets Manager secrets

Sours: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/tutorial-cluster-auto-scaling-console.html
Kubernetes cluster autoscaling for beginners

Scaling ECS Workloads

There are different approaches for scaling a system. Traditionally systems have used, what we call an Infrastructure First approach, where the system focuses on infrastructure metrics such as CPU or Memory usage, and scales up the cluster infrastructure. In this case the application scales up following the metrics derived from the infrastructure.

While you can still use that approach on ECS, ECS follows an Application First scaling approach, where the scaling is based on the number of desired. ECS has two type of scaling activities:

  • ECS Service / Application Scaling: This refers to the ability to increase or decrease the desired count of tasks in your Amazon ECS service based on dynamic traffic and load patterns in the workload. Amazon ECS publishes CloudWatch metrics with your service’s average CPU and memory usage. You can use these and other CloudWatch metrics to scale out your service (add more tasks) to deal with high demand at peak times, and to scale in your service (run fewer tasks) to reduce costs during periods of low utilization.

  • ECS Container Instances Scaling: This refers to the ability to increase or decrease the desired count of EC2 instances in your Amazon ECS cluster based on ECS Service / Application scaling. For this kind of scaling, it is typical practice depending upon Auto Scaling group level scaling policies.

To scale the infrastructure using the Application First approach on ECS, we will use Amazon ECS cluster Capacity Providers to determine the infrastructure in use for our tasks and we will use Amazon ECS Cluster Auto Scaling (CAS) to enables to manage the scale of the cluster according to the application needs.

Capacity Providers configuration include:

  • An Auto Scaling Group to associate with the capacity provider. The Autoscaling group must already exist.
  • An attribute to enable/disable Managed scaling; if enabled, Amazon ECS manages the scale-in and scale-out actions of the Auto Scaling group through the use of AWS Auto Scaling scaling plan also referred to as Cluster Auto Scaling (CAS). This also means you can scale up your ECS cluster zero capacity in the Auto Scaling group.
  • An attribute to define the Target capacity %(percentage) - number between 1 and 100. When managed scaling is enabled this value is used as the target value against the metric used by Amazon ECS-managed target tracking scaling policy.
  • An attribute to define Managed termination protection. which prevents EC2 instances that contain ECS tasks and that are in an Auto Scaling group from being terminated during scale-in actions.

Each ECS cluster can have one or more capacity providers and an optional default capacity provider strategy. For an ECS Cluster there is a Default capacity provider strategy that can be set for Newly created tasks or services on the cluster that are created without an explicit strategy. Otherwise, for those services or tasks where the default capacity provider strategy does not meet your needs you can define a capacity provider strategy that is specific for that service or task.

You can read more about Capacity Provider Strategieshere

When enabling managed scaling Amazon ECS manages the scale-in and scale-out actions of the Auto Scaling group. This is what we call ECS Cluster Auto Scaling (CAS). CAS is a new capability for ECS to manage the scaling of EC2 Auto Scaling groups (ASG). CAS relies on ECS capacity providers.

Amazon ECS creates an AWS Auto Scaling scaling plan with a target tracking scaling policy based on the target capacity value you specify. Amazon ECS then associates this scaling plan with your Auto Scaling group. For each of the capacity providers with managed scaling enabled, an Amazon ECS managed CloudWatch metric with the prefix is created along with two CloudWatch alarms. The CloudWatch metrics and alarms used to monitor the container instance capacity in your Auto Scaling groups and will trigger the Auto Scaling group to scale in and scale out as needed.

The scaling policy uses a new CloudWatch metric called CapacityProviderReservation that ECS publishes for every ASG capacity provider that has managed scaling enabled. The new CloudWatch metric CapacityProviderReservation is defined as follows.

Where:

  • N represents the current number of instances in the Auto Scaling group(ASG) that are already running
  • M represents the number of instances running in an ASG necessary to meet the needs of the tasks assigned to that ASG, including tasks already running and tasks the customer is trying to run that don’t fit on the existing instances.

Given this assumption, if N = M, scaling out not required, and scaling in isn’t possible. If N < M, scale out is required because you don’t have enough instances. If N > M, scale in is possible (but not necessarily required) because you have more instances than you need to run all of your ECS tasks.The CapacityProviderReservation metric is a relative proportion of Target capacity value and dictates how much scale-out / scale-in should happen. CAS always tries to ensure CapacityProviderReservation is equal to specified Target capacity value either by increasing or decreasing number of instances in ASG.

The scale-out activity is triggered if > for 1 datapoints with 1 minute duration. That means it takes 1 minute to scale out the capacity in the ASG. The scale-in activity is triggered if CapacityProviderReservation < Target capacity for 15 data points with 1 minute duration. We will see all of this demonstrated in this workshop.

You can read more about ECS Cluster Auto Scaling (CAS) and how it works under different scenarios and conditions in this blog post

Sours: https://ec2spotworkshops.com/ecs-spot-capacity-providers/introduction/scaling_ecs_workloads.html

Similar news:

Scaling Container Clusters on AWS: ECS and EKS

Containers are a powerful tool to streamline your development and deployment process. However, a container cluster - no matter if you are using ECS (Elastic Container Service), EKS (Elastic Kubernetes Service), or self-managed Kubernetes - increases complexity. You are not only managing virtual machines anymore, but you are also operating containers on top of those virtual machines. Luckily, AWS offers a few approaches to minimize the effort of providing the computing capacity for your container cluster.

  • ECS with Cluster Auto Scaling
  • ECS with DIY Auto Scaling based on CloudWatch Events and Metrics
  • ECS on Fargate
  • EKS with Cluster Autoscaler and Managed Node Group
  • EKS on Fargate

I have taken a closer look at the different approaches. Read on to learn about differences and pitfalls.

Do you prefer listening to a podcast episode over reading a blog post? Here you go!

AWS Fargate

With Fargate, AWS offers a fully-managed and scalable container infrastructure. No need to manage virtual machines anymore. ECS and EKS launch containers on machines operated by AWS. Removing virtual machines from your architecture decreases complexity significantly. Therefore, I highly recommend using Fargate whenever possible.

However, there are a few reasons when using Fargate is not an option:

  • Fargate (EKS) is only available in 8 of 22 commercial regions.
  • Fargate (EKS) supports ALB as the only load balancer type.
  • Fargate offers a maximum of 4 vCPU and 30 GB memory per container.
  • Fargate does not provide specialized hardware (e.g., memory-optimized, storage-optimized, GPU, …)
  • Pricing options to reduce costs are limited, especially for Fargate (EKS).

What to do when using AWS Fargate is not an option?

ECS with Cluster Auto Scaling

AWS announced Cluster Auto Scaling for ECS in December 2019. A huge improvement, as there was no built-in way to scale the EC2 instance for an ECS cluster automatically before.

To get started, you need to create a capacity provider associated with the Auto Scaling Group that manages the EC2 instances forming your ECS cluster. On top of that, Cluster Auto Scaling writes a CloudWatch metric named , a target tracking scaling policy continually tries to achieve a capacity reservation of 100 by scaling out or in.

It is important to mention that the lifecycle for ECS tasks has been extended with the additional state . If there is not enough capacity within the cluster, an ECS task will stay in state . Next, the will cross the target of 100. Therefore, the target tracking scaling policy will increase the desired capacity of the Auto Scaling Group. A few minutes later, one or multiple EC2 instances will register at the ECS cluster.

Scaling in works the other way round. Overcapacity in the cluster will decrease the below the target of 100. Again, the target tracking scaling policy will kick in and reduces the desired capacity of the Auto Scaling Group.

This is where it gets tricky. The Cluster Auto Scaling sets the termination protection flag for all EC2 instances running at least one task (other than daemon tasks). Therefore, the Auto Scaling Group will not terminate an EC2 instance whenever this could cause a service interruption. The way the Cluster Auto Scaling scales in comes with two major problems:

  1. Cluster Auto Scaling does not mitigate fragmentation by moving tasks (a group of containers) to another EC2 instance. Therefore, you will waste a lot of money because the cluster does not scale in as much as possible.
  2. There is no way to roll out a new version of the ECS AMI. The termination protection breaks rolling updates of EC2 instances via CloudFormation.

Check out Deep Dive on Amazon ECS Cluster Auto Scaling when interested in more details.

In my opinion, those are two significant problems. That is why I came up with a do-it-yourself (DIY) auto-scaling approach.

Sours: https://cloudonaut.io/scaling-container-clusters-on-aws-ecs-eks/


1575 1576 1577 1578 1579