Uber के ledger डेटा को DynamoDB से LedgerStore में migrate करना

• पिछले हफ़्ते Uber के अतिरिक्त purpose-built ledger-style database, LedgerStore(LSG), का अध्ययन किया गया था.
• इस हफ़्ते यह देखा गया है कि Uber ने अपने business-critical ledger डेटा को LSG में कैसे migrate किया.
• 1 trillion से अधिक entries (कई petabytes डेटा) को बिना रुकावट और पारदर्शी तरीके से कैसे move किया गया, और इस प्रक्रिया में क्या सीखा गया, इस पर चर्चा की गई है.

इतिहास

• Gulfstream, Uber का payments platform है, जिसे 2017 में DynamoDB का उपयोग करके launch किया गया था.
• Uber के scale पर DynamoDB महँगा पड़ने लगा, इसलिए केवल 12 हफ़्तों का डेटा (hot data) DynamoDB में रखा गया और पुराना डेटा (cold data) Uber के blobstore, TerraBlob, में store किया जाने लगा.
• लंबी अवधि के समाधान के रूप में LSG का उपयोग करना लक्ष्य था. LSG को payments-style डेटा store करने के लिए purpose-built बनाया गया था.
• LSG की मुख्य विशेषताएँ:
  • verifiable immutability (cryptographic signatures का उपयोग कर यह सत्यापित किया जा सकता है कि records बदले नहीं गए हैं)
  • cost management के लिए tiered storage (hot data को request serve करने के लिए उपयुक्त स्थान पर, cold data को storage-optimized स्थान पर रखा जाता है)
  • eventually consistent secondary indexes के latency में सुधार
• 2021 तक Gulfstream डेटा store करने के लिए DynamoDB, TerraBlob, और LSG के संयोजन का उपयोग कर रहा था.
  • DynamoDB: पिछले 12 हफ़्तों का डेटा
  • TerraBlob: cold data
  • LSG: डेटा लिखने और migration के target के रूप में

migration क्यों करना था?

• immutability के कारण LSG, ledger-style डेटा store करने के लिए अधिक उपयुक्त है.
• LSG पर जाने से recurring cost savings काफ़ी अधिक थीं.
• तीन storage systems से एक storage system पर आने से Gulfstream service के code और design को सरल बनाया जा सकता था.
• LSG ने कम indexing latency का वादा किया, और Uber के data centers के भीतर on-premises चलने के कारण तेज़ network latency भी प्रदान की.

डेटा की प्रकृति से जुड़े जोखिम

• migrate किया जाने वाला डेटा 2017 के बाद से Uber का पूरा business ledger डेटा था:
  • immutable records: compressed size 1.2 PB
  • secondary indexes: uncompressed size 0.5 PB
• immutable records को बदला नहीं जा सकता, जबकि secondary index डेटा में समस्याएँ ठीक करने के लिए संशोधन की कुछ flexibility होती है.

validation

• यह सुनिश्चित करने के लिए कि backfill हर पहलू में सही और स्वीकार्य है, यह जाँचना ज़रूरी था कि क्या यह current traffic संभाल सकता है और जो डेटा अभी access नहीं हो रहा वह भी सही है.
• validation criteria:
  • completeness: क्या सभी records backfill किए गए
  • correctness: क्या सभी records सही हैं
  • load: क्या LSG वर्तमान load संभाल सकता है
  • latency: क्या LSG की P99 latency स्वीकार्य सीमा में है
  • lag: क्या secondary index generation lag स्वीकार्य सीमा में है

shadow validation

• migration से पहले और बाद के responses की तुलना की गई ताकि current traffic डेटा migration समस्याओं या code bugs से प्रभावित न हो.
• shadow validation के ज़रिए यह सुनिश्चित किया गया कि backfill कम-से-कम 99.99% complete और correct है, और upper bound 99.9999% रखा गया.
• shadow validation ने यह जाँचने में मदद की कि LSG production traffic संभाल सकता है, और data access code पर भरोसा दिया.
• shadow validation ने वर्तमान में access हो रहे डेटा की completeness और correctness पर विश्वास प्रदान किया.

offline validation और incremental backfill

• LSG के पूरे डेटा की तुलना DynamoDB के data dump से की गई.
• offline validation यह सुनिश्चित करने के लिए था कि data backfill सही तरीके से हुआ है, और यह पूरे डेटा को कवर करता है.
• offline validation को shadow validation के साथ किया जाना चाहिए.

backfill की समस्याएँ

• हर backfill जोखिमपूर्ण होता है. Uber ने backfill के लिए Apache Spark का उपयोग किया.
• समस्याओं से निपटने के तरीके:
  • scalability: छोटे scale से शुरू करके धीरे-धीरे विस्तार करना
  • incremental backfill: डेटा को छोटे batches में बाँटकर backfill करना
  • rate control: backfill jobs की गति नियंत्रित करना
  • dynamic rate control: मौजूदा system state की निगरानी करके गति समायोजित करना
  • emergency stop: overload की आशंका होने पर backfill को जल्दी रोक सकने की क्षमता देना
  • data file size: data dump files का आकार उचित रखना
  • fault tolerance: data quality/corruption समस्याओं को संभालना
  • logging: logs को सीमित रखना ताकि logging infrastructure पर बोझ न पड़े

