रॉब्लॉक्स सेवा में वापसी

28 अक्टूबर से शुरू होकर और 31 अक्टूबर को पूरी तरह से सुलझने तक, Roblox ने 73 घंटे की आउटेज का सामना किया।¹ पचास मिलियन खिलाड़ी हर दिन नियमित रूप से Roblox का उपयोग करते हैं, और हमारे खिलाड़ियों की अपेक्षित अनुभव प्रदान करने के लिए, हमारे पैमाने में सैकड़ों आंतरिक ऑनलाइन सेवाएँ शामिल हैं। किसी भी बड़े पैमाने की सेवा की तरह, हमें समय-समय पर सेवा रुकावटों का सामना करना पड़ता है, लेकिन इस आउटेज की लंबी अवधि इसे विशेष रूप से उल्लेखनीय बनाती है। हम अपने समुदाय से इस डाउनटाइम के लिए हार्दिक रूप से क्षमा चाहते हैं।

हम अपनी समुदाय को समस्या के मूल कारण की समझ देने के लिए, हमने इसे कैसे संबोधित किया, और भविष्य में इसी तरह की समस्याओं को होने से रोकने के लिए हम क्या कर रहे हैं, इन तकनीकी विवरणों को साझा कर रहे हैं। हम यह दोहराना चाहेंगे कि इस घटना के दौरान किसी भी उपयोगकर्ता डेटा का नुकसान या किसी भी जानकारी तक अनधिकृत पक्षों द्वारा पहुँच नहीं हुई।

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

आउटेज सारांश

यह आउटेज अवधि और जटिलता दोनों ही मामलों में अनूठा था। मूल कारण को समझने और सेवा को वापस चालू करने के लिए टीम को कई चुनौतियों का क्रमबद्ध रूप से सामना करना पड़ा।

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

भूमिका: हमारा क्लस्टर वातावरण और हैशस्टैक

Roblox का कोर इंफ्रास्ट्रक्चर Roblox डेटा सेंटर में चलता है। हम अपना हार्डवेयर, और साथ ही उस हार्डवेयर पर अपने कंप्यूट, स्टोरेज और नेटवर्किंग सिस्टम को खुद डिप्लॉय और मैनेज करते हैं। हमारे डिप्लॉयमेंट का पैमाना काफी बड़ा है, जिसमें 18,000 से अधिक सर्वर और 170,000 कंटेनर शामिल हैं।

कई साइटों पर हजारों सर्वर चलाने के लिए, हम एक तकनीकी सुइट का लाभ उठाते हैं जिसे आम तौर पर "HashiStack" के नाम से जाना जाता है। Nomad, Consul और Vault वे तकनीकें हैं जिनका उपयोग हम दुनिया भर में सर्वरों और सेवाओं का प्रबंधन करने के लिए करते हैं, और जो हमें उन कंटेनरों को व्यवस्थित करने की अनुमति देती हैं जो Roblox सेवाओं का समर्थन करते हैं।

नोमैड का उपयोग कार्य शेड्यूलिंग के लिए किया जाता है। यह तय करता है कि कौन से कंटेनर किन नोड्स पर चलेंगे और वे किन पोर्ट्स पर सुलभ होंगे। यह कंटेनर की स्वास्थ्य-स्थिति को भी मान्य करता है। यह सारा डेटा एक सर्विस रजिस्ट्री को भेजा जाता है, जो आईपी:पोर्ट संयोजनों का एक डेटाबेस है। रॉब्लॉक्स सेवाएँ एक-दूसरे को खोजने के लिए सर्विस रजिस्ट्री का उपयोग करती हैं ताकि वे संवाद कर सकें। इस प्रक्रिया को "सर्विस डिस्कवरी" कहा जाता है। हम सर्विस डिस्कवरी, हेल्थ चेक्स, सेशन लॉकिंग (ऊपर बने HA सिस्टम के लिए), और एक KV स्टोर के रूप में कंसुल का उपयोग करते हैं।

