100 कोटींहून अधिक ChatGPT वापरकर्त्यांसाठी ऑनलाइन स्टोरेजचा वेगवान विस्तार (भाग 2)

OpenAI च्या सर्व उत्पादनांना डेटा जलद आणि विश्वासार्हपणे उपलब्ध व्हावा लागतो. आमचा संचयन मंच Habitat ही गरज पूर्ण करतो. त्याला 40 भौगोलिक प्रदेशांतील 100 कोटींहून अधिक वापरकर्त्यांना मिलिसेकंदांत प्रतिसाद द्यावा लागतो. आमच्या पायाभूत सुविधांसमोर मोठे आव्हान होते: प्रचंड वेगाने होणारी वाढ आणि नवे वापर समर्थित करतानाच विश्वासार्हता, कार्यप्रदर्शन आणि उत्पादन डेव्हलपरच्या कामाचा वेग सुधारणे. त्यासाठी आमच्या ऑनलाइन स्टोरेज प्लॅटफॉर्मच्या रचनेचा आणि संचालनाचा नव्याने विचार करावा लागला. आम्ही सतत पर्यायांचे फायदे-तोटे तपासत हा क्रम पाळला: आधी अत्यावश्यक उत्पादन विनंत्यांसाठी पुरेशी विश्वासार्हता, मग जागतिक वापरकर्त्यांसाठी पुरेसा वेग आणि शेवटी प्रचंड प्रमाणावर कुशल संचालन.

साध्या क्लायंट लायब्ररी व डेटाबेसपासून 500 पेटाबाइटपेक्षा जास्त डेटा पुरवणाऱ्या जागतिक वितरित संचयन मंचापर्यंत Habitat चा विकास आम्ही कसा केला, हे या दोन भागांच्या मालिकेत स्पष्ट केले आहे. भाग 1 मध्ये Python क्लायंटपासून सेवेपर्यंत Habitat चा झालेला विकास मांडला होता. अनेकांना व्यवहार्य वाटेल त्या मर्यादेपलीकडे Python-आधारित सेवेची क्षमता नेण्यासाठी वापरलेल्या तंत्रांचाही त्यात आढावा घेतला होता.

या पोस्टच्या भाग दोनमध्ये, आम्ही Azure Cosmos DB या मूळ स्टोरेज घटकाचे स्केलिंग कसे केले, हे पाहणार आहोत. Azure टीमसोबतच्या घनिष्ठ कार्य भागीदारीतून, आम्ही सह-व्यवस्थापित कंटेनर्सचा एक व्यवहार्य मल्टी-टेनन्सी दृष्टिकोन विकसित केला, जो प्रचंड, जागतिक स्तरावर उत्कृष्ट वाचन कार्यक्षमता देतो.

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

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

Habitat मध्ये, मोठ्या प्रमाणावर एक विश्वसनीय, कार्यक्षम स्टोरेज प्रणाली डिझाइन करण्यासाठी आम्हाला या सर्व तडजोडींचा विचार करावा लागला. आज, Habitat हे अनेक OpenAI उत्पादनांसाठी एक मल्टी-टेनंट डेटाबेस लेयर आहे, परंतु आम्ही एका मल्टी-टेनंट Azure Cosmos DB कंटेनरचा वापर करण्यापासून ते सिंगल-टेनंट बॅकिंग कंटेनर्सची तरतूद करण्यापर्यंत आणि शेवटी डीफॉल्टनुसार मल्टी-टेनंट कंटेनरकडे परत येण्यापर्यंत एका चक्राकार प्रवासातून गेलो आहोत. Habitat वरील आमच्या मल्टी-टेनन्सीच्या प्रवासात आम्ही अजूनही अगदी सुरुवातीच्या टप्प्यावर आहोत: आम्ही मोठ्या संख्येने वापराच्या केसेसना समर्थन देतो, परंतु जिथे शक्य असेल तिथे Azure Cosmos DB च्या अंगभूत प्रिमिटिव्ह्जचा लाभ घेऊन आम्ही या क्षेत्रातील गुंतवणूक पुढे ढकलू शकलो आहोत.

