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

▶
sequential programming for replicated data stores
SMART_READER_LITE
LIVE PREVIEW

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

Dec 30, 2023 153 likes •913 views

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

slide-1
SLIDE 1

Sequential Programming for Replicated Data Stores

Nicholas V. Lewchenko1 Arjun Radhakrishna2 Akash Gaonkar1 Pavol ˇ Cern´ y1

1University of Colorado Boulder 2Microsoft

ICFP 2019

slide-2
SLIDE 2

Why Distribute?

Distributed architectures are required for software services that people rely on.

2/18

slide-3
SLIDE 3

Why Distribute?

Distributed architectures are required for software services that people rely on. Distributed applications can survive change. Centralized services cannot.

2/18

slide-4
SLIDE 4

Why Distribute?

Distributed architectures are required for software services that people rely on. Distributed applications can survive change. Centralized services cannot.

2/18

slide-5
SLIDE 5

Replicated Data Stores

1 1 1 1

3/18

slide-6
SLIDE 6

Replicated Data Stores

1 1 1 1 deposit 3 +3

3/18

slide-7
SLIDE 7

Replicated Data Stores

4 1 1 1 +3

3/18

slide-8
SLIDE 8

Replicated Data Stores

4 1 4 1

3/18

slide-9
SLIDE 9

Replicated Data Stores

4 1 4 1

Failed!

3/18

slide-10
SLIDE 10

Replicated Data Stores

4 1 4 1

Failed!

deposit 4 +4

3/18

slide-11
SLIDE 11

Replicated Data Stores

4 1 4 5

Failed! Availability

3/18

slide-12
SLIDE 12

Pre- and Post-Condition Reasoning

Given some input to a program, what is its output?

4/18

slide-13
SLIDE 13

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

slide-14
SLIDE 14

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

slide-15
SLIDE 15

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

slide-16
SLIDE 16

Replicated Data Stores

4 1 4 5

Failed!

5/18

slide-17
SLIDE 17

Replicated Data Stores

4 1 4 5 withdraw 3

Failed!

5/18

slide-18
SLIDE 18

Replicated Data Stores

4 1 4 5 withdraw 3 Pre-store 5

Failed!

5/18

slide-19
SLIDE 19

Replicated Data Stores

4 1 4 5 withdraw 3 Pre-store 5 −3 Effect

  • k

Return value

Failed!

Pre-stores of withdraw 3: 5

5/18

slide-20
SLIDE 20

Replicated Data Stores

4 1 4 2

Failed!

−3 Also a pre-store

  • f withdraw 3

Pre-stores of withdraw 3: 5, 4

5/18

slide-21
SLIDE 21

Replicated Data Stores

4 1 1 2

Failed!

Pre-stores of withdraw 3: 5, 4, 4?

5/18

slide-22
SLIDE 22

Replicated Data Stores

4 1 1 2 Pre-stores of withdraw 3: 5, 4, 4?, 1?

5/18

slide-23
SLIDE 23

An Unfortunate Conflict

So how do we maintain both consistency and availability?

6/18

slide-24
SLIDE 24

An Unfortunate Conflict

So how do we maintain both consistency and availability? We don’t...

6/18

slide-25
SLIDE 25

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

slide-26
SLIDE 26

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

slide-27
SLIDE 27

But My App Needs All Three!

Partitions are unavoidable for a distributed system.

7/18

slide-28
SLIDE 28

But My App Needs All Three!

Partitions are unavoidable for a distributed system. Consistency and Availability can be balanced as needed.

7/18

slide-29
SLIDE 29

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

slide-30
SLIDE 30

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

slide-31
SLIDE 31

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 Some def. of “complete” input Consistent Empty Input must include all pre-stores

7/18

slide-32
SLIDE 32

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 Some def. of “complete” input Consistent Empty Input must include all pre-stores No balance is universal!

7/18

slide-33
SLIDE 33

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 Consistency Level Consistent Empty Input must include all pre-stores No balance is universal!

7/18

slide-34
SLIDE 34

The Special Tasks of Replicated Store Programming:

8/18

slide-35
SLIDE 35

The Special Tasks of Replicated Store Programming:

  • 1. Configure segments of application to enforce

particular consistency levels.

8/18

slide-36
SLIDE 36

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

slide-37
SLIDE 37

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

slide-38
SLIDE 38

Our Contribution

Carol is a programming language that simplifies the Special Tasks.

9/18

slide-39
SLIDE 39

Our Contribution

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

9/18

slide-40
SLIDE 40

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

slide-41
SLIDE 41

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

slide-42
SLIDE 42

Let’s Write an ATM Application!

First, let’s deposit money. deposit := λn. issue (Add n) in n

10/18

slide-43
SLIDE 43

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

slide-44
SLIDE 44

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

slide-45
SLIDE 45

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

slide-46
SLIDE 46

Demanding consistency

Add n := λx. x + n How do we safely withdraw money?

11/18

slide-47
SLIDE 47

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

slide-48
SLIDE 48

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

slide-49
SLIDE 49

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

Special Task 1

slide-50
SLIDE 50

EQV (x = pre-stores) LEQ GEQ (x ≥ pre-stores) ⊤

Guards: consistency level domain based on data refinements.

12/18

slide-51
SLIDE 51

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

slide-52
SLIDE 52

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

slide-53
SLIDE 53

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

Special Task 0

slide-54
SLIDE 54

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