कंसल को दो भूमिकाओं में मशीनों के एक क्लस्टर के रूप में तैनात किया जाता है। "वोटर्स" (5 मशीनें) क्लस्टर की स्थिति को आधिकारिक रूप से धारण करते हैं; "नॉन-वोटर्स" (5 अतिरिक्त मशीनें) रीड-ओनली प्रतिकृतियाँ हैं जो रीड अनुरोधों को स्केल करने में सहायता करती हैं। किसी भी समय, क्लस्टर द्वारा वोटर्स में से एक को लीडर के रूप में चुना जाता है। लीडर अन्य वोटर्स को डेटा की प्रतिकृति बनाने और यह निर्धारित करने के लिए जिम्मेदार होता है कि लिखा गया डेटा पूरी तरह से प्रतिबद्ध हो गया है या नहीं।  कंसुल लीडर चुनाव के लिए और क्लस्टर में राज्य को इस तरह वितरित करने के लिए राफ्ट नामक एल्गोरिदम का उपयोग करता है कि यह सुनिश्चित हो कि क्लस्टर का प्रत्येक नोड अपडेट पर सहमत हो। किसी दिए गए दिन में कई बार लीडर चुनाव के माध्यम से लीडर का बदलना असामान्य नहीं है।

घटना के बाद Roblox में एक Consul डैशबोर्ड का निम्नलिखित एक हालिया स्क्रीनशॉट है। इस ब्लॉग पोस्ट में संदर्भित कई प्रमुख परिचालन मेट्रिक्स सामान्य स्तर पर दिखाए गए हैं। उदाहरण के लिए, KV लागू होने का समय 300ms से कम को सामान्य माना जाता है और इस क्षण में यह 30.6ms है। Consul लीडर का क्लस्टर में अन्य सर्वरों के साथ पिछले 32ms में संपर्क हुआ है, जो बहुत हाल ही की बात है।

अक्टूबर की घटना से पहले के महीनों में, Roblox ने एक नई स्ट्रीमिंग सुविधा का लाभ उठाने के लिए Consul 1.9 से Consul 1.10 में अपग्रेड किया। यह स्ट्रीमिंग सुविधा बड़े पैमाने के क्लस्टरों, जैसे Roblox में मौजूद क्लस्टर, में अपडेट वितरित करने के लिए आवश्यक CPU और नेटवर्क बैंडविड्थ को काफी कम करने के लिए डिज़ाइन की गई है।

प्रारंभिक पता लगाना (10/28 13:37)

28 अक्टूबर की दोपहर को, वॉल्ट का प्रदर्शन खराब हो गया था और एक ही कंसुल सर्वर पर सीपीयू लोड अधिक था। Roblox के इंजीनियरों ने जांच शुरू कर दी। इस समय खिलाड़ियों पर कोई प्रभाव नहीं पड़ा था।

प्रारंभिक निदान (10/28 13:37 – 10/29 02:00)

प्रारंभिक जांच से पता चला कि वह कंसुल क्लस्टर, जिस पर वॉल्ट और कई अन्य सेवाएँ निर्भर करती हैं, अस्वस्थ था।  विशेष रूप से, कंसल क्लस्टर मेट्रिक्स ने उस अंतर्निहित KV स्टोर के लिए बढ़ी हुई राइट लेटेंसी दिखाई जिसमें कंसल डेटा संग्रहीत करता है। इन ऑपरेशनों पर 50वां पर्सेंटाइल लेटेंसी आमतौर पर 300ms से कम थी, लेकिन अब यह 2 सेकंड थी। Roblox के पैमाने पर हार्डवेयर संबंधी समस्याएं असामान्य नहीं हैं, और कंसल हार्डवेयर विफलता से बच सकता है। हालांकि, यदि हार्डवेयर विफल होने के बजाय केवल धीमा है, तो यह समग्र कंसल प्रदर्शन को प्रभावित कर सकता है। इस मामले में, टीम को खराब हार्डवेयर प्रदर्शन को मूल कारण के रूप में संदेह था और उन्होंने कंसुल क्लस्टर नोड में से एक को बदलने की प्रक्रिया शुरू कर दी। यह घटना का निदान करने का हमारा पहला प्रयास था। इसी समय के आसपास, हैशीकॉर्प के कर्मचारियों ने निदान और सुधार में मदद करने के लिए रॉब्लॉक्स इंजीनियरों के साथ काम करना शुरू कर दिया। इस बिंदु से आगे "टीम" और "इंजीनियरिंग टीम" के सभी संदर्भ रॉब्लॉक्स और हैशीकॉर्प दोनों कर्मचारियों को संदर्भित करते हैं।

