CAP Theorem Technologies for Scalable Distribu8on - - PowerPoint PPT Presentation

CAP ¡Theorem ¡ Technologies ¡for ¡Scalable ¡ Distribu8on ¡ ¡

CS4230 ¡ Jay ¡Urbain, ¡Ph.D. ¡

Credits: ¡ “Dynamo: ¡Amazon’s ¡Highly ¡Available ¡Key-­‑value ¡Store,” ¡ ¡ ¡ Giuseppe ¡DeCandia, ¡Deniz ¡Hastorun, ¡Madan ¡Jampani, ¡ Gunavardhan ¡Kakulapa8, ¡Avinash ¡Lakshman, ¡Alex ¡Pilchin, ¡ Swaminathan ¡Sivasubramanian, ¡Peter ¡Vosshall ¡and ¡Werner ¡

• Vogels. ¡

Willet ¡

Graphic ¡thanks ¡to ¡ Migra8ng ¡Your ¡Applica8ons ¡and ¡Processes ¡to ¡the ¡Cloud: ¡Prac8cal ¡Checklist ¡

Topics ¡

• Technologies ¡for ¡Scalable ¡Distribu8on ¡

– Cap ¡Theorem ¡ ¡ – Consistent ¡Hashing ¡ – Vector ¡Clocks ¡ – Sloppy ¡Quorum ¡ – Merkle ¡Hash ¡Trees ¡

• Dynamo: ¡Amazon’s ¡Highly ¡Available ¡

Key-­‑value ¡Store ¡

How ¡much ¡data ¡is ¡a ¡lot? ¡

640K ¡ought ¡to ¡be ¡ enough ¡for ¡anybody. ¡

How ¡much ¡data? ¡

• Google ¡indexes ¡60 ¡trillion ¡web ¡pages ¡(2016). ¡
• It ¡takes ¡over ¡100 ¡petabytes ¡(equivalent ¡to ¡100,000 ¡1TB ¡hard ¡drives) ¡to ¡store ¡it ¡
• all. ¡For ¡comparison ¡Google’s ¡web ¡index ¡was ¡1 ¡trillion ¡pages ¡in ¡2008 ¡and ¡in ¡2000 ¡

it ¡was ¡a ¡meager ¡1 ¡billion. ¡

• Google ¡also ¡indexes ¡private ¡data ¡like ¡email, ¡photos, ¡docs, ¡etc. ¡The ¡private ¡index ¡

is ¡somewhat ¡more ¡recent ¡but ¡has ¡been ¡growing ¡rapidly ¡along ¡with ¡the ¡web ¡

• index. ¡

– haps://www.google.com/insidesearch/howsearchworks/crawling-­‑ indexing.html ¡

• Facebook ¡has ¡a ¡500+ ¡Peta ¡byte ¡data ¡warehouse, ¡and ¡processes ¡>500 ¡TB ¡of ¡new ¡

data ¡daily ¡(2014) ¡ – hap://www.adweek.com/social8mes/orcfile/434041 ¡

• Wayback ¡Machine ¡has ¡~9 ¡PB ¡+ ¡20 ¡TB/week(3/December ¡2014) ¡
• CERN’s ¡LHC: ¡100 ¡PB ¡a ¡year ¡(2015) ¡
• Large ¡Synop8c ¡Survey ¡Telescope ¡(LSST): ¡6-­‑10 ¡PB ¡a ¡year ¡(~2015) ¡

¡ A ¡petabyte ¡(PB) ¡is ¡1015 ¡bytes ¡of ¡data, ¡1,000 ¡terabytes ¡(TB) ¡or ¡1,000,000 ¡gigabytes ¡ (GB). ¡ ¡

Consistency ¡Models ¡in ¡Rela8onal ¡ DBMS ¡

• RDBMS ¡transac8ons ¡are ¡typically ¡described ¡as ¡“ACID” ¡
• transac8ons. ¡ ¡ ¡

– Atomic: ¡The ¡transac8on ¡is ¡indivisible ¡– ¡either ¡all ¡the ¡ statements ¡in ¡the ¡transac8on ¡are ¡applied ¡to ¡the ¡database, ¡

• r ¡none ¡are. ¡

– Consistent: ¡The ¡database ¡remains ¡in ¡a ¡consistent ¡state ¡ before ¡and ¡amer ¡transac8on ¡execu8on. ¡ – Isolated: ¡While ¡mul8ple ¡transac8ons ¡can ¡be ¡executed ¡by ¡

• ne ¡or ¡more ¡users ¡simultaneously, ¡one ¡transac8on ¡should ¡

not ¡see ¡the ¡effects ¡of ¡other ¡concurrent ¡transac8ons. ¡ – Durable: ¡Once ¡a ¡transac8on ¡is ¡commiaed, ¡its ¡changes ¡are ¡ expected ¡to ¡persist. ¡

Consistency ¡Models ¡in ¡Non-­‑rela8onal ¡ DBMS ¡

• One ¡of ¡the ¡most ¡significant ¡differences ¡between ¡the ¡new ¡

genera8on ¡of ¡non-­‑rela8onal ¡(NoSQL) ¡databases ¡and ¡ tradi8onal ¡RDBMS ¡is ¡the ¡way ¡in ¡which ¡consistency ¡of ¡data ¡is ¡

• handled. ¡ ¡ ¡
• In ¡a ¡tradi8onal ¡RDBMS, ¡all ¡users ¡see ¡a ¡consistent ¡view ¡of ¡the ¡
• data. ¡ ¡ ¡
• Once ¡a ¡user ¡commits ¡a ¡transac8on, ¡all ¡subsequent ¡queries ¡

will ¡report ¡that ¡transacFon ¡and ¡no-­‑one ¡will ¡“see” ¡par8al ¡ results ¡of ¡a ¡transac8on. ¡(Note: ¡dependent ¡on ¡the ¡isolaFon ¡ level). ¡

Eventual ¡Consistency ¡

• A ¡compromise ¡between ¡consistency ¡and ¡weak ¡(no ¡

guarantees) ¡consistency ¡is ¡Eventual ¡Consistency. ¡

