रॉब्लॉक्सने त्यांच्या काफ्का प्लॅटफॉर्मची क्षमता दररोज १८ ट्रिलियन संदेशांपर्यंत कशी वाढवली

गेल्या दोन वर्षांत, आम्ही आमच्या अंतर्गत मेसेज क्यू प्लॅटफॉर्मची क्षमता दरवर्षी 2.5 पट वाढवून दररोज 18 ट्रिलियन संदेशांपर्यंत पोहोचवली आहे. सध्या आम्ही प्रति सेकंद 300 दशलक्षाहून अधिक संदेश प्रक्रिया करत आहोत आणि 99.995% उपलब्धता राखत आहोत. Apache Kafka वर आधारित हे संदेश रांग प्लॅटफॉर्म कंपनीभरात डेटा वाहून नेण्याच्या आमच्या प्रक्रियेचा एक महत्त्वपूर्ण भाग बनले आहे. हे विश्लेषणात्मक घटना, मॉडरेशन पाइपलाइन, मॅचमेकिंग प्रणाली आणि इतर अनेक कार्यभार समर्थित करते. हे आकडे उत्साहवर्धक आहेत, परंतु त्यापेक्षा महत्त्वाची गोष्ट म्हणजे आम्ही तिथे कसे पोहोचलो. 

एंड-टू-एंड ऑप्टिमायझेशनचा प्रभाव 

मोठ्या प्रमाणावरील प्रणालींबद्दल एक सामान्य गैरसमज असा आहे की क्षमता ही मुख्यतः हार्डवेअरची समस्या आहे. आमच्या अनुभवात, स्केलेबिलिटीला एंड-टू-एंड अभियांत्रिकी समस्या म्हणून हाताळल्याने सर्वात प्रभावी सुधारणा होतात.

Roblox मधील विविध संघांनी मेसेजिंग क्यूच्या वर विविध प्लॅटफॉर्म तयार केले आहेत, ज्यात AI प्रशिक्षण पाइपलाइन, स्ट्रीम प्रोसेसिंग अ‍ॅबस्ट्रॅक्शन आणि टेलिमेट्री सिस्टम यांचा समावेश आहे. या प्लॅटफॉर्मच्या मालकांसोबत भागीदारी केल्याने आम्हाला बॅचिंग आणि कॉम्प्रेशन सक्षम करण्यासारख्या सर्वोत्तम पद्धतींचे पालन सुनिश्चित करण्यात मदत होते. यामुळे अंतिम वापरकर्त्यांना तपशीलवार कॉन्फिगरेशन सेटअपमध्ये गुंतवल्याशिवाय कार्यक्षम सिस्टम तयार होतात.

प्लॅटफॉर्मचा वापर करणाऱ्या संघांशी व्यावसायिक प्राधान्यक्रम, मापन आणि यश निकष याबाबत समन्वय साधणे अत्यंत महत्त्वाचे आहे आणि ते विविध संघांमधील सहकार्य वाढवण्यास मदत करते. मुख्य मेट्रिक्स प्रणालीच्या विविध स्तरांनुसार बदलतात: जरी आपण कमी मशीनसह मोठ्या प्रमाणावर डेटा कार्यक्षमतेने हाताळण्यासाठी Kafka सर्व्हरचे ऑप्टिमायझेशन करू शकतो, तरी अंतिम वापरकर्ते मिलिसेकंदांच्या पातळीपर्यंत एंड-टू-एंड विलंब किंवा त्यांच्या बॅच जॉबद्वारे डेटा लिहिण्यास लागणारा एकूण वेळ यासाठी ऑप्टिमायझ करू इच्छित असू शकतात. 

सर्व ट्रॅफिक समान नसते

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

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

आम्ही स्टॅकमध्ये खाली हार्डवेअर थरातही, प्रत्येक क्लस्टर त्याद्वारे सेवा दिलेल्या उपयोग प्रकरणांसाठी अनुकूलित करण्याची ही पद्धत लागू करतो. 

हार्डवेअर अद्याप महत्त्वाचे आहे

