आम्ही Roblox चे पायाभूत सुविधा अधिक कार्यक्षम आणि लवचिक कसे बनवत आहोत

गेल्या 16+ वर्षांत रॉब्लॉक्स जसे वाढले आहे, तसे लाखो इमर्सिव्ह 3D सह-अनुभवांना आधार देणाऱ्या तांत्रिक पायाभूत सुविधांचा आकार आणि गुंतागुंतही वाढली आहे. गेल्या दोन वर्षांत आम्ही समर्थन करत असलेल्या मशीनची संख्या तिप्पटपेक्षा जास्त झाली आहे, 30 जून, 2021 रोजी सुमारे 36,000 वरून आज जवळपास 145,000 झाली आहे. जगभरातील लोकांसाठी या नेहमी चालणाऱ्या अनुभवांना समर्थन देण्यासाठी 1,000 पेक्षा जास्त अंतर्गत सेवा आवश्यक आहेत. खर्च आणि नेटवर्क विलंब नियंत्रित करण्यात मदत करण्यासाठी, आम्ही ही मशीन मुख्यत्वे ऑन-प्रिमायसवर चालणाऱ्या, खास तयार केलेल्या आणि हायब्रिड खासगी क्लाउड पायाभूत सुविधांचा भाग म्हणून तैनात आणि व्यवस्थापित करतो.  

आमची पायाभूत सुविधा सध्या जगभरात ७० दशलक्षाहून अधिक दैनंदिन सक्रिय वापरकर्त्यांना समर्थन देते, ज्यात त्यांच्या व्यवसायांसाठी Roblox च्या अर्थव्यवस्थेवर अवलंबून असलेल्या निर्मात्यांचा समावेश आहे. या लाखो लोकांना अत्यंत उच्च पातळीची विश्वासार्हता अपेक्षित असते. आमच्या अनुभवांच्या गहन स्वरूपामुळे, लॅग किंवा विलंबासाठी अगदीच कमी सहनशीलता आहे, अपयशाची (outages) तर सोडाच. रॉब्लॉक्स हे संवाद आणि जोडणीसाठीचे एक व्यासपीठ आहे, जिथे लोक इमर्सिव्ह 3D अनुभवांमध्ये एकत्र येतात. जेव्हा लोक इमर्सिव्ह स्पेसमध्ये त्यांच्या अवतारद्वारे संवाद साधत असतात, तेव्हा मजकूर थ्रेड किंवा कॉन्फरन्स कॉलच्या तुलनेत अगदी किरकोळ विलंब किंवा ग्लिचही अधिक लक्षात येतात.

ऑक्टोबर 2021 मध्ये, आम्हाला संपूर्ण प्रणालीत आउटेजचा अनुभव आला. त्याची सुरुवात एका डेटा सेंटरमधील एका घटकातील एका समस्येने लहान प्रमाणात झाली. परंतु आम्ही तपास करत असताना ती वेगाने पसरली आणि अखेरीस 73 तासांचा आउटेज झाला. त्या वेळी, आम्ही काय घडले याचे तपशील आणि या समस्येतून मिळालेल्या आमच्या काही प्रारंभिक शिकवणी शेअर केल्या. तेव्हापासून, आम्ही त्या शिकवणींचा अभ्यास करत आहोत आणि आमच्या पायाभूत सुविधांची लवचिकता वाढवण्यासाठी काम करत आहोत, जेणेकरून ती सर्व मोठ्या प्रमाणावरील प्रणालींमध्ये होणाऱ्या अपयशांच्या प्रकारांना तोंड देऊ शकेल, जे अत्यधिक ट्रॅफिक स्पाइक, हवामान, हार्डवेअर अपयश, सॉफ्टवेअर बग्स, किंवा फक्त मानवी चुका यांसारख्या घटकांमुळे होतात. जेव्हा हे अपयश घडते, तेव्हा एखाद्या एका घटकात किंवा घटकांच्या गटात असलेली समस्या संपूर्ण प्रणालीपर्यंत पसरणार नाही याची आम्ही कशी खात्री करू? गेल्या दोन वर्षांपासून हा प्रश्न आमच्या लक्ष केंद्रीत आहे आणि हे काम सुरू असतानाच, आतापर्यंत आम्ही जे केले आहे त्याचा परिणाम दिसू लागला आहे. उदाहरणार्थ, २०२२ च्या पहिल्या सहामाहीच्या तुलनेत २०२३ च्या पहिल्या सहामाहीत, आम्ही दर महिन्याला १२५ दशलक्ष एंगेजमेंट तास वाचवले. आज, आम्ही आतापर्यंत केलेले काम तसेच अधिक लवचिक पायाभूत सुविधा प्रणाली तयार करण्यासाठी आमचे दीर्घकालीन दृष्टीकोन शेअर करत आहोत.