• Eventual ¡consistency: ¡database ¡may ¡have ¡some ¡

inconsistencies ¡at ¡a ¡point ¡in ¡8me, ¡but ¡it ¡will ¡eventually ¡ become ¡consistent ¡should ¡all ¡updates ¡cease. ¡ ¡ ¡ – I.e., ¡ ¡inconsistencies ¡are ¡transitory: ¡ ¡eventually ¡all ¡nodes ¡ will ¡receive ¡the ¡latest ¡consistent ¡updates. ¡

Remembrance ¡Inc. ¡– ¡Ch. ¡1 ¡

Credits: ¡Kaushik ¡Sathupadi ¡ hap://ksat.me/a-­‑plain-­‑english-­‑introduc8on-­‑to-­‑cap-­‑theorem/ ¡ ¡

Remembrance ¡Inc! ¡-­‑ ¡Never ¡forget, ¡ ¡even ¡without ¡remembering! ¡ ¡ ¡ ¡Ever ¡felt ¡bad ¡that ¡you ¡forget ¡so ¡much? ¡ ¡Don't ¡worry. ¡Help ¡is ¡just ¡a ¡phone ¡ away! ¡ ¡ ¡ ¡ ¡When ¡you ¡need ¡to ¡remember ¡something, ¡just ¡call ¡555-­‑55-­‑REMEM ¡and ¡tell ¡ us ¡what ¡you ¡need ¡to ¡remember. ¡For ¡e.g., ¡call ¡us ¡and ¡let ¡us ¡know ¡of ¡your ¡ boss's ¡phone ¡number, ¡and ¡forget ¡to ¡remember ¡it. ¡when ¡you ¡need ¡to ¡know ¡it ¡

• back. ¡Call ¡back ¡the ¡same ¡number[(555)-­‑-­‑55-­‑REMEM ¡] ¡and ¡we'll ¡tell ¡you ¡what's ¡

your ¡boss's ¡phone ¡number. ¡ ¡ ¡ ¡Charges ¡: ¡only ¡$0.10 ¡per ¡request ¡

• Ch. ¡2 ¡: ¡You ¡scale ¡up ¡

Your ¡venture ¡gets ¡funded ¡by ¡YCombinator. ¡Your ¡idea ¡is ¡so ¡simple, ¡needs ¡nothing ¡ but ¡a ¡paper ¡notebook ¡and ¡phone, ¡yet ¡so ¡effec8ve ¡that ¡it ¡spreads ¡like ¡wild ¡fire. ¡ You ¡start ¡ge@ng ¡hundreds ¡of ¡call ¡every ¡day. ¡ ¡ You ¡see ¡that ¡more ¡and ¡more ¡of ¡your ¡customers ¡have ¡to ¡wait ¡in ¡the ¡queue ¡to ¡ speak ¡to ¡you. ¡Most ¡of ¡them ¡even ¡hang ¡up, ¡8red ¡of ¡the ¡wai8ng. ¡Besides ¡when ¡ you ¡were ¡sick ¡the ¡other ¡day ¡and ¡could ¡not ¡come ¡to ¡work ¡you ¡lost ¡a ¡whole ¡day ¡of ¡

• business. ¡Not ¡to ¡men8on ¡all ¡those ¡dissa8sfied ¡customers ¡who ¡wanted ¡

informa8on ¡on ¡that ¡day. ¡ You ¡decide ¡it’s ¡Fme ¡for ¡you ¡to ¡scale ¡your ¡service ¡and ¡bring ¡in ¡your ¡wife ¡to ¡help ¡

• you. ¡

¡ Your ¡start ¡with ¡a ¡simple ¡plan: ¡

• You ¡and ¡your ¡wife ¡both ¡get ¡an ¡extension ¡phone ¡
• Customers ¡s8ll ¡dial ¡(555)–55-­‑REMEM ¡and ¡need ¡to ¡remember ¡only ¡one ¡

number ¡

• A ¡PBX ¡will ¡route ¡the ¡a ¡customers ¡call ¡to ¡whoever ¡is ¡free ¡

• Ch. ¡3 ¡: ¡“Bad ¡Service” ¡ ¡

Two ¡days ¡amer ¡you ¡implemented ¡the ¡new ¡system, ¡you ¡get ¡a ¡call ¡from ¡your ¡trusted ¡customer ¡

• John. ¡This ¡is ¡how ¡it ¡goes: ¡

¡ John: ¡Hey ¡ You: ¡Glad ¡you ¡called ¡“Remembrance ¡Inc!”. ¡What ¡can ¡I ¡do ¡for ¡you? ¡ John: ¡Can ¡you ¡tell ¡me ¡when ¡is ¡my ¡flight ¡to ¡Boston? ¡ You: ¡Sure.. ¡1 ¡sec ¡sir ¡ (You ¡look ¡up ¡your ¡notebook, ¡wow! ¡there ¡is ¡no ¡entry ¡for ¡“flight ¡date” ¡in ¡John’s ¡page)!!!!! ¡ You: ¡Sir, ¡I ¡think ¡there ¡is ¡a ¡mistake. ¡You ¡never ¡told ¡us ¡about ¡your ¡flight ¡to ¡Boston ¡ John: ¡What! ¡I ¡just ¡called ¡you ¡guys ¡yesterday! ¡(cuts ¡the ¡call!) ¡ ¡ How ¡did ¡that ¡happen? ¡Could ¡John ¡be ¡lying? ¡You ¡think ¡about ¡it ¡for ¡a ¡second ¡and ¡the ¡reason ¡hits ¡ you! ¡Could ¡John’s ¡call ¡yesterday ¡reached ¡your ¡wife? ¡You ¡go ¡to ¡your ¡wife’s ¡desk ¡and ¡check ¡her ¡

• notebook. ¡Sure ¡enough ¡it’s ¡in ¡there. ¡You ¡tell ¡this ¡to ¡your ¡wife ¡and ¡she ¡realizes ¡the ¡problem ¡too. ¡

