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
- 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
- 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
- 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
- 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
- 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?)
- 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
- 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.
- Reference:
http://aws.amazon.com/autoscaling/
- Reference:
http://aws.amazon.com/autoscaling/
- As far as I know, I built the first tool to do this.