Roblox के विशाल-स्तरीय मल्टीप्लेयर गेमिंग वातावरण में, उपयोगकर्ता इतनी मात्रा और गति से डेटा पढ़ते और लिखते हैं कि यह मानक कैशिंग पैटर्न को चूर-चूर कर देता है। एक उपयोगकर्ता को एक मानक वेबपेज पर 200ms की देरी शायद ही महसूस हो, जो स्टैटिक डेटा को कैश करता है, लेकिन Roblox पर इंटरैक्शन डेटा या सर्वर मेटाडेटा प्राप्त करने में 200ms की देरी गेमप्ले को रोक सकती है और सिमुलेटेड गेम की दुनिया में व्यवधान डाल सकती है। Roblox एक ऐसे इकोसिस्टम पर काम करता है जिसमें अप्रत्याशित, उच्च-गति और क्षणिक डेटा होता है, जिसे इमर्सन बनाए रखने के लिए मिलीसेकंड के भीतर प्राप्त किया जाना चाहिए। 

हमारी कैशिंग लेयर को लाखों समवर्ती उपयोगकर्ताओं और हमारे स्थायी भंडारण के बीच एक विशाल शॉक एब्जॉर्बर के रूप में काम करने के लिए डिज़ाइन किया गया है। यह प्रति सेकंड 1.38 बिलियन क्वेरीज़ (QPS) के पीक लोड को संभालती है, जिसमें एकल लॉजिकल क्लस्टर 100 मिलियन QPS तक पहुँचते हैं। इस पोस्ट में, हम इस बात से पर्दा उठाएंगे कि हमने एक संघीय कैशिंग सेवा कैसे तैयार की है, जो बड़े थ्रूपुट के लिए Redis® नोड सीमाओं से परे स्केल कर सकती है, और साथ ही हमारे सबसे बड़े क्लस्टर पर अभूतपूर्व 10 गुना ट्रैफ़िक वृद्धि का सामना भी कर रही है।

बढ़ती मांगों को पूरा करने के लिए उद्योग सीमा से परे विस्तार

Roblox में, हमारी कैशिंग सेवा Redis® तकनीक पर बनी है, और एक Redis® क्लस्टर में 1,000 नोड्स तक का समर्थन करने की क्षमता है। हालाँकि, अनुभवजन्य और उद्योग द्वारा स्वीकृत सीमा बहुत कम है—लगभग 400–500 नोड्स।¹ ऐसा Redis® के विकेंद्रीकृत गॉसिप प्रोटोकॉल के कारण है, जो स्वास्थ्य, स्थिति और शार्ड मैपिंग साझा करने के लिए इंटर-नोड संचार का उपयोग करता है। कुछ सौ नोड्स से बड़े क्लस्टर में, गॉसिप प्रोटोकॉल से होने वाली बातचीत पर्याप्त CPU और नेटवर्क संसाधनों का उपभोग करना शुरू कर देती है। प्रत्येक नोड को लगातार बढ़ते पीयरों की संख्या से स्थिति अपडेट को संसाधित करना होता है, जो कम विलंबता पर डेटा परोसने के प्राथमिक कार्य से संसाधन छीन लेता है। यह कंट्रोल प्लेन ओवरहेड अस्थिरता और अप्रत्याशित प्रदर्शन का कारण बन सकता है, यही कारण है कि प्रबंधित क्लाउड प्रदाता नोड सीमाओं को लागू करते हैं। यह एक व्यावहारिक सीमा है जिसे विश्वसनीयता से समझौता किए बिना पार नहीं किया जा सकता।

यह व्यावहारिक एकल क्लस्टर सीमा Roblox के पैमाने पर चलने वाले प्लेटफ़ॉर्म का समर्थन करने के लिए पर्याप्त नहीं है, जहाँ सबसे बड़ी बैकएंड सेवा ने चरम पर हमारे एक लॉजिकल Redis® क्लस्टर से 100 मिलियन QPS से अधिक की मांग की, जो तीन महीनों के भीतर 10 मिलियन से बढ़ी थी।