¡ What ¡a ¡terrible ¡flaw ¡in ¡your ¡distributed ¡design! ¡Your ¡distributed ¡system ¡is ¡not ¡consistent! ¡There ¡ could ¡always ¡be ¡a ¡chance ¡that ¡a ¡customer ¡updates ¡something ¡which ¡goes ¡to ¡either ¡you ¡or ¡your ¡ wife, ¡and ¡when ¡the ¡next ¡call ¡from ¡the ¡customer ¡is ¡routed ¡to ¡another ¡person ¡there ¡will ¡not ¡be ¡a ¡ consistent ¡reply ¡from ¡Remembrance ¡Inc! ¡

• Ch. ¡4: ¡Fix ¡the ¡Consistency ¡problem ¡

Whenever ¡any ¡one ¡of ¡us ¡get ¡a ¡call ¡for ¡an ¡update, ¡before ¡compleFng ¡the ¡call ¡we ¡tell ¡the ¡other ¡ person ¡(transacFon: ¡consistency). ¡ This ¡way ¡both ¡of ¡us ¡note ¡down ¡any ¡updates. ¡ When ¡there ¡is ¡a ¡call ¡for ¡search, ¡we ¡don’t ¡need ¡to ¡talk ¡with ¡the ¡other ¡person. ¡Since ¡both ¡of ¡us ¡ have ¡the ¡latest ¡updated ¡informa8on ¡in ¡both ¡of ¡our ¡notebooks ¡we ¡can ¡just ¡refer ¡to ¡it. ¡ ¡ Problem: ¡“update” ¡request ¡has ¡to ¡involve ¡both ¡of ¡us, ¡and ¡we ¡cannot ¡work ¡in ¡parallel ¡during ¡ that ¡Fme. ¡E.g. ¡when ¡you ¡get ¡an ¡update ¡request ¡and ¡telling ¡me ¡to ¡update ¡too, ¡I ¡cannot ¡take ¡other ¡

• calls. ¡But ¡that’s ¡okay ¡because ¡most ¡calls ¡we ¡get ¡anyway ¡are ¡“search” ¡(a ¡customer ¡updates ¡once ¡

and ¡asks ¡many ¡8mes) ¡. ¡Besides, ¡we ¡cannot ¡give ¡wrong ¡informa8on ¡at ¡any ¡cost. ¡ ¡ “Neat” ¡your ¡wife ¡says, ¡“but ¡there ¡is ¡one ¡more ¡flaw ¡in ¡this ¡system ¡that ¡you ¡haven’t ¡thought ¡of: ¡ What ¡if ¡one ¡of ¡us ¡doesn’t ¡report ¡to ¡work ¡on ¡a ¡parFcular ¡day? ¡On ¡that ¡day, ¡then, ¡we ¡won’t ¡be ¡ able ¡to ¡take ¡“any” ¡update ¡calls, ¡because ¡the ¡other ¡person ¡cannot ¡be ¡updated! ¡ ¡ ¡ We ¡will ¡have ¡an ¡Availability ¡problem ¡, ¡I.e., ¡if ¡an ¡update ¡request ¡comes ¡to ¡me ¡I ¡will ¡never ¡be ¡able ¡ to ¡complete ¡that ¡call ¡because ¡even ¡though ¡I ¡have ¡wriaen ¡the ¡update ¡in ¡my ¡note ¡book, ¡I ¡can ¡never ¡ update ¡you. ¡So ¡I ¡can ¡never ¡complete ¡the ¡call!” ¡

• Ch. ¡5: ¡You ¡come ¡up ¡with ¡the ¡greatest ¡solu8on ¡ever! ¡

You ¡begin ¡to ¡realize ¡a ¡liale ¡bit ¡on ¡why ¡a ¡distributed ¡system ¡might ¡not ¡be ¡as ¡easy ¡as ¡you ¡thought ¡ at ¡first. ¡Is ¡it ¡that ¡difficult ¡to ¡come ¡up ¡with ¡a ¡solu8on ¡that ¡could ¡be ¡both ¡“Consistent ¡and ¡ Available?” ¡ ¡

• Whenever ¡any ¡one ¡of ¡us ¡gets ¡a ¡call ¡for ¡an ¡update ¡before ¡comple8ng ¡the ¡call, ¡if ¡the ¡other ¡

person ¡is ¡available ¡we ¡tell ¡the ¡other ¡person. ¡This ¡way ¡both ¡of ¡us ¡note ¡down ¡any ¡updates ¡

• But ¡if ¡the ¡other ¡person ¡is ¡not ¡available ¡(doesn’t ¡report ¡to ¡work) ¡we ¡send ¡the ¡other ¡person ¡an ¡

email ¡about ¡the ¡update. ¡

• The ¡next ¡day ¡when ¡the ¡other ¡person ¡comes ¡to ¡work ¡amer ¡taking ¡a ¡day ¡off, ¡He ¡first ¡goes ¡

through ¡all ¡the ¡emails, ¡updates ¡his ¡note ¡book ¡accordingly.. ¡before ¡taking ¡his ¡first ¡call. ¡ ¡ Genius! ¡Your ¡wife ¡says. ¡I ¡can’t ¡find ¡any ¡flaws ¡in ¡this ¡systems. ¡Let’s ¡put ¡it ¡to ¡use. ¡Remembrance ¡ Inc! ¡is ¡now ¡both ¡consistent ¡and ¡available! ¡

• Ch. ¡6: ¡Your ¡wife ¡gets ¡angry ¡ ¡

Everything ¡goes ¡well ¡for ¡a ¡while. ¡Your ¡system ¡is ¡consistent. ¡Your ¡system ¡works ¡well ¡even ¡when ¡

• ne ¡of ¡you ¡doesn’t ¡report ¡to ¡work. ¡ ¡

