Roblox च्या प्रचंड-स्तरीय मल्टीप्लेअर गेमिंग वातावरणात, वापरकर्ते इतक्या प्रमाणात आणि वेगाने डेटा वाचतात व लिहितात की ते पारंपारिक कॅशिंग पॅटर्न्सना तुटवून टाकतात. सामान्य वेबपेजवर स्थिर डेटा कॅश केल्यामुळे 200 मिलीसेकंदांचा विलंब वापरकर्त्याला जाणवणार नाही, परंतु Roblox वर परस्परसंवाद डेटा किंवा सर्व्हर मेटाडेटा मिळवताना 200 मिलीसेकंदांचा विलंब गेमप्ले थांबवू शकतो आणि सिम्युलेटेड गेम जगात व्यत्यय आणू शकतो. Roblox अप्रत्याशित, उच्च गतीचे आणि क्षणभंगुर डेटाच्या परिसंस्थेवर कार्य करते, ज्याला इमर्सन टिकवण्यासाठी मिलीसेकंदांच्या आत प्राप्त करणे आवश्यक असते. 

आमची कॅशिंग लेयर लाखो समवर्ती वापरकर्ते आणि आमच्या कायमस्वरूपी स्टोरेज यांच्यात एक प्रचंड शॉक अॅबसॉर्बर म्हणून कार्य करण्यासाठी डिझाइन केलेली आहे. ती प्रति सेकंद 1.38 अब्ज क्वेरीज (QPS) इतक्या उच्चतम लोडला हाताळते, ज्यात एकल लॉजिकल क्लस्टर्स 100 दशलक्ष QPS पेक्षा जास्त क्षमतेपर्यंत पोहोचतात. या पोस्टमध्ये, आम्ही आमच्या सर्वात मोठ्या क्लस्टरवर अभूतपूर्व 10 पट वाहतुकीच्या वाढीचा सामना करत असताना, प्रचंड थ्रूपुटसाठी Redis® नोड मर्यादा ओलांडून स्केल करण्यासाठी आम्ही कशी फेडरेटेड कॅशिंग सेवा रचली, याची पडदा उचलणार आहोत.

उद्योगाच्या मर्यादेपलीकडे वाढत जाणाऱ्या मागण्या पूर्ण करण्यासाठी स्केलिंग

Roblox मध्ये, आमची कॅशिंग सेवा Redis® तंत्रज्ञानावर आधारित आहे, आणि एका Redis® क्लस्टरमध्ये 1,000 नोड्सपर्यंत समर्थन करण्याची क्षमता आहे. तथापि, प्रत्यक्ष आणि उद्योगात मान्यताप्राप्त मर्यादा खूपच कमी आहे—सुमारे 400–500 नोड्स.¹ हे Redis® च्या विकेंद्रीकृत गॉसिप प्रोटोकॉलमुळे आहे, जे आरोग्य, स्थिती आणि शार्ड मॅपिंग शेअर करण्यासाठी इंटरनोड संवादाचा वापर करते. काही शेकडो नोड्सपेक्षा मोठ्या क्लस्टर्समध्ये, गॉसिप प्रोटोकॉलमधील संवाद महत्त्वपूर्ण CPU आणि नेटवर्क संसाधने वापरू लागतो. प्रत्येक नोडला सतत वाढत जाणाऱ्या समकक्षांकडून (peers) स्थिती अद्यतने (status updates) प्रक्रिया करावी लागतात, ज्यामुळे कमी विलंबात डेटा सर्व्ह करण्याच्या मुख्य कामासाठी संसाधने कमी होतात. या कंट्रोल प्लेनच्या ओव्हरहेडमुळे अस्थिरता आणि अनपेक्षित कामगिरी उद्भवू शकते, म्हणूनच व्यवस्थापित क्लाउड प्रदाते नोड मर्यादा लागू करतात. ही एक व्यावहारिक मर्यादा आहे जी विश्वासार्हतेशी तडजोड न करता ओलांडता येत नाही.

