एक अब्जाहून अधिक ChatGPT वापरकर्त्यांसाठी ऑनलाइन स्टोरेजचा जलद विस्तार

प्रत्येक OpenAI उत्पादन जलद, विश्वासार्ह डेटा प्रवेशावर अवलंबून असते, मग कोणी लॉग इन करत असेल, त्यांच्या Codex सेटिंग्ज तपासत असेल किंवा ChatGPT मध्ये नवीन संभाषण सुरू करत असेल. उत्पादन प्रतिसाद देऊ शकण्यापूर्वी यांपैकी प्रत्येक कृतीसाठी अनेक स्वतंत्र डेटा शोध आवश्यक असू शकतात. त्या विनंत्या धीम्या असल्यास, उत्पादन धीमे वाटते. त्या विनंत्या अयशस्वी झाल्यास, उत्पादन पूर्णपणे कार्य करणे थांबवते.

Habitat हे आम्ही तयार केलेले ऑनलाइन स्टोरेज प्लॅटफॉर्म आहे, ज्यामुळे OpenAI उत्पादने आवश्यक माहिती जलद आणि विश्वासार्हपणे मिळवू शकतात. Habitat आता दर सेकंदाला 70 दशलक्षपेक्षा जास्त विनंत्या हाताळते आणि जवळपास 40 भौगोलिक प्रदेशांमध्ये दर आठवड्याला 1 अब्जपेक्षा जास्त लोक वापरत असलेल्या उत्पादनांना समर्थन देते. एकाच डेटाबेसशी जोडलेली साधी Python क्लायंट-साइड लायब्ररी म्हणून सुरुवात करून, GPTsना समर्थन देण्यासाठी Habitat प्रथम DevDay 2023 मध्ये लाँच करण्यात आले. आज, ही 500 पेटाबाइटपेक्षा जास्त डेटा हाताळणारी एक जटिल वितरित प्रणाली आहे.

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

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

भविष्यातील एका पोस्टमध्ये, आम्ही मोठ्या प्रमाणावर मल्टी-टेनन्सीची विश्वासार्हता कशी साध्य केली, रीड परफॉर्मन्स अनुकूलित करण्यासाठीची आमची स्तरित रणनीती आणि अभूतपूर्व मागणी विश्वासार्हपणे हाताळण्यासाठी Azure Cosmos DB सोबतची आमची भागीदारी कशी वाढवली याबद्दल सविस्तर माहिती देऊ.

Habitat ची सुरुवात एका साध्या कल्पनेतून झाली: उत्पादन अभियंत्यांना डेटाबेस व्यवस्थापनाचा विचार करण्याची गरज भासू नये. ChatGPT च्या मुख्य सर्व्हरशी संवाद साधणारी छोटी Python लायब्ररी म्हणून, GPTs ला समर्थन देण्यासाठी Habitat प्रथम DevDay 2023 मध्ये लाँच करण्यात आले. ते डेटाबेस अनुप्रयोग, Azure Cosmos DB, शी अंतर्गतपणे मॅप होणाऱ्या मर्यादित ऑपरेशन्सना समर्थन देत होते.

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

उत्पादन अभियंत्यांना स्कीमा लुकअप, रूटिंग, अधिकृतता, एन्क्रिप्शन, सीरियलायझेशन, विनंती आकारनिर्धारण आणि कनेक्शन पूलिंगची चिंता करण्याची गरज नाही. डेटा कुठून येतो याचाही त्यांना विचार करण्याची गरज नव्हती: Azure Cosmos DB, कॅशेस किंवा इतर प्रकारचे संचयन.

या Python लायब्ररीने चांगले काम केले आणि self-serve Postgres व Azure Cosmos DB वापरण्यापासून दूर जाण्यासाठी कोणताही एकत्रित केंद्रीय प्रयत्न नसतानाही, OpenAI मधील उत्पादन अभियंत्यांमध्ये Habitat चा वेगाने स्वीकार झाला.

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

