Cache Serializability: Reducing Inconsistency in Edge Transactions

Cache Serializability: Reducing Inconsistency in Edge Transactions Ittay Eyal Ken Birman Robbert van Renesse Cornell University tributed databases. Until recently, technical chal- Abstract—Read-only caches are widely used in cloud lenges have forced such large-system operators infrastructures to reduce access latency and load on to forgo transactional consistency, providing per- backend databases. Operators view coherent caches as object consistency instead, often with some form of impractical at genuinely large scale and many client- facing caches are updated in an asynchronous manner eventual consistency. In contrast, backend systems with best-effort pipelines. Existing solutions that support often support transactions with guarantees such as cache consistency are inapplicable to this scenario since snapshot isolation and even full transactional atom- they require a round trip to the database on every cache icity [9], [4], [11], [10]. transaction. Our work begins with the observation that it can Existing incoherent cache technologies are oblivious to be difficult for client-tier applications to leverage transactional data access, even if the backend database supports transactions. We propose T-Cache, a novel the transactions that the databases provide: trans- caching policy for read-only transactions in which incon- actional reads satisfied primarily from edge caches sistency is tolerable (won’t cause safety violations) but cannot guarantee coherency. Yet, by running from undesirable (has a cost). T-Cache improves cache consis- cache, client-tier transactions shield the backend tency despite asynchronous and unreliable communication database from excessive load, and because caches between the cache and the database. We define cache- are typically placed close to the clients, response serializability, a variant of serializability that is suitable latency can be improved. The result is a tradeoff: we for incoherent caches, and prove that with unbounded resources T-Cache implements this new specification. With run transactions against incoherent caches, and each limited resources, T-Cache allows the system manager to time a cache returns inconsistent data, the end-user choose a trade-off between performance and consistency. is potentially exposed to visibly incorrect results. Our evaluation shows that T-Cache detects many incon- The problem centers on the asynchronous style sistencies with only nominal overhead. We use synthetic of communication used between the database and workloads to demonstrate the efficacy of T-Cache when the geo-distributed caches. A cache must minimize data accesses are clustered and its adaptive reaction to workload changes. With workloads based on the real-world the frequency of backend database interactions; any arXiv:1409.8324v3 [cs.DC] 26 Apr 2015 topologies, T-Cache detects 43 − 70% of the inconsisten- approach requiring a significant rate of round-trips cies and increases the rate of consistent transactions by to the database would incur unacceptable latency. 33 − 58%. A cache must also respond promptly, which rules I. INTRODUCTION out asynchronous update policies that might lock cache entries. The latency from cache to database Internet services like online retailers and social and back is often high, ruling out cache coherency networks store important data sets in large dis- schemes that would require the backend database to invalidate or update cached objects. In many settings Ittay Eyal; Ken Birman; Robbert van Renesse, “Cache Serializ- ability: Reducing Inconsistency in Edge Transactions,” Distributed the backend can’t even track the locations at which Computing Systems (ICDCS), IEEE 35th International Conference cached objects might reside. Here, we define a on, June 29 2015–July 2 2015. variant of serializability called cache-serializability This work was supported, in part, by research grants from DARPA under its MRC program, and NSF under its Cloud Computing that is suitable for incoherent caches. program. Today, many transactional web applications, from social networks to online retailers, run over caches II. MOTIVATION oblivious to consistency. These transactions won’t crash if an inconsistency arises, but the end-user a) Two-tier structure: Large Internet services may be frustrated and platform revenue is sub- store vast amounts of data. Online retailers such sequently reduced. With T-Cache, the benefits of as Amazon and eBay maintain product stocks and reading from an edge cache are maintained, but information, and social networking sites such as the frequency of these negative costs is reduced. Facebook and Twitter maintain graphical databases Our protocol is especially beneficial for workloads representing user relations and group structures. where data accesses are clustered, which is common For throughput, durability, and availability, such in today’s large-scale systems. T-Cache achieves this databases are sharded and replicated. benefit by storing dependency information with the The vast majority of accesses are read-only (e.g., cached objects, allowing the cache (or the appli- Facebook reports a 99.8% read rate [7]). To reduce cation) to identify possible inconsistencies without database load and to reduce access latency, these contacting the database. The user can improve the companies employ a two-tier structure, placing lay- level of consistency by adjusting the size of this ers of cache servers in front of the database (see dependency data: more dependency data leads to Figure 1). increased consistency. The caches of primary interest to us are typically situated far from the backend database systems — To demonstrate the efficacy of the proposed to reduce latency, companies place caches close to scheme, we created a prototype implementation clients. Timeouts are used to ensure that stale cached and exposed it to workloads based on graphically- objects will eventually be flushed, but to achieve structured real-world data, such as those seen in a high cache hit ratio, timeout values are gener- social-networking situations. The method detects ally large. To obtain reasonable consistency, the 43 − 70% of the inconsistencies and can increase database sends an asynchronous stream of invalida- the ratio of consistent transactions by 33 − 58%, tion records or cache updates, often using protocols both with low overhead. We construct synthetic optimized for throughput and freshness and lacking workloads and explore the behavior of T-Cache absolute guarantees of order or reliability. with different degrees of data clustering, and also investigate its rate of response when clusters change. It is difficult to make this invalidation mecha- nism reliable without hampering database efficiency. With perfectly clustered workloads, T-Cache im- First, the databases themselves are large, residing on plements full cache-serializability. To explain this many servers, and may be geo-replicated. Databases perfect behavior we prove a related claim — we supporting cloud applications are often pipelined, show that with unbounded resources T-Cache im- using locks prudently in order to maximize concur- plements cache-serializability. rency but ensuring that there is always other work to In summary, the contributions of this work are: do; the result is that some updates complete rapidly but others can exhibit surprisingly high latency. 1) Definition of cache-serializability, a variant of During these delays, read access must go forward. serializability suitable for incoherent caches. Databases cannot always accurately track the caches 2) The T-Cache architecture, which allows trading that hold a copy of each object, because the context off efficiency and transaction-consistency in makes it very hard to send timely invalidations: they large scale cache deployments. could be delayed (e.g., due to buffering or retrans- 3) Evaluation of T-Cache with synthetic work- missions after message loss), not sent (e.g., due to loads, demonstrating its adaptivity and sensi- an inaccurate list of locations), or even lost (e.g., tivity to clustering. due to a system configuration change, buffer satu- 4) Evaluation of T-Cache with workloads based ration, or because of races between reads, updates, on graphically-structured real-world data. and invalidations). A missing invalidation obviously 5) Proof that T-Cache with unbounded resources leaves the corresponding cache entry stale. Pitfalls implements cache-serializability. of such invalidation schemes are described in detail but incorporate workarounds to tolerate weak consistency. When inconsistency does arise, the platform’s utility is reduced. This is our target: our goal is to reduce the frequency of such events as much as possible. There has been a wave of recent innovations within the backend, offering scalable object stores that can efficiently support transactions through snapshot isolation and even full atomic- ity [9], [4], [11], [10]. Our approach seeks to improve transaction consistency at the cache layer, without requiring the cache to access the backend Fig. 1. The common two-tiered structure. Clients perform read- only transactions by accessing caches, which receive their values on each read or to invalidate items that may be by reading from the database (solid lines). Update transactions go undergoing updates. directly to the database (double lines). Subsequent cache invalidations c) Caches bring value but cause problems: As can be delayed or even lost due to race conditions, leading to a potentially inconsistent view by the cache clients. noted, many of today’s

Load more