बॅकस्टॉप तयार करणे

मोठ्या प्रमाणावरील पायाभूत सुविधा प्रणालींमध्ये, लहान स्तरावरील अपयश दिवसातून अनेकदा घडतात. जर एखाद्या मशीनमध्ये समस्या आली आणि ती सेवेतून बाहेर काढावी लागली, तरी ते व्यवस्थापित करता येते कारण बहुतेक कंपन्या त्यांच्या बॅक-एंड सेवांचे अनेक उदाहरणे (instances) राखतात. त्यामुळे जेव्हा एक उदाहरण अयशस्वी होते, तेव्हा इतर त्या कामाचा भार उचलतात. या वारंवार होणाऱ्या अपयशांना तोंड देण्यासाठी, विनंत्या सामान्यतः एखादी त्रुटी आल्यास स्वयंचलितपणे पुन्हा प्रयत्न करण्यासाठी सेट केल्या जातात.

जेव्हा एखादी प्रणाली किंवा व्यक्ती खूपच आक्रमकपणे पुन्हा प्रयत्न करते, तेव्हा हे आव्हानात्मक ठरते, कारण अशा प्रकारे त्या लहान प्रमाणावरील अपयशांना संपूर्ण पायाभूत सुविधांमध्ये इतर सेवा आणि प्रणालींपर्यंत पसरण्याची संधी मिळू शकते. जर नेटवर्क किंवा एखादा वापरकर्ता सातत्याने पुरेसे प्रयत्न करत राहिला, तर तो अखेरीस त्या सेवेच्या प्रत्येक उदाहरणावर आणि संभाव्यतः इतर प्रणालींवरही जागतिक पातळीवर ओव्हरलोड करेल. आमच्या 2021 मधील आउटेजचे कारण मोठ्या प्रमाणावरच्या प्रणालींमध्ये सामान्यपणे घडणारी एक घटना होती: एक अपयश लहान स्वरूपात सुरू होते आणि नंतर संपूर्ण प्रणालीमध्ये पसरते, इतक्या वेगाने वाढते की सर्व काही बंद होण्याआधी ते सोडवणे कठीण होते. 

आमच्या आऊटेजच्या वेळी, आमच्याकडे एक सक्रिय डेटा सेंटर होते (त्यातील घटक बॅकअप म्हणून कार्यरत होते). एखाद्या समस्येमुळे विद्यमान डेटा सेंटर बंद पडल्यास, नवीन डेटा सेंटरवर मॅन्युअली फेलओव्हर करण्याची क्षमता आम्हाला आवश्यक होती. आमची पहिली प्राधान्यता Roblox ची बॅकअप तैनाती सुनिश्चित करणे होती, म्हणूनच आम्ही ती वेगळ्या भौगोलिक प्रदेशातील नवीन डेटा सेंटरमध्ये तयार केली. यामुळे वाईट प्रसंगात संरक्षण वाढले: जेव्हा एखाद्या डेटा सेंटरमधील पुरेश्या घटकांमध्ये आडमेळी पसरते आणि ते पूर्णपणे निष्क्रिय होते. आता आमच्याकडे एक डेटा सेंटर कामांचा भार हाताळत आहे (सक्रिय) आणि एक बॅकअप म्हणून स्टँडबायवर आहे (निष्क्रिय). आमचे दीर्घकालीन उद्दिष्ट म्हणजे या सक्रिय-निष्क्रिय कॉन्फिगरेशनमधून सक्रिय-सक्रिय कॉन्फिगरेशनकडे जाणे, ज्यामध्ये दोन्ही डेटा सेंटर वर्कलोड हाताळतील, आणि लेटन्सी, क्षमता आणि आरोग्य यावर आधारित विनंत्या त्यांच्यामध्ये वितरीत करण्यासाठी एक लोड बॅलन्सर असेल. एकदा हे राबवले की, आम्हाला रोब्लॉक्ससाठी आणखी उच्च विश्वासार्हता मिळेल आणि अनेक तासांऐवजी जवळजवळ तात्काळ फेलओव्हर करता येईल, अशी अपेक्षा आहे.