But ¡what ¡if ¡both ¡of ¡you ¡report ¡to ¡work ¡and ¡one ¡of ¡you ¡doesn’t ¡update ¡the ¡other ¡person? ¡ ¡ Remember ¡all ¡those ¡days ¡you’ve ¡been ¡waking ¡your ¡wife ¡up ¡early ¡with ¡your ¡Greatest-­‑idea-­‑ever-­‑ bullshit? ¡ ¡ What ¡if ¡your ¡wife ¡decides ¡to ¡take ¡calls, ¡but ¡is ¡too ¡angry ¡with ¡you ¡and ¡decides ¡not ¡to ¡update ¡you ¡ for ¡a ¡day? ¡Your ¡idea ¡totally ¡breaks! ¡Your ¡idea ¡so ¡far ¡is ¡good ¡for ¡consistency ¡and ¡availability ¡but ¡is ¡ not ¡Par55on ¡Tolerant! ¡ ¡ The ¡big ¡idea: ¡ You ¡can ¡decide ¡to ¡be ¡par55on ¡tolerant ¡and ¡consistent ¡by ¡deciding ¡not ¡to ¡take ¡any ¡calls ¡un8l ¡you ¡ patch ¡things ¡up ¡with ¡your ¡wife. ¡Then ¡your ¡system ¡will ¡not ¡be ¡available ¡during ¡that ¡8me… ¡ ¡ Or ¡ ¡ You ¡can ¡decide ¡to ¡be ¡par55on ¡and ¡available ¡to ¡your ¡customers, ¡but ¡not ¡consistent ¡with ¡your ¡ wife’s ¡data. ¡ ¡

• Ch. ¡6: ¡Conclusion ¡

CAP ¡Theorem: ¡ When ¡you ¡are ¡designing ¡a ¡distributed ¡system ¡you ¡cannot ¡achieve ¡all ¡three ¡of ¡Consistency, ¡ Availability ¡and ¡Par88on ¡tolerance. ¡You ¡can ¡pick ¡only ¡two ¡of: ¡

• Consistency: ¡Your ¡customers, ¡once ¡they ¡have ¡updated ¡informa8on ¡with ¡you, ¡will ¡always ¡get ¡

the ¡most ¡updated ¡informa8on ¡when ¡they ¡call ¡subsequently. ¡No ¡maaer ¡how ¡quickly ¡they ¡call ¡

• back. ¡
• Availability: ¡Remembrance ¡Inc. ¡will ¡always ¡be ¡available ¡for ¡calls. ¡
• ParFFon ¡Tolerance: ¡Remembrance ¡Inc. ¡will ¡work ¡even ¡if ¡there ¡is ¡a ¡communica8on ¡loss ¡

between ¡you ¡and ¡your ¡wife! ¡

Epilogue: ¡Eventual ¡Consistency ¡with ¡a ¡run ¡around ¡clerk ¡ ¡

Eventual ¡consistency: ¡

• You ¡can ¡have ¡a ¡run ¡around ¡clerk, ¡who ¡will ¡update ¡other’s ¡notebook ¡when ¡one ¡of ¡

you ¡or ¡your ¡wife’s ¡note ¡books ¡is ¡updated. ¡ ¡

• The ¡greatest ¡benefit ¡of ¡this ¡is ¡that, ¡the ¡clerk ¡can ¡work ¡in ¡the ¡background, ¡and ¡one ¡
• f ¡your ¡or ¡your ¡wife’s ¡“update” ¡doesn’t ¡have ¡to ¡block, ¡wai8ng ¡for ¡the ¡other ¡one ¡to ¡
• update. ¡ ¡
• This ¡is ¡how ¡many ¡NoSql ¡systems ¡work, ¡one ¡node ¡updates ¡itself ¡locally ¡and ¡a ¡

background ¡process ¡synchronizes ¡all ¡other ¡nodes ¡accordingly. ¡ ¡

• The ¡only ¡problem ¡is ¡that ¡you ¡will ¡loose ¡consistency ¡for ¡some ¡8me. ¡E.g., ¡a ¡

customer’s ¡call ¡reaches ¡your ¡wife ¡first ¡and ¡before ¡the ¡clerk ¡has ¡a ¡chance ¡to ¡update ¡ your ¡notebook ¡, ¡the ¡customer ¡calls ¡back ¡and ¡it ¡reaches ¡you. ¡Then ¡he ¡won’t ¡get ¡a ¡ consistent ¡reply. ¡ ¡

• Not ¡at ¡all ¡a ¡bad ¡idea ¡if ¡such ¡cases ¡are ¡limited. ¡E.g., ¡assuming ¡a ¡customer ¡won’t ¡

forget ¡things ¡so ¡quickly ¡that ¡he ¡calls ¡back ¡in ¡5 ¡minutes. ¡Depends ¡on ¡your ¡ applica8on! ¡

• Note: ¡MVCC ¡– ¡MulF-­‑valued ¡Concurrency ¡Control ¡

CAP ¡Theorem ¡

• In ¡2000, ¡ ¡Eric ¡Brewer ¡outlined ¡the ¡CAP ¡(Brewer’s) ¡Theorem. ¡ ¡ ¡ ¡
• The ¡CAP ¡theorem ¡states ¡that ¡in ¡a ¡distributed ¡database ¡

system, ¡you ¡can ¡only ¡have ¡at ¡most ¡two ¡of ¡the ¡following ¡three ¡ characteris8cs: ¡ – Consistency: ¡All ¡nodes ¡in ¡the ¡(compu8ng) ¡cluster ¡see ¡ exactly ¡the ¡same ¡data ¡at ¡any ¡point ¡in ¡8me. ¡ – Availability: ¡Failure ¡of ¡a ¡node ¡does ¡not ¡render ¡the ¡ database ¡inopera8ve. ¡ – Par88on ¡tolerance: ¡ ¡Nodes ¡can ¡s8ll ¡func8on ¡when ¡ communica8on ¡with ¡other ¡groups ¡of ¡nodes ¡is ¡lost. ¡

CAP ¡Theorem ¡

• Interpreta8on ¡and ¡implementa8ons ¡of ¡CAP ¡theorem ¡vary, ¡ ¡

but ¡most ¡of ¡the ¡NoSQL ¡database ¡systems ¡favor ¡parFFon ¡ tolerance ¡and ¡availability ¡over ¡strong ¡consistency. ¡

