Skip to content

autoscaling 3.3 spec

Jump to bottom Edit New page
chris grzegorczyk edited this page Dec 14, 2012 · 10 revisions

Table of Contents

Overview

Feature consists of fundamental Autoscaling support implementing the AWS defined API. There are two primary use cases:

  1. Manual auto-scaling
  2. Action triggered auto-scaling based on custom metrics
Other important characteristics which are essential in serving these use cases are:
  1. Register/Deregister instances with ELB

Types of Scaling

For 3.3 we only consider two kinds of scaling:

  1. Manual : user controlled change to sizing of autoscaling group.
    1. SetDesiredCapacity allows the user to explicitly set the group size.
    2. ExecutePolicy allows the user to trigger the application of a scaling policy by hand.
  2. Alarm/Policy based: user configures metric-based actions which trigger application of a scaling policy.
    1. MetricAlarms configured using PutMetricAlarm act as triggers.
    2. AlarmActions reference the ScalingPolcicy relative to the fully qualified AutoScalingGroupARN.
  3. Second for 3.3
    1. Metric collection
    2. Scaling process control
  4. Excluded from 3.3
    1. Notifications
    2. Operations requiring VPC support
    3. Anything requiring support for spot instances
    4. Schedule based scaling is not part of the 3.3 implementation plan.
    5. Operations needed for schedule based scaling must still be present and Describe operations must successfully return an empty response. This is needed to avoid breaking client tools.

API Operations

  • Required operations in topological order
    • Operations for definiton a group
      • {Create,Describe,Update,Delete}AutoScalingGroup
    • Running and health checking an instance in the group

Service Interactions

Client Tools

Components

Launch Configuration

  • Describes how to add instances instances
    • AMI
    • Instance Type
    • Security Group
    • Instance Key Pair
  • Only one active launch configuration at a time
  • Auto Scaling will terminate instances with old launch configurations first
    • Rolling software updates

Auto Scaling Group

Auto Scaling managed grouping of EC2 instances Automatic health check to maintain pool size Automatically scale the number of instances by policy Min, Max, Desired Automatic Integration with ELB Automatic Integration with AZs Automatic distribution & balancing across AZs

Auto Scaling Policy

Parameters for performing an Auto Scaling action Scale Up/Down By how much ChangeInCapacity (+/- #) ExactCapacity (#) ChangeInPercent (+/- %) Cool Down (seconds) Policy can be triggered by CloudWatch Events

Cloud Watch Alarms

Monitors a CloudWatch metric Threshold (> 50% CPU) Period (for 3 minutes) Alarm States OK - Within defined threshold ALARM - Outside defined threshold INSUFFICIENT_DATA - Metric does not have enough data to determine state Available Actions Trigger Auto Scaling Policy (scale up/down event) Send SNS notification

Scaling Activity

Instance Launch Instances are launched (not started) from a “gold” image  Bootstrapping is important!  Automatically added to ELB (if configured) Instance Termination Instances are terminated (not stopped)  Longest running instance from the oldest launch config first  Automatically removed from ELB (if configured) Cooldown The period after an Auto Scaling activity during which no other scaling activity can take place Gives the system time to perform and adjust to before executing a new scaling activity 300 seconds (5 minutes) by default Suspend/Resume Processes Allows you to manually suspend and resume Auto Scaling activities

Operation Parameters

See autoscaling-3.3-api-parameters

Testing Plan

Footnotes

    tag:rls-3.3
    Add a custom footer
    • Contact Info
    Clone this wiki locally