आम्ही RAID10 HDD मशीनवर Kafka चालवून सुरुवात केली. ट्रॅफिकचे प्रमाण वाढल्यावर, आमच्या मशीनची डिस्क I/O क्षमता प्रति-सर्व्हर Kafka थ्रूपुट मर्यादित करणारी मुख्य अडचण बनली. यावर उपाय म्हणून, आम्ही दोन ऑप्टिमायझेशन केल्या. आम्ही ब्रोकर्सना शक्य तितक्या SSDs वापरण्यास रूपांतरित केले, ज्यामुळे अडचण डिस्क I/O क्षमतेपासून नेटवर्क थ्रूपुट किंवा डिस्क स्पेसकडे (कारण आम्ही घेतलेल्या SSDs मध्ये कमी डिस्क स्पेस होता) वळली. यामुळे डिस्क I/O थ्रूपुटमध्ये 10 पट वाढ झाली. आम्ही उरलेल्या HDD ला RAID10 वरून RAID0 मध्ये रूपांतरित करणेही सुरू केले. RAID0 मध्ये प्रत्येक राइटसाठी दोनऐवजी फक्त एका डिस्कवर लिहावे लागते, त्यामुळे डिस्क I/O क्षमता सुमारे दुप्पट झाली. 

यामध्ये जोखीम अशी आहे की प्रत्येक संदेशाची प्रतिकृती RAID10 मध्ये दोन डिस्कवर लिहिण्याऐवजी प्रत्येक ब्रोकरमधील एका डिस्कवर लिहिली जाते, त्यामुळे RAID10 वरून RAID0 कडे जाताना विश्वसनीयतेचा धोका उद्भवू शकतो. विश्वसनीयता टिकवून ठेवण्यासाठी, आम्ही महत्त्वाच्या वापर प्रकरणांसह 'acks' आणि डेटा प्रतिकृती वाढवण्यासाठी काम केले, ज्यात अनेक प्रदेशांमध्ये प्रतिकृती करणे समाविष्ट आहे.

प्रत्येक मशीनच्या स्टोरेज आणि थ्रूपुट क्षमतेचा पूर्णपणे लाभ घेण्यासाठी अतिरिक्त काम करावे लागले. आम्ही आमच्या मेमरी वाटप आणि पेज कॅश व्यवस्थापन कॉन्फिगरेशनचे ऑप्टिमायझेशन केले, ज्यामुळे Kafka संदेश बफर करू शकते आणि मेमरीमधून वाचन किंवा अलीकडील डेटा सर्व्ह करू शकते, आणि फक्त आवश्यक तेव्हाच डिस्कवर जाऊन मौल्यवान IOPS वापरते, जसे की ऐतिहासिक डेटा वाचताना. 

हार्डवेअरच्या मर्यादा समजून घेण्यासाठी आणि सॉफ्टवेअर-स्तरावर कोणत्या मर्यादा सेट करायच्या हे ठरवण्यासाठी आम्ही परफॉर्मन्स बेंचमार्क देखील चालवतो. प्रत्यक्षात, याचा अर्थ Kafka ब्रोकरचे वाचणे आणि लिहिणे थ्रॉटल सेट करणे होय, जे क्लस्टर्स चालवणाऱ्या हार्डवेअरवर अवलंबून बदलतात. आमच्या SSD मशीन्स प्रत्येक ब्रोकरसाठी जास्त थ्रूपुट हाताळू शकतात, तर आमच्या HDD मशीन्स ऐतिहासिक डेटाच्या दीर्घकालीन साठवणीसाठी आवश्यक असलेल्या वापराच्या प्रकरणांसाठी अधिक योग्य आहेत. 

विश्वसनीयतेसाठी बांधणी

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

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