नए हार्डवेयर के बावजूद, कंसुल क्लस्टर का प्रदर्शन प्रभावित होता रहा। 16:35 पर, ऑनलाइन खिलाड़ियों की संख्या सामान्य के 50% तक घट गई।

यह गिरावट सिस्टम की स्वास्थ्य स्थिति में एक महत्वपूर्ण गिरावट के साथ मेल खाती थी, जिसके परिणामस्वरूप अंततः पूरा सिस्टम ठप हो गया। क्यों? जब कोई Roblox सेवा किसी अन्य सेवा से संवाद करना चाहती है, तो वह उस सेवा के स्थान की नवीनतम जानकारी के लिए Consul पर निर्भर करती है। हालाँकि, यदि कंसल अस्वस्थ है, तो सर्वर कनेक्ट होने के लिए संघर्ष करते हैं। इसके अलावा, नोमैड और वॉल्ट कंसल पर निर्भर करते हैं, इसलिए जब कंसल अस्वस्थ होता है, तो सिस्टम नए कंटेनरों को शेड्यूल नहीं कर सकता या प्रमाणीकरण के लिए उपयोग किए जाने वाले प्रोडक्शन सीक्रेट्स को पुनः प्राप्त नहीं कर सकता। संक्षेप में, सिस्टम विफल हो गया क्योंकि कंसल एक एकल विफलता बिंदु था, और कंसल स्वस्थ नहीं था।

इस बिंदु पर, टीम ने इस बारे में एक नया सिद्धांत विकसित किया कि क्या गलत हो रहा था: बढ़ी हुई ट्रैफ़िक। शायद कंसल धीमा था क्योंकि हमारी प्रणाली एक निर्णायक बिंदु पर पहुँच गई थी, और जिन सर्वरों पर कंसल चल रहा था, वे अब लोड को संभाल नहीं पा रहे थे? यह घटना के मूल कारण का निदान करने का हमारा दूसरा प्रयास था।

घटना की गंभीरता को देखते हुए, टीम ने कंसुल क्लस्टर में सभी नोड्स को नई, अधिक शक्तिशाली मशीनों से बदलने का फैसला किया। इन नई मशीनों में 128 कोर (2 गुना वृद्धि) और नए, तेज़ NVME SSD डिस्क थे। 19:00 बजे तक, टीम ने क्लस्टर के अधिकांश हिस्से को नई मशीनों पर माइग्रेट कर दिया था, लेकिन क्लस्टर अभी भी स्वस्थ नहीं था। क्लस्टर यह रिपोर्ट कर रहा था कि अधिकांश नोड्स राइट्स (writes) के साथ तालमेल नहीं बिठा पा रहे थे, और KV राइट्स पर 50वां पर्सेंटाइल लेटेंसी (latency) सामान्य 300ms या उससे कम के बजाय अभी भी लगभग 2 सेकंड थी।

सेवा में लौटने का प्रयास #1 (10/29 02:00 – 04:00)

कंसल क्लस्टर को स्वस्थ स्थिति में वापस लाने के पहले दो प्रयास असफल रहे। हम अभी भी KV राइट लेटेंसी में वृद्धि देख सकते थे, साथ ही एक नया अजीब लक्षण भी था जिसे हम समझ नहीं सके: कंसल लीडर नियमित रूप से अन्य वोटर्स के साथ सिंक से बाहर था। 

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

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

