Upload
kimberly-macias
View
108
Download
2
Tags:
Embed Size (px)
Citation preview
Copyright 2015 Blue Chip Tek
AWS Auto Scalingpresented by BlueChipTek
web: bluechiptek.comtwitter: @bluechiptekphone: 408-731-7700
Copyright 2015 Blue Chip Tek
Who am I? DevOps Engineer and occasional ProgrammerWhat experience do I have? Lyft: ride-sharing startup in San Francisco NetShelter: multi-region ad-networkCertified? AWS Certified Solutions Architect, number 2564 AWS Certified SysOps, number 224Projects? Contributed some cool features to SaltStack project
Intro: Colin Johnson
Copyright 2015 Blue Chip Tek
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
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
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
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
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
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
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
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
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
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
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