Aws Autoscaling
Download as PPTX, PDF2 likes1,429 views
The document provides an overview of AWS Auto Scaling, highlighting its benefits, challenges, and integration with other AWS services. It outlines key concepts such as regions, availability zones, auto scaling groups, and launch configurations while also offering best practices for implementation. The presenter, Colin Johnson of Blue Chip Tek, shares insights based on his experience as a DevOps engineer, emphasizing the importance of managing dynamic infrastructure effectively.
Aws Autoscaling
- 1. AWS Auto Scaling presented by BlueChipTek web: bluechiptek.com twitter: @bluechiptek phone: 408-731-7700 Copyright 2015 Blue Chip Tek
- 2. Who am I? DevOps Engineer and occasional Programmer What experience do I have? Lyft: ride-sharing startup in San Francisco NetShelter: multi-region ad-network Certified? AWS Certified Solutions Architect, number 2564 AWS Certified SysOps, number 224 Projects? Contributed some cool features to SaltStack project Intro: Colin Johnson Copyright 2015 Blue Chip Tek
- 3. Understand use cases for Auto Scaling Understand benefits and drawbacks of Auto Scaling Determine if and where Auto Scaling a fit for existing Infrastructure Implement Auto Scaling! Objectives Copyright 2015 Blue Chip Tek
- 4. A Quick AWS Introduction (as is relevant to Auto Scaling) Copyright 2015 Blue Chip Tek
- 5. Regions: 9 Available Regions (as of April, 2015) Costs are Different in Each Region (~50% difference between lowest/most expensive EC2 instance) Use Regions to Meet Availability, Compliance or Performance Requirements Availability Zones: Each Availability Zone is Isolated, typically 3-4 AZs per-region Meet Availability or Scalability Requirements Regions and Availability Zones Copyright 2015 Blue Chip Tek
- 6. AWS: Global Regions Copyright 2015 Blue Chip Tek
- 7. Example: Multi-AZ Architecture us-west-2 us-west-2bus-west-2a Internet Load Balancer Multi-AZ Auto Scaling Group Multi-AZ Database Multi-AZ wwwlb-prod01 www-prod01 www-prod01wwwlb-prod01 db-prod01 db-prod01 Mobile Client Client Copyright 2015 Blue Chip Tek
- 8. Example: Multi-AZ Architecture during Failure Copyright 2015 Blue Chip Tek
- 9. March, 2006 – S3 Launched August, 2006 – EC2 Beta Launched October, 2007 – EC2 “Large and Extra Large” Instances March, 2008 – Availability Zones October, 2008 – EC2 Officially Released May, 2009 – AWS Console Launched May, 2009 – Auto Scaling Released December, 2013 – Auto Scaling added to AWS Console AWS and Auto Scaling: Timeline Copyright 2015 Blue Chip Tek
- 10. Provides Elasticity and Scalability Respond to changes in demand by scaling in/out EC2 servers. Scale manually, automatically or on schedule Automatic scaling based on CloudWatch Metrics Provides Availability Spreads Instances across Availability Zones Eliminate outages as result of changes in demand Terminate and rebuild failed nodes automatically Cost: “pay for what you need” or utilize “Spot” instances Auto Scaling: Benefits Copyright 2015 Blue Chip Tek
- 11. Dynamic infrastructure creates challenges: Monitoring Tools Log File Collection and Analysis Changing IP Addresses/Ranges Applications saving “State” on Terminated Servers Applications may require modification to work with Auto Scaling Auto Scaling: Challenges Copyright 2015 Blue Chip Tek
- 12. AWS Auto Scaling (the Details) Copyright 2015 Blue Chip Tek
- 13. An Auto Scaling Group has the following attributes: Min Size Max Size Desired Capacity Health Check Type (EC2 or ELB) Associated Load Balancers LaunchConfiguration Provides Instance Type, AMI ID, User Data Auto Scaling: Attributes Copyright 2015 Blue Chip Tek
- 14. A Launch Configuration tells an Auto Scaling Group About the Instance to Launch. Example attributes: ImageID (aka AMI) InstanceType KeyName SecurityGroups Spot Price User-Data Auto Scaling: Launch Configuration Copyright 2015 Blue Chip Tek
- 15. Tags applied on an “Auto Scaling Group” are also applied to instances Tag with “Application”, “Environment”, “Owner” to enable reporting and easier AWS Administration Tags are “Eventually Consistent” for Instances Create an instance as part of “web-prod01” and the instance may not get that tag immediately Auto Scaling: Tags Copyright 2015 Blue Chip Tek
- 16. Auto Scaling is designed to be used with other AWS Services: Elastic Load Balancing for routing Inbound requests SQS for dispatching messages/work to ephemeral EC2 Servers CloudWatch for controlling scale/up events Auto Scaling: Typical Design Copyright 2015 Blue Chip Tek
- 17. Auto Scaling and ELB Copyright 2015 Blue Chip Tek
- 18. Auto Scaling and SQS Copyright 2015 Blue Chip Tek
- 19. Use CloudFormation to provision Auto Scaling Groups Auto Scaling Groups are challenging to build manually Auto Scaling Groups don’t support easy “Launch Configuration” modifications* Auto Scaling is Integrated with or Used By: CodeDeploy (for getting code onto instances) Elastic Load Balancers? Sure seems like it… Elastic Beanstalk EC2 Container Service (optional, but recommended) Integration with other AWS Services Copyright 2015 Blue Chip Tek
- 20. AWS Auto Scaling (Live Demo) Copyright 2015 Blue Chip Tek
- 21. Use all Availability Zones AWS may “deny” the ability to launch an instance in an AZ if over capacity Ship all data off instances as quickly as possible Avoid use of Lifecycle Hooks if Possible Create groups of 1 Instance If errors arise, terminate instance and rebuild Over-provision by 1 node until Scaling policy well understood Keep Auto Scaling Rules Simple Auto Scaling: Best Practices Copyright 2015 Blue Chip Tek
Editor's Notes
- #6: Regions: Costs: as of April 2015, difference between us-west-2 and sa-east-1 not all Services Available in All Regions: http://aws.amazon.com/about-aws/global-infrastructure/regional-product-services Availability Zones: Availability Zones aid in meeting availability requirements: A majority of AWS failures occur only in one AZ Availability Zones are Isolated from one another (http://aws.amazon.com/ec2/faqs/ - How isolated are Availability Zones from one another?)
- #8: Slide is a representation of a highly available, multi-AZ architecture. The Load Balancer is run in both the us-west-2a and us-west-2b Availability Zones The Auto Scaling Group is also run in both the us-west-2a and us-west-2b Availability Zones. The Multi-AZ RDS Database runs in both us-west-2a and us-west-2b
- #9: Slide is a representation of the result of a us-west-2a Failure: The ELB will most likely stop making the IP address(es) of the instances in the us-east-2a availability zone available, at which point clients will begin sending to alternative IP addresses (there are exceptions) The Auto Scaling Group will notice that the capacity of the Auto Scaling Group has dropped from 2 EC2 instances to 1 EC2 instance, and will respond by increasing the number of instances in the us-east-2b availability zone. The RDS instance will failover to the standby node in the us-west-2b availability zone.
- #10: Reference: http://aws.amazon.com/autoscaling/
- #11: Reference: http://aws.amazon.com/autoscaling/
- #20: As far as I know, I built the first tool to do this.