रीसेट सुचारू रूप से हो गया, और शुरू में, मेट्रिक्स अच्छे दिख रहे थे। जब हमने iptables ब्लॉक हटाया, तो आंतरिक सेवाओं से सर्विस डिस्कवरी और हेल्थ चेक लोड उम्मीद के मुताबिक वापस आ गया। हालांकि, कंसुल का प्रदर्शन फिर से खराब होने लगा, और अंततः हम वहीं आ गए जहाँ से शुरू किया था: KV राइट ऑपरेशंस पर 50वां पर्सेंटाइल फिर से 2 सेकंड पर आ गया था। Consul पर निर्भर सेवाएँ खुद को "अस्वस्थ" (unhealthy) चिह्नित करने लगीं, और अंततः, सिस्टम फिर से उसी परिचित समस्याग्रस्त स्थिति में चला गया। अब सुबह के 04:00 बज रहे थे। यह स्पष्ट था कि Consul पर हमारे लोड में ही कुछ ऐसा था जो समस्या पैदा कर रहा था, और इस घटना को शुरू हुए 14 घंटे से अधिक समय हो चुका था, फिर भी हमें पता नहीं चल पाया था कि वह क्या था।

सेवा में लौटने का प्रयास #2 (10/29 04:00 – 10/30 02:00)

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

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

इस बिंदु पर, यह स्पष्ट था कि 28 तारीख को सबसे पहले हमारे द्वारा देखी गई प्रदर्शन गिरावट में कुल मिलाकर कंसुल का उपयोग एकमात्र योगदानकर्ता नहीं था। इस एहसास को देखते हुए, टीम ने फिर से रणनीति बदली। उस पर निर्भर रोब्लॉक्स सेवाओं के दृष्टिकोण से कंसुल को देखने के बजाय, टीम ने सुरागों के लिए कंसुल की आंतरिक कार्यप्रणाली को देखना शुरू कर दिया।

कॉन्टेंशियन में शोध (10/30 02:00 – 10/30 12:00)

अगले 10 घंटों में, इंजीनियरिंग टीम ने डीबग लॉग और ऑपरेटिंग सिस्टम-स्तर के मेट्रिक्स में और गहराई से जाँच की। इस डेटा से पता चला कि कंसुल केवी (KV) राइट्स लंबे समय तक ब्लॉक हो रहे थे। दूसरे शब्दों में, "प्रतिस्पर्धा"। प्रतिस्पर्धा का कारण तुरंत स्पष्ट नहीं था, लेकिन एक सिद्धांत यह था कि आउटेज की शुरुआत में 64 से 128 सीपीयू कोर सर्वरों पर जाने से समस्या और खराब हो गई होगी। नीचे दिए गए स्क्रीनशॉट में दिखाए गए htop डेटा और प्रदर्शन डिबगिंग डेटा को देखने के बाद, टीम ने यह निष्कर्ष निकाला कि आउटेज से पहले उपयोग किए गए सर्वरों के समान 64 कोर सर्वरों पर वापस जाना उचित होगा। टीम ने हार्डवेयर की तैयारी शुरू कर दी: कंसल इंस्टॉल किया गया, ऑपरेटिंग सिस्टम कॉन्फ़िगरेशन की तीन बार जाँच की गई, और मशीनों को यथासंभव विस्तार से सेवा के लिए तैयार किया गया। फिर टीम ने कंसुल क्लस्टर को वापस 64 CPU कोर सर्वरों पर स्थानांतरित किया, लेकिन इस बदलाव से कोई मदद नहीं मिली। यह घटना के मूल कारण का निदान करने का हमारा चौथा प्रयास था।

मूल कारण पाए गए (10/30 12:00 – 10/30 20:00)