2025 च्या मध्यापर्यंत, क्लायंट-साइड अंमलबजावणी म्हणून Habitat ने तुमच्या मर्यादा गाठल्या होत्या. Habitat स्तर अधिक जटिल होत असताना आणि OpenAI च्या सेवांची संख्या वाढत असताना, बॅकवर्ड-कॉम्पॅटिबल प्रोटोकॉल बदल करणे अशक्य झाले होते.

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

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

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

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

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

आम्हाला सेवा आवश्यक असल्याचे माहीत होते, पण सेवा म्हणून Python चा अतिरिक्त ओव्हरहेड असूनही, आम्हाला अजून Python पासून स्थलांतर करायचे नव्हते. स्थानिक लायब्ररी एक्झिक्युशनच्या तुलनेत, उच्च-थ्रुपुट सेवेसाठी Python वापरल्याने नेटवर्क लेटन्सी वाढली आणि CPU व मेमरी स्केलिंगचा लक्षणीय खर्च वाढला. शिवाय, आम्ही ओळखले की 100x स्केलवर Python ची अकार्यक्षमता स्वीकारार्ह ठरणार नाही, त्यामुळे अखेरीस पुनर्लेखन जवळजवळ निश्चित होते.

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

आमच्या स्वतःच्या कोडिंग मॉडेल्सची जलद प्रगती भविष्यातील तांत्रिक मार्ग सुलभ करेल, यावर आम्ही विचारपूर्वक पैज लावली होती. Python वरून पूर्ण स्थलांतर आवश्यक होईपर्यंत, Codex आणि GPT त्या स्थलांतराला शक्य करतील, अशी आमची पैज होती. ती पैज अखेरीस खरी ठरली.

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

Asyncio मुळे Python ला I/O-बद्ध वर्कलोड्स समवर्तीपणे चालवता येतात, परंतु ते Python GIL चा अडथळा दूर करण्यात आणि CPU समांतरता प्रदान करण्यात मदत करत नाही. I/O-केंद्रित विनंती प्रॉक्सींगव्यतिरिक्त, Habitat अनेक CPU-केंद्रित जबाबदाऱ्या आणि पार्श्वभूमीतील कार्ये हाताळते: राउटिंग, संक्षेपण, कूटबद्धीकरण, चेकसमिंग, डाउनस्ट्रीम हेल्थ तपासणी, विनंती शॅडोइंग आणि हेजिंग.

आमच्या सेवेमध्ये इतके CPU-केंद्रित वर्कलोड आणि पार्श्वभूमीतील कार्ये असल्याने, asyncio शेड्युलिंग विलंब टेल रिक्वेस्ट लेटन्सीवर सहजपणे वर्चस्व गाजवू शकतो. आमच्या प्रारंभिक सेवा लाँचसाठी ट्यून करण्यापूर्वी, आम्ही p99 आणि त्याहून अधिक विलंब असलेल्या विनंत्यांच्या ट्रेसमध्ये पाहिले की, डाउनस्ट्रीम स्टोरेजने त्वरीत प्रतिसाद दिला तरीही, प्रतिसाद पार्स करण्यासाठी जबाबदार कोरूटिन पुन्हा वेळापत्रित होईपर्यंत विनंत्या अनेकदा अडकून राहत होत्या.

OpenAI मधील Python सेवांसाठी, मेमरी, CPU, नेटवर्क आणि डिस्क वापरावरील मानक वापर व संपृक्तता मेट्रिक्स मोजण्यासोबतच, asyncio लूप आणि तो किती व्यस्त आहे याचे निरीक्षण करणे आणि त्यानुसार ट्यून करणेही महत्त्वाचे असल्याचे आम्हाला आढळते.

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

परिणामी, आम्ही प्रत्येक प्रक्रियेला एकाच वेळी फक्त थोड्या विनंत्या हाताळण्यापुरते मर्यादित ठेवतो आणि त्याऐवजी Python वर्कर प्रक्रियांची संख्या मोठ्या प्रमाणात वाढवतो.