ही व्यावहारिक एकल क्लस्टर मर्यादा Roblox इतक्या प्रमाणात चालणाऱ्या प्लॅटफॉर्मसाठी पुरेशी नाही, जिथे सर्वात मोठ्या बॅकएंड सेवेने तीन महिन्यांत 10 दशलक्षांवरून शिखरावर आमच्या एका लॉजिकल Redis® क्लस्टरकडून 100 दशलक्ष QPS पेक्षा जास्त मागणी केली.

या वास्तुकला मर्यादेवर मात करण्यासाठी आम्ही एक संघटित वास्तुकला स्वीकारली, ज्यात अनेक लहान, स्वतंत्र Redis® क्लस्टर्सच्या समोर क्लायंट रिव्हर्स प्रॉक्सी ठेवली. पूर्वानुमेय कामगिरी सुनिश्चित करण्यासाठी आम्ही प्रत्येक क्लस्टरसाठी 400-नोड मर्यादा वापरतो. 

आमच्या हजारो अॅप्लिकेशन्स आणि सेवांच्या दृष्टीकोनातून, क्लायंट रिव्हर्स प्रॉक्सी या विभक्त क्लस्टर्सना एकसंध, सुसंगत आणि स्केलेबल कॅशिंग सेवा म्हणून सादर करते. ही फेडरेशन आम्हाला फक्त फेडरेशनमध्ये अधिक क्लस्टर्स जोडल्याने जवळजवळ मर्यादेशिवाय क्षैतिज स्केल करण्यास अनुमती देते, ज्याद्वारे गॉसिप प्रोटोकॉलच्या मर्यादा पूर्णपणे बाजूला करता येतात. आज, आमची सर्वात मोठी एकल कॅशिंग तैनाती ६,००० पेक्षा जास्त Redis® नोड्सची आहे, ज्यांना १५ पेक्षा जास्त स्वतंत्र Redis® क्लस्टर्सचा पाठिंबा आहे—हे प्रमाण फक्त या फेडरेटेड मॉडेलमुळेच शक्य झाले आहे.

तीन-चरणी स्थलांतर प्रक्रिया

परंपरागत सेटअपमधून फेडरेटेड आर्किटेक्चरकडे स्थलांतर करणे आणि त्याच वेळी शेकडो सक्रिय उत्पादन क्लस्टर्सचे व्यवस्थापन करणे हे एक महत्त्वपूर्ण उपक्रम होते. २०२४ च्या अखेरीस, यापैकी अनेक क्लस्टर्स आमच्या ४००-नोड मर्यादेच्या जवळ पोहोचले होते, ज्यामुळे उच्च क्षमतेच्या मॉडेलकडे संक्रमण तातडीचे बनले. मुख्य आव्हान म्हणजे मानक Redis® उदाहरणे स्वतंत्रपणे कार्य करतात आणि इतर क्लस्टर्सबद्दल त्यांना अंतर्निहित माहिती नसते, ज्यामुळे स्थलांतरादरम्यान डेटाची प्रतिकृती तयार करण्यासाठी सानुकूल पद्धत आवश्यक ठरली.

यावर उपाय म्हणून, आम्ही एक पारदर्शक, तीन-चरणी स्थलांतर पाइपलाइन विकसित केली जी कोणत्याही ग्राहकांच्या सहभागाशिवाय किंवा अनुप्रयोग-स्तरीय बदलांशिवाय सेवा हस्तांतरित करण्यासाठी डिझाइन केलेली आहे.

स्थानांतरण वर्कफ्लो

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

आम्ही आमच्या सर्वात महत्त्वाच्या सेवांना एका फेडरेटेड मॉडेलमध्ये यशस्वीरित्या स्थलांतरित केले, जे 6,000 पेक्षा जास्त नोड्सना समर्थन देते, जे एकाच Redis® क्लस्टरच्या मर्यादेपेक्षा खूप जास्त आहे. 

ग्रो अ गार्डनच्या झपाट्याने वाढती हाताळणे

