Sequential Programming for Replicated Data Stores Nicholas V. - PowerPoint PPT Presentation

Sequential Programming for Replicated Data Stores Nicholas V. Lewchenko 1 Arjun Radhakrishna 2 Pavol ˇ Akash Gaonkar 1 y 1 Cern´ 1 University of Colorado Boulder 2 Microsoft ICFP 2019

Why Distribute? Distributed architectures are required for software services that people rely on. 2/18

Why Distribute? Distributed architectures are required for software services that people rely on. Distributed applications can survive change. Centralized services cannot. 2/18

Why Distribute? Distributed architectures are required for software services that people rely on. Distributed applications can survive change. Centralized services cannot. 2/18

Replicated Data Stores 1 1 1 1 3/18

Replicated Data Stores 1 + 3 1 1 deposit 3 1 3/18

Replicated Data Stores 4 + 3 1 1 1 3/18

Replicated Data Stores 4 1 4 1 3/18

Replicated Data Stores 4 Failed! 1 4 1 3/18

Replicated Data Stores 4 Failed! 1 4 1 + 4 deposit 4 3/18

Replicated Data Stores 4 Failed! 1 4 5 Availability 3/18

Pre- and Post-Condition Reasoning Given some input to a program, what is its output? 4/18

Pre- and Post-Condition Reasoning Given some input to a program, what is its output? A formal system: Dependent Refinement Types sort : ( xs : List ) → { xs ′ : List | length xs = length xs ′ } 4/18

Pre- and Post-Condition Reasoning Given some input to a program, what is its output? A formal system: Dependent Refinement Types sort : ( xs : List ) → { xs ′ : List | length xs = length xs ′ } How could we extend this to a replicated store operation? Conditions on pre-store → Conditions on ( Effect × Return ) 4/18

Pre- and Post-Condition Reasoning Given some input to a program, what is its output? A formal system: Dependent Refinement Types sort : ( xs : List ) → { xs ′ : List | length xs = length xs ′ } How could we extend this to a replicated store operation? Conditions on pre-store → Conditions on ( Effect × Return ) Consistency 4/18

Replicated Data Stores 4 Failed! 1 4 5 5/18

Replicated Data Stores 4 Failed! 1 4 5 withdraw 3 5/18

Replicated Data Stores 4 Failed! 1 4 5 Pre-store 5 withdraw 3 5/18

Replicated Data Stores 4 Failed! 1 4 5 Effect Pre-store − 3 5 withdraw 3 Return value ok Pre-stores of withdraw 3 : 5 � 5/18

Replicated Data Stores 4 Also a pre-store Failed! 1 4 of withdraw 3 − 3 2 Pre-stores of withdraw 3 : 5 � , 4 � 5/18

Replicated Data Stores 4 Failed! 1 1 2 Pre-stores of withdraw 3 : 5 � , 4 � , 4 ? 5/18

Replicated Data Stores 4 1 1 2 Pre-stores of withdraw 3 : 5 � , 4 � , 4 ? , 1 ? 5/18

An Unfortunate Conflict So how do we maintain both consistency and availability? 6/18

An Unfortunate Conflict So how do we maintain both consistency and availability? We don’t... 6/18

An Unfortunate Conflict So how do we maintain both consistency and availability? We don’t... ◮ Consistency: pre/post logic can be enforced ◮ Availability: a called operation always returns a response ◮ Partitions: the network may drop arbitrary messages CAP Theorem: You can only have two. 6/18

An Unfortunate Conflict So how do we maintain both consistency and availability? We don’t... ◮ Consistency: output depends on complete input ◮ Availability: output must eventually be returned ◮ Partitions: complete input might never arrive CAP Theorem: You can only have two. 6/18

But My App Needs All Three! Partitions are unavoidable for a distributed system. 7/18

But My App Needs All Three! Partitions are unavoidable for a distributed system. Consistency and Availability can be balanced as needed. 7/18

But My App Needs All Three! Partitions are unavoidable for a distributed system. Consistency and Availability can be balanced as needed. ◮ Consistency: output depends on complete input 7/18

But My App Needs All Three! Partitions are unavoidable for a distributed system. Consistency and Availability can be balanced as needed. ◮ Consistency: output depends on complete(?) input 7/18

But My App Needs All Three! Partitions are unavoidable for a distributed system. Consistency and Availability can be balanced as needed. ◮ Consistency: output depends on complete(?) input Available Consistent Some def. of Empty Input must “complete” input include all pre-stores 7/18

