Design and Evaluation of a Continuous Consistency Model For

Design and Evaluation of a Continuous Consistency Model For

Design and Evaluation of a Continuous Consistency Model for Replicated Services Haifeng Yu Amin Vahdat Computer Science Department Duke University Durham, NC 27708 g fyhf, vahdat @cs.duke.edu g http://www.cs.duke.edu/˜ fyhf, vahdat Abstract imposes performance overheads and limits system avail- ability. Thus, a variety of optimistic consistency mod- The tradeoffs between consistency, performance, and els [14, 15, 18, 31, 34] have been proposed for applica- availability are well understood. Traditionally, how- tions that can tolerate relaxed consistency. Such models ever, designers of replicated systems have been forced require less communication, resulting in improved per- to choose from either strong consistency guarantees or formance and availability. none at all. This paper explores the semantic space be- Unfortunately, optimistic models typically provide no tween traditional strong and optimistic consistency mod- bounds on the inconsistency of the data exported to els for replicated services. We argue that an important client applications and end users. A fundamental ob- class of applications can tolerate relaxed consistency, but servation behind this work is that there is a continuum benefit from bounding the maximum rate of inconsistent between strong and optimistic consistency that is seman- access in an application-specific manner. Thus, we de- tically meaningful for a broad range of network services. velop a set of metrics, Numerical Error, Order Error, This continuum is parameterized by the maximum dis- and Staleness, to capture the consistency spectrum. We tance between a replica’s local data image and some fi- then present the design and implementation of TACT, nal image “consistent” across all replicas after all writes a middleware layer that enforces arbitrary consistency have been applied everywhere. For strong consistency, bounds among replicas using these metrics. Finally, we this maximum distance is zero, while for optimistic con- show that three replicated applications demonstrate sig- sistency it is infinite. We explore the semantic space in nificant semantic and performance benefits from using between these two extremes. For a given workload, pro- our framework. viding a per-replica consistency bound allows the system to determine an expected probability, for example, that a write operation will conflict with a concurrent write 1 Introduction submitted to a remote replica, or that a read operation observes the results of writes that must later be rolled Replicating distributed services for increased avail- back. No such analysis can be performed for optimistic ability and performance has been a topic of considerable consistency systems because the maximum level of in- interest for many years. Recently however, exponen- consistency is unbounded. tial increase in access to popular Web services provides The relationship between consistency, availability, us with concrete examples of the types of services that and performance is depicted in Figure 1(a). In moving would benefit from replication, their requirements and from strong consistency to optimistic consistency, ap- semantics. One of the primary challenges to replicating plication performance and availability increases. This network services is consistency across replicas. Provid- benefit comes at the expense of an increasing probabil- ing strong consistency (e.g., one-copy serializability [4]) ity that individual accesses will return inconsistent re- sults, e.g., stale/dirty reads, or conflicting writes. In This work is supported in part by the National Science our work, we allow applications to bound the maxi- Foundation (EIA-99772879,ITR-0082912). Vahdat is also sup- mum probability/degree of inconsistent access in ex- ported by an NSF CAREER award (CCR-9984328). Ad- ditional information on the TACT project can be found at change for increased performance and availability. Fig- http://www.cs.duke.edu/ari/issg/TACT/. ure 1(b) graphs different potential improvements in ap- Probability of Inconsistent Access Curve based on workload/network Availability Probability of characteristics Performance Inconsistent Access Strong 1 2 Optimistic 0 0 Performance Consistency Consistency 1 2 (a) (b) Figure 1: a) The spectrum between strong and optimistic consistency as measured by a bound on the probability of inconsistent access. b) The tradeoff between consistency, availability, and performance depends upon application and network characteristics. plication performance versus the probability of incon- mote replicas). Otherwise, the operation blocks until sistent access, depending on workload/network charac- TACT is able to synchronize with one or more remote teristics. Moving to the right in the figure corresponds replicas (i.e., push or pull some subset of local/remote to increased performance, while moving up in the figure updates) as determined by system consistency require- corresponds to increased inconsistency. To achieve in- ments. creased performance, applications must tolerate a corre- We propose three metrics, Numerical Error, Order sponding increase in inconsistent accesses. The tradeoff Error,andStaleness, to bound consistency. Numerical between performance and consistency depends upon a error limits the total weight of writes that can be applied number of factors, including application workload, such across all replicas before being propagated to a given as read/write ratios, probability of simultaneous writes, replica. Order error limits the number of tentative writes etc., and network characteristics such as latency, band- (subject to reordering) that can be outstanding at any one width, and error rates. At the point labeled “1” in the replica, and staleness places a real-time bound on the de- consistency spectrum in Figure 1(b), a modest increase lay of write propagation among replicas. Algorithms are in performance corresponds to a relatively large increase then designed to bound each metric: Numerical error is in inconsistency for application classes corresponding to bounded using a push approach based solely on local the top curve, perhaps making the tradeoff unattractive information; a write commitment algorithm combined for these applications. Conversely, at point “2,” large with compulsory write pull enforces order error bound; performance increases are available in exchange for a and staleness is maintained using real-time vector. To relatively small increase in inconsistency for applica- evaluate the effectiveness of our system, we implement tions represented by the bottom curve. and deploy across the wide area three applications with Thus, the goals of this work are: i) to explore the is- a broad range of dynamically changing consistency re- sues associated with filling the semantic, performance, quirements using the TACT toolkit: an airline reserva- and availability gap between optimistic and strong con- tion system, a distributed bulletin board service, and load sistency models, ii) to develop a set of metrics that allow distribution front ends to a Web server. Relative to strong a broad range of replicated services to conveniently and consistency techniques, TACT improves the throughput quantitatively express their consistency requirements, of these applications by up to a factor of 10. Relative iii) to quantify the tradeoff between performance and to weak consistency approaches, TACT provides strong consistency for a number of sample applications, and semantic guarantees regarding the maximum inconsis- iv) to show the benefits of dynamically adapting consis- tency observed by individual read and write operations. tency bounds in response to current network, replica, and The rest of this paper is organized as follows. Sec- client-request characteristics. To this end, we present tion 2 describes the three network services implemented the design, implementation, and evaluation of the TACT in the TACT framework to motivate our system archi- toolkit. TACT is a middleware layer that accepts specifi- tecture. Section 3 presents the system model and design cations of application consistency requirements and me- we adopt for our target services. Next, Section 4 details diates read/write access to an underlying data store. If the TACT architecture and Section 5 evaluates the per- an operation does not violate pre-specified consistency formance of our three applications in the TACT frame- requirements, it proceeds locally (without contacting re- work. Finally, Section 6 places our work in the context of related work and Section 7 presents our conclusions. concurrent read/write access under the assumption that conflicts are rare or can be resolved automatically. Desirable consistency requirements for the bulletin 2 Applications board example include maintaining causal and/or total order among messages posted at different replicas. With causal order, a reply to a message will never appear be- 2.1 Airline Reservations fore the original message at any replica. Total order en- sures that all messages appear in the same order at all Our first application is a simple replicated airline replicas, allowing the service to assign globally unique reservation system that is designed to be representative identifiers to each message. Another interesting consis- of replicated E-commerce services that accept inquiries tency requirement for interactive applications, including (searches) and purchase orders on a catalog. In our im- the bulletin board, is to guarantee that at any time t,no t plementation, each server maintains a full replica of the more than k messages posted

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    14 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us