Invariant Safety for Distributed Applications

Presented at PaPoC 2019, colocated with EuroSys 2019.

Transcript

1. Invariant Safety for Distributed Applications 1 Sreeja Nair1, Gustavo Petri2, Marc Shapiro1 1 LIP6, Sorbonne University & Inria 2 ARM Research Cambridge The 6th Workshop on Principles and Practice of Consistency for Distributed Data PaPoC’19 25-03-2019
2. Distributed Applications • Modern day applications serve users in different geographical regions • Applications are replicated closer to users due to demands of low response time • CAP theorem depicts a tension between Consistency and Availability 2
3. Replicated Online Auction 3 Alice Bob Charles
4. Invariant Safety for Distributed Applications • Ideal world for developers = high availability + application safety • A modular proof rule to ensure this! • Reason about one operation at a time 4
5. Auction application • State • Status • INVALID or ACTIVE or CLOSED • Winner • Set of bids, each bid comprising • BidId • Placed • Amount 5 • Invariant • Bids can be placed only when the status is active • When auction is closed, there is a winner • Winner is the highest bid • Operations • Start auction • Place bid • Close auction
6. Evolution of state 6 Alice/ Australia Bob/ Belgium Charles/ Canada Start auction Place bid Place bid Status Winner Bids Merge! ??? 100 105 1 100 105 100 1 Close auction 100 1 100 105
7. Safety in sequential executions 7 Start auction Close auction Place Bid 100 Start auction Close auction Place Bid 100 100 105 100 105 100 105 100 105 100 105 105 100
8. Safety in sequential executions 8 Close auction 100 100 105 Close auction 100 100 95 100 95 100 105
9. Safety in sequential executions • Each operation and merge must satisfy the invariant • Ensured by preconditions 9
10. Precondition for merge? • It must hold true since merge can happen at any time • Can be also called Concurrent Invariant • The weakest precondition to be upheld for the resulting state of merge to uphold the sequential invariant • Ensures all concurrent operations are still safe • Never block any merge!! 10 Invglobal = Invapp ∧ Invconcurrent
11. Concurrency • A state in a replica evolves with • A local update by operation • Merge • Merge is the only point of observable concurrency 11 Alice/ Bob/ Charles Start Place Place 100 105 1 100 105 100 1
12. Proof Rule for safety of distributed applications • Initial state must satisfy the application invariant and concurrent invariant • Each update and merge should preserve both the application invariant and concurrent invariant 12
13. Proof Rule for safety of distributed applications • Intuition • Merge is the only point of external influence • Merge can happen any time • Modular • Each operation and merge reasoned in isolation 13
14. Revisiting auction • Invariant • Bids can be placed only when the status is active • When auction is closed, there is a winner • Winner is the highest bid • Concurrent Invariant • Winner in either state is the highest bid in both states 14
15. Safety of Auction 15 Alice/ Australia Bob/ Belgium Charles/ Canada Start auction Place bid Place bid 100 105 1 100 105 100 1 Close auction 100 1 100 105
16. Safety of Auction • Start auction 16 • Invariant • Bids can be placed only when the status is active • When auction is closed, there is a winner • Winner is the highest bid • Concurrent Invariant • Winner in either state is the highest bid in both states • Place bid • If auction concurrently closed in other replica, precondition of merge violated! • Close auction • Similar to place bid
17. Concurrency Control • Option 1: • Strong consistency of place bid and close auction operations • Issue: each place bid need synchronisation • Option 2: • Concurrency control similar to readers-writer lock • Place bids work without synchronisation • Closing auction needs synchronisation 17
18. 18 Evolution of state with Concurrency Control Alice/ Australia Bob/ Belgium Charles/ Canada Start auction Place bid Place bid Close auction 100 Release token 100 105 Release token 105 Release token 1 1 100 105 105 100
19. Tool Support - Soteria • Implemented on top of Boogie • Input • Application state • Invariant • Partial Order function • Operations with preconditions • Merge operation with precondition 19
20. Soteria checks • Sanity checks • Convergence checks • Each operation is monotonically non-decreasing • Merge is the least upper bound • Safety checks • Sequential safety -> each operation preserves the invariant • Concurrent safety -> each operation preserves the precondition of merge 20
21. Semi-lattice • Set of state should form a monotonic semi-lattice • Equipped with a partial order function • Each update should inflate the state • Merge should be the Least Upper Bound 21 100 105 100 105
22. Conclusion • A new proof rule for verification of distributed applications • For applications using state-based update propagation • A tool for design verification • Available at https://github.com/sreeja/soteria_tool 22