NoSQL ¡

• NoSQL ¡is ¡a ¡term ¡used ¡to ¡describe ¡high-­‑performance, ¡non-­‑

rela8onal ¡databases. ¡ ¡

• NoSQL ¡databases ¡u8lize ¡a ¡variety ¡of ¡data ¡models, ¡including ¡

document, ¡graph, ¡key-­‑value, ¡and ¡columnar. ¡ ¡

• NoSQL ¡databases ¡are ¡widely ¡recognized ¡for ¡ease ¡of ¡

development, ¡scalable ¡performance, ¡high ¡availability, ¡and ¡

• resilience. ¡ ¡

SQL ¡vs ¡NoSQL ¡Database ¡Comparison ¡

SQL ¡vs ¡NoSQL ¡Database ¡Comparison ¡

haps://aws.amazon.com/nosql/? sc_channel=PS&sc_campaign=pac_ps_q4&sc_publisher=google&sc_medium=dynamodb_hv_b_ pac_q42017&sc_content=sitelink&sc_detail=dynamodb&sc_category=dynamodb&sc_segment= webp&sc_matchtype=e&sc_country=US&sc_geo=namer&sc_outcome=pac&s_kwcid=AL!4422! 3!224596745488!e!!g!!dynamodb&ef_id=WM1YAAAAAHwO1Q7Z:20171022182636:s ¡

Introduc8on ¡-­‑ ¡Amazon ¡

• Amazon ¡runs ¡a ¡world-­‑wide ¡e-­‑commerce ¡pla•orm ¡that ¡serves ¡

hundreds ¡of ¡millions ¡of ¡customers ¡at ¡peak ¡8mes ¡using ¡hundreds ¡

• f ¡thousands ¡of ¡servers ¡located ¡in ¡many ¡data ¡centers ¡around ¡the ¡

world ¡(availability ¡zones!). ¡

• Opera8onal ¡requirements: ¡

– Performance ¡ – Reliability ¡ – Efficiency ¡ – Scalability ¡for ¡con8nuous ¡growth: ¡horizontal ¡scalability ¡ ¡

¡

Services ¡provided ¡through ¡loosely ¡coupled ¡ distributed ¡architecture ¡

• Applica8on ¡can ¡deliver ¡its ¡

func8onality ¡in ¡bounded ¡8me ¡if: ¡ ¡ – Every ¡dependency ¡in ¡the ¡pla•orm ¡ delivers ¡its ¡func8onality ¡with ¡ even ¡8ghter ¡bounds. ¡ – Like ¡factory ¡cycle ¡8me. ¡

• Example: ¡ ¡

– service ¡guaranteeing ¡that ¡it ¡will ¡ provide ¡a ¡response ¡within ¡300ms ¡ for ¡99.9% ¡of ¡its ¡requests ¡for ¡a ¡ peak ¡client ¡load ¡of ¡500 ¡requests ¡ per ¡second. ¡

Service-­‑oriented ¡architecture ¡of ¡ ¡ Amazon’s ¡plaSorm ¡

System ¡Architecture ¡

In ¡addi8on ¡to ¡the ¡actual ¡data ¡persistence ¡component, ¡the ¡system ¡ needs ¡scalable ¡and ¡robust ¡solu8ons ¡for: ¡

• Load ¡balancing ¡
• Failure ¡recovery ¡ ¡
• Replica ¡synchroniza8on ¡
• Overload ¡handling, ¡auto-­‑scaling ¡
• State ¡transfer ¡
• Concurrency ¡and ¡job ¡scheduling ¡
• Request ¡marshalling ¡
• Request ¡rou8ng ¡
• System ¡monitor ¡and ¡alarming ¡ ¡
• Configura8on ¡management ¡

Mee8ng ¡reliability ¡& ¡scalability ¡needs ¡

• Need ¡to ¡provide ¡control ¡over ¡tradeoffs ¡for ¡diverse ¡set ¡of ¡

applica8ons ¡using ¡mul8ple ¡storage ¡technologies: ¡

– Availability ¡ – Consistency ¡ – Par88on ¡tolerance ¡ – Cost-­‑effec8veness ¡ – Performance ¡

• To ¡meet ¡the ¡reliability ¡and ¡scaling ¡needs, ¡Amazon ¡has ¡

developed ¡a ¡number ¡of ¡storage ¡technologies. ¡ – S3, ¡EBS, ¡SimpleDB, ¡RDS, ¡Redshim, ¡and ¡Dynamo ¡

• Dynamo ¡is ¡used ¡to ¡manage ¡the ¡state ¡of ¡services ¡that ¡have ¡

very ¡high ¡reliability/availability ¡and ¡scalability ¡requirements. ¡

Key ¡requirements ¡

• Key ¡requirement: ¡reliability/availability ¡

– Slightest ¡outage ¡has ¡significant ¡financial ¡consequences ¡and ¡ impacts ¡customer ¡trust. ¡

• To ¡support ¡con8nuous ¡growth, ¡pla•orm ¡needs ¡to ¡be ¡highly ¡
• scalable. ¡
• Key ¡organiza8on ¡lesson ¡learned: ¡

– The ¡Reliability ¡and ¡scalability ¡of ¡a ¡system ¡is ¡dependent ¡on ¡ how ¡its ¡applica5on ¡state ¡is ¡managed. ¡ ¡

Observa8on ¡

• Many ¡services ¡require ¡only ¡a ¡simple ¡primary-­‑key ¡access ¡to ¡a ¡

data ¡store: ¡

– Best ¡seller ¡lists ¡ – Shopping ¡carts ¡ – Customer ¡preferences ¡ – Session ¡management ¡ – Sales ¡rank ¡ – Product ¡catalog ¡

¡System ¡Requirements ¡

• The ¡Dynamo ¡distributed ¡storage ¡system: ¡

