रॉब्लॉक्स ने अपने काफ़्का प्लेटफ़ॉर्म को प्रतिदिन 18 ट्रिलियन से अधिक संदेशों तक कैसे स्केल किया

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

एंड-टू-एंड ऑप्टिमाइज़ेशन का प्रभाव 

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

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

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

सभी ट्रैफ़िक समान नहीं होते

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

इस समस्या को हल करने के लिए, हम यह सुनिश्चित करने के लिए ट्रैफ़िक को उपयोग-मामले की आवश्यकताओं के अनुसार समूहित करते हैं कि प्रत्येक का अच्छी तरह से समर्थन किया गया है। Kafka में एंड-टू-एंड लेटेंसी और थ्रूपुट के बीच समझौता नए उपयोग-मामलों को स्थापित करते समय प्राथमिक विचारों में से एक है। यह प्रोड्यूसर से सर्वर से कंज्यूमर तक के डेटा पथ में भी सच है: इनमें से प्रत्येक के पास ऐसी कॉन्फ़िगरेशन हैं जिन्हें या तो थ्रूपुट या लेटेंसी के लिए अनुकूलित किया जा सकता है। क्लाइंट-साइड कॉन्फ़िगरेशन को व्यक्तिगत उपयोग मामलों के लिए ट्यून किया जा सकता है, लेकिन सर्वर-साइड कॉन्फ़िगरेशन कम लचीले होते हैं, क्योंकि प्रत्येक अलग उपयोग मामले के लिए एक समर्पित क्लस्टर बनाए रखना संभव नहीं है। 

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

हार्डवेयर अभी भी महत्वपूर्ण है

हमने RAID10 HDD मशीनों पर Kafka चलाकर शुरुआत की। जैसे-जैसे ट्रैफ़िक की मात्रा बढ़ी, हमारी मशीनों की डिस्क I/O क्षमता, प्रति-सर्वर Kafka थ्रूपुट को सीमित करने वाली मुख्य बाधा बन गई। इसे हल करने के लिए, हमने दो अनुकूलन किए। हमने ब्रोकरों को यथासंभव SSDs का उपयोग करने के लिए परिवर्तित किया, जिससे बाधा डिस्क I/O क्षमता से नेटवर्क थ्रूपुट या डिस्क स्पेस पर चली गई (क्योंकि हमने जो SSDs खरीदे थे उनमें कम डिस्क स्पेस था)। इससे डिस्क I/O थ्रूपुट 10 गुना बढ़ गया। हमने अपने शेष HDDs को RAID10 से RAID0 में बदलना भी शुरू कर दिया। इससे डिस्क I/O क्षमता लगभग दोगुनी हो गई, क्योंकि RAID0 के साथ प्रत्येक राइट के लिए दो के बजाय केवल एक डिस्क राइट की आवश्यकता होती है। 

इसका समझौता यह है कि चूंकि प्रत्येक संदेश की प्रतिकृति दो के बजाय एक डिस्क पर लिखी जाती है, इसलिए RAID10 से RAID0 पर जाने में विश्वसनीयता का जोखिम हो सकता है। विश्वसनीयता बनाए रखने के लिए, हमने महत्वपूर्ण उपयोग मामलों के साथ मिलकर acks और डेटा प्रतिकृति बढ़ाई, जिसमें कई क्षेत्रों में प्रतिकृति बनाना भी शामिल है।

प्रत्येक मशीन की स्टोरेज और थ्रूपुट क्षमताओं का पूरी तरह से लाभ उठाने के लिए अतिरिक्त काम की आवश्यकता थी। हमने अपनी मेमोरी आवंटन और पेज कैश प्रबंधन कॉन्फ़िगरेशन को अनुकूलित किया ताकि Kafka संदेशों को बफर कर सके और मेमोरी से रीड्स या हालिया डेटा परोस सके, और केवल तभी डिस्क का उपयोग करे और मूल्यवान IOPS खर्च करे जब आवश्यक हो, जैसे कि ऐतिहासिक डेटा पढ़ते समय। 

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

विश्वसनीयता के लिए निर्माण

क्யூ प्लेटफ़ॉर्म Roblox के बुनियादी ढांचे का एक महत्वपूर्ण घटक है, और विश्वसनीयता बनाए रखना महत्वपूर्ण है। प्री-लॉन्च परीक्षण के साथ-साथ चल रहे विफलता परिदृश्य परीक्षण (जिसे कभी-कभी गेम डे एक्सरसाइज कहा जाता है) यह सत्यापित करने में महत्वपूर्ण रहे हैं कि हमारा बुनियादी ढांचा एकल होस्ट विफलता, रैक विफलता, नेटवर्किंग समस्याओं और कई अन्य विफलता मोड के प्रति लचीला है। हमारी विश्वसनीयता टीम के आंतरिक काओस परीक्षण प्लेटफ़ॉर्म ने विभिन्न विफलता परिदृश्यों का अनुकरण करने की प्रक्रिया को सक्षम और सुव्यवस्थित किया है। ये परीक्षण सिस्टम में सुधार या गिरावट की पहचान करने और नियमित रूप से अलर्ट को मान्य करके परिचालन उत्कृष्टता बनाने में मदद करते हैं, साथ ही यह सुनिश्चित करते हैं कि ऑपरेटर विभिन्न मुद्दों—यहां तक कि दुर्लभ मुद्दों—से निपटने के चरणों से परिचित हैं।

हमने फेलओवर प्रक्रियाएं भी डिज़ाइन और लागू की हैं जो निर्भर उपयोग मामलों के लिए कतार (queue) की कार्यक्षमता को जल्दी से बहाल कर सकती हैं। एक व्यक्तिगत क्लस्टर की कुल विफलता की स्थिति में भी, हम ग्राहकों (clients) को पर्याप्त क्षमता वाले एक स्वस्थ क्लस्टर में स्विच करने में सक्षम हैं। यह सुनिश्चित करने के लिए कि हमारे पास पर्याप्त अप्रयुक्त क्षमता उपलब्ध हो, हम एक स्टैंडबाय काफ़्का क्लस्टर बनाए रखते हैं। यह लाइव क्लस्टर के बीच ट्रैफ़िक को स्थानांतरित करते समय 'नॉइज़ी नेबर' (noisy neighbor) समस्याओं के किसी भी जोखिम को खत्म करने में मदद करता है।

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

Roblox की सुरक्षा के लिए सख्त आवश्यकताएँ हैं, जो विश्वसनीयता का भी एक महत्वपूर्ण हिस्सा है। हमने ट्रांज़िट में एन्क्रिप्शन (mTLS के साथ), रेस्ट पर एन्क्रिप्शन (एन्क्रिप्टेड डिस्क के साथ), डेटा प्रतिधारण आयु आवश्यकताएँ, और Kafka प्रिंसिपल्स और ACLs के साथ प्रमाणीकरण/अधिकृतिकरण जैसी मानक सुरक्षा सुविधाएँ लागू की हैं। हम सुरक्षा को और बेहतर बनाने के लिए अपने उपयोगकर्ताओं के क्रेडेंशियल को स्वचालित रूप से रोटेट भी करते हैं।

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

आगे की राह

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

काफ़्का का स्केलिंग केवल क्लस्टर की संख्या और आकार को स्केल करने के बारे में नहीं है। यह इंजीनियरिंग अनुशासन, सार (abstractions), और परिचालन मॉडल बनाने के बारे में है जो Roblox को आशावाद और सभ्यता के साथ हर दिन एक अरब लोगों को जोड़ने की हमारी यात्रा जारी रखने की अनुमति देता है।