सेल्युलर पायाभूत सुविधांकडे वाटचाल

आमची पुढची प्राधान्यक्रमाची गोष्ट प्रत्येक डेटा सेंटरच्या आत मजबूत स्फोट-प्रतिरोधक भिंती तयार करणे होती, ज्यामुळे संपूर्ण डेटा सेंटर अयशस्वी होण्याची शक्यता कमी होईल. सेल्स (काही कंपन्या त्यांना क्लस्टर्स म्हणतात) ही मूलतः मशीनचा एक संच आहे आणि अशा भिंती तयार करण्याचा हा मार्ग आहे. अतिरिक्त पुनरावृत्तीसाठी आम्ही सेल्सच्या आत आणि सेल्सच्या दरम्यान सेवांची प्रतिकृती तयार करतो. शेवटी, आम्हाला Roblox वरील सर्व सेवा सेल्समध्ये चालवायच्या आहेत, ज्यामुळे त्या मजबूत स्फोट-प्रतिरोधक भिंती आणि पुनरावृत्ती या दोन्हींचा लाभ घेऊ शकतील. जर एखादी सेल कार्यरत नसेल, तर ती सुरक्षितपणे निष्क्रिय केली जाऊ शकते. सेलमधील पुनरावृत्तीमुळे सेल दुरुस्त होत असतानाही सेवा चालू ठेवता येते. काही प्रकरणांमध्ये, सेल दुरुस्ती म्हणजे सेलचे पूर्णपणे पुनर्प्रोव्हिजनिंग करणे होऊ शकते. संपूर्ण उद्योगात, एखाद्या वैयक्तिक मशीनची किंवा काही मशीनांच्या लहान गटाची विस्फोट करणे आणि पुनर्प्रोव्हिजनिंग करणे हे सामान्य आहे, परंतु सुमारे 1,400 मशीन असलेल्या संपूर्ण सेलसाठी हे करणे सामान्य नाही. 

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

सध्या सर्व सेवा या अटी पूर्ण करत नाहीत, त्यामुळे आम्ही सेवा मालकांना शक्य तितक्या ठिकाणी त्या पूर्ण करण्यात मदत करण्यासाठी काम केले आहे, आणि तयार झाल्यावर सेवांना सेल्समध्ये स्थलांतरित करणे सोपे करण्यासाठी आम्ही नवीन साधने तयार केली आहेत. उदाहरणार्थ, आमचे नवीन डिप्लॉयमेंट टूल सेल्समध्ये सेवा तैनाती आपोआप "स्ट्रायप्स" करते, ज्यामुळे सेवा मालकांना पुनरावृत्ती धोरणाबद्दल विचार करावा लागत नाही. या कडकपणामुळे स्थलांतर प्रक्रिया अधिक आव्हानात्मक आणि वेळखाऊ होते, परंतु दीर्घकालीन फायद्याने अशी प्रणाली तयार होईल जिथे: 

• अपयश मर्यादित ठेवणे आणि ते इतर सेल्समध्ये पसरण्यापासून प्रतिबंधित करणे खूप सोपे होते; 
• आमचे इन्फ्रास्ट्रक्चर अभियंते अधिक कार्यक्षम होऊ शकतात आणि जलद गतीने पुढे जाऊ शकतात; आणि 
• उत्पादन-स्तरीय सेवा तयार करणार्‍या अभियंत्यांना त्यांच्या सेवा कोणत्या सेल्समध्ये चालू आहेत हे जाणून घेण्याची किंवा त्याबद्दल काळजी करण्याची गरज नाही.

मोठ्या आव्हानांचे निराकरण

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

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

