- Uber के payments platform ने 2017 के बाद जमा हुए ledger data के 1 trillion से अधिक records और कई PB scale तक बढ़ जाने पर DynamoDB·TerraBlob·LedgerStore की mixed structure को LedgerStore-केंद्रित architecture में migrate किया
- DynamoDB की लागत के दबाव के कारण हाल की 12 हफ्तों की data ही बनाए रखने वाली संरचना से, append-only ledger-style storage LedgerStore को long-term solution के रूप में चुना गया
- verification के लिए production traffic को replicate करने वाली shadow validation और full dump की तुलना करने वाली offline validation को साथ चलाया गया, ताकि current data और cold data के risk को अलग-अलग जांचा जा सके
- backfill सामान्य traffic से बड़ा load पैदा कर सकता है, इसलिए इसे छोटे batches, idempotency, rate control, emergency stop, और problematic records को अलग करके धीरे-धीरे आगे बढ़ाया गया
- transition को कई हफ्तों तक सावधानी से rollout किया गया, और शुरुआती fallback, एक महीने तक DynamoDB data बनाए रखने, फिर final backup और table deletion तक पूरी प्रक्रिया बिना downtime के पूरी हुई
migration का दायरा और पुरानी storage structure
- Uber payments platform Gulfstream ने 2017 में launch के समय DynamoDB को storage के रूप में इस्तेमाल किया
- Uber के scale पर DynamoDB की लागत बढ़ने के साथ storage structure तीन हिस्सों में बंट गई
- हाल की 12 हफ्तों की hot data DynamoDB में stored थी
- पुरानी cold data Uber के internal blob store TerraBlob में stored थी
- LedgerStore में पहले से data लिखा जा रहा था, और वही अंतिम migration target बना
- migration का दायरा 2017 के बाद Uber के पूरे business की ledger data थी
- immutable records: compression के आधार पर 1.2PB
- secondary indexes: uncompressed आधार पर 0.5PB
- ledger records को एक बार लिखने के बाद व्यवहारिक रूप से बदला नहीं जा सकता, जबकि issue fix की जरूरत होने पर secondary index data को update किया जा सकता है
LedgerStore चुनने के कारण
- LedgerStore एक append-only ledger-style database है
- payment-type data के लिए किया गया इसका design, Gulfstream की जरूरतों से मेल खाता था
- cryptographic signatures के जरिए record में बदलाव हुआ या नहीं, यह जांचने वाली verifiable immutability
- request handling और storage cost के अनुसार hot data और cold data को अलग करने वाला tiered storage
- eventual consistency वाले secondary indexes के लिए बेहतर latency characteristics
- तीन storage systems को एक में लाने से Gulfstream का storage access code और index generation design सरल हो गया
- LedgerStore Uber data centers के भीतर on-premises चलता है, इसलिए यह अधिक तेज network latency दे सकता है
- LedgerStore में migration का recurring cost reduction effect भी बड़ा था
shadow validation से current traffic की stability की जांच
- backfill सही है या नहीं, यह तय करने के लिए पांच criteria रखे गए
- completeness: सभी records backfill हुए हों
- correctness: सभी records सही हों
- load: LedgerStore current load संभाल सके
- latency: LedgerStore की P99 latency acceptable range में हो
- index latency: background secondary index creation latency acceptable range में हो
- shadow validation में existing storage-based response और LedgerStore को data source मानने पर मिलने वाले response की तुलना की गई
- लक्ष्य यह था कि shadow validation criteria के आधार पर backfill की completeness और correctness कम से कम 99.99% रहे, लेकिन 99.9999% को upper bound रखा गया
- upper bound की जरूरत इसलिए थी क्योंकि large-scale data validation में हर suspicious case की आखिर तक जांच करते रहने से project रुक सकता है
- historical data migration में शुरुआती development के समय की गलत writes या scale के कारण data corruption शामिल हो सकती है
- S3 भले 11 nines durability देता हो, लेकिन 1 trillion records के scale पर 10 corrupted records की उम्मीद की जा सकती है
- eventual consistency indexes में कुछ seconds बाद दिखने वाले records shadow validation में missing दिख सकते हैं, यानी false positives पैदा हो सकते हैं
- 6 nines को भरोसेमंद ढंग से verify करने के लिए 100 million comparisons चाहिए, और 1,000 comparisons per second की दर से एक दिन से अधिक data collection चाहिए
- 7 nines के लिए उन्हीं conditions में 12 दिन इंतजार करना पड़ेगा
- production traffic को LedgerStore में replicate करते हुए load, latency, index latency, और access code की reliability को साथ-साथ verify किया जा सका
- migration के दौरान मिली latency और index latency की समस्याओं से कई fixes निकले
- index data distribution सुधारने के लिए partition key optimization
- point lookup की जगह record scan trigger करने वाली index problem का fix
- live shadow validation वर्तमान में access होने वाली data के लिए उपयोगी है, लेकिन बहुत कम access होने वाली historical data के लिए मजबूत guarantee देना कठिन है
offline validation और incremental backfill
- offline validation में LedgerStore के full data और DynamoDB data dump की तुलना की गई
- live traffic मुख्य रूप से हाल की data access करता है, इसलिए cold data में छिपी समस्याएं shadow validation से पकड़ना कठिन होता है
- data issue वाले records को backfill आगे बढ़ सके इसलिए skip करना पड़ता है, और backfill job खुद buggy हो सकती है, यह भी ध्यान में रखना होता है
- सबसे बड़ा validation job compressed 70TB और अनुमानित uncompressed 300TB data पर चला, जिसमें एक ही job में 760 billion records compare किए गए
- इस scale की Apache Spark job में data shuffle की जरूरत थी, और Distributed Shuffle as a Service for Spark, Dynamic Resource Allocation, और Speculative Execution का साथ में उपयोग किया गया
- offline validation से मिले missing records को incremental backfill input के रूप में इस्तेमाल किया गया
- validation और backfill को दोहराते हुए यह सुनिश्चित किया गया कि सभी records लिखे जा चुके हों
backfill के दौरान सामने आई operational समस्याएं
- backfill को छोटे scale से शुरू करके system limits तक धीरे-धीरे बढ़ाना चाहिए
- limit के पार बिना सोचे-समझे push करने पर अपनी ही system पर DDoS जैसी स्थिति बन सकती है
- bottleneck ढूंढकर fix करना होता है, फिर दोबारा scale up करना होता है
- हर scale-up के बाद करीबी monitoring जरूरी होती है
- कई सालों की data को कुछ महीनों में backfill करने पर सामान्य traffic से कहीं ज्यादा load बनता है
- अगर production 1,000 requests per second संभाल रहा हो, तो 10,000 requests per second पर 100 billion records backfill करने में 120 दिन लगेंगे
- अगर backfill job के चलते outage होने की आशंका हो, तो उसे तुरंत रोकना चाहिए
- backfill कोई एक बार में अंत तक दौड़ने वाली job नहीं है, इसे incremental batches में बांटना चाहिए
- हर batch इतना छोटा हो कि कुछ मिनटों में पूरा हो सके
- batch के बीच job terminate हो सकती है, इसलिए idempotent होना जरूरी है
- batch पूरा होने पर read records की संख्या, backfilled records की संख्या जैसी stats को file में लिखकर aggregate किया जाता है, ताकि progress track की जा सके
- safe backfill के लिए adjustable rate control जरूरी है
- Java/Scala में Guava का RateLimiter इस्तेमाल किया जा सकता है
- जब production traffic कम हो, तब system health monitor करके RPS बढ़ाया जा सकता है
- Uber ने additive increase/multiplicative decrease तरीके से RPS adjust किया, लेकिन safety के लिए upper bound बनाए रखा
- failure या overload का शक हो तो backfill को जल्दी से रोक पाना चाहिए
- outage के दौरान backfill को precaution और noise reduction, दोनों कारणों से रोक देना चाहिए
- outage के बाद भी system recovery के दौरान अतिरिक्त load बन सकता है
- emergency stop capability scale-related issue debugging में भी मदद करती है
बड़े files, fault tolerance, और logging
- data dump file size लगभग 1GB रखना और दोनों दिशाओं में करीब 10x flexibility देना उपयुक्त है
- file बहुत बड़ी हो तो कई tools की MultiPart limits से टकरा सकती है
- file बहुत छोटी हो तो files की संख्या इतनी बढ़ जाती है कि सिर्फ listing में ही बहुत समय लग सकता है
- shell command चलाते समय ARGMAX limit से टकराव हो सकता है
- backfill के data transformation process में data quality issues या corrupted records का आना लगभग तय है
- problematic records random तरीके से फैले हो सकते हैं, इसलिए हर बार job रोकना संभव नहीं
- साथ ही यह code bug भी हो सकता है, इसलिए इन्हें नजरअंदाज भी नहीं किया जा सकता
- problematic records को अलग dump किया जाता है और उनकी stats monitor की जाती हैं
- अगर failure rate ज्यादा हो, तो backfill को manually रोककर issue fix करने के बाद फिर आगे बढ़ाया जाता है
- RPC timeout के कारण record write fail हो सकती है
- retry किया जा सकता है, लेकिन किसी बिंदु पर कारण चाहे जो हो, छोड़कर आगे बढ़ना पड़ता है ताकि पूरा काम आगे बढ़ सके
- debugging और progress checks के लिए बहुत logs छोड़ने की इच्छा हो सकती है, लेकिन इससे logging infrastructure पर बड़ा दबाव बन सकता है
- logs रखना संभव हो तब भी retained volume बहुत ज्यादा हो सकता है
- जिन हिस्सों में logs ज्यादा निकलते हों, वहां rate limiting लगाई जाती है
- अगर errors बहुत कम आती हों, तो सभी error logs भी रखे जा सकते हैं
gradual rollout और fallback हटाना
- LedgerStore transition में validation और backfill stats analysis के अलावा conservative rollout से risk कम किया गया
- rollout कई हफ्तों में किया गया और यह major caller services के on-call engineers की approval के साथ आगे बढ़ा
- शुरुआती चरण में LedgerStore में data न मिलने पर DynamoDB से लाने वाला fallback इस्तेमाल किया गया
- fallback logs में missing दिखाए गए हर record के लिए दोबारा जांचा गया कि वह वाकई LedgerStore में missing है या नहीं
- fallback हटाने के बाद भी DynamoDB data को एक महीने तक बनाए रखा गया
- इसके बाद DynamoDB writes रोकी गईं, final backup बनाया गया, और फिर tables delete कर दी गईं
- पूरा migration 2 साल में पूरा हुआ, और migration के दौरान या बाद में कोई downtime या outage नहीं हुआ
1 टिप्पणियां
Hacker News की टिप्पणियाँ
यह सोचने वाली बात है कि क्या 1.7 पेटाबाइट डेटा (1 ट्रिलियन indexed records) को एक बेहद ताकतवर bare-metal server पर, जिसकी मासिक लागत कुछ हज़ार डॉलर से कम हो, रखकर SQLite से serve किया जा सकता है
उदाहरण के लिए कुछ ऐसा: https://use.expensify.com/blog/scaling-sqlite-to-4m-qps-on-a...
SQLite अधिकतम 281 टेराबाइट database support करता है, वह भी इस मान्यता पर कि आपको 281 टेराबाइट file support करने वाला disk drive और filesystem मिल जाए. फिर भी, अगर content size टेराबाइट स्तर तक बढ़ने के संकेत हों, तो SQLite की बजाय centralized client/server database पर विचार करना बेहतर बताया गया है
इतनी storage एक ही server में भरना मुश्किल लगता है, और मासिक कुछ हज़ार डॉलर में तो और भी नहीं. SQLite भी इस उपयोग के लिए उपयुक्त नहीं है
जिस कंपनी के पास पर्याप्त पूंजी और organizational strength हो, वह अपना cloud इससे कहीं सस्ता बना सकती है, लेकिन इस हिसाब का बड़ा हिस्सा risk factors को outsource करने में है
[0] https://www.sqlite.org/releaselog/3_33_0.html
[1] https://www.sqlite.org/limits.html (#12)
LedgerStore शायद open source नहीं है [1], और इसके बारे में जानकारी ढूँढ़ने के लिए Uber के आपस में back-link किए गए blog posts का पीछा करना पड़ता है
2021 की पोस्टों में LedgerStore के बारे में सबसे ज़्यादा जानकारी शायद इसमें दिखती है:
https://www.uber.com/en-US/blog/dynamodb-to-docstore-migrati...
[1]:https://github.com/uber
कुल मिलाकर Uber में खुद बनाओ वाली प्रवृत्ति काफ़ी मज़बूत लगती है. लगता है वे अक्सर यह निष्कर्ष निकालते हैं कि मौजूदा open source solutions पर्याप्त नहीं हैं, और फिर खुद बनाते हैं. यह Facebook के उस तरीके से अलग है जहाँ उसने MySQL में MyRocks/RocksDB जोड़कर सुधार किया और उसे open source रखा
पोस्ट पढ़ने पर साफ़ दिखता है कि Uber काफी जल्दी DynamoDB का गलत इस्तेमाल कर रहा था
कुछ महत्वपूर्ण user journeys में strong consistency चाहिए थी, और पुराने transactions के लिए बड़े पैमाने पर data warehousing की ज़रूरत भी थी
यह अजीब है कि उन्होंने 2-table DynamoDB structure को पहले DynamoDB + Redshift जैसे setup में नहीं बदला. यह काफ़ी आम pattern है
लगभग 2015 के आसपास एक दौर था जब Netflix, Spotify, SoundCloud, Uber जैसी शानदार tech कंपनियाँ बहुत सारे infrastructure और database tools बना रही थीं
आजकल engineers अक्सर AWS/cloud terminology में बात करते हैं
यह देखना ताज़गीभरा है कि अब भी कुछ organizations ऐसे tools खुद बना रही हैं
मुझे नहीं पता कि इस खास project की economics क्या है, लेकिन DynamoDB सच में महँगा है
एक समय मुझे लगता था कि बाकी लोग बस DynamoDB का गलत इस्तेमाल कर रहे हैं, और precomputed tables पर point lookups की जगह scans और queries चला रहे हैं
लेकिन इसे distributed hash table की तरह इस्तेमाल करने पर भी आपको भारी premium देना पड़ता है
1 RCU से अधिकतम 4KB पढ़ा जा सकता है, इसलिए 100MB पढ़ने के लिए 100,000 RCU चाहिए होंगे, जिसकी कीमत 30,000 डॉलर प्रति वर्ष या 2,500 डॉलर प्रति माह होगी. अगर मेरा हिसाब गलत नहीं है, तो कीमत के मामले में इसके आसपास भी कुछ नहीं आता
सोच रहा हूँ कि क्या उन्होंने https://tigerbeetle.com पर विचार किया होगा
और Uber शायद उन दुर्लभ बड़ी कंपनियों में से एक होगी जिसका Zig Foundation के साथ support contract हो सकता है
इस काम में शामिल लोगों को बधाई. लेकिन सिर्फ़ इस team को चलाने की लागत ही शायद काफ़ी बड़ी होगी और 6 मिलियन डॉलर की बचत से बहुत अलग नहीं होगी, ऊपर से maintenance burden भी जुड़ जाएगा
यह भी कम संभावना लगती है कि payments system कोई long-term bet हो, इसलिए यह दिलचस्प है कि teams ऐसे projects क्यों लेती हैं. क्या यह उनके पास पहले से मौजूद engineering team की वजह से पैदा होने वाली किसी तरह की sunk cost है?
इनके बीच कहीं ज़्यादा यथार्थवादी cost estimate की गुंजाइश है
अगर data और indexes 1.7PB हैं, तो DynamoDB storage list price पर इसकी लागत लगभग 5.1 मिलियन डॉलर प्रति वर्ष होगी
business के core हिस्से के लिए अच्छी तरह fit होने वाला dedicated system रखने के लिहाज़ से यह काफ़ी यथार्थवादी लगता है
यह उतना बड़ा काम नहीं था जितना लोग कह रहे हैं. ऊपर से records immutable थे, इसलिए बहुत कुछ काफ़ी आसान हो गया
सोचता हूँ कि क्या यह फिर एक और अपवादात्मक मामला है जहाँ किसी खास scale पर पहुँचने के बाद खुद बनाना अधिक फायदेमंद हो जाता है. Uber को जिस scale पर काम करना पड़ता है, वह काफ़ी चौंकाने वाला है
मूल लेख से यह स्पष्ट नहीं है कि नए refactored service की कुल cost of ownership कितनी है. क्या अब उन्हें अपना database और उसके पीछे का storage भी manage नहीं करना होगा? क्या मैं कुछ मिस कर रहा हूँ?
वह कंपनी end-user product बेचने वाली नहीं थी, बल्कि उसका product एक distributed filesystem था
मेरे हिसाब से ज़्यादातर कंपनियों के पास database जैसे systems बनाने की विशेषज्ञता नहीं होती, और भले ही लागत के हिसाब से development आकर्षक लगे, वे वास्तव में ऐसा काम करने से डरती हैं
यह एक बहुत अच्छा उदाहरण है कि proprietary cloud-based data stores कितने महँगे हो सकते हैं, और उनसे किसी दूसरी चीज़ पर migrate करना वास्तव में संभव भी है
अगर हम मान लें कि लोग तर्कसंगत ढंग से काम करते हैं, तो cloud service providers के लिए शायद हिसाब चुकता होने का समय आने वाला है
मैंने एक छोटी कंपनी के लिए contract work किया था, जहाँ वे 375MB के MySQL DB से निकले data पर reports चलाने के लिए GCP Bigtable इस्तेमाल कर रहे थे और हर महीने 11,000 डॉलर से ज़्यादा खर्च हो रहे थे
उन्होंने college से नए निकले एक data scientist को reports बनाने के लिए रखा था, और वह इतने छोटे dataset पर हैरान कर देने वाला inefficent काम कर रहा था. उन्होंने मुझसे कहा कि मैं इसे कल तक बहुत कम पैसों में ठीक कर दूँ, और मैंने मना कर दिया
यह बस एक खराब तरह से डिज़ाइन किया गया system था. अगर यही काम किसी on-premises database पर बहुत ज़्यादा overprovisioning के साथ चलाया जाता, तब भी यही समस्या होती