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. pingyeh@google.com
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 2
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 3
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. Infrastructure as a Service (IaaS): hardware + Virtual Machine + Frontend/Routing + Management, with elasticity Platform as a Service: IaaS + OS + Libraries + Reverse Proxy Layers of a Web Site Frontend / Routing HTTP, URL Reverse Proxy Instance Application Software Libraries HTTP, HTML Operating System (optional) Virtual Machine Elasticity Management Provisioning, accounting, monitoring, start/stop servers,... Hardware 4
How to to know user's behavior? Logs Fast analysis Designing a Web Application What does it it do? Your ideas here Function Analysis & Admin How to to manage the app? Admin UI UI Data {im ex}port Internal process How long do do I I need to to wait? Caching Data organization Static content etc Performance Web Application User Experience Cloud service can help Security Availability How to to use it? it? Flow Simplicity Interactivity etc Is Is it it available when I I need it? it? Scalability DDOS defense Fault tolerance Routing etc Is Is my data safe? Encryption Password strength Data replication XSRF Buffer overflow Privacy measures etc 5
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 6
Google App Engine http://code.google.com/appengine/ 7
Google App Engine at a Glance 8
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) 9
Life of an App Engine Request 10
Routing Routed to the nearest Google datacenter Travels over Google's network Same infrastructure other Google products use Lots of advantages for free 11
Request for Static Content Routing at the Front End Static Content Servers Google App Engine Front Ends Load balancing Routing Front Ends route static requests to specialized serving infrastructure Google Static Content Serving Built on shared Google Infrastructure Static files are physically separate from code files 12
Request For Static Content Response to the user 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 13
Request for Static Content Defining static content Java Runtime: appengine-web.xml... <static> <include path="/**.png" /> <exclude path="/data/**.png /> </static>... Python Runtime: app.yaml... - url: /images static_dir: static/images OR - url: /images/(.*) static_files: static/images/\1 upload: static/images/(.*)... 14
Front Ends Request for Dynamic Content Route dynamic requests to App Servers App Servers Serve dynamic requests Where your code runs App Master Schedules applications Informs Front Ends 15
Request for Dynamic Content 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! 16
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 17
Requests accessing APIs 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... 18
APIs 19
Memcacheg 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 A more persistent in-memory cache 20
The App Engine Datastore Persistent storage http://labs.google.com/papers/bigtable.html 21
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) 22
Other APIs GMail Gadget API Google Accounts Task Queue Picasaweb Google Talk 23
The App Engine Datastore 24 24
The Datastore Is... Transactional Natively Partitioned Hierarchical Schema-less Based on Bigtable Not a relational database Not a SQL engine 25 25
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 26 26
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) class Person(db.Model): Age = db.integerproperty() BestFriend = db.referenceproperty() sally = Person() sally.put() ethel = Person(Age=30, BestFriend=Sally) ethel.put() Kind Person Entity Group /Person:Ethel Key /Person:Ethel Age Int64: 30 Best Friend Key:/Person:Sally 27 27
Noteworthy Datastore Features Kind Ancestor Heterogenous property types Multi-value properties Variable properties Entity Group Key Person /Person:Ethel /Person:Ethel Age Int64: 30 Best Friend Key:/Person:Sally Same entity group class Person(db.Expando): BestFriend = db.listproperty(db.key) ethel = Person(BestFriend=[sally]) ethel.age = 30 ethel.put() jane = Person(BestFriend=[eloise,patty], parent=ethel) jane.age = 8.5 jane.grade = 3 jane.put() Kind Entity Group Key Person /Person:Ethel Age Double: 8.5 Best Friend Grade Int64: 3 /Person:Ethel/Person:Jane Key:/Person:Eloise, Key:/Person:Patty 28 28
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 Transaction /Person:Ethel/Person:Jane /Person:Max 29 29
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 30 30
Under the covers of the App Engine Datastore Slides are at http://snarfed.org/space/datastore_talk.html 31 31
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 32 32
Porting: check your queries Shift processing from reads to writes Identify joins Denormalize or rewrite as multiple queries select * from PERSON p, ADDRESS a where a.person_id = p.id and p.age > 25 and a.country = US Relational Database select from com.example.person where age > 25 and country = US App Engine Datastore Identify unsupported filter operations (distinct, toupper()) Rewrite as multiple queries Filter in-memory 33 33
Open For Questions The White House's "Open For Questions" application accepted 100K questions and 3.6M votes in under 48 hours 34
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. 35 35
Functional specs Homework #2 (cont.) 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. 36 36