लघुकालीन दृष्टीने, आम्ही प्रत्येक कम्प्यूट सेलमध्ये संगणकीय सेवांच्या प्रती तैनात केल्या आहेत, जेणेकरून डेटा सेंटरमधील बहुतेक विनंत्या एकाच सेलद्वारे पूर्ण होऊ शकतात. आम्ही सेलमधील ट्रॅफिकचे लोड-बॅलन्सिंग देखील करत आहोत. पुढील काळात पाहता, आम्ही पुढील-पिढीची सेवा शोध प्रक्रिया (service discovery process) तयार करण्यास सुरुवात केली आहे, ज्याचा वापर सर्व्हिस मेश (service mesh) द्वारे केला जाईल, जी आम्ही 2024 मध्ये पूर्ण करण्याची आशा करतो. यामुळे आम्हाला अशा प्रगत धोरणांची अंमलबजावणी करता येईल जी फक्त तेव्हाच सेल-दरम्यान संवाद परवानगी देतील जेव्हा ते फेलओव्हर सेलवर नकारात्मक परिणाम करणार नाहीत. तसेच, 2024 मध्ये अवलंबून विनंत्या एकाच सेलमधील सेवा आवृत्तीकडे निर्देशित करण्याची पद्धत येणार आहे, ज्यामुळे सेल-दरम्यानचा ट्रॅफिक कमी होईल आणि त्यामुळे सेल-दरम्यान अपयशांचा प्रसार होण्याचा धोका कमी होईल.

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

नेहमी चालू असलेल्या पायाभूत सुविधांचे स्थलांतर

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

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

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

आज सुमारे 30,000 मशीन सेल्सद्वारे व्यवस्थापित केल्या जात आहेत. हे आमच्या एकूण फ्लीटचा फक्त एक भाग आहे, परंतु आतापर्यंत कोणताही नकारात्मक परिणाम न होता हा संक्रमण खूप सुरळीत पार पडला आहे. आमचे अंतिम उद्दिष्ट म्हणजे आमच्या प्रणालींनी प्रत्येक महिन्याला 99.99 टक्के वापरकर्ता अपटाइम साध्य करणे, म्हणजेच आम्ही गुंतवणुकीच्या तासांपैकी 0.01 टक्क्यांपेक्षा जास्त व्यत्यय आणणार नाही. उद्योग क्षेत्रात, डाउनटाइम पूर्णपणे दूर करता येणार नाही, परंतु आमचे उद्दिष्ट कोणताही Roblox डाउनटाइम इतक्या प्रमाणात कमी करणे आहे की तो जवळजवळ लक्षातच येणार नाही.

जसे जसे आम्ही विस्तारित होत आहोत, भविष्यासाठी तयारी

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

सारांशतः, आजपर्यंत आम्ही: 

• दुसरे डेटा सेंटर बांधले आणि सक्रिय/निष्क्रिय स्थिती यशस्वीरित्या प्राप्त केली. 
• आमच्या सक्रिय आणि निष्क्रिय डेटा सेंटरमध्ये सेल्स तयार केल्या आहेत आणि आमच्या बॅक-एंड सेवा ट्रॅफिकचा 70 टक्क्यांहून अधिक भाग या सेल्सकडे यशस्वीरित्या स्थलांतरित केला आहे.
• आमच्या पायाभूत सुविधांचा उर्वरित भाग स्थलांतरित करत असताना सर्व सेल्स एकसमान ठेवण्यासाठी आवश्यक आवश्यकता आणि सर्वोत्तम पद्धती आम्ही राबवल्या आहेत. 
• सेल्समध्ये अधिक मजबूत "ब्लास्ट वॉल्स" बांधण्याची सतत चालणारी प्रक्रिया सुरू केली आहे. 

हे सेल्स अधिक परस्परविनिमयक्षम झाल्यामुळे सेल्समध्ये क्रॉसटॉक कमी होईल. यामुळे मॉनिटरिंग, ट्रबलशूटिंग आणि अगदी वर्कलोड्स आपोआप हलवण्याच्या ऑटोमेशनमध्ये वाढ करण्याच्या दृष्टीने आमच्यासाठी काही अत्यंत रोचक संधी उपलब्ध होतील. 

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