कुछ महीने पहले, हमने अपनी सेवाओं के एक उपसमूह पर एक नया Consul स्ट्रीमिंग फीचर सक्षम किया था। यह फीचर, जिसे Consul क्लस्टर के CPU उपयोग और नेटवर्क बैंडविड्थ को कम करने के लिए डिज़ाइन किया गया था, उम्मीद के मुताबिक काम किया, इसलिए अगले कुछ महीनों में हमने इस फीचर को अपनी अधिक बैकएंड सेवाओं पर क्रमिक रूप से सक्षम किया। 27 अक्टूबर को 14:00 बजे, आउटेज से एक दिन पहले, हमने इस फीचर को एक बैकएंड सेवा पर सक्षम किया जो ट्रैफ़िक राउटिंग के लिए ज़िम्मेदार है। इस रोलआउट के हिस्से के रूप में, साल के अंत में आम तौर पर देखने को मिलने वाले बढ़े हुए ट्रैफ़िक की तैयारी के लिए, हमने ट्रैफ़िक रूटिंग का समर्थन करने वाले नोड्स की संख्या में 50% की वृद्धि भी की। घटना शुरू होने से एक दिन पहले, इस स्तर पर स्ट्रीमिंग के साथ सिस्टम ठीक से काम कर रहा था, इसलिए शुरू में यह स्पष्ट नहीं था कि इसका प्रदर्शन क्यों बदल गया था। हालाँकि, कंसुल सर्वरों से प्राप्त perf रिपोर्टों और फ्लेम ग्राफ़ के विश्लेषण के माध्यम से, हमने सबूत पाए कि स्ट्रीमिंग कोड पथ उच्च CPU उपयोग का कारण बनने वाले contention के लिए जिम्मेदार थे। हमने ट्रैफ़िक रूटिंग नोड्स सहित सभी कंसुल सिस्टमों के लिए स्ट्रीमिंग सुविधा को अक्षम कर दिया। कॉन्फ़िग परिवर्तन 15:51 पर फैल गया, जिस समय कंसुल KV राइट्स के लिए 50वां पर्सेंटाइल 300ms तक कम हो गया। अंततः हमें एक सफलता मिली।

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

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

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

हालाँकि, BoltDB के डिज़ाइन के कारण, सबसे पुरानी लॉग प्रविष्टियों को हटाने पर भी, डिस्क पर BoltDB द्वारा उपयोग की जाने वाली जगह कभी भी कम नहीं होती है। इसके बजाय, सभी पेज (फ़ाइल के भीतर 4kb के खंड) जिनका उपयोग हटाए गए डेटा को संग्रहीत करने के लिए किया गया था, उन्हें "फ़्री" के रूप में चिह्नित कर दिया जाता है और बाद के राइट्स के लिए फिर से उपयोग किया जाता है। BoltDB इन फ्री पेजों को अपनी "फ्रीलिस्ट" नामक संरचना में ट्रैक करता है। आम तौर पर, फ्रीलिस्ट को अपडेट करने में लगने वाले समय से लेखन विलंब (write latency) पर कोई खास असर नहीं पड़ता, लेकिन Roblox के वर्कलोड ने BoltDB में एक गंभीर प्रदर्शन समस्या (pathological performance issue) को उजागर किया, जिसने फ्रीलिस्ट के रखरखाव को बेहद महंगा बना दिया। 

कैशिंग सेवा को पुनर्स्थापित करना (10/30 20:00 – 10/31 05:00)

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

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

कैश पुनः परिनियोजन प्रक्रिया को कई समस्याओं का सामना करना पड़ा: 

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

टीम ने इन समस्याओं की पहचान करने और उन्हें हल करने, कैश सिस्टम के ठीक से तैनात होने को सुनिश्चित करने, और उसकी शुद्धता की जांच करने के लिए पूरी रात काम किया। 31 अक्टूबर को सुबह 05:00 बजे, आउटेज शुरू होने के 61 घंटे बाद, हमारे पास एक स्वस्थ कंसुल क्लस्टर और एक स्वस्थ कैशिंग सिस्टम था। हम बाकी रोब्लॉक्स को वापस लाने के लिए तैयार थे।

खिलाड़ियों की वापसी (10/31 05:00 – 10/31 16:00)

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