एप्रिल 2025 पासून, आम्हाला अशा प्रमाणात क्षमता आव्हान सामोरे जावे लागले जे फारच कमी सेवांना कधीच अनुभवावे लागते. याचे उत्प्रेरक Grow a Garden च्या अभूतपूर्व यशाने होते. लाँच झाल्यानंतर काही आठवड्यांतच, Grow a Garden ने केवळ Roblox चे विक्रमच नव्हे तर सर्वकालीन गेमिंग उद्योगातील समवर्ती वापरकर्त्यांच्या (CCU) विक्रमांनाही मोडण्यास सुरुवात केली. फक्त तीन महिन्यांत, गेमचे प्रेक्षक आमच्या मागील एका गेमच्या CCU विक्रमापेक्षा (2.8 दशलक्ष खेळाडू) पार जाऊन 21 दशलक्षांच्या शिखरावर पोहोचले. या विस्फोटक वाढीमुळे आमच्या सर्वात मोठ्या Redis® क्लस्टरकडे 10 पट अधिक ट्रॅफिक आणि एकूण कॅशिंगकडे 3 पट अधिक ट्रॅफिक पाठवले गेले.

Roblox आमच्या स्वतःच्या डेटा सेंटरमधील भौतिक मशीनवर आमच्या कॅशिंग प्रणाली चालवते, आणि हा अभूतपूर्व वाढ आमच्या दीर्घकालीन क्षमता आराखड्याचा भाग नव्हता. या प्रचंड लाटेला तोंड देण्यासाठी आणि प्लॅटफॉर्म स्थिर ठेवण्यासाठी, आम्हाला विश्वासार्हतेला प्राधान्य देत आमच्या विद्यमान फ्लीटची कार्यक्षमता मूलभूतपणे सुधारण्याची गरज होती. 

वाढीच्या काळात कार्यक्षमता सुधारणे

प्रथम, आमच्या सिस्टममधील सर्वात प्रभावी अडथळे ओळखणे आवश्यक होते, जेणेकरून आम्ही ऑप्टिमायझेशन कामाला प्राधान्य देऊ शकू. Roblox कॅशिंग दोन भिन्न हार्डवेअर पूल्सवर चालते: एक Redis® बॅकएंड नोडसाठी आणि एक Envoy साठी. आमची Redis® फ्लीट मुख्यत्वे मेमरी-बाउंड आहे, तर क्लायंट प्रॉक्सी कम्प्यूट-बाउंड आहे. 

आमच्या मेमरी-बाउंड Redis® फ्लीटसाठी, आम्ही भौतिक मशीन गटांमध्ये मेमरी वापर अधिक चांगल्या प्रकारे संतुलित करण्यासाठी नवीन शेड्यूलिंग धोरण राबवले. मेमरी फ्रॅगमेंटेशन कमी करण्यासाठी आम्ही कंटेनरचा आकारही सूक्ष्मपणे समायोजित केला. 

CPU वापर सुधारण्यासाठी, आम्ही आमच्या कॅश सिस्टममध्ये दोन मुख्य ऑप्टिमायझेशन अंमलात आणल्या:

1. क्लायंट प्रॉक्सी ऑटोस्केलिंग: आम्ही आमच्या गणना-आधारित क्लायंट प्रॉक्सी फ्लीटसाठी ऑटोस्केलिंग धोरण समायोजित केले. लक्ष्य CPU पासून परवानगी दिलेली विचलन कमी करून, आम्ही स्केल-अप मर्यादा न बदलता नोकऱ्यांसाठी उच्च सरासरी CPU वापर साध्य केला.
2. आंतरिक क्लस्टर आरोग्य तपासण्या: आम्ही अनावश्यक हार्टबीट्स काढून टाकण्यासाठी आंतरिक आरोग्य तपासण्या अनुकूलित केल्या, ज्यामुळे मूळ शोध अंतर जपले गेले आणि संगणकीय संसाधनांची बचत झाली.

या बदलांमुळे CPU वापरक्षमता सुमारे 10% ने वाढली. शेवटी, आम्ही cgroup कंटेनर-स्तरीय विभक्तीसह या दोन अत्यंत भिन्न वर्कलोड्सना एकाच मशीन पूलमध्ये एकत्रित केले, ज्यामुळे आमच्या एकूण क्षमतेच्या गरजा 25% ने कमी झाल्या.

अढळ विश्वसनीयतेसाठी अभियांत्रिकी