आमच्या सुरुवातीच्या सेवा लाँचमध्ये, लाइव्ह सेवा CPU प्रोफाइलिंगद्वारे आम्हाला उच्च asyncio विलंबाचे (आणि परिणामी उच्च टेल लेटन्सीचे) एक मूळ कारण आढळले: Statsig द्वारे आमच्या फीचर फ्लॅग कॉन्फिगरेशनचे नियतकालिक JSON पार्सिंग (Statsig हे फीचर फ्लॅग व्यवस्थापित करणारे साधन आहे आणि त्याचा वापर A/B चाचण्या व इतर गोष्टींसाठी केला जाऊ शकतो).

डीफॉल्टनुसार, Statsig दर मिनिटाला कोणत्याही जिटरशिवाय अद्ययावत कॉन्फिगरेशनसाठी पोल करण्यासाठी कॉन्फिगर केले होते आणि कॉन्फिगरेशनमध्ये प्रत्येक सेवेतील प्रत्येक प्रॉडक्शन नियम समाविष्ट होता. दुसरीकडे, CPU वापर उच्च करण्यासाठी आणि कमी विलंबता देण्यासाठी प्रति pod जास्तीत जास्त आठ Python प्रक्रिया चालवण्याचा आर्किटेक्चरल निर्णय घेण्यात आला. एकत्रितपणे, याचा अर्थ असा की प्रत्येक मिनिटाला प्रत्येक पॉडमध्ये असा एक क्षण येत असे जेव्हा सर्व कर्मचारी चालू असलेल्या विनंत्यांची प्रक्रिया थांबवून त्याऐवजी त्यांच्या CPU चक्रांचा वापर एका प्रचंड कॉन्फिगरेशन फाइलचे पार्सिंग करण्यासाठी करत.

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

asyncio विलंब कमी ठेवण्यासाठी, सर्व्हर प्रक्रियांमध्ये विनंत्यांचे चांगले लोड बॅलन्सिंग राखणेही महत्त्वाचे आहे; ट्यूनिंगशिवाय कनेक्शन पूलिंग याच्या प्रतिकूल ठरू शकते.

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

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

कनेक्शन पूलमध्येच दोष असावा असा आम्हाला संशय होता आणि Max कनेक्शन पुनर्वापर कालावधी मर्यादित करून आम्ही या संशयाची चाचणी केली. त्यामुळे ऱ्हास खरोखरच मर्यादित झाला आणि आमच्या तपासाची दिशा योग्य असल्याची पुष्टी झाली. पुढील तपासात असे आढळले की Python चे aiohttp TCPConnector डीफॉल्टनुसार LIFO पद्धतीने कनेक्शन्सचा पुनर्वापर करते: सर्वात अलीकडे परत केलेले कनेक्शन पुढील विनंतीसाठी निवडले जाते. सामान्यतः हा एक वाजवी डीफॉल्ट आहे: अलीकडील कनेक्शन्सचा पुनर्वापर केल्याने अचानक वाढणारी ट्रॅफिक हाताळण्यासाठी तयार केलेल्या अतिरिक्त कनेक्शन्सना निष्क्रिय टाइमआउटपर्यंत पोहोचता येते, त्यामुळे अतिरिक्त कनेक्शन्स राखण्याचा ओव्हरहेड कमी होतो. या प्रकरणात मात्र, यामुळे आमच्यासाठी एक मेटास्टेबल अपयश निर्माण झाले. विनंत्यांचा अचानक मोठा ओघ आला असताना, धीम्या आणि ओव्हरलोड झालेल्या सर्व्हरना केलेल्या विनंत्यांमुळे कनेक्शन्स नंतर पूलमध्ये परत आली आणि त्यामुळे पुढील विनंत्यांकडून ती अधिक वारंवार निवडली गेली. परिणामी, आधीच अडचणीत असलेल्या पॉड्सवर अधिकाधिक ट्रॅफिक हळूहळू केंद्रित होत गेले. कनेक्शन पूलमध्ये FIFO पुनर्वापर वापरण्यासाठी पॅच केल्याने हा फीडबॅक लूप तुटला आणि स्थिर स्थितीतील विनंत्यांच्या विचलनातही घट झाली.