– Scalable ¡ – Simple: ¡key-­‑value ¡ – Highly ¡available ¡ – Par55on ¡tolerance ¡via ¡redundancy ¡ – Able ¡to ¡guarantee ¡Service ¡Level ¡Agreements ¡(SLA) ¡to ¡ internal ¡and ¡external ¡customers. ¡

¡ ¡

Dynamo ¡

• Dynamo ¡uses ¡a ¡synthesis ¡of ¡well ¡known ¡techniques ¡to ¡achieve ¡

scalability ¡and ¡availability: ¡

– Data ¡is ¡par88oned ¡and ¡replicated ¡using ¡hashing. ¡ – Consistency ¡is ¡facilitated ¡by ¡object ¡versioning. ¡

• Consistency ¡among ¡replicas ¡during ¡updates ¡is ¡maintained ¡by ¡a: ¡

– Quorum-­‑like ¡technique ¡ ¡ – Decentralized ¡replica ¡synchroniza8on ¡protocol ¡

System ¡Interface ¡

Stores ¡objects ¡associated ¡with ¡a ¡key ¡through ¡two ¡opera8ons: ¡ get() ¡and ¡put(). ¡ ¡

• get(key) ¡ ¡

– locates ¡the ¡object ¡replicas ¡associated ¡with ¡the ¡key ¡in ¡the ¡storage ¡system ¡and ¡ returns ¡a ¡single ¡object, ¡or ¡a ¡list ¡of ¡objects ¡with ¡conflicFng ¡versions ¡along ¡with ¡a ¡

• context. ¡
• put(key, ¡context, ¡object) ¡ ¡

– determines ¡where ¡the ¡replicas ¡of ¡the ¡object ¡should ¡be ¡placed ¡based ¡on ¡the ¡ associated ¡key, ¡and ¡writes ¡the ¡replicas ¡to ¡disk. ¡

• Notes: ¡

– The ¡context ¡encodes ¡system ¡metadata ¡about ¡the ¡object ¡that ¡is ¡opaque ¡to ¡the ¡ caller ¡and ¡includes ¡informa8on ¡such ¡as ¡the ¡version ¡of ¡the ¡object. ¡ – Context ¡info ¡is ¡stored ¡with ¡the ¡object ¡to ¡verify ¡the ¡validity ¡of ¡the ¡put ¡request. ¡ – Key ¡(128 ¡bits) ¡and ¡object ¡is ¡treated ¡as ¡BLOB. ¡

Summary ¡of ¡techniques ¡used ¡in ¡Dynamo ¡and ¡ their ¡advantages ¡ ¡

Problem Technique Advantage

Partitioning Consistent Hashing* Incremental Scalability High Availability for writes Vector clocks with reconciliation during reads Logical clocks for read consistency, Version is decoupled from update rates. Handling temporary failures Sloppy Quorum and hinted handoff Provides high availability and durability guarantee when some of the replicas are not available. Recovering from permanent failures Anti-entropy using Merkle trees (hash tree) Synchronizes divergent replicas in the background. Membership and failure detection Gossip-based membership protocol and failure detection. Preserves symmetry and avoids having a centralized registry for storing membership and node liveness information. Bounded time.

*In ¡most ¡tradi8onal ¡hash ¡tables, ¡a ¡change ¡in ¡the ¡number ¡of ¡array ¡slots ¡causes ¡ nearly ¡all ¡keys ¡to ¡be ¡remapped. ¡Only ¡K/n ¡(keys/slots) ¡needs ¡remapping. ¡

Par88oning ¡

• Use ¡consistent ¡hashing ¡to ¡parFFon ¡load ¡across ¡mul8ple ¡

storage ¡hosts. ¡

• Output ¡range ¡of ¡hash ¡func8on ¡treated ¡as ¡a ¡fixed ¡circular ¡ring. ¡
• Each ¡node ¡is ¡assigned ¡a ¡random ¡value ¡within ¡this ¡space ¡(ring). ¡
• Each ¡data ¡item ¡iden8fied ¡by ¡a ¡key ¡is ¡assigned ¡to ¡a ¡node ¡by ¡

hashing ¡the ¡data ¡item’s ¡key ¡to ¡yield ¡its ¡posi8on ¡on ¡the ¡ring. ¡

• Walk ¡the ¡ring ¡clockwise ¡to ¡find ¡the ¡first ¡node ¡with ¡a ¡posi8on ¡

larger ¡than ¡the ¡item’s ¡posi8on. ¡ Consistent ¡Hashing ¡and ¡Random ¡Trees: ¡Distributed ¡Caching ¡ Protocols ¡for ¡Relieving ¡Hot ¡Spots ¡on ¡the ¡World ¡Wide ¡Web ¡by ¡ David ¡Karger ¡et ¡al). ¡

Consistent ¡Hashing ¡1 ¡

• The ¡need ¡for ¡consistent ¡hashing ¡arose ¡from ¡limita8ons ¡

experienced ¡while ¡running ¡collec8ons ¡of ¡caching ¡machines ¡-­‑ ¡ web ¡caches, ¡for ¡example. ¡

• If ¡you ¡have ¡a ¡collec8on ¡of ¡n ¡cache ¡machines ¡then ¡a ¡common ¡

way ¡of ¡load ¡balancing ¡across ¡them ¡is ¡to ¡put ¡object ¡o ¡in ¡cache ¡ machine ¡number ¡hash(o) ¡mod ¡n. ¡

• This ¡works ¡well ¡un8l ¡you ¡add ¡or ¡remove ¡cache ¡machines ¡(for ¡

whatever ¡reason), ¡for ¡then ¡n ¡changes ¡and ¡every ¡object ¡is ¡ hashed ¡to ¡a ¡new ¡loca8on. ¡ ¡

Consistent ¡Hashing ¡2 ¡

• It ¡would ¡be ¡nice ¡if, ¡when ¡a ¡cache ¡machine ¡was ¡added, ¡it ¡took ¡

its ¡fair ¡share ¡of ¡objects ¡from ¡all ¡the ¡other ¡cache ¡machines. ¡ ¡

• Equally, ¡when ¡a ¡cache ¡machine ¡was ¡removed, ¡it ¡would ¡be ¡nice ¡