slide-55
SLIDE 55

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. ⊢ deposit : (n : Nat) → { Op Ctr Nat | e(s) = s + n } ⊢ balance : { Op Ctr Int | e = id }

13/18

slide-56
SLIDE 56

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. ⊢ deposit : (n : Nat) → { Op Ctr Nat | e(s) = s + n } ⊢ balance : { Op Ctr Int | e = id } Everything is an operation! ⊢ 5 : { Op D Int | e = id ∧ r = 5 }

13/18

slide-57
SLIDE 57

Verifying Withdraw

ϕ := (s ≥ 0 ⇒ e(s) ≥ 0) ∧ (r = s − e(s))

14/18

slide-58
SLIDE 58

Verifying Withdraw

ϕ := (s ≥ 0 ⇒ e(s) ≥ 0) ∧ (r = s − e(s))

  • 1. Account never goes below zero

14/18

slide-59
SLIDE 59

Verifying Withdraw

ϕ := (s ≥ 0 ⇒ e(s) ≥ 0) ∧ (r = s − e(s))

  • 1. Account never goes below zero
  • 2. Value returned to caller is operation’s real effect on store

14/18

slide-60
SLIDE 60

Verifying Withdraw

ϕ := (s ≥ 0 ⇒ e(s) ≥ 0) ∧ (r = s − e(s))

  • 1. Account never goes below zero
  • 2. Value returned to caller is operation’s real effect on store

withdraw := λn. query x : LEQ in if n ≤ x then (issue Sub n in n) else 0 Γ ⊢ LEQ : Guard(Ctr) Γ, x : { Op Ctr Int | r ≤ s } ⊢ if . . . : { Op Ctr Nat | ϕ } Γ ⊢ query x : LEQ in if . . . : { Op Ctr Nat | ϕ }

14/18

slide-61
SLIDE 61

Verifying Withdraw

ϕ := (s ≥ 0 ⇒ e(s) ≥ 0) ∧ (r = s − e(s))

  • 1. Account never goes below zero
  • 2. Value returned to caller is operation’s real effect on store

withdraw := λn. query x : LEQ in if n ≤ x then (issue Sub n in n) else 0 Γ ⊢ LEQ : Guard(Ctr) Γ, x : { Op Ctr Int | r ≤ s } ⊢ if . . . : { Op Ctr Nat | ϕ } Γ ⊢ query x : LEQ in if . . . : { Op Ctr Nat | ϕ }

14/18

Special Task 2

slide-62
SLIDE 62

So Who’s Paying For This?

Programmer only needs local, sequential reasoning...

15/18

slide-63
SLIDE 63

So Who’s Paying For This?

Programmer only needs local, sequential reasoning... But runtime needs more.

15/18

slide-64
SLIDE 64

So Who’s Paying For This?

Programmer only needs local, sequential reasoning... But runtime needs more. Add Sub Set LEQ GEQ Accords tell the runtime which effects are safe during a query. Theorem: If {guard} is in accord with {effect}, then a query using {guard} can safely return without including {effect}.

15/18

slide-65
SLIDE 65

What Have We Gained?

Accords are more reusable and involve less code than full-operation concurrent verification.

16/18

slide-66
SLIDE 66

What Have We Gained?

Accords are more reusable and involve less code than full-operation concurrent verification. ATM System RDT (conc. ver.)

16/18

slide-67
SLIDE 67

What Have We Gained?

Accords are more reusable and involve less code than full-operation concurrent verification. ATM System RDT (conc. ver.) vs. Ctr CARD (conc. ver.) balance deposit withdraw (seq. ver.)

16/18

slide-68
SLIDE 68

What Have We Gained?

Accords are more reusable and involve less code than full-operation concurrent verification. ATM System RDT (conc. ver.) vs. Ctr CARD (conc. ver.) balance deposit withdraw (seq. ver.) countVisitor moveRobotX checkRobotRoom

16/18

slide-69
SLIDE 69

Future Work: Advanced Runtimes

17/18

slide-70
SLIDE 70

Future Work: Advanced Runtimes Preserving semantics

◮ Effects or guards—who gets right-of-way? ◮ Contention management

17/18

slide-71
SLIDE 71

Future Work: Advanced Runtimes Preserving semantics

◮ Effects or guards—who gets right-of-way? ◮ Contention management

Extending semantics/language

◮ Direct messages for safety-preserving side deals.

17/18

slide-72
SLIDE 72

In Conclusion

◮ Consistency guards isolate programmer from global, concurrent reasoning—operations behave according to local, sequential rules

18/18

slide-73
SLIDE 73

In Conclusion

◮ Consistency guards isolate programmer from global, concurrent reasoning—operations behave according to local, sequential rules ◮ The local, sequential reasoning is formalized by a dependent refinement type system

18/18

slide-74
SLIDE 74

In Conclusion

◮ Consistency guards isolate programmer from global, concurrent reasoning—operations behave according to local, sequential rules ◮ The local, sequential reasoning is formalized by a dependent refinement type system ◮ Accords statically capture the concurrent knowledge needed to run many not-yet-written applications

18/18

slide-75
SLIDE 75

In Conclusion

◮ Consistency guards isolate programmer from global, concurrent reasoning—operations behave according to local, sequential rules ◮ The local, sequential reasoning is formalized by a dependent refinement type system ◮ Accords statically capture the concurrent knowledge needed to run many not-yet-written applications ◮ Haskell DSL and runtime implementation: https://github.com/cuplv/discard

18/18