- Stripe ने 2023 में कुल $1 ट्रिलियन का payment volume प्रोसेस करते हुए भी 99.999% uptime बनाए रखा
- Stripe की database infrastructure team, API की foundational layer के रूप में DocDB नाम की database as a service (DBaaS) उपलब्ध कराती है
- DocDB, MongoDB Community का एक extended version है, जो Stripe के भीतर बनाए गए कई services से मिलकर बना है
- यह प्रति सेकंड 50 लाख से अधिक queries संभालता है, और petabyte-स्तर के महत्वपूर्ण financial data को 2,000 से अधिक database shards में वितरित करके 5,000 से अधिक collections में स्टोर करता है
- MongoDB Community को चुनने का कारण document model की flexibility और बड़े पैमाने पर real-time data processing की क्षमता थी
- 2011 में MongoDB Atlas मौजूद नहीं था, इसलिए cloud पर चलने वाला self-managed MongoDB instance cluster बनाया गया
- DocDB का केंद्र Data Movement Platform है
- इसे मूल रूप से MongoDB की vertical scaling limits को पार करने के लिए horizontal scaling solution के रूप में बनाया गया था, लेकिन बाद में अलग-अलग उद्देश्यों के लिए customize किया गया
- जैसे utilization और efficiency बढ़ाने के लिए unused database shards को merge करना, reliability के लिए database engine के major version upgrades करना, और बड़े users के लिए multi-tenant से single-tenant में migration करना
- Data Movement Platform कम संख्या वाले बड़े database shards से अधिक संख्या वाले छोटे database shards में बदलाव संभव बनाता है
- साथ ही यह clients के लिए transparent migration और zero downtime उपलब्ध कराता है, जिससे अत्यधिक resilient DBaaS दिया जा सकता है
- DocDB traffic spike के समय database shards को split कर सकता है, और traffic कम होने पर bin-packing के जरिए हजारों databases को consolidate कर सकता है
Database infrastructure कैसे बनाया गया
- Stripe ने 2011 में launch के समय standard relational databases की तुलना में बेहतर developer productivity के कारण MongoDB को अपने online database के रूप में चुना
- Stripe, MongoDB के ऊपर API reliability को प्राथमिकता देने वाला मजबूत database infrastructure चलाना चाहता था, लेकिन उसकी requirements पूरी करने वाला कोई off-the-shelf DBaaS नहीं मिला
- सर्वोच्च स्तर की availability, durability, और performance
- client applications की unoptimized queries से होने वाली समस्याओं से बचने के लिए database features का न्यूनतम exposure
- sharding के जरिए horizontal scalability का support
- enforced quotas के साथ multi-tenancy के लिए first-class support
- authorization policies लागू करके मजबूत security
- समाधान था MongoDB को base storage engine के रूप में इस्तेमाल कर DocDB बनाना — एक truly elastic और scalable DBaaS, जिसमें online data migration मुख्य तत्व है
- Stripe की product applications, database के data तक access, Go में internally विकसित database proxy server fleet के जरिए करती हैं, ताकि reliability, scalability, permission control और access control से जुड़े मुद्दों को लागू किया जा सके
- इसी दौरान horizontal scaling mechanism के रूप में sharding का उपयोग करने का अहम architectural decision लिया गया
- accumulated data के छोटे-छोटे chunks को अलग-अलग रखने वाले हजारों database shards अब Stripe के सभी products की नींव बन चुके हैं
- जब application database proxy server को query भेजती है, तो वह query को parse करता है, उसे एक या अधिक shards तक route करता है, फिर shards के results को combine करके application को वापस देता है
- database proxy server, chunk metadata service पर निर्भर करता है, जो chunks को database shards से map करती है, ताकि किसी query के लिए संबंधित shards को आसानी से lookup किया जा सके
- database writes से पैदा हुए change events को streaming software system में भेजा जाता है, और अंततः change data capture (CDC) pipeline के जरिए object storage में रखा जाता है
- Stripe की team, product application स्तर पर internal document database control plane का उपयोग करके data के logical containers provision करती है, जिन्हें logical database कहा जाता है और जिनमें संबंधित उद्देश्य वाले documents से बनी एक या अधिक DocDB collections शामिल होती हैं
- इन DocDB collections का data कई databases (physical databases) में वितरित होता है, जिनमें collection के छोटे chunks रखे जाते हैं
- DocDB के physical databases, shards में रहते हैं जो replica sets के रूप में deploy किए जाते हैं; इनमें एक primary node और replication तथा automatic failover वाले कई secondary nodes होते हैं
Data Movement Platform कैसे डिज़ाइन किया गया
- ऐसा horizontally scalable और highly elastic DBaaS product बनाने के लिए, जो product applications की ज़रूरत के अनुसार scale up और down कर सके, यह क्षमता ज़रूरी थी कि database shards के बीच data को clients के लिए transparent तरीके से zero downtime के साथ migrate किया जा सके
- यह एक जटिल distributed systems समस्या है, जो महत्वपूर्ण financial data की विशेष आवश्यकताओं के कारण और भी कठिन हो जाती है
- Data consistency और completeness: यह सुनिश्चित करना ज़रूरी था कि migrate हो रहा data source shard और target shard, दोनों पर consistent और complete रहे
- Availability: data migration के दौरान लंबे downtime की अनुमति नहीं दी जा सकती थी, क्योंकि लाखों businesses 24x7 अपने customers से payments लेने के लिए Stripe पर निर्भर हैं
- लक्ष्य यह था कि migration process के महत्वपूर्ण चरण planned database primary failover time (आमतौर पर कुछ सेकंड) से भी छोटे रहें, और product applications के retry budget के भीतर फिट हों
- Granularity और adaptability: Stripe के scale पर, किसी भी संख्या के data chunks को किसी भी संख्या के sources से target shards तक migrate करना संभव होना चाहिए
- fleet में चल रहे database chunk migrations की संख्या पर कोई सीमा नहीं होनी चाहिए, और किसी समय किसी विशेष shard के शामिल होने वाली migrations की संख्या पर भी सीमा नहीं होनी चाहिए
- साथ ही, क्योंकि database shards का बड़ा हिस्सा terabyte-स्तर का data रखता है, विभिन्न sizes के chunks को high throughput के साथ migrate करना भी संभव होना चाहिए
- Source shard पर performance impact न हो: shards के बीच database chunks migrate करते समय लक्ष्य यह था कि source shard की performance और available throughput सुरक्षित रहे, ताकि user queries की performance और throughput पर नकारात्मक असर न पड़े
- इन requirements को पूरा करने के लिए Stripe ने purpose-built services को invoke करके shards के बीच online data migration manage करने वाला data movement platform बनाया
- data movement platform का Coordinator component, online data migration से जुड़े कई steps को orchestrate करता है, और नीचे बताए गए हर configuration step को पूरा करने के लिए संबंधित services को call करता है
चरण 1: Chunk migration register करना
- सबसे पहले, chunk metadata service में source shard से किसी target shard तक database chunk migrate करने की मंशा register की जाती है
- उसके बाद target shard पर migrate हो रहे chunk के लिए indexes बनाए जाते हैं
चरण 2: Bulk data import
- इसके बाद समय T पर source shard के chunk snapshot का उपयोग करके data को एक या अधिक database shards में load किया जाता है
- bulk data import करने वाली service, कई तरह के data filters स्वीकार करती है, और केवल वही data chunks import करती है जो filtering criteria पूरा करते हैं
- शुरुआत में यह सरल लगा, लेकिन DocDB shards में bulk data load करते समय throughput limits सामने आईं
- writes को batch करने और optimal bulk ingestion के लिए DocDB engine parameters tune करने की कोशिश की गई, लेकिन बहुत सफलता नहीं मिली
- लेकिन जब टीम ने यह उपयोग किया कि DocDB data sort करने के लिए B-tree data structure इस्तेमाल करता है, और insert order optimize करने का तरीका खोजा, तब बड़ा breakthrough मिला
- collection में सबसे आम index properties के आधार पर data sort करके और sorted order में insert करके write locality काफी बढ़ाई गई, जिससे write throughput 10 गुना बढ़ गया
चरण 3: Asynchronous replication
- target shard में data import करने के बाद, migrate हो रहे database chunk के लिए समय T से source से target shard तक write replication शुरू की जाती है
- asynchronous replication system, CDC system के source shard पर हुए writes से उत्पन्न changes को पढ़ता है और target shard पर writes execute करता है
- operation log या oplog, हर DocDB shard की एक special collection होती है, जो उस shard के database में data बदलने वाले सभी operations का record रखती है
- सभी DocDB shards के oplog को event streaming platform Kafka में भेजा जाता है, और फिर Amazon S3 जैसी cloud object storage service में रखा जाता है
- Kafka और Amazon S3 में मौजूद oplog events का उपयोग करके Stripe ने ऐसी service बनाई जो एक या अधिक source DocDB shards से एक या अधिक target DocDB shards तक changes replicate करती है
- यह CDC system के oplog events पर निर्भर करती है, ताकि source shard की user queries के लिए उपलब्ध read throughput consume न हो और user query speed धीमी न पड़े, साथ ही source shard के oplog size की सीमा से बंधना न पड़े
- service को इस तरह design किया गया है कि target shard उपलब्ध न होने पर भी यह resilient रहे, और किसी भी समय checkpoint से sync शुरू, pause और resume किया जा सके
- replication service replication lag प्राप्त करने की क्षमता भी देती है
- migration में शामिल chunk के changes, source shard से target shard और उल्टी दिशा में भी bidirectional replicate किए जाते हैं, और replication service circular asynchronous replication रोकने के लिए अपने द्वारा जारी writes को tag करती है
- यह जानबूझकर चुना गया design था, ताकि target shard पर traffic भेजते समय समस्या आने पर traffic को source shard पर वापस लौटाया जा सके
चरण 4: Correctness verification
- source shard और target shard के बीच replication sync हो जाने के बाद, point-in-time snapshots की तुलना करके data completeness और correctness की व्यापक जाँच की जाती है
- यह shard throughput को प्रभावित न करने के लिए लिया गया एक जानबूझकर design decision था
चरण 5: Traffic switchover
- जब chunk का data source से target shard तक import हो जाता है और changes सक्रिय रूप से replicate हो रहे होते हैं, तब Coordinator द्वारा traffic switchover orchestrate किया जाता है
- migrate हो रहे data chunk के लिए read और write paths को फिर से point करने के लिए, पहले source shard के traffic को थोड़ी देर के लिए pause करना पड़ता है, फिर chunk metadata service में route update किया जाता है, और proxy servers को target shard की ओर reads और writes redirect करनी होती हैं
- traffic switchover protocol, version gating के विचार पर आधारित है
- steady state में हर proxy server, DocDB shard को भेजे जाने वाले requests में version token number जोड़ता है
- MongoDB में custom patches जोड़े गए ताकि shard यह verify कर सके कि proxy server से मिले request का version token number उसके ज्ञात version token number से नया है या नहीं, और केवल उसी मानदंड को पूरा करने वाले requests process करे
- chunk routing update करने के लिए Coordinator के जरिए ये steps किए जाते हैं:
- सबसे पहले source DocDB shard का version token number बढ़ाया जाता है। version token number, DocDB की एक special collection में मौजूद document में stored होता है, और इस बिंदु पर source shard के chunk के लिए सभी reads और writes reject हो जाते हैं
- फिर replication service द्वारा source shard की pending writes replicate होने का इंतज़ार किया जाता है
- अंत में chunk metadata service में chunk route को update करके उसे target shard और version token number की ओर point कराया जाता है
- यह पूरा होने पर proxy servers, chunk metadata service से उस chunk के लिए updated route और सबसे ताज़ा version token number प्राप्त करते हैं
- proxy servers, chunk के लिए updated route का उपयोग करके reads और writes को target shard तक route करते हैं
- पूरा traffic switchover protocol execute होने में 2 सेकंड से कम समय लेता है, और source shard पर भेजी गई सभी failed reads और writes retry पर सफल हो जाती हैं
चरण 6: Chunk migration unregister करना
- अंत में chunk metadata service में migration को complete mark किया जाता है और source shard से chunk data delete करके migration process समाप्त की जाती है
Data Movement Platform का उपयोग
- DocDB shards के बीच online तरीके से data chunks migrate करने की क्षमता ने Stripe को अपनी database infrastructure को अपनी growth speed के अनुरूप horizontally scale करने में मदद की
- database infrastructure team के engineers सिर्फ एक button click करके size और throughput के आधार पर DocDB shards को split कर सकते हैं, जिससे product teams के लिए database storage और throughput headroom सुनिश्चित होता है
- 2023 में Stripe ने data movement platform का उपयोग करके database infrastructure utilization सुधारा
- खास तौर पर, product applications के लिए transparent तरीके से 1.5 petabyte data migrate करके हजारों कम-उपयोग वाले databases को bin-pack किया गया, और underlying DocDB shards की कुल संख्या को लगभग तीन-चौथाई तक घटा दिया गया
- साथ ही data movement platform का उपयोग करके database infrastructure fleet को upgrade किया गया, जिसमें data को MongoDB के बाद के version पर एक ही step में forklift किया गया, बिना बीच के major या minor versions से गुज़रे
- Stripe की database infrastructure team, internet economy की growth के साथ scale होने वाली मजबूत और भरोसेमंद foundation बनाने पर केंद्रित है
- टीम फिलहाल size और throughput के आधार पर shards के बीच data को proactively balance करने वाली thermal management system का prototype बना रही है, और traffic patterns में बदलाव के अनुसार dynamic shard autoscaling में निवेश कर रही है
अभी कोई टिप्पणी नहीं है.