ECS scaling

 


ECS Cluster Auto Scaling (CAS) is a new capability for ECS to manage the scaling of EC2 Auto Scaling Groups (ASG). 

CAS relies on ECS capacity providers, which provide the link between your ECS cluster and the ASGs

Each ASG is associated with a capacity provider, and each such capacity provider has only one ASG, but many capacity providers can be associated with one ECS cluster. In order to scale the entire cluster automatically, each capacity provider manages the scaling of its associated ASG.

Design goal #1: CAS should scale the ASG out (adding more instances) whenever there is not enough capacity to run tasks the customers is trying to run.

Design goal #2: CAS should scale in (removing instances) only if it can be done without disrupting any tasks (other than daemon tasks).

Design goal #3: customers should maintain full control of their ASGs, including the ability to set the minimum and maximum size, use other scaling policies, configure instance types, etc.

Uses ECS life cycle state provisioning to indicate there are no ec2 instances to launch task.

Uses some optimisation to find out how many ec2 instances to launch.

Capacity reservation metric = # of tasks currently running + waiting to run/ # currently running * 100

= M/N *100

If M < N possibility of scale in only if some instances are not running any task except daemon task

If M>N need to scale out


https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/




Comments

Post a Comment

Popular posts from this blog

ECS

  https://medium.com/boltops/ gentle-introduction-to-how- aws-ecs-works-with-example- tutorial-cea3d27ce63d Cluster creation : Template type - Networking only (Fargate), EC2 type Roles Task execution IAM role , this role helps to pull images from your docker registery Task Role - for accessing AWS services  Service creation Type - Fargate/EC2 Type - Replica No of task instances  Min, Max num of healthy instances  Service Auto Scaling is made possible by a combination of the Amazon ECS, CloudWatch, and Application Auto Scaling APIs. Services are created and updated with Amazon ECS, alarms are created with CloudWatch, and scaling policies are created with Application Auto Scaling. Application Auto Scaling turns off scale-in processes while Amazon ECS deployments are in progress. However, scale-out processes continue to occur, unless suspended, during a deployment. Target tracking, step, schedule scaling supported More complex explanation  https://docs.aws. amazon.com/AmazonECS/latest/ d
Read more

RDS

    Multi-AZ DB instance deployment . - one standby instance , but doesn’t serve reads.  The primary DB instance is synchronously replicated across Availability Zones to a standby replica.  can have increased write and commit latency compared to a Single-AZ deployment. This can happen because of the synchronous data replication that occurs. You might have a change in latency if your deployment fails over to the standby replica, although AWS is engineered with low-latency network connectivity between Availability Zones. For production workloads, we recommend that you use Provisioned IOPS (input/output operations per second) for fast, consistent performance Multi-AZ DB cluster deployment . - multiple standby instance ,  serve reads
Read more

DKIM and OCI Email

DKIM stands for Domain Key Identified Mail. It allows an organization to take responsbility to sign emails sent from its domains. It uses pub/private key to sign and allow receiver to verify the authenticity of the email. It prevent mail spoofing and proliferation attacks. OCI email delivery allows to configure DKIMs for email domains.When DKIM is created, it generates a CNAME record to be used in email domain configuraiton. Email Configuration Create a User and generate SMTP Credentials for that user. This user/credentials is used to login to the SMTP server. Create an approved sender in the Email Domain. This will be the from address. Attach a DKIM to the sender/domain.
Read more