Azure Cosmos DB सोबतचा आमचा प्रवास पाहण्याआधी काही मूलभूत माहिती:

• Azure Cosmos DB खाते हे कंटेनरचा संच आणि प्रतिकृतीकरणाचे धोरण ठरवते

• प्रत्येक कंटेनरसाठी प्रतिसेकंद विनंती एककांत (RU/s) ठरावीक थ्रुपुटची तरतूद केली जाते

• प्रत्येक कंटेनरमधील डेटा, प्रत्येक लॉजिकल पार्टिशन की साठी स्टोरेज आणि थ्रुपुटच्या नमूद केलेल्या मर्यादांसह, एका विशिष्ट लॉजिकल पार्टिशन की नुसार शार्ड-पद्धतीने साठवला जातो

• Azure Cosmos DB, स्टोरेज एका मर्यादेपेक्षा जास्त झाल्यावर किंवा कंटेनरला पुरवलेला थ्रुपुट टिकवून ठेवण्यासाठी अधिक फिजिकल पार्टिशन्सची आवश्यकता असताना, लॉजिकल पार्टिशन कीजचे कमी बॅकिंग फिजिकल पार्टिशन्समध्ये शार्डिंग करून त्यांना अनेक फिजिकल पार्टिशन्समध्ये विभागते

सुरुवातीला, आम्ही बॅक प्रेशर देण्यासाठी प्रत्येक लॉजिकल पार्टिशन की साठी नमूद केलेल्या 10K RU/s मर्यादेवर अवलंबून, कोणत्याही क्लायंट लोडला परवानगी दिली होती. जेव्हा आम्ही पहिल्यांदा सुरुवात केली, तेव्हा आम्ही प्रत्येक खात्यामध्ये फक्त एकच डीफॉल्ट Azure Cosmos DB कंटेनर वापरत होतो. हे पुरेसे चांगले काम करत होते, परंतु काही कारणांमुळे ते समस्याप्रधान ठरले:

सुरुवातीच्या API निवडींमुळे, आम्ही लॉजिकल पार्टिशन की निवड थेट क्लायंटसाठी खुली केली. परिणामी, वेगवेगळ्या उत्पादन वापराच्या प्रकरणांमध्ये,user_id किंवा workspace_id सारख्या सामान्यतः वापरल्या जाणाऱ्या पार्टिशन की मध्ये वारंवार संघर्ष होतात. ही वापराची प्रकरणे त्याच लॉजिकल पार्टिशन की वर Azure Cosmos DB च्या मर्यादा शेअर करत असल्यामुळे, या डिझाइनने एका विशिष्ट वापरकर्त्यासाठी एकूण थ्रुपुट मर्यादित केले.

Habitat आणि Azure Cosmos DB वर स्थलांतरित होण्यापूर्वी, Postgres चे स्केलिंग करताना आम्हाला एक सामान्य समस्या भेडसावत होती. ती म्हणजे, खूप जास्त वापर असलेल्या संस्थेकडून किंवा हॉट की असलेल्या एका टेनंटकडून येणाऱ्या अनेक रिक्वेस्ट्समुळे निर्माण होणारा प्रमाणाबाहेरचा उच्च भार संपूर्ण डेटाबेसवर येऊ शकत होता. त्या कीज कॅशे करण्यासाठी आणि कॅशे मिसमध्ये लीज तयार करण्यासाठी महत्त्वपूर्ण सामूहिक प्रयत्न केले गेले, जेणेकरून परिणामी कॅशे मिस लोड मूळ डेटाबेसवर मोठा भार टाकणार नाही.

जरी दस्तऐवजीकृत डेटा आकार आणि थ्रुपुट मर्यादा लॉजिकल पार्टिशन कीजवर लागू होत असल्या तरी, प्रत्यक्षात या मर्यादा फिजिकल पार्टिशनवर लागू केल्या जातात. व्यवहारात, याचा अर्थ असा होतो की लॉजिकल पार्टिशन्स 10,000 RU/s पर्यंत पोहोचू शकत नाहीत. त्याऐवजी, ते त्या फिजिकल पार्टिशनवर असलेल्या इतर प्रत्येक लॉजिकल पार्टिशन की सोबत त्या फिजिकल पार्टिशनच्या मर्यादा शेअर करतात.

