Exploiting Application Semantics: Harvest, Yield CS 444A Fall 99 Software for Critical Systems Armando Fox & David Dill © 1999 Armando Fox

© 1999, Armando Fox Harvest and Yield n Yield: probability of completing a query n Harvest: (application-specific) fidelity of the answer l Fraction of data represented? l Precision? l Semantic proximity? n Harvest/yield questions: l When can we trade harvest for yield to improve availability? l How to measure harvest “threshold” below which response is not useful? n Application decomposition to improve “degradation tolerance” (and therefore availability)

© 1999, Armando Fox Example 1: Search Engine n Stripe database randomly across all nodes, replicate high-priority data l Random striping: worst case == average case l Replication: high priority data unlikely to be lost l Harvest: fraction of nodes reporting n Questions… l Why not just wait for all nodes to report back? l Should harvest be reported to end user? l What is the “useful” harvest threshold? l Is nondeterminism a problem? n Trade harvest for yield/throughput

© 1999, Armando Fox Example 2: TranSend n lossy on-the-fly Web image compression, extensively parameterized (per user, device, etc.) n Harvest: “semantic fidelity” of what you get l Worst case: the original image original l Intermediate case: “close” image that has been previously computed and cached l Metrics for semantic fidelity? n Trade harvest for yield/throughput desired delivered

© 1999, Armando Fox Synergies With Cluster Computing n Common thread: trade harvest for yield or throughput l Search engine: harvest == fraction of nodes reporting l TranSend: harvest == semantic similarity between delivered & requested results l Both cases: a direct function of availability of computing power n Harvest vs. Yield neat tricks l Migrating a cluster with zero downtime l Managing user classes

© 1999, Armando Fox Application Decomposition n Decomposing the canonical e-commerce site Billing Profiles Catalog Internet $ $ FE W W W T W W W A

© 1999, Armando Fox Component State Management n User profiles l Read often, write infrequently l Must persist across sessions n Online merchandise catalog l Read-only database l Presentation should depend on user preferences n Shopping cart l Read and write frequently l Need not persist across sessions n Billing (transactional DB)

© 1999, Armando Fox Degradable State: Shopping Cart n Shopping cart is more “state-intensive” than billing l Shopping cart subsystem manipulates more incremental state per user than billing l But, shopping cart is an “optimization” l We can reflect this into provisioning/growth n One idea: Keep cart contents in a cache l Not a database! l Non-ACID l Soft state by definition

© 1999, Armando Fox Per-Component Failure Modes l Shopping cart can be periodically checkpointed to user profile l Transformation & aggregation modules can present catalog based on user input Billing Profiles Catalog Internet $ $ FE W W W T W W W A

© 1999, Armando Fox Degradable State, cont’d. n What’s the probability of losing the shopping cart? l HW or SW failure in cache (e.g. transient node failure, write corruption) l Eviction: rate depends on cache size and working set size; can grow cache incrementally to fix problem n What happens to users when cache is thrashing? l Turn off shopping cart for everyone? l “Use at own risk” shopping cart? l Rent some machines at high cost, until new ones arrive? l Probably cheaper to deploy a Web cache node than a new DB node!

© 1999, Armando Fox State vs. Interactivity Characterization n Idea: to decompose applications, characterize the pieces according to state and interactivity requirements n Rationale l State management is easy, if performance is not a concern l High performance is easy, if there is no state to manage l Proper decomposition may allow harvest-intolerant pieces to fail independently but overall service still available in degraded form n Goal: Combine harvest-intolerant pieces into a harvest-tolerant service, then quantify harvest degradation

© 1999, Armando Fox Interactivity Characterization n R: read interactivity l Example: static content server n W: write and read interactivity l Example: DB with high update load n N: non-interactive l Example: user requests are deferred or processed offline, with confirmation sent later n More like a spectrum than three distinct points l Treads the line of “performance vs. correctness”

© 1999, Armando Fox State Characterization n P: persistent l Failure to store persistently == incorrect behavior n S: soft/regeneratable l Stored state is an optimization, loss affects “only” performance l regeneration is possible but expensive, so expected to be rare (If both the state and the ability to generate it are lost, incorrect application behavior results) n D: degradable l trading harvest for some other property, e.g. yield or interactive performance

© 1999, Armando Fox The Resulting Space

© 1999, Armando Fox Example: Aggregated hit counter WS Hits WS Hits (W,P) (N,P) (W,S) n Naïve implementation: shared hit counter is (W,P) n Reimplementation: l Each node keeps in-memory counter: (W,S) l Main counter is periodically updated: (N,P) l Main counter must be fast to read: (R,P) l If staleness/imprecision is allowed, main counter can be (R,D) using caching

© 1999, Armando Fox Open Problems n Quantifying state degradation n Quantifying probabilistic availability n Abstractions for manipulating reduced-fidelity results n Might this apply to reactive systems?