Sunday, 11 February 2018

AWS EC2(Spot)

Overview
  • Opportunity to reduce EC2 costs by running on unused AWS capacity

Spot pool (capacity pool)
  • Set of instances with the same:
    • AZ
    • instance type
    • instance size
    • misc
      • OS
      • network platform (EC2-Classic or EC2-VPC)
  • Each pool has its own number of instances available
  • AWS continuously monitors it and updates spot price
  • Shared between on-demand instances and spot instances

Pricing
  • fluctuates (infrequently) based on supply/demand
  • you pay actual price (often lower than your bid)
  • everyone pays the same price
  • partial hours
    • not billed when interrupted (i.e. last hour is free)
    • billed when terminated by customer (i.e. last hour is paid)

Interruption
  • AWS reclaims the instance back
  • Application should be fault tolerant (must be prepared)
  • Does not happen very often
  • Can hibernate
    • Memory is flushed to disk (just like laptop)
    • Started again when capacity is available
  • When
    • (obsolete) bid price < market price
    • Capacity: not enough unused instances
      • on-demand have priority
    • Constraints: e.g. launch group or AZ can no longer be met
  • How
    • 2 minute termination notice
    • can be retrieved via metadata 
    • CloudWatch Event


Spot fleet
  • Fleet of spot instances managed by AWS
  • Spot fleet request
    • Target capacity (how many instances you want)
    • Launch Specifications 
    • ValidFrom
    • ValidUntil
  • EC2 tries to maintain target capacity by looking at all specifications (spot pools) and give most economical combination
  • Resource-oriented
    • Specify weights for instance types ("capacity units" for whatever you are after: CPU, memory, bandwidth, TPS)
      • WeightedCapacity how many capacity units instance types contributes to the fleet
        • "I am OK to pay 2x more for r3.xlarge than for r3.large"
        • "Spot: each instance is worth number of vCPUs. Now, fetch me 1000 vCPUS"
  • Can use different instance types (better chances of getting bid price on at least one type)
  • Allocation strategy
    • lowestPrice - use spot pool with lowest price 
      • good for small fleets that are short running (minimizes cost)
      • "puts all your eggs in one basket"
    • diversified - distirbute across many spot pools 
      • good for large fleets that are long running (minimizes interruptions)
  • Best practices (stock market)
    • Older generations have more stable pricing
    • Use multiple capacity pools
  • Data feed
    • log of spot usage provided

Spot request (obsolete)
  • spot price - current market price (lowest fulfilled bid)
  • constraints (optional)
    • launch group
      • instances launched and terminated together 
      • if AWS has to terminate it will terminate whole group 
      • if you terminate yourself the rest stays
    • availability zone group     
      • all instances in the same group
      • if AWS has to terminate it will not terminate the whole group (unlike launch group)
  • AZ selection
    • EC2-Classic: any AZ with lowest bid
    • Default VPC - chosen subnet and its AZ (or if not specified chooses subnet itself, but may not be the cheapest)
    • Nondefault VPC - chosen subnet
  • Spot instance request
    • bid price, instance count, launch specification, one time | persistent, ValidFrom, ValidUntil
    • status: open, active (fulfilled), failed (bad parameters), closed (interrupted OR terminated), canceled

Spot bid (obsolete)
  • how much (at most) you are willing to pay for an instance
  • you get instance when your bid price > market price
  • one-time
  • persistent (automatically resubmitted when spot instance terminates)
  • obsolete (no need to specify it anymore)

References

No comments:

Post a Comment