Consistency-Based - PowerPoint Presentation

Slide1

Consistency-Based Service Level Agreements for Cloud Storage

Douglas B. Terry, Vijayan Prabhakaran, Ramakrishna Kotla, Mahesh Balakrishnan, Marcos K. Aguilera, Hussam Abu-Libdeh

Microsoft ResearchSlide2

“A foolish consistency is the hobgoblin of little minds”-- Ralph Waldo Emerson (1841)“… and of large clouds”-- Douglas Brian Terry (2013)

2Slide3

Today’s Cloud Storage ProvidersReplicate data widelyOffer choice of strong or eventual

consistency

e.g. Amazon

DynamoDB

, Yahoo PNUTS, Google App Engine, Oracle NoSQL, Cassandra, … Microsoft Windows AzureTradeoff consistency, availability and performance

3Slide4

ProblemDevelopers must choose consistency No single choice is best for all clients and situations4

Client

Consistency

U.S.

(secondary)

England

(primary)

India

(secondary)

China (client only)strong147.51.2435.5307.23eventual1.11.01.1160.2

Shopping cart: Want read in under 300

ms.

roundtrip times in millisecondsSlide5

Pileus key featuresReplicated, partitioned key-value storeChoice of consistency

Consistency-based

service level agreements (SLAs)

5

a cap cloudSlide6

Pileus System Model

6

p

rimary

core

s

econdary

nodes

G

et

(key, SLA)Put(key, value)Get(key, SLA)

syncreplication

lazy

replication

G

et

(key, SLA)

API

BeginSession

(SLA)

BeginTx

(SLA)

Put

(key, value)

Get

(key, SLA)

returns value,

consistency

EndTx

()

EndSession

()Slide7

Read Consistency Guarantees7

Strong Consistency

Return value of latest

Put

.

Causal ConsistencyReturn value

of latest causally preceding

Put

.

Bounded Staleness (

t)Return value that is stale by at most t seconds.Read My WritesReturn value of latest Put in client session or a later value.Monotonic ReadsReturn same or later value as earlier Get in client session.Eventual ConsistencyReturn value of any Put.[COPS 2011][TACT 2002][Bayou 1994]Slide8

Read Latencies8

Client/

Consistency

U.S.

(secondary)

England

(primary

)

India

(secondary)

China(client only)strong147.51.2435.5307.3causal146.31.0431.6306.4bounded(30)

75.11.0

234.6

241.9

read-my-writes

13.01.1

18.4

166.8

monotonic

1.1

1.0

1.1

160.2

eventual

1.1

1.0

1.1

160.2

roundtrip times in milliseconds

consistency affects latency

client location affects latencySlide9

Consistency-based SLAApplications declare desired consistency/latency9

strong

300

ms.

consistency

latency

read my writes

300

ms.

1.

2.1.0utility0.5eventual300 ms.3.0.1Shopping Cart:Slide10

SLA Enforcement: Client MonitoringNode

Primary?

RTTs

High Timestamp

A

yes

210

B

no

166

Cno20310For each tablet:

from configuration service

measured on Gets

,

Puts

, and pings

returned from

G

ets

,

Puts

, and pingsSlide11

SLA Enforcement: Node SelectionFor each subSLA and node, compute Platency

compute

P

consistency

compute

Platency x Pconsistency x utility

Select node with maximum expected utility

Send

G

et

operation to nodeMeasure RTT and update recordsReturn data and delivered consistency to caller11On Get (key, SLA):Slide12

Experimental SetupSystem configuration:Primary: EnglandSecondaries: U.S., IndiaClients: U.S., England, India, China

Benchmark:

YCSB with 50/50

Gets/Puts

500-op sessions

Node selection schemes:Primary = get

from primary

Random

= get from random node

Closest

= get from closest nodePileus = get from node with highest expected utilityMeasurement: Average utility for Get operations

U.S.

England

China

India

149

287

436

161

308

181

12Slide13

Experiment #1: SLA Simplified shopping cart SLA:13

consistency

latency

read my writes

300

ms.

1.

2.

utility

1.0

eventual300 ms.0.5Slide14

Experiment #1: Delivered Utility14

Average utility

per Get

Client datacenter

(secondary)

(secondary)

(primary)

(client only)Slide15

Experiment #1: Delivered Utility15

Average utility

per Get

Client datacenter

(secondary)

(secondary)

(primary)

(client only)

Primary selection works well when close to the primary, but poorly when distantSlide16

Experiment #1: Delivered Utility16

Average utility

per Get

Client datacenter

(secondary)

(secondary)

(primary)

(client only)

Random selection rarely works wellSlide17

Experiment #1: Delivered Utility17

Average utility

per Get

Client datacenter

(secondary)

(secondary)

(primary)

(client only)

100% Gets from England;

100% meet top subSLASlide18

Average utilityper GetExperiment #1: Delivered Utility18

Client datacenter

(secondary)

(secondary)

(primary)

(client only)

91% from U.S.;

9% from England;

100% meets top subSLA

14.5

ms.

avg. latency

vs.

148

ms.

for primarySlide19

Experiment #1: Delivered Utility19

Average utility

per Get

Client datacenter

(secondary)

(secondary)

(primary)

(client only)

99.6% from U.S.;

0.4% from India;

96% meets top subSLASlide20

(secondary)(secondary)(primary)

(client only)

Client datacenter

Experiment #1: Delivered Utility

20

Pileus always delivers the most utility!

Average utility

per GetSlide21

Experiment #1: Delivered Utility21

Average utility

per Get

Client datacenter

(secondary)

(secondary)

(primary)

(client only)

9% fail to meet read-my-writeSlide22

Experiment #2: SLA Password checking SLA:22

consistency

latency

strong

150

ms.

1.

2.

utility

1.0

eventual150 ms.0.53.strong1000 ms.0.25Slide23

Experiment #2: Delivered Utility23

Average utility

per Get

Client datacenter

(secondary)

(secondary)

(primary)

(client only)Slide24

Conclusions: Main ContributionsOur Pileus systemprovides a broad choice of consistency guarantees and range of delivered read latencyallows declarative specification of desired consistency and latency through

consistency-based

SLAs

s

elects nodes to maximize expected utility while adapting to varying conditions