यामुळे नॉईजी नेबर्सला अनेक असंबंधित लॉजिकल पार्टिशन कीजवर परिणाम करण्याची संधी मिळाली, तसेच विशिष्ट उत्पादन वैशिष्ट्यांसाठीच्या डेटावर चालणाऱ्या वर्कलोड्सनी मुख्य लॉगिन आणि साइनअप प्रक्रियांमध्ये व्यत्यय आणला.

दिलेल्या फिजिकल पार्टिशनची थ्रुपुट मर्यादा देखील Azure Cosmos DB कंटेनरला नेमून दिलेल्या एकूण थ्रुपुटवर अवलंबून, बदलणारी असते. कंटेनरचे प्रोव्हिजन केलेले थ्रुपुट त्या कंटेनरच्या फिजिकल पार्टिशन्समध्ये साधारणपणे समान रीतीने वितरित केले जाते.

डेटाचे प्रमाण वाढत असताना, भौतिक पार्टिशन्स विभाजित होतात, ज्यामुळे एकूण पार्टिशनची संख्या वाढते, परंतु एकूण उपलब्ध थ्रुपुट मात्र अपरिवर्तित राहते. याचा परिणाम असा होतो की, डेटाचा आकार वाढल्याने प्रत्येक पार्टिशनची प्रभावी थ्रुपुट मर्यादा कमी होते.

आमच्या सर्वाधिक स्टोरेज वापरणाऱ्या, ब्लॉब-सारख्या वापराच्या बाबतीत, यामुळे एक अशी त्रुटी निर्माण होते जिथे विनंती दर आणि वापर स्थिर राहिले तरीही, केवळ स्टोरेजच्या वाढीमुळे सक्रिय वर्कलोडची थ्रुपुट क्षमता कमी होते.

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

आम्ही मजबूत आयसोलेशनची आवश्यकता असलेल्या सर्वात महत्त्वाच्या नवीन वापरांसाठी स्वतंत्र Azure Cosmos DB कंटेनर्स वापरण्यास सुरुवात केली. प्रत्येक कंटेनरसाठी प्रोव्हिजन केलेल्या एकूण थ्रुपुटला त्याच्या फिजिकल पार्टिशन्सच्या संख्येसोबत सिंक्रोनाइझ करून वीक पार्टिशन्स व्यवस्थापित करणाऱ्या स्क्रिप्टच्या संयोगाने, आम्ही भेडसावणाऱ्या बहुतेक सर्व समस्या टाळल्या.

मात्र, सुरुवात एका पूर्वनिर्धारित कंटेनरपासून केल्याने अनेक जुने महत्त्वाचे वापर दुर्दैवाने तिथेच अडकले होते; डेटा स्थलांतराशिवाय त्यांना हलवता येत नव्हते. शेअर केलेल्या पूर्वनिर्धारित कंटेनरमधील डेटावर अजूनही अवलंबून असलेल्या महत्त्वाच्या सेवांचे संरक्षण करण्यासाठी, नव्या सेवा किंवा मोठ्या उत्पादन सुविधांसाठी स्वतंत्र कंटेनर तयार करण्याचा सल्ला आम्ही संघांना अनेकदा देत होतो. आमचा विस्तार झाला तसा पूर्वनिर्धारित कंटेनरवरील ताण आणि प्रत्यक्ष सेवा चालवताना उद्भवणाऱ्या घटनाही वाढल्या. पूर्वनिर्धारित कंटेनरवर आणखी भार पडू नये म्हणून आम्ही प्रत्येक नव्या सेवेसाठी किंवा मोठ्या उत्पादन सुविधेसाठी कंटेनर तयार करू लागलो.

यामुळे आम्ही अनेक साइट-व्यापी व्यत्ययांपासून वाचलो, आणि त्याचा परिणाम केवळ सुविधा किंवा सेवेच्या गुणवत्तेतील घसरणीपुरता मर्यादित राहिला. तथापि, नवीन कंटेनरची तरतूद करण्याचा अतिरिक्त खर्च अखेरीस आमच्यावर भारी पडला:

जुन्या शेअर केलेल्या डिफॉल्ट कंटेनरमध्ये, 0 QPS वरून 1 दशलक्ष QPS पर्यंत जाणाऱ्या कोणत्याही विशिष्ट नवीन वापराच्या केसमुळे एकूण एकत्रित वापरात लक्षणीय बदल होण्याची शक्यता कमी होती. तथापि, एका आयसोलेटेड कंटेनरवर, 0 वरून 1 दशलक्ष QPS पर्यंत जाणाऱ्या नवीन वापराच्या केसमुळे, केवळ अंतर्गत डॉगफूडिंगमुळे निर्माण होणाऱ्या बेसलाइनपेक्षा 1,000 पट जास्त लोड येऊ शकतो.

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

हा मल्टी-टेनंट सिस्टीमचा एक मुख्य वर्कलोड मिक्सिंगचा फायदा आहे, जो या कंटेनर स्ट्रॅटेजीमुळे मिळणाऱ्या उत्तम आयसोलेशनमुळे आपण गमावतो.

कालांतराने समर्पित कंटेनरच्या वापरावर लक्ष ठेवण्यासाठी विनंत्यांचा प्रवाह कधी बदलेल किंवा वाढेल, याचे उत्पादनाविषयीचे सखोल ज्ञानही आवश्यक झाले.

आम्ही वाढीच्या ट्रेंडनुसार प्रत्येक कंटेनरसाठी प्रोव्हिजन केलेला थ्रुपुट वाढवण्यासाठी एक मूलभूत कंट्रोल प्लेन स्क्रिप्ट देऊ शकतो, परंतु स्थिर एकूण वाढीशिवाय, हे योग्यरित्या स्केल केल्यामुळे OpenAI मधील प्रत्येक उत्पादन टीमला क्षमता नियोजनात सहभागी होणे शक्य झाले.

प्रत्येक सेवेच्या मालकीच्या टीमने त्यांच्या Azure Cosmos DB प्रोव्हिजनिंगकडे किती लक्ष दिले यात मोठी तफावत असल्याने, हे संस्थात्मक स्तरावर वाढवता आले नाही.

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

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

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

Azure Cosmos DB मध्ये आधीपासूनच एक सर्व्हरलेस मोड होता, ज्यामुळे प्रोव्हिजन मोडमधील आमच्या कमकुवत पार्टिशन्सची समस्या सुटली असती. तथापि, त्यात एक मोठी कमतरता होती: तो केवळ स्टोरेज वापराच्या आधारावर स्केल होत असे आणि प्रत्येक फिजिकल पार्टिशनसाठी RU चा वापर 5,000 RU/s पर्यंत मर्यादित ठेवत असे. यामुळे आमच्या कमकुवत पार्टिशन्सची समस्या सुटली असती, परंतु जास्त RU लागणाऱ्या वापराच्या केसेस स्केल अप करण्यापासून आम्हाला रोखले गेले असते.

Azure Cosmos DB टीमने आमच्यासाठी तयार केलेल्या नवीन सुधारित सर्वरलेस मोडमुळे प्रत्येक फिजिकल पार्टिशनला 10K RU/s पर्यंत स्केल अप करणे शक्य झाले आणि स्टोरेज-वापर-आधारित स्प्लिट्स व्यतिरिक्त RU-वापर-आधारित स्प्लिट्स सादर केल्यामुळे आम्हाला कंटेनर्सचे मॅन्युअली मॉनिटरिंग आणि स्केल अप करणे थांबवता आले.

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