आज, OpenAI च्या संपूर्ण पायाभूत सुविधांमध्ये कनेक्शन पूलिंग आणि सर्व्हरच्या लोडचा विचार करणाऱ्या अधिक चांगल्या संतुलन धोरणांसाठी आम्ही मुख्यतः Istio आणि Envoy वर अवलंबून असतो आणि ही समस्या पूर्णपणे टाळतो.

कमी asyncio विलंबासाठी ट्यूनिंग केल्याचा आणि इतक्या मोठ्या संख्येने Python प्रक्रिया असल्याचा एक दुष्परिणाम असा आहे की, कनेक्शनच्या प्रचंड संख्येमुळे डाउनस्ट्रीम अवलंबित्वांवर भार पडणे खूप सोपे होते (यालाच “थंडरिंग हर्ड” म्हणतात).

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

आमच्या कनेक्शन फॅन-इनला कमाल करण्यासाठी आम्ही Envoy वरही अवलंबून असतो. मल्टिप्लेक्सिंगचा लाभ घेण्यासाठी आम्ही त्याचा वापर Python च्या HTTP/1 कनेक्शनना HTTP/2 मध्ये अपग्रेड करण्यासाठी करतो आणि नंतर ती कनेक्शन्स पूल करून त्यांचे आयुष्य वाढवतो. प्रत्येक स्वतंत्र Python प्रक्रियेत कमी प्रभावी ठरणाऱ्या रेट मर्यादा आणि सर्किट ब्रेकर्स अंमलात आणण्यासाठी Envoy आम्हाला एक मध्यवर्ती ठिकाणही देते.

आम्ही Python इतक्या प्रमाणात स्केल करू शकलो याचे एक कारण म्हणजे Habitat चे मर्यादित API, जे विनंतीचा खर्च पूर्वानुमानित ठेवते. क्लायंटना मोठ्या टेबलचे स्कॅन किंवा अनेक टेबलमधील जॉइन होऊ शकतील अशा मनमानी SQL क्वेरी तयार करू देण्याऐवजी, Habitat एक साधे NoSQL API उपलब्ध करून देते. शक्तिशाली API नसणे ही Habitat च्या डिझाइनमधील स्पष्ट तडजोड आहे.

सोप्या, अंदाज करता येणाऱ्या आणि स्थिर कामाच्या विनंत्यांसाठी अनुकूलन करण्याचे आमचे उद्दिष्ट आहे. आमच्या अनुभवात, या प्रणालींचे स्केलिंग करणे लक्षणीयरीत्या सोपे असते आणि त्यांच्याबाबत चूक करणे किंवा त्यांचा गैरवापर करणे कठीण असते. अनपेक्षित फॅनआउट असलेल्या विनंत्या कार्यान्वयनाच्या दृष्टीने धोकादायक असतात: त्या विलगीकरण आणि लोड बॅलन्सिंग अधिक गुंतागुंतीचे करतात आणि सेवेसाठी तसेच तिच्या क्लायंटसाठी स्केल करणे कठीण असलेले लेटन्सी क्लिफ्स निर्माण करतात.

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

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