कोल्ड कैश और एक ऐसे सिस्टम के साथ जिसके बारे में हम अभी भी अनिश्चित थे, हम ट्रैफ़िक की बाढ़ नहीं चाहते थे जो संभावित रूप से सिस्टम को फिर से अस्थिर स्थिति में डाल सकती थी। बाढ़ से बचने के लिए, हमने DNS स्टीयरिंग का उपयोग उन खिलाड़ियों की संख्या को प्रबंधित करने के लिए किया जो Roblox तक पहुँच सकते थे। इसने हमें यादृच्छिक रूप से चुने गए खिलाड़ियों के एक निश्चित प्रतिशत को अंदर आने देने की अनुमति दी, जबकि अन्य को हमारे स्थिर रखरखाव पेज पर पुनर्निर्देशित किया जाता रहा। हर बार जब हम प्रतिशत बढ़ाते थे, तो हम डेटाबेस लोड, कैश प्रदर्शन और समग्र सिस्टम स्थिरता की जाँच करते थे। दिन भर काम जारी रहा, और लगभग 10% की वृद्धि के साथ एक्सेस बढ़ाया जाता रहा। हमें यह देखकर खुशी हुई कि हमारे कुछ सबसे समर्पित खिलाड़ियों ने हमारी DNS स्टीयरिंग योजना का पता लगा लिया और ट्विटर पर इस जानकारी का आदान-प्रदान करना शुरू कर दिया ताकि जब हमने सेवा को वापस चालू किया तो वे "अर्ली" एक्सेस प्राप्त कर सकें। रविवार को 16:45 बजे, आउटेज शुरू होने के 73 घंटे बाद, 100% खिलाड़ियों को एक्सेस दे दिया गया और Roblox पूरी तरह से चालू हो गया।

आउटेज से उत्पन्न आगे का विश्लेषण और परिवर्तन

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

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

उपरोक्त कमांड आउटपुट हमें कई बातें बताता है:

• यह 4.2GB का लॉग स्टोर केवल 489MB वास्तविक डेटा (सभी इंडेक्स आंतरिक भागों सहित) ही संग्रहीत कर रहा है। 3.8GB "खाली" स्थान है।
• फ्रीलिस्ट 7.8MB की है क्योंकि इसमें लगभग दस लाख फ्री पेज आईडी शामिल हैं।

इसका मतलब है, हर लॉग जोड़ (कुछ बैचिंग के बाद प्रत्येक राफ्ट राइट) के लिए, एक नया 7.8MB का फ्रीलिस्ट भी डिस्क पर लिखा जा रहा था, जबकि जो असल कच्चा डेटा जोड़ा जा रहा था वह 16kB या उससे कम का था। 

इन ऑपरेशनों पर बैक प्रेशर ने TCP बफ़र्स को भी भर दिया और अस्वस्थ लीडर्स पर 2-3 सेकंड के राइट टाइम में योगदान दिया। नीचे की छवि इस घटना के दौरान TCP जीरो विंडोज़ पर किए गए शोध को दिखाती है।

HashiCorp और Roblox ने मौजूदा BoltDB टूलिंग का उपयोग करके डेटाबेस को "कम्पैक्ट" करने के लिए एक प्रक्रिया विकसित और तैनात की, जिससे प्रदर्शन संबंधी समस्याओं का समाधान हुआ।

हाल के सुधार और भविष्य के कदम

आउटेज को 2.5 महीने हो गए हैं। हम क्या कर रहे हैं? हमने इस समय का उपयोग आउटेज से जितना हो सके उतना सीखने, जो हमने सीखा उसके आधार पर इंजीनियरिंग प्राथमिकताओं को समायोजित करने, और अपने सिस्टम को मजबूती से सुदृढ़ करने के लिए किया। हमारे Roblox के मूल्यों में से एक है समुदाय का सम्मान करना, और हालांकि हम यह समझाने के लिए कि क्या हुआ, पहले एक पोस्ट जारी कर सकते थे, हमें लगा कि प्रकाशित करने से पहले हमारे सिस्टम की विश्वसनीयता में सुधार करने पर महत्वपूर्ण प्रगति करना आपके, हमारे समुदाय के प्रति हमारा कर्तव्य है। 

पूरे किए गए और चल रहे विश्वसनीयता सुधारों की पूरी सूची इस लेख के लिए बहुत लंबी और बहुत विस्तृत है, लेकिन यहाँ प्रमुख मदें हैं:

टेलिमेट्री में सुधार

हमारे टेलीमेट्री सिस्टम और कंसल के बीच एक वृत्ताकार निर्भरता थी, जिसका अर्थ था कि जब कंसल अस्वस्थ था, तो हमारे पास उस टेलीमेट्री डेटा का अभाव था जो हमें यह पता लगाने में मदद करता कि क्या गलत था। हमने इस वृत्ताकार निर्भरता को हटा दिया है। अब हमारे टेलीमेट्री सिस्टम उन सिस्टमों पर निर्भर नहीं करते हैं जिनकी निगरानी के लिए उन्हें कॉन्फ़िगर किया गया है।

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

कई उपलब्धता क्षेत्रों और डेटा केंद्रों में विस्तार

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

कंसल अपग्रेड और शार्डिंग

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

कुछ मुख्य रॉब्लॉक्स सेवाएँ डेटा संग्रहीत करने के लिए एक सुविधाजनक स्थान के रूप में सीधे कंसुल के KV स्टोर का उपयोग कर रही हैं, भले ही हमारे पास अन्य स्टोरेज सिस्टम हैं जो संभवतः अधिक उपयुक्त हैं। हम इस डेटा को एक अधिक उपयुक्त स्टोरेज सिस्टम में माइग्रेट करने की प्रक्रिया में हैं। पूरा हो जाने पर, इससे कंसुल पर लोड भी कम हो जाएगा।

हमने बड़ी मात्रा में अप्रचलित KV डेटा पाया। इस अप्रचलित डेटा को हटाने से Consul के प्रदर्शन में सुधार हुआ।

हम HashiCorp के साथ मिलकर कंसल का एक नया संस्करण तैनात करने पर काम कर रहे हैं जो BoltDB को bbolt नामक एक उत्तराधिकारी से बदलता है, जिसमें अनलिमिटेड फ्रीलिस्ट वृद्धि की वही समस्या नहीं है। हमने अपने साल के अंत के चरम ट्रैफ़िक के दौरान एक जटिल अपग्रेड से बचने के लिए इस प्रयास को जानबूझकर नए साल में टाल दिया। इस अपग्रेड का अब परीक्षण किया जा रहा है और यह Q1 में पूरा हो जाएगा।

बूटस्ट्रैपिंग प्रक्रियाओं और कॉन्फ़िग प्रबंधन में सुधार

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

हमने HashiCorp के साथ मिलकर Nomad में कई सुधारों की पहचान की है, जो लंबे समय तक अनुपलब्ध रहने के बाद हमारे लिए बड़ी नौकरियों को फिर से चालू करना आसान बना देंगे। इन सुधारों को हमारे अगले Nomad अपग्रेड के हिस्से के रूप में तैनात किया जाएगा, जो इस महीने के अंत में निर्धारित है।

हमने मशीन कॉन्फ़िगरेशन परिवर्तनों को तेज़ बनाने के लिए तंत्र विकसित और तैनात किए हैं।

स्ट्रीमिंग का पुनर्परिचय

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

सार्वजनिक क्लाउड पर एक नोट

इस तरह की आउटेज के बाद, यह पूछना स्वाभाविक है कि क्या रॉब्लॉक्स सार्वजनिक क्लाउड में जाने और किसी तीसरे पक्ष को हमारी बुनियादी कंप्यूट, स्टोरेज और नेटवर्किंग सेवाओं का प्रबंधन करने देने पर विचार करेगा।