हमने इस वास्तुशिल्प सीमा को दूर करने के लिए एक संघीय वास्तुकला अपनाई, जिसमें कई छोटे, स्वतंत्र Redis® क्लस्टर के सामने एक क्लाइंट रिवर्स प्रॉक्सी को स्थापित किया गया। हम पूर्वानुमेय प्रदर्शन सुनिश्चित करने के लिए प्रति क्लस्टर 400-नोड की सीमा का उपयोग करते हैं। 

हमारे हजारों एप्लिकेशन और सेवाओं के दृष्टिकोण से, क्लाइंट रिवर्स प्रॉक्सी इन असंगत क्लस्टरों को एक एकल, एकीकृत और स्केलेबल कैशिंग सेवा के रूप में प्रस्तुत करता है। यह संघ हमें संघ में और अधिक क्लस्टर जोड़कर, गॉसिप प्रोटोकॉल की बाधाओं को पूरी तरह से दरकिनार करते हुए, लगभग बिना किसी सीमा के क्षैतिज रूप से स्केल करने की अनुमति देता है। आज, हमारी सबसे बड़ी एकल कैशिंग डिप्लॉयमेंट में 6,000 से अधिक Redis® नोड्स शामिल हैं, जिन्हें 15 से अधिक स्वतंत्र Redis® क्लस्टर द्वारा समर्थित किया जाता है—एक ऐसा पैमाना जो केवल इस फेडरेटेड मॉडल द्वारा ही संभव हो पाया है।

तीन-चरणीय माइग्रेशन प्रक्रिया

सैकड़ों सक्रिय प्रोडक्शन क्लस्टर का प्रबंधन करते हुए एक पारंपरिक सेटअप से एक फेडरेटेड आर्किटेक्चर में जाना एक महत्वपूर्ण प्रयास था। 2024 के अंत तक, इनमें से कई क्लस्टर पहले से ही हमारी 400-नोड सीमा के करीब पहुँच रहे थे, जिससे उच्च-क्षमता वाले मॉडल में संक्रमण करना तत्काल हो गया था। प्राथमिक चुनौती यह थी कि मानक Redis® इंस्टेंस अलग-थलग काम करते हैं और उन्हें अन्य क्लस्टर की कोई अंतर्निहित जानकारी नहीं होती है, जिसके कारण स्थानांतरण के दौरान डेटा को प्रतिकृति बनाने के लिए एक कस्टम विधि की आवश्यकता थी।

इसे हल करने के लिए, हमने एक पारदर्शी, तीन-चरणीय माइग्रेशन पाइपलाइन विकसित की जो बिना किसी ग्राहक भागीदारी या एप्लिकेशन-साइड परिवर्तनों के सेवाओं को स्थानांतरित करने के लिए डिज़ाइन की गई है।

प्रवासन वर्कफ़्लो

1. डुअल-राइटिंग: हमने क्लाइंट रिवर्स प्रॉक्सी को डुअल राइट करने के लिए कॉन्फ़िगर किया, जिससे इनकमिंग डेटा एक ही समय में मूल क्लस्टर और नई फेडरेटेड डेस्टिनेशन दोनों को भेजा जाता था।
2. पैरिटी और रीड स्विच: एक बार जब डुअल-राइट प्रक्रिया ने नए क्लस्टर को समान डेटा से भर दिया, तो चूंकि सभी डेटा एक टाइम टू लिव (TTL) से बंधे होते हैं, हमने लेगेसी क्लस्टर से रीड ट्रैफ़िक को नए फेडरेटेड आर्किटेक्चर में स्थानांतरित कर दिया।
3. डीकमीशनिंग: नए क्लस्टर की स्थिरता की पुष्टि करने के बाद, हमने मूल क्लस्टर पर सभी राइट ऑपरेशंस बंद कर दिए और उसे रिटायर कर दिया।

हमने अपनी सबसे महत्वपूर्ण सेवाओं को एक ऐसे संघीय मॉडल में सफलतापूर्वक स्थानांतरित कर दिया है जो 6,000 से अधिक नोड्स का समर्थन करता है, जो एक एकल Redis® क्लस्टर की सीमाओं से कहीं अधिक है। 