खालील आकृती फेलओव्हर अंमलात आणण्यासाठी उच्च-स्तरीय टप्पे दर्शवते. प्रथम, ऑपरेटर फेलओव्हरची व्याप्ती ओळखतो. नंतर, स्टँडबाय क्लस्टरवर स्वयंचलित बल्क ऑपरेशनद्वारे टॉपिक्स आणि ऍक्सेस कंट्रोल लिस्ट (ACLs) तयार केल्या जातात. शेवटी, ऑपरेटर आमच्या कंट्रोल प्लेन सेवा कॉन्फिग्स अपडेट करतो, ज्याद्वारे क्लायंट्स कोणतीही पुनर्संयोजन आवश्यक आहे का हे ठरवण्यासाठी पोल करतात. खालील चित्र सामान्य रिअल-टाइम वापर प्रकरणांसाठी आहे. आमच्याकडे इतर वापरप्रकरणे आणि परिस्थितींसाठी अतिरिक्त धोरणे आणि साधने उपलब्ध आहेत, ज्यात Mirror Maker 2 वापरून टॉपिक मिररिंग, डेटा बॅकफिल साधने आणि बरेच काही समाविष्ट आहे.

Roblox कडे सुरक्षा यासाठी कडक आवश्यकता आहेत, जी विश्वसनीयतेचा देखील एक महत्त्वाचा भाग आहे. आम्ही ट्रान्झिटमध्ये एन्क्रिप्शन (mTLS सह), विश्रांतीवर एन्क्रिप्शन (एन्क्रिप्टेड डिस्कसह), डेटा प्रतिधारण कालावधीच्या आवश्यकता आणि Kafka प्रिन्सिपल्स व ACLs सह प्रमाणीकरण/अधिकृतकरण यांसारख्या मानक सुरक्षा वैशिष्ट्यांची अंमलबजावणी केली आहे. आम्ही सुरक्षा आणखी सुधारण्यासाठी आमच्या वापरकर्त्यांच्या क्रेडेन्शियल्सचे स्वयंचलितपणे रोटेशनही करतो.

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

पुढील मार्ग

आमच्या क्यू प्लॅटफॉर्मसाठी पुढील अध्याय म्हणजे डेव्हलपर्ससाठी प्लॅटफॉर्म आणखी सोपा बनवणे, तर त्याचबरोबर लवचिकता आणि पृथक्करण सुधारणे सुरू ठेवणे. आम्ही नवीन अमूर्ततांमध्ये (abstractions) गुंतवणूक करत आहोत, ज्यात प्रोड्युसर आणि कन्झ्युमर प्रॉक्सी तसेच पूर्णपणे व्यवस्थापित कनेक्टरचा समावेश आहे. या प्रणाली अॅप्लिकेशन टीमना पायाभूत सुविधांच्या गुंतागुंतीपासून आणखी वेगळे करतील आणि आमच्या प्लॅटफॉर्मना मोठ्या प्रमाणावर स्वीकारणे आणि व्यवस्थापित करणे सोपे करतील. उदाहरणार्थ, एक कंझ्युमर प्रॉक्सी स्पर्धात्मक कंझ्युमर पॅटर्न सक्षम करेल, ज्यामुळे प्लॅटफॉर्मला अधिक विस्तृत वापर प्रकरणांना समर्थन देता येईल आणि प्रोसेसरचे स्केलिंग Kafka विभाजनांच्या स्केलिंगपासून स्वतंत्र करता येईल. हे सूचनांच्या मोठ्या प्रमाणावर होणाऱ्या स्फोट प्रक्रियेसारख्या वापर प्रकरणांसाठी उपयुक्त आहे, ज्यांना क्रमांकणाची आवश्यकता नसते आणि अंतिम-ते-अंत वितरण लक्ष्य पूर्ण करण्याच्या बंधनाशिवाय तात्पुरते प्रोसेसरची संख्या वाढवून फायदा होऊ शकतो.

Kafka चे स्केलिंग म्हणजे फक्त क्लस्टर्सच्या संख्येची आणि आकाराची वाढ करणे इतकेच नाही. हे अभियांत्रिकी शिस्त, सारसंकल्पना आणि ऑपरेशनल मॉडेल तयार करण्याबद्दल आहे, जे Roblox ला आशावाद आणि सभ्यतेने दररोज अब्जा लोकांना जोडण्याच्या आमच्या प्रवासात पुढे जाण्यास अनुमती देते.