कंपन्या OpenAI इतक्या मोठ्या झाल्यावर व्यवस्थापित सेवा तितक्या “व्यवस्थापित” राहत नाहीत. अनेक कार्यभार क्लाउड पुरवठादाराच्या नेहमीच्या पायाभूत वापरापेक्षा वेगळे ठरतात. OpenAI हे Azure Cosmos DB च्या सर्वांत मोठ्या वापरकर्त्यांपैकी एक झाल्यावर, ते यशस्वीपणे चालवण्यासाठी वेगळे मॉडेल लागले: संयुक्त चाचण्या, शेअर केलेले डॅशबोर्ड्स, थेट अभियांत्रिकी संपर्क आणि केवळ आमच्या प्रमाणावर दिसणाऱ्या बिघाडांची संयुक्त जबाबदारी. आज आमच्या सर्वांत मोठ्या Azure Cosmos DB खात्यात अनेक पेटाबाइट डेटा साठवलेला आहे आणि ते 2 कोटींहून अधिक QPS हाताळते. आमच्या माहितीनुसार, Azure Cosmos DB इतक्या मोठ्या प्रमाणावर वापरणारी आम्ही एकमेव कंपनी आहोत.

2024 च्या अखेरीस एका प्रादेशिक सेवा खंडित होण्याच्या घटनेतून हे सहकार्य का आवश्यक आहे ते स्पष्ट झाले. तेव्हा आमच्या सर्वांत मोठ्या Azure Cosmos DB खात्यांपैकी एकाच्या प्राथमिक Azure प्रदेशात वीजपुरवठा खंडित झाला. त्यामुळे पर्यायी प्रदेशात सेवा वळवताना कळले की आमची सर्वांत मोठी खाती दुय्यम प्रदेशात वळवायला अनेक तास लागतील. आमच्या प्रमाणावर याची चाचणी ना आमच्या संघाने केली होती, ना Azure Cosmos DB संघाने.

सुमारे महिन्याभरानंतर ही खाती मूळ प्रदेशात परत वळवताना आमच्यामुळे आणखी एक गंभीर सेवा खंडित होण्याची घटना घडली. मूळ प्रदेशात एकाच वेळी प्रचंड कनेक्शन आल्याने तेथील Azure Cosmos DB प्रवेशद्वारावर क्षमतेपलीकडे ताण पडला. प्रवेशद्वार मोडमधील Azure Cosmos DB क्लायंट पर्यायी प्रदेशात सेवा वळवताना ज्या पद्धतीने वागत होता, त्यातील एका वैशिष्ट्यामुळे हे झाले. काही फिजिकल पार्टिशन्सने मूळ प्रदेशात परतली असतानाही सर्व क्लायंटनी लगेच तिथे कनेक्शन जोडून विनंत्या पाठवायला सुरुवात केली.

प्रत्येक वेळी OpenAI आणि Azure या दोघांनी घटना व्यवस्थापन प्रक्रिया राबवल्या, अनेक मूळ कारणे शोधली आणि दुरुस्त्या लागू केल्या. पण या घटना आमचा संघ आणि Azure Cosmos DB संघ यांच्या संचालन व चाचणी पद्धतींमधील मोठ्या प्रणालीगत समस्येची लक्षणे होती. सुरुवातीला व्यवस्थापित सेवांमुळे आम्हाला वेगाने पुढे जाता आले आणि व्यावसायिक उद्दिष्टांवर लक्ष देता आले. मोठ्या प्रमाणावर या सेवा तितक्या व्यवस्थापित राहत नाहीत. रचनेपासून संचालनापर्यंत प्रत्येक पातळीवर सेवा पुरवठादारासोबत सखोल समन्वय आवश्यक होतो.

आज Habitat आणि Azure चे अभियांत्रिकी संघ आमच्या सेवा स्तरांपासून Azure Cosmos DB च्या भौतिक संचयन स्तरांपर्यंत Habitat च्या प्रत्येक स्तरावर संयुक्तपणे लक्ष ठेवतात. प्रत्यक्ष सेवेइतक्याच आकाराच्या, पण प्रत्यक्ष सेवा न देणाऱ्या Azure Cosmos DB खात्यावर आम्ही बदल चालवून तपासतो. आम्ही SDK ची एकत्र चाचणी करतो, त्यांत सुधारणा करतो आणि आमच्या Azure Cosmos DB खात्यांचा आकार व क्षमता वाढवण्यासाठी सर्वोत्तम पद्धती ठरवतो. Teams द्वारे आम्ही एकमेकांच्या अभियांत्रिकी संघांशी थेट संपर्क साधू शकतो. सहाय्याच्या विविध स्तरांतून न जाता एकमेकांना थेट तातडीचा इशारा देण्याचीही सोय केली आहे.