if ¡its ¡objects ¡were ¡shared ¡between ¡the ¡remaining ¡machines. ¡

• This ¡is ¡what ¡consistent ¡hashing ¡does ¡-­‑ ¡consistently ¡maps ¡
• bjects ¡to ¡the ¡same ¡cache ¡machine, ¡as ¡far ¡as ¡is ¡possible. ¡

Consistent ¡Hashing ¡3 ¡

• The ¡basic ¡idea ¡behind ¡the ¡consistent ¡hashing ¡algorithm ¡is ¡to ¡

hash ¡both ¡objects ¡and ¡caches ¡using ¡the ¡same ¡hash ¡func8on. ¡ ¡

• The ¡reason ¡to ¡do ¡this ¡is ¡to ¡map ¡the ¡cache ¡to ¡an ¡interval, ¡which ¡

will ¡contain ¡a ¡number ¡of ¡object ¡hashes. ¡ ¡

• If ¡the ¡cache ¡is ¡removed ¡then ¡its ¡interval ¡is ¡taken ¡over ¡by ¡a ¡

cache ¡with ¡an ¡adjacent ¡interval. ¡All ¡the ¡other ¡caches ¡remain ¡

• unchanged. ¡

Consistent ¡Hashing ¡Example ¡1 ¡

• The ¡hash ¡func8on ¡actually ¡maps ¡objects ¡and ¡caches ¡to ¡a ¡number ¡range. ¡
• The ¡circle ¡has ¡a ¡number ¡of ¡objects ¡(1, ¡2, ¡3, ¡4) ¡and ¡caches ¡(A, ¡B, ¡C) ¡marked ¡

at ¡the ¡points ¡that ¡they ¡hash ¡to. ¡

• To ¡find ¡which ¡cache ¡an ¡object ¡goes ¡in, ¡move ¡clockwise ¡round ¡the ¡circle ¡

un8l ¡we ¡find ¡a ¡cache ¡point. ¡So ¡object ¡1 ¡and ¡4 ¡belong ¡in ¡cache ¡A, ¡object ¡2 ¡ belongs ¡in ¡cache ¡B ¡and ¡object ¡3 ¡belongs ¡in ¡cache ¡C. ¡

Consistent ¡Hashing ¡Example ¡2 ¡

• Consider ¡what ¡happens ¡if ¡cache ¡C ¡is ¡removed: ¡object ¡3 ¡now ¡

belongs ¡in ¡cache ¡A, ¡and ¡all ¡the ¡other ¡object ¡mappings ¡are ¡ unchanged ¡(lem). ¡ ¡

• If ¡then ¡another ¡cache ¡D ¡is ¡added ¡in ¡the ¡posi8on ¡marked ¡it ¡will ¡

take ¡objects ¡3 ¡and ¡4, ¡leaving ¡only ¡object ¡1 ¡belonging ¡to ¡A ¡ (right). ¡

Consistent ¡Hashing ¡Example ¡2 ¡

Java ¡implementa8on: ¡ hap://www.tom-­‑e-­‑white.com/2007/11/consistent-­‑hashing.html ¡ ¡

• This ¡works ¡well, ¡except ¡the ¡size ¡of ¡the ¡intervals ¡assigned ¡to ¡

each ¡cache ¡is ¡hit ¡and ¡miss. ¡ ¡

• The ¡solu8on ¡to ¡this ¡problem ¡is ¡to ¡introduce ¡the ¡idea ¡of ¡

"virtual ¡nodes", ¡which ¡are ¡replicas ¡of ¡cache ¡points ¡in ¡the ¡

• circle. ¡ ¡
• So ¡whenever ¡we ¡add ¡a ¡cache ¡we ¡create ¡a ¡number ¡of ¡points ¡in ¡

the ¡circle ¡for ¡it. ¡

Data ¡Versioning ¡

• Dynamo ¡provides ¡eventual ¡consistency. ¡
• Allows ¡updates ¡to ¡be ¡propagated ¡to ¡all ¡replicas ¡asynchronously. ¡
• A ¡put() ¡call ¡may ¡return ¡to ¡its ¡caller ¡before ¡the ¡update ¡has ¡been ¡

applied ¡to ¡all ¡of ¡the ¡replicas. ¡

• A ¡get() ¡call ¡may ¡return ¡many ¡versions ¡of ¡the ¡same ¡object. ¡
• Challenge: ¡ ¡

– an ¡object ¡having ¡dis8nct ¡version ¡sub-­‑histories, ¡which ¡the ¡system ¡ will ¡need ¡to ¡reconcile ¡in ¡the ¡future. ¡

• Solu8on: ¡ ¡

– use ¡vector ¡clocks ¡in ¡order ¡to ¡capture ¡causality ¡between ¡ different ¡versions ¡of ¡the ¡same ¡object. ¡

Vector ¡Clocks ¡

• Algorithm ¡for ¡genera8ng ¡a ¡par8al ¡ordering ¡of ¡events ¡in ¡

a ¡distributed ¡system ¡and ¡detec8ng ¡causality ¡viola8ons. ¡

• Based ¡on ¡Lamport ¡Fmestamps: ¡ ¡interprocess ¡messages ¡

contain ¡the ¡state ¡of ¡the ¡sending ¡process's ¡logical ¡clock. ¡ ¡

• A ¡vector ¡clock ¡of ¡a ¡system ¡of ¡N ¡processes ¡is ¡an ¡array/vector ¡
• f ¡N ¡logical ¡clocks. ¡
• One ¡clock ¡per ¡process; ¡a ¡local ¡"smallest ¡possible ¡values" ¡copy ¡
• f ¡the ¡global ¡clock-­‑array ¡is ¡kept ¡in ¡each ¡process. ¡

Vector ¡Clocks ¡– ¡Update ¡Rules ¡

• Ini8ally ¡all ¡clocks ¡are ¡zero. ¡
• Each ¡8me ¡a ¡process ¡experiences ¡an ¡internal ¡event, ¡it ¡

