Lecture 6 – Cloud Application Development, using Google ... · Lecture 6 – Cloud Application...
Transcript of Lecture 6 – Cloud Application Development, using Google ... · Lecture 6 – Cloud Application...
Lecture 6 – Cloud Application Development, using Google App Engine as an example
922EU3870 – Cloud Computing and Mobile Platforms,
Autumn 2009 (2009/10/19)
http://code.google.com/appengine/
Ping Yeh (葉平 ), Google, Inc. [email protected]
2
Numbers real world engineers should know
L1 cache reference 0.5 ns
Branch mispredict 5 ns
L2 cache reference 7 ns
Mutex lock/unlock 100 ns
Main memory reference 100 ns
Compress 1 KB with Zippy 10,000 ns
Send 2 KB through 1 Gbps network 20,000 ns
Read 1 MB sequentially from memory 250,000 ns
Round trip within the same data center 500,000 ns
Disk seek 10,000,000 ns
Read 1 MB sequentially from network 10,000,000 ns
Read 1 MB sequentially from disk 30,000,000 ns
Round trip between California and Netherlands 150,000,000 ns
3
Web Applications and APIs
• A web application = a software that
– input: taken from HTTP and URL
– output: contained in HTML, sent via HTTP
• contained stuff: HTML, javascript, CSS, flash, etc
• A web API = a software that
– input: taken from HTTP and URL
– output: data in a format like XML or JSON sent via HTTP
• Not a clear cut
4
Instance
Layers of a Web Site
Hardware
Management
Provisioning,
accounting,
monitoring,
start/stop
servers,
...(optional) Virtual Machine
Operating System
Libraries
Application Software
Frontend / Routing
Reverse Proxy
• Software as a Service: The instance on a hardware, may or may not have elasticity
• Hosting service: allocation of hardware or virtual machines, no elasticity.
HTTP, URL HTTP, HTML
Elasticity
• Infrastructure as a Service (IaaS): hardware + Virtual Machine + Frontend/Routing + Management, with elasticity
• Platform as a Service: IaaS + OS + Libraries + Reverse Proxy
5
Designing a Web Application
WebApplication
FunctionUserExperience
Security
AvailabilityPerformance
Analysis &Admin
What does it do?• Your ideas here
What does it do?• Your ideas here
How to use it?• Flow• Simplicity• Interactivity• etc
How to use it?• Flow• Simplicity• Interactivity• etc
Is my data safe?• Encryption• Password
strength• Data replication• XSRF• Buffer overflow• Privacy measures• etc
Is my data safe?• Encryption• Password
strength• Data replication• XSRF• Buffer overflow• Privacy measures• etc
Is it available when I need it?
• Scalability• DDOS defense• Fault tolerance• Routing• etc
Is it available when I need it?
• Scalability• DDOS defense• Fault tolerance• Routing• etc
How long do I need to wait?
• Caching• Data organization• Static content• etc
How long do I need to wait?
• Caching• Data organization• Static content• etc
How to know user's behavior?
• Logs• Fast analysis
How to manage the app?
• Admin UI• Data {im|ex}port• Internal process
How to know user's behavior?
• Logs• Fast analysis
How to manage the app?
• Admin UI• Data {im|ex}port• Internal process Cloud service can help
6
Cloud Platforms
• IaaS: Amazon EC2 / S3 / SimpleDB, GoGrid, Sun, RackSpace Cloud, and others.
• Infrastructure software: Eucalyptus
• PaaS
– Engine Yard and Heroku: Ruby on Rails on EC2
– Force.com: for applications that run on salesforce.com
– Google App Engine: Python and Java on GFS / BigTable / Google's frontend
– Microsoft Azure: .NET on Microsoft's infrastructure
• Platform software: AppScale, Vertebra
7
Google App Enginehttp://code.google.com/appengine/
8
Google App Engine at a Glance
9
Design Motivations
• Build on Existing Google Technology
– Frontend, BigTable, GFS
• Provide an Integrated Environment
• Encourage Small Per-Request Footprints
• Encourage Fast, Efficient Requests
• Maintain Isolation Between Applications
• Encourage Statelessness and Specialization
• Require Partitioned Data Model (from BigTable)
10
Life of an App Engine Request
11
Routing
• Routed to the nearest Google datacenter
• Travels over Google's network
– Same infrastructure other Google products use
– Lots of advantages for free
12
Request for Static Content
Google App Engine Front Ends
– Load balancing
– Routing
– Front Ends route static requests to specialized serving infrastructure
Routing at the Front End
Google Static Content Serving
– Built on shared Google Infrastructure
– Static files are physically separate from code files
Static Content Servers
13
Request For Static Content
– Back to the Front End and out to the user
• Front End handles connection to the user
• Frees up Static Content server
– Specialized infrastructure
• App Server runtimes don't serve static content
– Flexible cache expiration settings
Response to the user
14
Defining static content
Request for Static Content
...<static> <include path="/**.png" /> <exclude path="/data/**.png /></static>...
Java Runtime: appengine-web.xml
...- url: /images static_dir: static/imagesOR- url: /images/(.*) static_files: static/images/\1 upload: static/images/(.*)...
Python Runtime: app.yaml
15
Request for Dynamic Content
Front Ends
– Route dynamic requests to App Servers
App Servers
– Serve dynamic requests
– Where your code runs
App Master
– Schedules applications
– Informs Front Ends
16
• Checks for cached runtime
– If it exists, no initialization
• Execute request
• Cache the runtime
Consequences / Opportunities
– Slow first request, faster subsequent requests
– Optimistically cache data in your runtime!
Request for Dynamic Content
17
App Servers - What do they do?
– Many applications
– Many concurrent requests
• Smaller footprint + faster requests = more apps
– Enforce Isolation
• Keeps apps safe from each other
– Enforce statelessness
• Allows for scheduling flexibility
– Service API requests
• Provides access to other services
18
App Servers
1. App issues API call
2. App Server accepts
3. App Server blocks runtime
4. App Server issues call
5. Returns the response
• Use APIs to do things you don't want to do in your runtime, such as...
Requests accessing APIs
19
APIs
20
– Distributed in-memory cache
– Very fast
– memcacheg
• Like memcached
• Also written by Brad Fitzpatrick
• adds: set_multi, get_multi, add_multi
– Optimistic caching
– Very stable, robust and specialized
Memcacheg
A more persistent in-memory cache
21
The App Engine Datastore
Persistent storage
http://labs.google.com/papers/bigtable.html
22
The App Engine Datastore
– Your data is already partitioned on day one
• Use Entity Groups
– Explicit Indexes make for fast reads
• But slower writes
– Replicated and fault tolerant
• On commit: ≥3 machines
• Geographically distributed (shortly thereafter)
– Bonus: Keep globally unique IDs for free
Persistent storage
(more about it later)
23
• GMail
• Google Accounts
• Picasaweb
Other APIs
• Gadget API
• Task Queue
• Google Talk
24 24
The App Engine Datastore
25 25
The Datastore Is...
• Transactional
• Natively Partitioned
• Hierarchical
• Schema-less
• Based on Bigtable
• Not a relational database
• Not a SQL engine
26 26
Simplifying Storage
• Simplify development of apps
• Simplify management of apps
• App Engine services build on Google’s strengths
• Scale always matters
– Request volume
– Data volume
27 27
Datastore Storage Model
• Basic unit of storage is an Entity consisting of
– Kind (compare: table)
– Key (compare: primary key)
– Entity Group (compare: partition)
– 0..N typed Properties (compare: columns)
Kind Person
Entity Group /Person:Ethel
Key /Person:Ethel
Age Int64: 30
Best Friend Key:/Person:Sally
class Person(db.Model): Age = db.IntegerProperty() BestFriend = db.ReferenceProperty()
sally = Person()sally.put()ethel = Person(Age=30, BestFriend=Sally)ethel.put()
28 28
Noteworthy Datastore Features
• Ancestor
• Heterogenous property types
• Multi-value properties
• Variable properties
Kind Person
Entity Group /Person:Ethel
Key /Person:Ethel/Person:Jane
Age Double: 8.5
Best Friend Key:/Person:Eloise,Key:/Person:Patty
Grade Int64: 3
Kind Person
Entity Group /Person:Ethel
Key /Person:Ethel
Age Int64: 30
Best Friend Key:/Person:Sally
class Person(db.Expando): BestFriend = db.ListProperty(db.Key)
ethel = Person(BestFriend=[sally])ethel.Age = 30ethel.put()jane = Person(BestFriend=[eloise,patty], parent=ethel)jane.Age = 8.5jane.Grade = 3jane.put()
Same entity group
29 29
Datastore Transactions
• Transactions apply to a single Entity Group
– Watch out for contention!
– Global transactions are feasible
• get(), put(), delete() are transactional
• Queries cannot participate in transactions (yet)
/Person:Ethel/Person:Jane
/Person:Ethel
/Person:Max
Transaction
30 30
Transparent Entity Group Management
• Entity Group layout is important (* probably the most crucial design decision of your application *)
– Write throughput (1 – 10 writes/second in an entity group)
– Atomicity of updates
• Object relationships can be described as “owned” or “unowned”
– owned: an entity doesn't make sense without another entity, e.g., chapter and book.
– unowned: otherwise, e.g., car and person.
• We let ownership imply co-location within an Entity Group
31 31
Under the covers of the
App Engine Datastore
Slides are at
http://snarfed.org/space/datastore_talk.html
32 32
Porting: check your Transactions
• Identify “roots” in your data model
– User is often a good choice for online services
• Identify operations that transact on multiple roots
• Analyze the impact of partial success and then either
– refactor
– disable the transaction
– disable the transaction and write compensating logic
33 33
Porting: check your queries
• Shift processing from reads to writes
• Identify joins
– Denormalize or rewrite as multiple queries
• Identify unsupported filter operations (distinct, toUpper())
– Rewrite as multiple queries
– Filter in-memory
select * from PERSON p, ADDRESS a where a.person_id = p.id and p.age > 25 and a.country = “US”
select from com.example.Person where age > 25 and country = “US”
Relational Database
App Engine Datastore
34
Open For Questions
– The White House's "Open For Questions" application accepted 100K questions and 3.6M votes in under 48 hours
35 35
Homework #2
• Implement the paxos algorithm
– Assume that disk never fails, but processes may die (TA kills it) and restart a random time later, and communications may randomly be duplicated (TA sends it again) or lost (OS glitch).
• Start: $ paxos -p port config
– Config file lists ports of all processes (find N from it).
• Interfaces:
– “MASTER”: master location query, return “MASTER port” or “UNKONWN”.
– “WRITE name value”:
• to master: make value the consensus for name, return“WRITE OK”, “WRITE FAILED”, or “TRY AGAIN”.
• to non-master: return “MASTER port”
– “QUERY name”: return “VALUE name value” or “MASTER port” if the process died and missed the round for name.
36 36
Homework #2 (cont.)
• Functional specs
– Elect a master among processes before the master can take external values to propose.
– An acceptor waits randomly 0.5 - 1 second before replying to a message.
– Message timeout: configurable with config file, default 10s.
– Every process keeps at least 2 log files for crash recovery: proposer.{port}.log, acceptor.{port}.log, and a value.{port}.log for consensus of names and values.