1. A Pluggable Autoscaling
Service for Open Cloud
PaaS Systems
Chris Bunch Vaibhav Arora Navraj Chohan
Chandra Krintz Shashank Hedge Ankit Srivastava
UCC 2012 @ Chicago, IL
November 8, 2012
2. Cloud Computing
• Three tiers of abstraction:
• Infrastructure: Scalable hardware
• Platform: Scalable APIs
• Software: Scalable applications
3. 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
4. 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
5. Cloud Computing
• Infrastructure: Completely self-service
• Platform: Automated access to
certain APIs
• Software: Optimized for one piece of
software
6. 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
7. Role System
• Represent each component in the AppScale
stack as a “role”, which requires:
• Startup scripts
• Shutdown scripts
• Metric collection / storage
9. AppController + Roles
• AppController controls all other roles
• Automatically places roles on nodes
• Handles ordering dependencies
• Can scale based on role or node state
10. 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
11. 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
12. 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
13. 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
14. 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
17. 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
