A Pluggable Autoscaling Service for Open Cloud

PaaS SystemsChris Bunch Vaibhav Arora Navraj Chohan

Chandra Krintz Shashank Hedge Ankit Srivastava

UCC 2012 @ Chicago, ILNovember 8, 2012

Cloud Computing

• Three tiers of abstraction:

• Infrastructure: Scalable hardware

• Platform: Scalable APIs

• Software: Scalable applications

Autoscaling Cloud Services

• Easy access to vast resources

• Hard to automatically configure and deploy applications

• Requires in-depth knowledge about the app

• Lots of existing research on autoscaling

• Most solutions scale on coarsely-defined metrics

Solving these Problems

• No one solution works for all applications

• Need a “pluggable” system that users can experiment with, via existing or new autoscaling algorithms

• Need to automate scaling up and down for distributed software stacks

Cloud Computing

• Infrastructure: Completely self-service

• Platform: Automated access to certain APIs

• Software: Optimized for one piece of software

AppScale

• An open source implementation of the Google App Engine APIs

• Can run over Amazon EC2 or Eucalyptus

• Configures and deploys automatically

• Users need only specify the number of nodes to run over

Role System

• Represent each component in the AppScale stack as a “role”, which requires:

• Startup scripts

• Shutdown scripts

• Metric collection / storage

AppScale Roles

AppController + Roles

• AppController controls all other roles

• Automatically places roles on nodes

• Handles ordering dependencies

• Can scale based on role or node state

Scaling in a PaaS

• Can scale based on SaaS or PaaS-level info:

• SaaS-level: Application statistics

• API usage, request latency

• PaaS-level: Role or node statistics

• # of roles/nodes alive, failure history

High Availability

• AppControllers periodically check in w/Metadata service

• Any AppController missing their check in has failed

• Next AppController spawns a new node with roles of the failed node

Quality of Service

• Load Balancer checks in with Metadata service with:

• # of requests per app

• # of queued requests per app

• Estimate these values for next check in

• Scale up or down if predictions exceed customizable thresholds

Cost Awareness

• Amazon EC2 meters on a per-hour basis

• Scaling down => hot spares

• Scaling up => use hot spares first

• Reap VMs near the hour boundary

• Use Spot Instances to save money

Evaluation Methodology

• Python / Java Guestbook apps from Google

• Three-tier web deployment model

• Three virtual machines

• 40,000 web requests (70 concurrently)

• All values are the average of five runs

Python Guestbook

Java Guestbook

Wrapping it up

• Thanks to the AppScale team, especially co-lead Navraj Chohan and advisor Chandra Krintz

• AppScale 1.6.3 released on October 30

• Visit us at http://appscale.cs.ucsb.edu

• E-mail: cgb@cs.ucsb.edu