AppScale Talk at SBonRails

The AppScale ProjectPresented by Chris Bunch

(on behalf of the AppScale team)March 7, 2011 @ sbonrails meetup

Thursday, March 10, 2011

Overview

• Google App Engine

• AppScale - now with 50% Ruby!

• Research Directions

• Neptune - A Ruby DSL for the cloud


Google App Engine

• A web framework introduced in 2008

• Python and Java supported

• Offers a Platform-as-a-Service: Use Google’s APIs to achieve scale

• Upload your app to Google


Quotas


Data Model

• Not relational - semi-structured schema

• Compare to models in Rails

• Exposes a get / put / delete / query interface


Storing Data

• Datastore API - Persistent storage

• Memcache API - Transient storage

• User can set expiration times

• Blobstore API - Store large files

• need to enable billing to use it


Be Social!

• Mail API - Send and receive e-mail

• XMPP API - Send and receive IMs

• Channel API - Creating persistent connections via XMPP

• Use for chat rooms, games, etc.


Background Tasks

• Cron API - Access a URL periodically

• Descriptive language: “every 5 minutes”, “every 1st Sun of Jan, Mar, Dec”, etc.

• Uses a separate cron.yaml file

• Taskqueue API - Within your app, fire off tasks to be done later


Dealing with Users

• Users API: Uses Google Accounts

• Don’t write that ‘forgot password’ page ever again!

• Authorization: via app.yaml:

• anyone, must login, or admin only


When Services Fail

• Originally: failures throw exceptions

• Just catch them all!

• Capabilities API: Check if a service is available

• Datastore, Memcache, and so on


Deploying Your App

• Develop locally on SDK

• Stub implementations of most APIs

• Then deploy to Google


How to Scale

• Limitations on the programming model:

• No filesystem interaction

• 30 second limit per web request

• Language libraries must be on whitelist

• Sandboxed execution


Enter AppScale

• App Engine is easy to use

• but we really want to tinker with the internals!

• Need an open platform to experiment on

• test API implementations

• add new APIs


Enter AppScale

• Lots of NoSQL DBs out there

• Hard to compare DBs

• Configuration and deployment can be complex

• Need one-button deployment


Storing Data

• Datastore API - AppServers use a database agnostic layer - sends requests to PBServer

• Named for data format: Protocol Buffers

• Memcache API - memcached

• Blobstore API - Custom server


Be Social!

• Mail API - sendmail (disabled by default)

• XMPP API - ejabberd

• Channel API - strophejs


Background Tasks

• Cron API - Uses Vixie Cron

• Taskqueue - Separate thread fetches web page

• Both make a single attempt

• Will replace with distributed, fault-tolerant versions


Dealing with Users

• Users API: Defers users to AppLoadBalancer

• Password reset via command-line tools

• Authorization: no major changes here


Deploying Your App

• Develop locally on SDK

• Stub implementations of most APIs

• Then deploy to AppScale!

• Use your own cluster or via Amazon

• Command-line tools mirror Amazon’s


Deploying Your App

• run-instances: Start AppScale

• describe-instances: View cloud metadata

• upload-app: Deploy an App Engine app

• remove-app: Un-deploy an App Engine app

• terminate-instances: Stop AppScale


Deployment Models

• Cloud deployment: Amazon EC2 or Eucalyptus (the open source implementation of the EC2 APIs)

• Just specify how many machines you need

• Non-cloud deployment via Xen or KVM


AppController

• The brains of the outfit

• Runs on every node

• Handles configuration and deployment of all services (including other AppControllers)

• Written in Ruby


Load balancer

• Routes users to their app via nginx

• haproxy makes sure app servers are live

• Can’t assume the user has DNS:

• Thus we wrote the AppLoadBalancer

• Rails app that routes users to apps

• Performs authentication as well


AppLoadBalancer


App Server

• We modified the App Engine SDK

• Easier for Python (source included)

• Harder for Java (had to decompile)

• Removed non-scalable API implementations