गेल्या वर्षभरात Azure Cosmos DB च्या नियंत्रण स्तराची व प्रवेशद्वाराची विस्तारक्षमता सुधारण्यासाठी बरेच संयुक्त काम झाले. Azure Cosmos DB च्या मेटाडेटा विभाजनाचे संरक्षण करण्यासाठी प्रवेशद्वारात भारापासून संरक्षण आणि विविध मेटाडेटाचे कॅशिंग जोडले. कनेक्शन पूलिंग व कनेक्शनचा अधिक पुनर्वापर करून आमच्या Python habitat-service प्रक्रियांच्या संचामुळे येणारा ताण कमी केला. शक्य तिथे कार्यभार एकाच ठिकाणी ठेवले आणि वेगवेगळ्या VPC वापरून महत्त्वाचे कार्यभार ऑफलाइन कार्यभारांपासून विलग केले.

गेल्या वर्षभरात आमच्या Azure Cosmos DB च्या स्थिरतेसाठी या स्तरावरील सह-अभियांत्रिकी अत्यंत महत्त्वाची ठरली आहे. कोणतीही मोठी किंवा पुरेशी महत्त्वाची प्रणाली अशा प्रकारच्या सांघिक कार्याची मागणी करते: मालकीच्या मर्यादा तोडून संस्थात्मक सीमांच्या पलीकडे जाऊन काम करणे.

भाग 1 मध्ये म्हटल्याप्रमाणे, आमचे मूलभूत तत्त्व आहे: आधी काम होईल असे करा, मग वेग वाढवा, मग खर्च कमी करा. आधी विश्वासार्हता, मग कार्यप्रदर्शन, त्यानंतर कार्यक्षमता. Habitat ही OpenAI साठी अत्यावश्यक पायाभूत सुविधा बनली होती, त्यामुळे तिला विश्वासार्ह बनवणे हे पहिले प्राधान्य होते. 2025 मध्ये प्रणाली स्थिर झाली आणि OpenAI चा जागतिक विस्तार झाला, तेव्हा प्रतिसादातील विलंब हा वापरकर्त्यांसाठी आणि उत्पादन संघांसाठी पुढचा अडथळा ठरला.

संगणन आणि स्टोरेज क्षमता अनेकदा वेगवेगळ्या प्रदेशांत असल्याने प्रदेशांदरम्यान विनंत्या पाठवणे अपरिहार्य होते.

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

2026 मध्ये आमच्यासाठी हे एक मोठे लक्ष्य राहिले आहे, आणि आम्ही रीड परफॉर्मन्स ऑप्टिमाइझ करण्यासाठी एक स्तरित रणनीती विकसित केली आहे, जी Habitat च्या 90% पेक्षा जास्त विनंत्यांचे प्रतिनिधित्व करते:

ज्या वापरकर्त्यांना डेटा रेसिडेन्सीची आवश्यकता आहे, त्यांच्यासाठी आमच्याकडे जगभरातील विविध Azure रिजनमध्ये अनेक Azure Cosmos DB खाती आहेत. ज्या वापरकर्त्यांना डेटा रेसिडेन्सीची कठोर आवश्यकता नाही, त्यांच्यासाठीसुद्धा डेटा वापरकर्त्यांच्या जवळ ठेवल्याने कमी लेटन्सीद्वारे त्यांचा अनुभव सुधारतो.

प्रत्यक्षात, डेटा रेसिडेन्सीच्या वापराव्यतिरिक्त आम्ही हे व्यापकपणे साध्य करू शकत नाही, कारण प्लेसमेंट भौतिक क्लाउड क्षमतेमुळे मर्यादित आहे. आमच्या डेटा सेट्सच्या आकारामुळे, अनेक प्रदेश त्यांच्या वापरकर्त्यांच्या ट्राफिकच्या प्रमाणात आवश्यक असलेली प्रचंड स्टोरेज क्षमता सामावून घेऊ शकत नाहीत.

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