जोखिम कम करना

• विभिन्न validation और backfill statistics का विश्लेषण किया गया और LSG का rollout सावधानीपूर्वक किया गया.
• शुरुआत में, यदि backfill विफल हो जाए तो DynamoDB से डेटा लाने वाला fallback इस्तेमाल किया गया.
• fallback logs की जाँच कर यह सुनिश्चित किया गया कि LSG में वास्तव में डेटा missing नहीं है.

निष्कर्ष

• इस लेख में बड़े पैमाने पर business-critical ledger डेटा को एक data store से दूसरे data store में migrate करने की प्रक्रिया को कवर किया गया है.
• migration criteria, validation, backfill समस्याएँ, और safety सहित कई पहलुओं पर चर्चा की गई.
• 2 साल में migration बिना किसी interruption या outage के पूरा किया गया.

GN⁺ की राय

• data migration का महत्व: बड़े पैमाने का data migration जटिल और जोखिमपूर्ण होता है, लेकिन cost savings और system simplification के ज़रिए लंबे समय में बड़े फ़ायदे देता है.
• shadow validation की उपयोगिता: shadow validation एक शक्तिशाली tool है, जो वास्तविक traffic को प्रभावित किए बिना डेटा की completeness और correctness की जाँच कर सकता है.
• offline validation की आवश्यकता: shadow validation से न दिखने वाली समस्याएँ खोजने के लिए offline validation भी आवश्यक है.
• backfill का चरणबद्ध दृष्टिकोण: backfill jobs को छोटे batches में बाँटकर चरणबद्ध तरीके से चलाना system overload रोकने में प्रभावी है.
• emergency stop feature: backfill के दौरान समस्या आने पर तुरंत रोक सकने की क्षमता system stability बनाए रखने के लिए महत्वपूर्ण है.

[GN⁺]

Hacker News राय

Hacker News टिप्पणियों का संक्षिप्त सार

• प्रति तिमाही 2 billion rides

  • Uber हर तिमाही 2 billion rides प्रोसेस करता है। इसे लगभग 1000 transactions प्रति सेकंड के बराबर माना जा सकता है। यह समझना कठिन है कि infrastructure scaling को लेकर इतनी चिंता क्यों है।

• DynamoDB का खराब उपयोग

  • Uber, DynamoDB का सही तरह से उपयोग नहीं कर रहा था। कुछ महत्वपूर्ण customer user journeys (CUJ) के लिए strong consistency चाहिए, और historical transactions के लिए data warehousing की भी ज़रूरत होती है। यह अजीब है कि DynamoDB और Redshift architecture पर स्विच नहीं किया गया।

• Google के reject किए हुए प्रोजेक्ट

  • लगता है Uber ने Google में असफल रहे किसी प्रोजेक्ट को उठा लिया। ऐसे प्रोजेक्ट अक्सर बड़े promotion को ध्यान में रखकर किए जाते हैं। जैसे, "अपना सिस्टम design और build करके $Xm बचाए! मुझे promote करो!" लेकिन build करने की लागत ज़्यादा पड़ती है, और कुछ साल बाद इसे बंद किए जाने की संभावना रहती है।

• एक single server पर SQLite

  • यह जिज्ञासा है कि क्या 1.7 petabytes data (1 trillion indexed records) को एक high-performance bare metal server पर SQLite में रखा जा सकता है। एक उदाहरण लिंक दिया गया है।

• LedgerStore open source नहीं है

  • LedgerStore open source नहीं है। इसके बारे में जानकारी पाने के लिए Uber के blog posts तक जाना पड़ता है। 2021 की एक post का लिंक दिया गया है।

• custom infrastructure का दौर

  • 2015 के आसपास Netflix, Spotify, SoundCloud, Uber जैसी कई tech कंपनियाँ अपने infrastructure और database tools खुद बना रही थीं। आजकल बहुत से engineers AWS/cloud terminology में बात करते हैं। अभी भी ऐसे organizations को देखना ताज़गी भरा लगता है जो अपने tools खुद बनाते हैं।

• महंगा proprietary cloud

  • यह इस बात का अच्छा उदाहरण है कि proprietary cloud-based data stores कितने महंगे हो सकते हैं। किसी दूसरे विकल्प पर migrate करना संभव है।

• TigerBeetle पर विचार किया?

  • जिज्ञासा है कि क्या TigerBeetle पर विचार किया गया था।

• DynamoDB महंगा है

  • इस प्रोजेक्ट की economics क्या है, यह स्पष्ट नहीं है, लेकिन DynamoDB वास्तव में बहुत महंगा है। पहले लगा कि शायद दूसरे लोग इसका गलत उपयोग कर रहे हैं, लेकिन distributed hash table की तरह इस्तेमाल करने पर भी इसकी लागत काफी ज़्यादा रहती है।

• टीम चलाने की लागत

  • लगता है कि प्रोजेक्ट टीम को चलाने की लागत, बताई गई बचत ($6 million) से बहुत अलग नहीं होगी। इसके ऊपर maintenance cost भी जुड़ेगी। संभव है कि payments systems long-term bet न हों। यह दिलचस्प है कि ऐसे प्रोजेक्ट क्यों किए जाते हैं। शायद यह पहले से मौजूद engineering team से जुड़ी sunk cost का मामला हो सकता है।