increments ¡its ¡own ¡logical ¡clock ¡in ¡the ¡vector ¡by ¡one. ¡

• Each ¡8me ¡a ¡process ¡prepares ¡to ¡send ¡a ¡message, ¡it ¡

increments ¡its ¡own ¡ ¡logical ¡clock ¡ ¡in ¡the ¡vector ¡by ¡one ¡and ¡ then ¡sends ¡its ¡en8re ¡vector ¡along ¡with ¡the ¡message ¡being ¡

• sent. ¡
• Each ¡8me ¡a ¡process ¡receives ¡a ¡message, ¡it ¡increments ¡its ¡own ¡ ¡

logical ¡clock ¡ ¡in ¡the ¡vector ¡by ¡one ¡and ¡updates ¡each ¡element ¡ in ¡its ¡vector ¡by ¡taking ¡the ¡maximum ¡of ¡the ¡value ¡in ¡its ¡own ¡ vector ¡clock ¡and ¡the ¡value ¡in ¡the ¡vector ¡in ¡the ¡received ¡ message ¡(for ¡every ¡element). ¡

Vector ¡Clocks ¡– ¡Update ¡Rules ¡

Events ¡in ¡the ¡blue ¡region ¡are ¡the ¡causes ¡leading ¡to ¡event ¡B4, ¡whereas ¡those ¡in ¡ the ¡red ¡region ¡are ¡the ¡effects ¡of ¡event ¡B4 ¡

Sloppy ¡Quorum ¡

• To ¡maintain ¡consistency ¡among ¡its ¡replicas, ¡Dynamo ¡uses ¡a ¡

consistency ¡protocol ¡similar ¡to ¡those ¡used ¡in ¡quorum ¡systems. ¡

• Two ¡configurable ¡values: ¡R ¡and ¡W. ¡
• R/W ¡signify ¡the ¡minimum ¡number ¡of ¡nodes ¡that ¡must ¡

par8cipate ¡in ¡a ¡successful ¡read/write ¡opera8on ¡(from ¡top ¡N ¡in ¡ preference ¡list). ¡

• Se„ng ¡R ¡+ ¡W ¡> ¡N ¡yields ¡a ¡quorum-­‑like ¡system. ¡
• In ¡this ¡model, ¡the ¡latency ¡of ¡a ¡get ¡(or ¡put) ¡opera8on ¡is ¡

dictated ¡by ¡the ¡slowest ¡of ¡the ¡R ¡(or ¡W) ¡replicas. ¡ ¡

• For ¡this ¡reason, ¡R ¡and ¡W ¡are ¡usually ¡configured ¡to ¡be ¡less ¡

than ¡N, ¡to ¡provide ¡beaer ¡latency. ¡I.e., ¡sloppy. ¡

Mekle ¡Hash ¡Trees ¡

• Replica ¡synchroniza8on: ¡ ¡

– Every ¡non-­‑leaf ¡node ¡is ¡labeled ¡with ¡ the ¡hash ¡of ¡the ¡labels ¡of ¡its ¡children ¡ nodes, ¡i.e., ¡each ¡node ¡maintains ¡a ¡ separate ¡Merkle ¡(hash) ¡tree ¡for ¡each ¡ key ¡range. ¡ – Allows ¡two ¡nodes ¡to ¡compare ¡trees ¡to ¡ see ¡if ¡they ¡are ¡consistent ¡when ¡ synchronizing ¡replicas. ¡ – Allow ¡efficient ¡and ¡secure ¡verifica8on ¡

• f ¡the ¡contents ¡of ¡larger ¡data ¡
• structures. ¡ ¡

Gossip-­‑based ¡Message ¡Protocol ¡

• Membership ¡and ¡Failure ¡Detec8on: ¡ ¡

– Gossip-­‑based ¡message ¡protocol ¡to ¡propagate ¡membership ¡ changes ¡in ¡a ¡ring. ¡ – Inspired ¡by ¡the ¡form ¡of ¡gossip ¡seen ¡in ¡social ¡networks. ¡ – Involves ¡periodic, ¡pairwise, ¡inter-­‑process ¡interac8ons. ¡ – Informa8on ¡exchanged ¡during ¡interac8ons ¡of ¡bounded ¡

• size. ¡

– Reliability ¡not ¡assured. ¡

Amazon ¡Implementa8on ¡

• Each ¡storage ¡node ¡has ¡three ¡main ¡somware ¡components: ¡ ¡

1. Request ¡coordina8on ¡ 2. Membership ¡and ¡failure ¡detec8on ¡ 3. Local ¡persistence ¡engine ¡

• All ¡components ¡implemented ¡in ¡Java ¡
• Local ¡persistence ¡component ¡allows ¡for ¡different ¡storage ¡engines ¡to ¡

be ¡plugged ¡in: ¡ – Berkeley ¡Database ¡(BDB) ¡Transac8onal ¡Data ¡Store: ¡object ¡< ¡tens ¡

• f ¡kilobytes. ¡

– MySQL: ¡object ¡of ¡> ¡tens ¡of ¡kilobytes. ¡ – BDB ¡Java ¡Edi8on, ¡in ¡memory, ¡etc. ¡

• Pluggable ¡persistence ¡component ¡best ¡suited ¡for ¡applica8on’s ¡

access ¡paaerns. ¡

Evalua8on ¡– ¡ ¡ Shows ¡consistent ¡latency ¡

Write ¡latencies ¡ ¡ @99.9th ¡percen8le ¡ ~200ms ¡

Evalua8on ¡

Can ¡trade ¡off ¡ ¡ Durability ¡guarantees ¡ ¡ for ¡performance ¡and ¡ use ¡buffered ¡writes ¡

Lessons ¡Learned ¡

• Business ¡logic ¡reconcilia8on ¡

– Client ¡object ¡performs ¡its ¡own ¡reconcilia8on ¡logic. ¡

• Timestamp ¡based ¡reconcilia8on ¡

– Last ¡write ¡wins ¡

• High-­‑performance ¡read ¡engine ¡

– R=1, ¡W=N ¡