परिणामी, प्लेसमेंटचे निर्णय अनेकदा खालील बाबींमधील एक उत्पादन तडजोड असतात: A) विविध उत्पादनांसाठी आणि वापरकर्त्यांच्या उपसमूहांसाठी लेटन्सी ऑप्टिमाइझ करणे, आणि B) मूळ स्टोरेज आणि कम्प्युट क्षमता.

सर्वात जास्त लेटन्सी-संवेदनशील वर्कलोड्ससाठी, जसे की प्रत्येक रिक्वेस्टवर आवश्यक असणारे ऑथेंटिकेशन मेटाडेटा, आम्ही अनेक सेकंडरी रिजनसह अत्यंत रेप्लिकेटेड Azure Cosmos DB अकाउंट्स वापरून कम्प्यूट आणि Habitat मधील RTT कमी करतो. काही अकाउंट्स आम्ही ट्रॅफिक सर्व्ह करत असलेल्या सर्व 40 Azure रिजनमध्ये रेप्लिकेट होतात; तर इतर अकाउंट्स प्रत्येक खंडात किमान एका रिजनमध्ये रेप्लिकेट होतात.

आम्हाला अपेक्षेपेक्षा लवकर Habitat मध्ये एक पारदर्शक डेटा मूव्हमेंट आणि रूटिंग लेयर तयार करावा लागला आहे, जेणेकरून आम्ही वेगवेगळ्या रेप्लिकेशन टोपोलॉजी असलेल्या खात्यांमध्ये डेटासेटची देवाणघेवाण करू शकू.

मात्र, या पद्धतीलाही शेवटी क्षमतेचे बंधन आहे. म्हणून ती निवडक मोजक्या डेटासंचांपुरतीच मर्यादित आहे.

Habitat वर्कलोड्स प्रामुख्याने रीड-हेवी असतात, ज्यात ॲप्लिकेशन्स सतत सेटिंग्स, स्टेट आणि इतर प्रॉपर्टीज मिळवत असतात; वारंवार ॲक्सेस केल्या जाणाऱ्या प्रकारांच्या तुलनेने लहान वर्किंग सेटमुळे ट्रॅफिकचा एक मोठा भाग निर्माण होतो. यामुळे ही प्रणाली डिस्ट्रिब्युटेड कॅशिंगसाठी विशेषतः योग्य ठरते. सिंगल-रिजन इन्फ्रास्ट्रक्चरमध्ये कॅशिंगमुळे परफॉर्मन्स सुधारत असला तरी, विविध रिजनमध्ये काम करताना या सुधारणा अनेक पटींनी वाढतात, जिथे त्याचा उपयोग क्रॉस-रिजन लेटन्सी "लपवण्यासाठी" केला जाऊ शकतो.

आम्ही Habitat मध्ये वितरित, गरजेनुसार तपासला जाणारा कॅशिंग स्तर जोडला आहे. वापरकर्त्यांच्या विनंत्या जिथे हाताळल्या जातात, त्याजवळील Valkey सर्व्हरवर तो अलीकडे वापरलेल्या ऑब्जेक्ट आणि त्यांच्यातील संबंधांच्या प्रती ठेवतो. अशा कॅशमध्ये सहसा TTL वापरला जातो. त्यात कॅशमध्ये डेटा सापडण्याचा दर आणि डेटा जुना असण्याचे प्रमाण यांत तडजोड करावी लागते. कमी TTL मुळे डेटा कमी जुना राहतो, पण कॅशिंगचा फायदा कमी होतो. नोंदी लवकर कालबाह्य झाल्याने त्या वारंवार पुन्हा मिळवाव्या लागतात. जास्त TTL मुळे कॅशमध्ये डेटा अधिक वेळा सापडतो, पण जुना डेटा दीर्घकाळ पुरवला जातो. त्यामुळे वापरकर्ता अनुभव खालावतो आणि उत्पादनाचे वर्तन अनपेक्षित होते.

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