ग्रो ए गार्डन के तीव्र विकास को संभालना

अप्रैल 2025 से, हमें क्षमता की ऐसी चुनौती का सामना करना पड़ा, जिसका सामना शायद ही कोई सेवा कभी करती है। इसका उत्प्रेरक 'ग्रो ए गार्डन' की अभूतपूर्व सफलता थी। लॉन्च के कुछ ही हफ्तों के भीतर, 'ग्रो ए गार्डन' ने न केवल रॉब्लॉक्स के रिकॉर्ड बल्कि एक साथ उपयोगकर्ताओं (CCU) के लिए गेमिंग उद्योग के सर्वकालिक रिकॉर्ड भी तोड़ने शुरू कर दिए। केवल तीन महीनों में, गेम के दर्शक हमारे पिछले एकल-गेम CCU रिकॉर्ड 2.8 मिलियन खिलाड़ियों से बढ़कर 21 मिलियन से अधिक के शिखर पर पहुंच गए। इस विस्फोटक वृद्धि ने हमारे सबसे बड़े Redis® क्लस्टर पर 10 गुना अधिक ट्रैफ़िक और समग्र कैशिंग पर 3 गुना अधिक ट्रैफ़िक भेज दिया।

रॉब्लॉक्स हमारे कैशिंग सिस्टम को हमारे अपने डेटा सेंटर में भौतिक मशीनों पर चलाता है, और यह अभूतपूर्व वृद्धि हमारी दीर्घकालिक क्षमता योजना का हिस्सा नहीं थी। इस ज्वार-भाटे से बचने और प्लेटफ़ॉर्म को स्थिर रखने के लिए, हमें विश्वसनीयता को प्राथमिकता देते हुए अपने मौजूदा बेड़े की दक्षता में मौलिक रूप से सुधार करना पड़ा। 

उछाल के दौरान दक्षता में सुधार

सबसे पहले, हमें अपनी प्रणाली में सबसे प्रभावशाली बाधाओं की पहचान करने की आवश्यकता थी ताकि हम अनुकूलन कार्य को प्राथमिकता दे सकें। Roblox कैशिंग दो अलग-अलग हार्डवेयर पूल पर चलती है: एक Redis® बैकएंड नोड्स के लिए और एक Envoy के लिए। हमारा Redis® बेड़ा मुख्य रूप से मेमोरी-बाउंड है, जबकि क्लाइंट प्रॉक्सी कंप्यूट-बाउंड है। 

हमारे मेमोरी-बाउंड Redis® बेड़े के लिए, हमने अपने भौतिक मशीन समूहों में मेमोरी उपयोग को बेहतर ढंग से संतुलित करने के लिए एक नई शेड्यूलिंग नीति लागू की। हमने मेमोरी फ्रैगमेंटेशन को कम करने के लिए कंटेनर के आकार को भी ठीक किया। 

सीपीयू उपयोग में सुधार करने के लिए, हमने अपने कैश सिस्टम में दो प्रमुख अनुकूलन लागू किए:

1. क्लाइंट प्रॉक्सी ऑटोस्केलिंग: हमने अपने कंप्यूट-बाउंड क्लाइंट प्रॉक्सी फ्लीट के लिए ऑटोस्केलिंग नीति को समायोजित किया। लक्ष्य CPU से अनुमत विचलन को कम करके, हमने स्केल-अप थ्रेशोल्ड को बदले बिना जॉब्स के लिए उच्च औसत CPU उपयोगिता प्राप्त की।
2. आंतरिक क्लस्टर स्वास्थ्य जाँच: हमने अनावश्यक हार्टबीट्स को खत्म करने के लिए आंतरिक स्वास्थ्य जाँच को अनुकूलित किया, जिससे मूल डिटेक्शन इंटरवल को बनाए रखते हुए कंप्यूट संसाधनों की बचत हुई।