रेकॉर्ड-ब्रेकिंग मागणी पूर्ण करण्याच्या धावपळीतही विश्वसनीयता आमची सर्वोच्च प्राधान्य होती. 

एंड-टू-एंड निरीक्षणीयता

आम्ही प्रथम आमच्या कॅशिंग सिस्टमच्या सर्वसमावेशक, एंड-टू-एंड आरोग्य निरीक्षणासाठी आमच्या ऑब्झर्व्हेबिलिटी स्टॅकमध्ये मोठी गुंतवणूक करून संभाव्य अपयशांना समजून घेण्यावर लक्ष केंद्रित केले. संपूर्ण विनंती जीवनचक्रात सर्व्हर यश आणि क्लायंट-साइड अपयशांचा मागोवा घेऊन, आम्ही समस्या लवकरच शोधल्या आणि निदान केल्या, आणि अनेकदा वापरकर्त्यांवर होणारा परिणाम टाळला. उदाहरणार्थ, आम्ही हॉट की शोध (hot key detection) जोडला, जो थेट चालू ट्रॅफिकचे नमुने घेऊन जास्त प्रमाणात ऍक्सेस होणारा आणि कॅशिंग थरात ताण निर्माण करणारा डेटा ओळखतो. जेव्हा सिस्टम हॉट कीची सूचना देते, तेव्हा सिस्टम ओव्हरलोड होण्यापासून रोखण्यासाठी आम्ही सर्व्हर आणि क्लायंट दोन्ही बाजूंवर या कीजसाठीचा ट्रॅफिक सक्रियपणे मर्यादित करू शकतो.

अपयश हाताळणी

या प्रमाणाच्या कोणत्याही वितरित प्रणालीमध्ये, आंशिक अपयश कधीकधी घडते. आम्ही आमची प्रणाली या अपयशांना सुरळीतपणे हाताळण्यासाठी आणि त्यांचा परिणाम कमी करण्यासाठी रचली आहे.

• बॅच केलेल्या विनंत्यांमधील आंशिक अपयश: आम्ही बॅच केलेल्या विनंत्यांमधील आंशिक अपयश हाताळण्यासाठी सिस्टमची पुनर्रचना केली आहे. पूर्वी, विभाजित बॅच विनंतीमधील एका विनंतीच्या अपयशाने संपूर्ण बॅच अपयशी ठरवायची. आता काही कीज मिळविण्यात अपयश आले तरीही विनंत्या यशस्वी होऊ शकतात.
• हेड-ऑफ-लाइन ब्लॉकिंग कमी करणे: कॅशिंग सिस्टम वेगवान असण्याची अपेक्षा असते. अगदी थोडीशी नेटवर्क मंदताही विनंत्या साचून ठेवू शकते आणि टाइम-आउट होऊ शकते, ज्याला हेड-ऑफ-लाइन ब्लॉकिंग म्हणतात. आम्ही क्लायंट आणि प्रॉक्सी लेयरमध्ये हुशार रीट्राय यंत्रणा आणि कनेक्शन पूलिंग धोरणे अंमलात आणली आहेत, ज्यामुळे एका मंद विनंतीमुळे इतरांवर परिणाम होण्यापासून प्रतिबंध होतो.
• त्रुटी व विलंब इंजेक्शन: लवचिकता चाचणी करण्यासाठी, आम्ही आमच्या दोष इंजेक्शन फ्रेमवर्कचा वापर करून नियमितपणे नियंत्रित अपयश (नोड बंद होणे, रॅक बंद होणे, नेटवर्क विलंब, API त्रुटी) प्रोडक्शनमध्ये इंजेक्ट करतो. या परिस्थितींमध्ये सिस्टमच्या वर्तनाचे विश्लेषण करून, आम्ही सक्रियपणे कमकुवतपणा ओळखतो आणि दुरुस्त करतो, ज्यामुळे सातत्यपूर्ण विश्वसनीयता सुनिश्चित होते.

क्लायंट-साइड लवचिकता