Habitat क्लायंटने परिभाषित केलेल्या ऑब्जेक्ट आणि एज प्रकारांभोवती मॉडेल केलेले, TAO⁠(नवीन विंडोमध्ये उघडेल) पासून प्रेरित NoSQL API उपलब्ध करून देते. क्लायंट ऑब्जेक्ट आणि एज तसेच ते एकमेकांशी कसे संबंधित आहेत हे पूर्वनिर्धारित करतात, पण प्रत्येक प्रकाराची सामग्री पूर्वनिर्धारित करत नाहीत. परिणामी संबंध ग्राफसारखे दिसतात, पण Habitat स्वतः विशिष्ट ऑब्जेक्टच्या थेट एजची क्वेरी करण्याव्यतिरिक्त सामान्य ग्राफ ट्रॅव्हर्सल क्वेरींना समर्थन देत नाही.

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

अधिक जटिल क्वेरींगच्या गरजा असलेल्या क्लायंटसाठी, आम्ही Rockset द्वारे उपलब्ध करून दिलेले Habitat चे ऑफलाइन दुय्यम दृश्य प्रदान करतो. ऑनलाइन स्टोरेजमधील बदल जवळजवळ रिअल-टाइममध्ये वेगळ्या Rockset इन्स्टन्सेसकडे स्ट्रीम करण्यासाठी आम्ही चेंज डेटा कॅप्चर (CDC) वापरतो. प्रत्येक क्लायंट संघ त्यांच्या जटिल क्वेरींगच्या गरजांसाठी स्वतःचा Rockset इन्स्टन्स स्केल करण्यास जबाबदार असते.

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

Python चे पुनर्लेखन एक वर्ष पुढे ढकलल्यामुळे आमच्या अतिवेगवान वाढीदरम्यान अधिक तातडीच्या आणि परिणामकारक आव्हानांवर लक्ष केंद्रित करता आले. प्लॅटफॉर्म परिपक्व होत असताना आणि आमची वाढ वेगाने सुरू असताना, तसेच OpenAI मध्ये कोअर संख्येनुसार दुसरी सर्वात मोठी सेवा (आणि आमच्या Envoy वापराच्या व्याप्तीनुसार चौथी) असल्याने, अखेर Pythonच्या पलीकडे जाण्याची वेळ आली होती. सर्वोच्च टप्प्यावर, Python मुळे आम्हाला दर सेकंदाला 20 दशलक्षांहून अधिक विनंत्या हाताळता आल्या.

2026 च्या Q2 मध्ये, केवळ 2 अभियंते, Codex आणि GPT‑5.5 यांच्या मदतीने आम्ही संपूर्ण सेवा Rust मध्ये पुन्हा लिहू शकलो. ही नवीन Rust सेवा आता आमच्या उत्पादन विनंत्यांपैकी 95% विनंत्या हाताळत आहे; येत्या आठवड्यांत आम्ही Python पूर्णपणे वापरणे बंद करू. आमचा डेटा दर्शवतो की Python आवृत्तीच्या तुलनेत Rust सेवा CPU च्या बाबतीत सहापट अधिक कार्यक्षम आणि मेमरीच्या बाबतीत 15x अधिक कार्यक्षम आहे, तसेच तिची सरासरी आणि टेल लेटन्सी लक्षणीयरीत्या कमी आहे. भविष्यातील ब्लॉगमध्ये आणखी शिकवणी सामायिक करण्याची आमची योजना आहे.

Python—आणि आता Rust—सेवा ही Habitat चा फक्त एक पैलू आहे. एक अब्जाहून अधिक ChatGPT वापरकर्त्यांना सेवा देण्यासाठी आम्ही आमचे ऑनलाइन स्टोरेज वेगाने कसे वाढवले हे सांगणाऱ्या या मालिकेच्या भाग II मध्ये, आम्ही स्टोरेज लेयरबद्दल आणि Habitat दर सेकंदाला 500 पेटाबाइट्सहून अधिक डेटा आणि 70 दशलक्षांहून अधिक विनंत्या कशा हाताळते याबद्दल बोलू.

तुम्हाला अत्याधुनिक स्तरावरील OLTP प्रणालींवर काम करायचे असेल आणि अशा प्रकारच्या अभियांत्रिकीमध्ये रस असेल, तर आमच्या संघमधील ही खुली भूमिका पाहा⁠.