इन परिवर्तनों के परिणामस्वरूप सीपीयू उपयोग में लगभग 10% की सुधार हुई। अंत में, हमने इन दो बहुत अलग वर्कलोड को cgroup कंटेनर-स्तर के पृथक्करण के साथ एक ही मशीन पूल में सह-स्थित किया, जिससे हमारी समग्र क्षमता की ज़रूरतों में 25% की कमी आई।

अटूट विश्वसनीयता के लिए इंजीनियरिंग

रिकॉर्ड-तोड़ मांग को पूरा करने की दौड़ के बीच भी, विश्वसनीयता हमारी शीर्ष प्राथमिकता बनी रही। 

एंड-टू-एंड अवलोकनीयता

हमने सबसे पहले अपनी कैशिंग सिस्टम की व्यापक, एंड-टू-एंड स्वास्थ्य निगरानी के लिए अपने ऑब्ज़र्वबिलिटी स्टैक में भारी निवेश करके संभावित विफलताओं को समझने पर ध्यान केंद्रित किया। पूरे अनुरोध जीवनचक्र में सर्वर की सफलता और क्लाइंट-साइड विफलताओं को ट्रैक करके, हमने समस्याओं का जल्दी से पता लगाया और निदान किया, अक्सर उपयोगकर्ता पर प्रभाव पड़ने से पहले ही उन्हें रोक दिया। उदाहरण के लिए, हमने हॉट की डिटेक्शन जोड़ा, जो अत्यधिक एक्सेस किए जाने वाले और कैशिंग लेयर पर दबाव डालने वाले डेटा की पहचान करने के लिए लाइव ट्रैफ़िक का सैंपल लेता है। जब सिस्टम किसी हॉट की को फ़्लैग करता है, तो हम सिस्टम के ओवरलोड को रोकने के लिए सर्वर और क्लाइंट दोनों तरफ़ इन कीज़ पर ट्रैफ़िक को सक्रिय रूप से थ्रॉटल कर सकते हैं।

विफलता प्रबंधन

इस पैमाने के किसी भी वितरित सिस्टम में, आंशिक विफलताएं कभी-कभी होती हैं। हमने अपनी प्रणाली को इन विफलताओं को कुशलतापूर्वक संभालने और उनके प्रभाव को कम करने के लिए तैयार किया है।

• बैच अनुरोधों में आंशिक विफलताएँ: हमने बैच अनुरोधों में आंशिक विफलताओं को संभालने के लिए सिस्टम को पुनः संरचित किया है। पहले, एक शार्डेड बैच अनुरोध में एक ही अनुरोध की विफलता पूरे बैच को विफल कर देती थी। अब कुछ कुंजियों के पुनःप्राप्ति में विफल होने पर भी अनुरोध सफल हो सकते हैं।
• हेड-ऑफ़-लाइन ब्लकिंग को कम करना: कैशिंग सिस्टम से तेज़ होने की उम्मीद की जाती है। नेटवर्क में थोड़ी सी धीमी गति से भी अनुरोध जमा हो सकते हैं और टाइम आउट हो सकते हैं, जिसे हेड-ऑफ़-लाइन ब्लकिंग के रूप में जाना जाता है। हमने क्लाइंट और प्रॉक्सी दोनों लेयर में बुद्धिमानी से दोबारा प्रयास करने की मेकनिज्म और कनेक्शन पूलिंग रणनीतियों को लागू किया है ताकि एक धीमा अनुरोध दूसरों को प्रभावित न कर सके।
• त्रुटि और विलंब इंजेक्शन: लचीलेपन का परीक्षण करने के लिए, हम नियमित रूप से अपने त्रुटि इंजेक्शन फ्रेमवर्क का उपयोग करके प्रोडक्शन में नियंत्रित विफलताएं (नोड आउटेज, रैक आउटेज, नेटवर्क विलंब, एपीआई त्रुटियां) डालते हैं। इन परिस्थितियों में सिस्टम के व्यवहार का विश्लेषण करके, हम कमजोरियों की सक्रिय रूप से पहचान करते हैं और उन्हें ठीक करते हैं, जिससे निरंतर विश्वसनीयता सुनिश्चित होती है।