ट्रॅफिकमधील अचानक वाढीमुळे आमची कॅशिंग प्रणाली ओव्हरलोड होऊ नये यासाठी, आम्ही क्लायंट-साइडवरील अपयश सहनशक्ती मजबूत केली आहे. ही यंत्रणा अॅप्लिकेशन स्तरावर कार्य करते, ज्यामुळे कोणतीही एक सेवा कॅश संसाधनांवर वर्चस्व गाजवू शकत नाही.

• प्रवाह नियंत्रणासाठी दर मर्यादित करणे: आमच्या क्लायंटमध्ये एकूण आउटबाउंड ट्रॅफिकवर मर्यादा असते, ज्यामुळे बॅकएंड सेवा हाताळू शकते त्यापेक्षा जास्त विनंत्या पाठवल्या जात नाहीत. ही मर्यादा ओलांडल्यावर विनंत्या थ्रॉटल केल्या जातात, ज्यामुळे सेवा ओव्हरलोड होण्यापासून वाचते.
• पुन्हा प्रयत्न आणि टाइमआउट यंत्रणा: आमच्या क्लायंट लायब्ररींमध्ये काळजीपूर्वक समायोजित केलेल्या पुन्हा प्रयत्न यंत्रणांचा वापर केला जातो, ज्यात टाइमआउट आणि पुन्हा प्रयत्न बजेट यांचा समावेश होतो, जे 'थंडरिंग हर्ड' समस्या टाळतात. यामुळे परिणामी परिणामांचा विस्तार मर्यादित होतो, संसाधने मोकळी होतात, आणि अनिश्चित काळासाठी अडकणे व एकाच वेळी होणाऱ्या पुन्हा प्रयत्नांमुळे सिस्टमवर होणारा ताण टाळून एकूण सिस्टम प्रतिसादक्षमता सुधारते.

रॉब्लॉक्स कॅशिंगचे भविष्य

Roblox च्या कॅशिंग प्रवासाची सुरुवात प्रत्येकी अॅप्लिकेशन मालकांनी थेट व्यवस्थापित केलेल्या बेअर-मेटल Redis® क्लस्टर्सपासून झाली, नंतर ती आमच्या कॅशिंग टीमने व्यवस्थापित केलेल्या Memcached क्लस्टर्सकडे गेली, आणि शेवटी Redis®-as-a-service मॉडेलकडे संक्रमण झाले, जिथे Redis® क्लस्टर व्यवस्थापित सेवा म्हणून प्रदान केला जातो. जरी हा मॉडेल सध्याच्या प्रमाणात अत्यंत प्रभावी ठरला असला तरी, Roblox सारख्या गतिशील प्लॅटफॉर्मसाठी सेवा कार्यक्षमता आणि संसाधन विभक्तीकरणाच्या दृष्टीने त्यामधील मर्यादा आम्ही ओळखतो.

प्लॅटफॉर्म वाढत राहिल्यामुळे, आम्ही ValKey वर आधारित पुढील-पिढीच्या मल्टीटेनंट कॅशिंग सेवेत मोठी गुंतवणूक करण्याची योजना आखत आहोत. हे आर्किटेक्चर मल्टीटेनन्सीद्वारे सामान्य संसाधने सामायिक करून खर्च मोठ्या प्रमाणात कमी करण्यासाठी डिझाइन केलेले आहे, तर प्रत्येक टेनंटसाठी डेटा, संसाधन आणि अपयश पृथक्करण सुनिश्चित करते. Roblox वरील वाढत्या प्रचंड अनुभवांच्या मागण्या पूर्ण करण्यासाठी आमच्या कॅशिंग पायाभूत सुविधांची कार्यक्षमता, विस्तारक्षमता, विश्वसनीयता आणि खर्च-कार्यक्षमता मोठ्या प्रमाणात वाढवणे हे आमचे उद्दिष्ट आहे.

कृतज्ञता: 

ही कामगिरी एक सामूहिक प्रयत्न होती. महत्त्वपूर्ण योगदान देणाऱ्या इतर टीम सदस्यांचे आभार: उत्कर्ष सिंह, कार्तिक रामचंद्रन, विनीशा कासिरెड्डी, वेईजी हु, आणि लिओन गाओ.