हमारे Roblox मूल्यों में से एक और है 'दीर्घकालिक दृष्टिकोण अपनाना' (Take The Long View), और यह मूल्य हमारे निर्णय लेने में बहुत बड़ी भूमिका निभाता है। हम अपना बुनियादी ढांचा ऑन-प्रिमाइंस (on-prem) पर ही बनाते और प्रबंधित करते हैं क्योंकि, हमारे वर्तमान पैमाने पर, और इससे भी महत्वपूर्ण बात यह है कि, उस पैमाने पर जो हम जानते हैं कि हम अपने प्लेटफ़ॉर्म के बढ़ने के साथ हासिल करेंगे, हमारा मानना है कि यह हमारे व्यवसाय और हमारे समुदाय का समर्थन करने का सबसे अच्छा तरीका है। विशेष रूप से, बैकएंड और नेटवर्क एज सेवाओं के लिए अपने स्वयं के डेटा सेंटर बनाकर और प्रबंधित करके, हम सार्वजनिक क्लाउड की तुलना में लागतों को काफी हद तक नियंत्रित करने में सक्षम हुए हैं। यह बचत सीधे तौर पर उस राशि को प्रभावित करती है जो हम प्लेटफ़ॉर्म पर निर्माताओं को भुगतान करने में सक्षम हैं। इसके अलावा, अपने स्वयं के हार्डवेयर का मालिक होने और अपना स्वयं का एज इंफ्रास्ट्रक्चर बनाने से हम प्रदर्शन में भिन्नता को कम कर सकते हैं और दुनिया भर में हमारे खिलाड़ियों के लिए लेटेंसी को सावधानीपूर्वक प्रबंधित कर सकते हैं। सुसंगत प्रदर्शन और कम विलंबता हमारे खिलाड़ियों के अनुभव के लिए महत्वपूर्ण हैं, जो जरूरी नहीं कि सार्वजनिक क्लाउड प्रदाताओं के डेटा सेंटर के पास स्थित हों।

ध्यान दें कि हम किसी विशेष दृष्टिकोण से वैचारिक रूप से बंधे नहीं हैं: हम उन उपयोग मामलों के लिए सार्वजनिक क्लाउड का उपयोग करते हैं जहाँ यह हमारे खिलाड़ियों और डेवलपर्स के लिए सबसे अधिक समझ में आता है। उदाहरण के लिए, हम बर्स्ट क्षमता, हमारे DevOps वर्कफ़्लो के बड़े हिस्सों, और हमारे अधिकांश इन-हाउस एनालिटिक्स के लिए सार्वजनिक क्लाउड का उपयोग करते हैं। आम तौर पर हम पाते हैं कि पब्लिक क्लाउड उन एप्लिकेशनों के लिए एक अच्छा उपकरण है जो प्रदर्शन और लेटेंसी के लिहाज़ से बहुत महत्वपूर्ण नहीं हैं, और जो सीमित पैमाने पर चलते हैं। हालाँकि, हमारे सबसे ज़्यादा प्रदर्शन और लेटेंसी-संवेदनशील वर्कलोड के लिए, हमने अपना खुद का इंफ्रास्ट्रक्चर ऑन-प्रिमाइज़ बनाने और प्रबंधित करने का विकल्प चुना है। हमने यह विकल्प यह जानते हुए चुना कि इसमें समय, पैसा और प्रतिभा लगती है, लेकिन यह भी जानते हुए कि यह हमें एक बेहतर प्लेटफ़ॉर्म बनाने की अनुमति देगा। यह हमारे 'टेक द लॉन्ग व्यू' (Take The Long View) मूल्य के अनुरूप है।

आउटेज के बाद से सिस्टम की स्थिरता

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

अंतिम विचार

हम अपनी वैश्विक Roblox समुदाय को उनकी समझ और समर्थन के लिए धन्यवाद देना चाहते हैं। हमारे Roblox मूल्यों में से एक है, 'जिम्मेदारी लें', और हम यहां जो हुआ उसकी पूरी जिम्मेदारी लेते हैं। हम एक बार फिर से HashiCorp की टीम को अपना हार्दिक धन्यवाद देना चाहेंगे। उनके इंजीनियर इस अभूतपूर्व आउटेज की शुरुआत में हमारी सहायता के लिए तुरंत आगे आए और हमारे साथ बने रहे। अब, जब आउटेज को दो महीने हो चुके हैं, तब भी Roblox और HashiCorp के इंजीनियर यह सुनिश्चित करने के लिए मिलकर काम कर रहे हैं कि भविष्य में इस तरह की कोई भी समस्या दोबारा न हो।

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

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

एक बार फिर धन्यवाद।