क्लाइंट-साइड लचीलापन

ट्रैफ़िक में अचानक उछाल से हमारे कैशिंग सिस्टम पर अत्यधिक भार पड़ने से रोकने के लिए, हमने क्लाइंट-साइड विफलता सहनशीलता को मजबूत किया है। यह तंत्र एप्लिकेशन स्तर पर काम करता है, यह सुनिश्चित करते हुए कि कोई भी एकल सेवा कैश संसाधनों पर एकाधिकार नहीं कर सकती है।

• फ्लो कंट्रोल के लिए रेट लिमिटिंग: हमारे क्लाइंट पर कुल आउटबाउंड ट्रैफ़िक पर एक सीमा होती है, यह सुनिश्चित करते हुए कि यह बैकएंड सेवा द्वारा संभाले जा सकने वाले अनुरोधों से अधिक अनुरोध न भेजे। जब इस सीमा को पार कर दिया जाता है तो अनुरोधों को थ्रॉटल किया जाता है, जो सेवा को अतिभार से बचाता है।
• पुनः प्रयास और टाइमआउट तंत्र: हमारी क्लाइंट लाइब्रेरीज़ थंडरिंग हर्ड समस्याओं को रोकने के लिए सावधानीपूर्वक ट्यून किए गए पुनः प्रयास तंत्र का उपयोग करती हैं, जिसमें टाइमआउट और एक पुनः प्रयास बजट शामिल है। यह विस्फोट की सीमा को सीमित करता है, संसाधनों को मुक्त करता है, और सिस्टम को अभिभूत होने से रोककर अनिश्चितकालीन हैंग और एक साथ पुनः प्रयास को रोककर समग्र सिस्टम की प्रतिक्रियाशीलता में सुधार करता है।

रॉब्लॉक्स कैशिंग का भविष्य

Roblox की कैशिंग यात्रा प्रत्येक एप्लिकेशन मालिक द्वारा सीधे प्रबंधित बेयर-मेटल Redis® क्लस्टर के साथ शुरू हुई, फिर यह हमारी कैशिंग टीम द्वारा प्रबंधित Memcached क्लस्टर पर चली गई, और अंत में यह Redis®-एज़-ए-सर्विस मॉडल में परिवर्तित हो गई, जहाँ एक Redis® क्लस्टर एक प्रबंधित सेवा के रूप में प्रदान किया जाता है। हालांकि यह मॉडल हमारे वर्तमान पैमाने पर अत्यधिक प्रभावी साबित हुआ है, हम रोब्लॉक्स जैसे गतिशील प्लेटफ़ॉर्म के लिए सेवा दक्षता और संसाधन पृथक्करण के मामले में इसकी सीमाओं को पहचानते हैं।

जैसे-जैसे प्लेटफ़ॉर्म बढ़ रहा है, हम ValKey पर निर्मित अगली पीढ़ी की मल्टीटेनेंट कैशिंग सेवा में एक महत्वपूर्ण निवेश करने की योजना बना रहे हैं। यह आर्किटेक्चर मल्टीटेनेन्सी के माध्यम से सामान्य संसाधनों को साझा करके लागतों को काफी कम करने के लिए डिज़ाइन किया गया है, साथ ही प्रत्येक टेनेंट के लिए डेटा, संसाधन और विफलता अलगाव सुनिश्चित करता है। हमारा लक्ष्य Roblox पर लगातार बढ़ रहे विशाल अनुभवों की मांगों को पूरा करने के लिए हमारे कैशिंग इंफ्रास्ट्रक्चर के प्रदर्शन, स्केलेबिलिटी, विश्वसनीयता और लागत-कुशलता को बहुत बढ़ाना है।

स्वीकृति: 

यह उपलब्धि एक सामूहिक प्रयास था। अन्य टीम के सदस्यों का धन्यवाद जिन्होंने महत्वपूर्ण योगदान दिया: उत्कर्ष सिंह, कार्तिक रामचंद्रन, विनीशा कासिरैड्डी, वेइजी हु, और लियोन गाओ।