• Goal: Use open source whenever possible


A Common Feature Request


Database Options

• Open source / open APIs / proprietary

• Master / slave v. peer-to-peer

• Differences in query languages

• Data model (key/val, semi-structured)

• In-memory or persistent

• Data consistency model

• Interfaces - REST / Thrift / libraries


In AppScale:

• BigTable clones:

• Master / slave relationship

• Master stores metadata

• Slaves store data

• Fault-tolerant to slave failure

• Partially tolerant to master failure


In AppScale:

• Variably consistent DBs

• Voldemort and

• Both are peer-to-peer: no SPOF

• Voldemort: Specify consistency per table

• Cassandra: Specify consistency per request


In AppScale:

• Relational:

• Not NoSQL but used like NoSQL

• Document-oriented:

• Targets append-heavy workloads


In AppScale:

• Key-value datastores:

• MemcacheDB: like memcached but persistent and replicated

• Scalaris: in-memory, no persistence

• SimpleDB: semi-structured but used as key-value (will update this in the future)


Research Ideas• Placement support

• Monitoring

• Shared memory

• Cost modeling

• Hybrid cloud

• Active Cloud DB

• Disaster Recovery

• Neptune


Placement Support


Monitr


Shared memory

• Since AppServer + DB are co-located, reduce message overhead

• no serialization

• Leverage CoLoRs to do so across languages

• AS is in Python or Java, DBS is Python

• Can be orders-of-magnitude faster


Cost modeling

• Can we reproduce Google’s cost model?

• We can reproduce memory, network bandwidth in / out, size and types of data

• Can’t reproduce CPU - it’s based on Google’s load, which we can’t capture

• varies based on placement and time of day


Hybrid Cloud


Database Agnostic Transactions

• Want to support disparate DBs with ACID

• Leverage ZooKeeper for versioning

• And PBServer as the DB agnostic layer

• Needs strong consistency from DB itself

• And row-level atomicity on updates


Active Cloud DB

• Need a common interface to DBs

• But not just for Java / Python

• Named after Rails’ ActiveRecord

• Exposes REST interface for DB

• Included in AppScale 1.3


Disaster Recovery

• People are using App Engine as a production level environment

• Need a way to automatically back up data

• Can leverage this data for data analytics

• Need to also seamlessly switch to AppScale version if App Engine version goes down


Neptune

• Need a simple way to run compute-intensive jobs

• We have the code from the ‘net

• We have the resources - the cloud

• But the average user does not have the know how

• Our solution: create a domain specific language for configuring cloud apps

• Based on Ruby


Syntax

• It’s as easy as:

neptune :type => “mpi”,

:code => “MpiNQueens”,

:nodes_to_use => 8,

:output => “/mpi/output-1.txt”


Neptune Supports:

• Message Passing Interface (MPI)

• MapReduce

• Unified Parallel C (UPC)

• X10

• Erlang


Extensibility

• Experts can add support for other computational jobs

• Biochemists can run simulations via DFSP and dwSSA

• Embarassingly parallel Monte Carlo simulations


Compiling Code

• You may not have the binaries, so compile from source!

• Auto-generates makefiles for beginners

neptune :type => “compile”,

:code => “/home/appscale/mpi_nqueens”


Installing Neptune

• Just use good old ‘gem’:

• gem install neptune

• Current version is 0.0.4, fully compatible with AppScale 1.5

• More info at our web page:

• http://neptune-lang.org


http://neptune-lang.org

http://neptune-lang.org

Wrapping It Up

• Thanks to the AppScale team, especially:

• Co-lead Navraj Chohan and advisor Professor Chandra Krintz

• Check us out on the web:

• http://appscale.cs.ucsb.edu

• http://code.google.com/p/appscale


http://appscale.cs.ucsb.edu

http://appscale.cs.ucsb.edu

http://code.google.com/p/appscale

http://code.google.com/p/appscale

AppScale Talk at SBonRails

Technology

Transcript of AppScale Talk at SBonRails