A Pluggable Autoscaling System @ UCC
- 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
- 15. Python Guestbook
- 16. Java Guestbook
- 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