But My App Needs All Three! Partitions are unavoidable for a distributed system. Consistency and Availability can be balanced as needed. ◮ Consistency: output depends on complete(?) input Available Consistent Some def. of Empty Input must “complete” input include all pre-stores No balance is universal! 7/18

But My App Needs All Three! Partitions are unavoidable for a distributed system. Consistency and Availability can be balanced as needed. ◮ Consistency: output depends on complete(?) input Available Consistent Consistency Level Empty Input must include all pre-stores No balance is universal! 7/18

The Special Tasks of Replicated Store Programming: 8/18

The Special Tasks of Replicated Store Programming: 1. Configure segments of application to enforce particular consistency levels. 8/18

The Special Tasks of Replicated Store Programming: 1. Configure segments of application to enforce particular consistency levels. 2. Verify that chosen consistency levels preserve desired application properties (pre/post). 8/18

The Special Tasks of Replicated Store Programming: 0. Invent a domain of useful consistency levels. 1. Configure segments of application to enforce particular consistency levels. 2. Verify that chosen consistency levels preserve desired application properties (pre/post). 8/18

Our Contribution Carol is a programming language that simplifies the Special Tasks. 9/18

Our Contribution Carol is a programming language that simplifies the Special Tasks. ◮ Requires only local, sequential reasoning from the programmer 9/18

Our Contribution Carol is a programming language that simplifies the Special Tasks. ◮ Requires only local, sequential reasoning from the programmer ◮ Supports dependent refinement type system (based on Liquid Types) 9/18

Our Contribution Carol is a programming language that simplifies the Special Tasks. ◮ Requires only local, sequential reasoning from the programmer ◮ Supports dependent refinement type system (based on Liquid Types) Made possible by a novel replicated store runtime. 9/18

Let’s Write an ATM Application! First, let’s deposit money. deposit := λ n . issue ( Add n ) in n 10/18

Let’s Write an ATM Application! � Add n � := λ x . x + n First, let’s deposit money. deposit := λ n . issue ( Add n ) in n 10/18

Let’s Write an ATM Application! � Add n � := λ x . x + n First, let’s deposit money. deposit := λ n . issue ( Add n ) in n Now we check our balance. 10/18

Let’s Write an ATM Application! � Add n � := λ x . x + n First, let’s deposit money. deposit := λ n . issue ( Add n ) in n Now we check our balance. balance := query x in x 10/18

Demanding consistency � Add n � := λ x . x + n How do we safely withdraw money? 11/18

Demanding consistency � Add n � := λ x . x + n � Sub n � := λ x . x − n How do we safely withdraw money? withdraw := λ n . query x in if n ≤ x then ( issue Sub n in n ) else 0 11/18

Demanding consistency � Add n � := λ x . x + n � Sub n � := λ x . x − n � x : LEQ � := x ≤ pre-stores How do we safely withdraw money? withdraw := λ n . query x : LEQ in if n ≤ x then ( issue Sub n in n ) else 0 A query term can be annotated with a consistency guard, which the runtime enforces until termination of the operation. 11/18

Demanding consistency � Add n � := λ x . x + n � Sub n � := λ x . x − n � x : LEQ � := x ≤ pre-stores How do we safely withdraw money? withdraw := λ n . query x : LEQ in if n ≤ x then ( issue Sub n in n ) else 0 A query term can be annotated with a consistency guard, Special Task 1 � which the runtime enforces until termination of the operation. 11/18

EQV ( x = pre-stores) LEQ GEQ ( x ≥ pre-stores) ⊤ Guards: consistency level domain based on data refinements. 12/18

EQV ( x = pre-stores) LEQ GEQ ( x ≥ pre-stores) ⊤ Guards: consistency level domain based on data refinements. 1. Provides immediately clear data-based guarantees. 12/18

EQV ( x = pre-stores) LEQ GEQ ( x ≥ pre-stores) ⊤ Guards: consistency level domain based on data refinements. 1. Provides immediately clear data-based guarantees. 2. Enables local reasoning. Meaning of “ x : LEQ ” does not depend on what other operations exist. 12/18

EQV ( x = pre-stores) LEQ GEQ ( x ≥ pre-stores) ⊤ Guards: consistency level domain based on data refinements. 1. Provides immediately clear data-based guarantees. 2. Enables local reasoning. Meaning of “ x : LEQ ” does not depend on Special Task 0 � what other operations exist. 12/18

The Carol type system Γ ⊢ t : { Op D A | ϕ s , e , r } D is a Conflict-Aware Replicated Datatype (CARD) that defines the effects and guards of a store. 13/18