Meta च्या TAO सारख्या प्रणालींच्या धर्तीवर आम्ही नोंदी अवैध करण्याची अधिक प्रगत पद्धत स्वीकारली आहे. Habitat ची एकात्मिक कॅशे Azure Cosmos DB च्या बदल-प्रवाहातून बदल नोंदणी (CDC) करते. त्यातून काही सेकंदांत जगभर नोंदी अवैध केल्या जातात. त्यामुळे कॅशेमध्ये डेटा सापडण्याचा दर जास्त राहतो आणि डेटा कमी जुना असतो. आमच्या पायाभूत सुविधांतील एक सेवा हा बदल-प्रवाह वाचते आणि मूळ डेटा अद्ययावत झाल्यावर स्थानिक कॅशेमधील नोंदी अवैध करते. त्यामुळे पुढच्या वाचनावेळी डेटा कॅशेमध्ये सापडत नाही आणि त्याची नवीनतम आवृत्ती कॅशेमध्ये भरली जाते.

आम्ही मूळ Python पेक्षा अधिक कार्यक्षम असलेल्या Rust मध्ये कोड पुन्हा लिहून Habitat सेवेमधील ओव्हरहेड काढून लेटन्सी लक्षणीयरीत्या कमी केली आहे.

एकत्रितपणे, या बदलांमुळे आमचा एकूण ग्लोबल रीड p50 अंदाजे 120 ms वरून अंदाजे 10 ms पर्यंत कमी झाला आहे, जी या वर्षाच्या सुरुवातीला आम्ही कार्यक्षमतेवर लक्ष केंद्रित करण्यास सुरुवात केल्यापासून 12 पटींची सुधारणा आहे.

कॅशिंगमुळे सरासरी विलंब लक्षणीयरीत्या कमी झाला असला तरी, सर्वात धीम्या विनंत्यांना अजूनही मूळ स्टोरेजमधून, अनेकदा दूरच्या प्रदेशांमधून, कॅशे न केलेला डेटा आणावा लागतो. जसजशी अधिक क्षमता उपलब्ध होईल आणि आम्ही स्टोरेजची कार्यक्षमता सुधारू, तसतसे आम्ही एका अधिक मूलभूत आव्हानाला सामोरे जाण्याची योजना आखत आहोत: डेटा जिथे सुरुवातीपासूनच ॲक्सेस केला जाईल, त्याच्या जवळ ठेवणे.

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

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

जरी Habitat चा Azure Cosmos DB चा अंतर्गत वापर गुंतागुंतीचा असला तरी, उत्पादन डेव्हलपर्सना पायाभूत सुविधांच्या तपशिलांपासून दूर ठेवून उत्पादन विकासाचा वेग वाढवणे, हेच त्याचे मुख्य उद्दिष्ट राहिले आहे आणि आमचे CDC प्लॅटफॉर्मही यापेक्षा वेगळे नाही.

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

पुढील 100 कोटी वापरकर्त्यांसाठी Habitat आणि संभाषण स्टोरेज वाढवताना, आमच्या पायाभूत सुविधांमध्ये आणखी मोठ्या प्रमाणावर डेटाच्या प्रती तयार करण्याची अडचण सोडवावी लागेल. त्यासाठी पूर्वतयारी म्हणून आम्ही स्वतःची एक्साबाइट-स्तरीय ऑनलाइन स्टोरेज प्रणाली उभारत आहोत. ती Habitat च्या मोठ्या आकाराच्या डेटा प्रकारांसाठी खास अनुकूल केली आहे. विकासाधीन असलेली ही प्रणाली Rockset मधील RocksDB Cloud चा गाभा आणि Raft-आधारित प्रतिकृतीकरण एकत्र आणते. ती Azure Cosmos DB सारखेच दस्तऐवज मॉडेल वापरते. मात्र, संगणनापासून वेगळे स्टोरेज आणि भौतिक प्रतिकृतीकरण वापरून आवश्यक फ्लॅश क्षमता कमी करते; त्याबदल्यात कमाल प्रतिसेकंद क्वेरी दर कमी असतो.

जर तुम्हाला अशा प्रकारच्या अत्याधुनिक डेटा इन्फ्रास्ट्रक्चर प्रकल्पांवर काम करण्यात रस असेल, तर आमच्याकडील रिक्त पदांची माहिती⁠ घ्या.