1 अरब से ज़्यादा ChatGPT यूज़र्स के लिए ऑनलाइन स्टोरेज को तेज़ी से बढ़ाना (भाग 2)

OpenAI के सभी प्रोडक्ट्स को डेटा का तेज़ और भरोसेमंद एक्सेस चाहिए, जो हमारा स्टोरेज प्लेटफ़ॉर्म Habitat देता है. इसे 40 अलग-अलग रीजन में 1 अरब से ज़्यादा यूज़र्स की रिक्वेस्ट्स का जवाब मिलीसेकंड में देना होता है. हमारे इंफ़्रास्ट्रक्चर के सामने एक बड़ा चैलेंज था: तेज़ी से बढ़ते इस्तेमाल और नए यूज़ केसेज़ को सपोर्ट करना, साथ ही भरोसेमंद परफ़ॉर्मेंस, स्पीड और डेवलपर्स के काम करने की रफ़्तार लगातार बेहतर बनाना. इसके लिए हमें अपने ऑनलाइन स्टोरेज प्लेटफ़ॉर्म के डिज़ाइन और उसे चलाने के तरीके पर दोबारा सोचना पड़ा. हम लगातार अलग-अलग ऑप्शन्स के फ़ायदे और कमियाँ देखते रहे. हमारा तरीका था: पहले सिस्टम को इतना भरोसेमंद बनाना कि वह प्रोडक्ट्स का सबसे अहम ट्रैफ़िक सँभाल सके, फिर दुनिया भर के यूज़र्स के लिए उसे तेज़ बनाना और आखिर में बहुत बड़े पैमाने पर उसे आसानी से चलाना.

दो भागों वाली इस सीरीज़ में हम बताते हैं कि कैसे हमने Habitat को एक साधारण क्लाइंट लाइब्रेरी और डेटाबेस से बदलकर दुनिया भर में फैला स्टोरेज प्लेटफ़ॉर्म बनाया, जो 500 पेटाबाइट से ज़्यादा डेटा सँभालता है. पहले भाग में बताया गया था कि Habitat एक Python क्लाइंट से सर्विस कैसे बना. इसमें उन तकनीकों के बारे में भी बताया गया, जिनकी मदद से हमने 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 कई लॉजिकल पार्टिशन कीज़ को कम संख्या में फ़िज़िकल पार्टिशन्स पर बाँटकर मैनेज करता है. जब स्टोरेज एक तय लिमिट से बढ़ जाता है या कंटेनर को अपनी तय थ्रूपुट कैपेसिटी बनाए रखने के लिए और फ़िज़िकल पार्टिशन्स चाहिए होते हैं, तो यह उन्हें कई फ़िज़िकल पार्टिशन्स में बाँट देता है

शुरुआत में हम क्लाइंट्स से आने वाले किसी भी लोड को स्वीकार करते थे. हमें भरोसा था कि हर लॉजिकल पार्टिशन की के लिए तय 10 हज़ार 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 से बढ़कर 10 लाख QPS हो जाने पर भी कुल इस्तेमाल में बहुत बड़ा बदलाव आने की संभावना कम थी. लेकिन अलग कंटेनर में किसी नए यूज़ केस का लोड 0 से 10 लाख QPS तक पहुँचने का मतलब हो सकता था कि उस पर लोड शुरुआती स्तर से 1,000 गुना बढ़ गया है. यह शुरुआती स्तर सिर्फ़ इंटरनल टेस्टिंग के दौरान हुए इस्तेमाल पर आधारित होता था.

डेडिकेटेड कंटेनर्स के साथ अब टीमों को लॉन्च से पहले ही अनुमानित थ्रूपुट के हिसाब से कंटेनर्स की कैपेसिटी तैयार रखनी पड़ती थी. लेकिन प्रोडक्ट टीमें अक्सर अपने फ़ीचर्स प्रोडक्शन में लॉन्च कर देती थीं और पहले से कैपेसिटी बढ़ाना भूल जाती थीं. ऐसे में लॉन्च के दिन हमें SEV कॉल्स में शामिल होकर आखिरी समय पर कंटेनर्स की कैपेसिटी बढ़ाने की कोशिश करनी पड़ती थी.

मल्टी-टेनेंट सिस्टम्स में अलग-अलग वर्कलोड्स का लोड सँभालना आसान होता है. लेकिन इस कंटेनर स्ट्रैटेजी में बेहतर आइसोलेशन के लिए हमें यह फ़ायदा छोड़ना पड़ा.

समय के साथ डेडिकेटेड कंटेनर्स के इस्तेमाल को मॉनिटर करने के लिए प्रोडक्ट की गहरी जानकारी भी ज़रूरी हो गई. खास तौर पर यह समझना कि ट्रैफ़िक कब बदलेगा या बढ़ेगा.

हम एक बेसिक कंट्रोल प्लेन स्क्रिप्ट दे सकते थे, जो बढ़ते इस्तेमाल के ट्रेंड्स के हिसाब से हर कंटेनर की थ्रूपुट कैपेसिटी बढ़ा सके. लेकिन कुल इस्तेमाल में स्थिर बढ़ोतरी न होने की वजह से कैपेसिटी सही तरीके से बढ़ाने के लिए OpenAI की लगभग हर प्रोडक्ट टीम को कैपेसिटी प्लानिंग में शामिल होना पड़ता था.

यह तरीका पूरे ऑर्गेनाइज़ेशन में बड़े पैमाने पर काम नहीं कर पाया, क्योंकि हर सर्विस को सँभालने वाली टीम Azure Cosmos DB की कैपेसिटी तैयार करने और उसे मैनेज करने पर अलग-अलग स्तर का ध्यान देती थी.

संगठन बढ़ने के साथ संचालन की इन समस्याओं को संभालना कठिन हो गया. योजना बनाने वाली एक केंद्रीय टीम न होने से कई टीमें ठीक से योजना नहीं बना पा रही थीं. इसलिए हम फिर बहु-टेनेंट समाधान की ओर लौटे. Azure टीम के साथ मिलकर हमने साझा-टेनेंसी डिज़ाइन के ज़रिए बहु-टेनेंसी की शुरुआती समस्याओं के तकनीकी समाधान तैयार किए:

सबसे अधिक ट्रैफ़िक वाली कुंजियों की दर पहले सीमित करने से संसाधन-खाऊ पड़ोसी किसी भौतिक पार्टिशन का पूरा उपलब्ध थ्रूपुट नहीं ले पाते. इससे वह प्रभाव घटता है जिसमें एक अत्यधिक सक्रिय कुंजी पूरी साइट को प्रभावित कर सकती है.

अनुरोधों को स्तरों में बाँटने वाला QoS इसी तरह बड़े पैमाने पर डेटा जोड़ने या निकालने जैसे ऑफ़लाइन कार्यभार को किसी भौतिक पार्टिशन का पूरा थ्रूपुट इस्तेमाल करने से रोकता है. इन कार्यभार के अनुरोधों को कम प्राथमिकता देने से उनकी दर पहले सीमित होती है. इससे अंतिम उपयोगकर्ताओं के अधिक प्राथमिकता वाले, सीधे संवाद से जुड़े अनुरोधों पर दर सीमा लगाने की ज़रूरत नहीं पड़ती.

Azure Cosmos DB में पहले से सर्वरलेस मोड था, जो निर्धारित क्षमता वाले मोड में हमारी कमज़ोर पार्टिशन की समस्या हल कर सकता था. लेकिन इसकी एक बड़ी कमी थी: यह केवल स्टोरेज उपयोग के आधार पर क्षमता बढ़ाता था और हर भौतिक पार्टिशन का RU उपयोग 5 हज़ार RU/s तक सीमित रखता था. इससे कमज़ोर पार्टिशन की समस्या तो हल होती, लेकिन अधिक RU लेने वाले उपयोगों की क्षमता बढ़ाना संभव नहीं होता.

Azure Cosmos DB टीम ने हमारे लिए बेहतर सर्वरलेस मोड बनाया. इसमें हर भौतिक पार्टिशन 10 हज़ार RU/s तक बढ़ सकता था और स्टोरेज उपयोग के अलावा RU उपयोग के आधार पर भी विभाजन होता था. इससे कंटेनर की मैन्युअल निगरानी और क्षमता बढ़ाने की ज़रूरत समाप्त हो गई.

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

जब कंपनियाँ OpenAI जितनी बड़ी होती हैं, तो प्रबंधित सेवाओं में “प्रबंधन” का हिस्सा घटने लगता है. कई कार्यभार क्लाउड प्रदाता के बुनियादी ढाँचे में सामान्य दायरे से बाहर हो जाते हैं. OpenAI के Azure Cosmos DB के सबसे बड़े उपयोगकर्ताओं में शामिल होने पर सफल संचालन के लिए अलग तरीका चाहिए था: साझा परीक्षण, साझा डैशबोर्ड, इंजीनियरों के बीच सीधे संवाद और केवल हमारे पैमाने पर दिखने वाली विफलताओं की संयुक्त ज़िम्मेदारी. आज हमारा सबसे बड़ा Azure Cosmos DB खाता दर्जनों पेटाबाइट डेटा रखता है और प्रति सेकंड 2 करोड़ से अधिक क्वेरी संभालता है. हमारी जानकारी के अनुसार, हम अकेली कंपनी हैं जिसने इस पैमाने पर 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 खाते पर चलाकर जाँचते हैं जिसका आकार वास्तविक सेवा जितना है, लेकिन जो वास्तविक उपयोगकर्ताओं को सेवा नहीं देता. हम मिलकर एसडीके का परीक्षण और सुधार करते हैं तथा Azure Cosmos DB खातों की क्षमता और आकार तय करने के सर्वोत्तम तरीके निर्धारित करते हैं. Teams के ज़रिए हमारे इंजीनियर सीधे एक-दूसरे से संपर्क कर सकते हैं. हमने सहायता के विभिन्न स्तरों से गुज़रे बिना सीधे एक-दूसरे को आपात सूचना भेजने की सुविधा भी दी है.

पिछले एक साल में हमने मिलकर Azure Cosmos DB के कंट्रोल प्लेन और गेटवे को बड़े पैमाने पर काम करने के लिए बेहतर बनाया है. Azure Cosmos DB के मेटाडेटा पार्टिशन पर लोड कम करने के लिए गेटवे में लोड प्रोटेक्शन और अलग-अलग मेटाडेटा की कैशिंग जोड़ी गई. कनेक्शन पूलिंग और एक ही कनेक्शन को ज़्यादा बार इस्तेमाल करके Python habitat-service प्रोसेसेज़ से पड़ने वाला दबाव कम किया गया. जहाँ संभव था, वहाँ वर्कलोड्स को एक ही लोकेशन पर रखा गया. साथ ही, अलग-अलग VPC का इस्तेमाल करके अहम वर्कलोड्स को ऑफ़लाइन वर्कलोड्स से अलग किया गया.

पिछले एक साल में Azure Cosmos DB को स्थिर और भरोसेमंद बनाए रखने में इस तरह मिलकर की गई इंजीनियरिंग की अहम भूमिका रही है. किसी भी बड़े या बेहद अहम सिस्टम के लिए ऐसा टीमवर्क ज़रूरी होता है. इसमें अलग-अलग टीमों की ज़िम्मेदारियों के बीच की रुकावटें हटाकर ऑर्गेनाइज़ेशन्स के बीच मिलकर काम करना पड़ता है.

जैसा कि पहले भाग में बताया गया था, हमारा मुख्य तरीका है: पहले सिस्टम को काम करने लायक बनाएँ, फिर उसे तेज़ बनाएँ और उसके बाद लागत कम करें. सबसे पहले भरोसेमंद परफ़ॉर्मेंस, फिर स्पीड और उसके बाद एफ़िशिएंसी. Habitat, OpenAI के लिए बेहद अहम इंफ़्रास्ट्रक्चर बन चुका था. इसलिए हमारी पहली प्रायोरिटी इसे भरोसेमंद बनाना थी. 2025 में सिस्टम स्थिर होने लगा और OpenAI का ग्लोबल स्तर पर विस्तार हुआ. इसके बाद यूज़र्स और प्रोडक्ट टीमों के लिए लेटेंसी अगला बड़ा चैलेंज बन गई.

कंप्यूट और स्टोरेज की क्षमता अक्सर अलग-अलग रीजन में होती थी. इसलिए एक रीजन से दूसरे रीजन में रिक्वेस्ट भेजना ज़रूरी हो जाता था.

डेटा कहाँ स्टोर था और रिक्वेस्ट किस रीजन से प्रोसेस हो रही थी, इसके हिसाब से लेटेंसी में काफ़ी अंतर आता था. Habitat की रिक्वेस्ट्स को तेज़ बनाने के लिए प्रोडक्ट डेवलपर्स को अतिरिक्त क्लाइंट-साइड कैशिंग, रिक्वेस्ट बैचिंग और डेटाबेस में रीड व राइट ऑपरेशन्स कम करने जैसे तरीकों का इस्तेमाल करना पड़ता था. जहाँ मुमकिन होता, वे ज़रूरी प्रोसेस से कुछ काम भी हटा देते थे. इससे कुछ ऐसे प्रोडक्ट डिज़ाइन बने, जो डेटाबेस की समस्याओं के बावजूद बेहतर काम कर सकते थे. लेकिन प्रोडक्ट्स ज़्यादा मुश्किल हो गए और उनके नए वर्ज़न तैयार करने में भी ज़्यादा समय लगने लगा. यह Habitat के उस लक्ष्य के उलट था, जिसमें डेवलपर्स को डेटाबेस की गहरी जानकारी के बिना तेज़ी से प्रोडक्ट बनाने में मदद मिलनी चाहिए थी.

2026 में हमारा काफ़ी फ़ोकस इसी पर रहा है. हमने रीड परफ़ॉर्मेंस बेहतर बनाने के लिए कई लेवल्स पर काम करने का तरीका तैयार किया है. Habitat की 90% से ज़्यादा रिक्वेस्ट्स रीड रिक्वेस्ट्स होती हैं:

हमारे पास दुनिया भर के अलग-अलग Azure क्षेत्रों में कई Azure Cosmos DB अकाउंट हैं, जो उन यूज़र्स के लिए हैं जिन्हें डेटा रेज़िडेंसी की ज़रूरत है. जिन यूज़र्स के लिए डेटा रेज़िडेंसी की कोई सख़्त ज़रूरत नहीं होती है, उनके लिए भी, डेटा को यूज़र्स के पास रखने से लेटेंसी कम होती है और अनुभव बेहतर होता है.

असल में, डेटा रेज़िडेंसी वाले यूज़ केसेज़ के अलावा हम बड़े पैमाने पर ऐसा नहीं कर पाते, क्योंकि डेटा कहाँ रखा जा सकता है, यह क्लाउड की फ़िज़िकल कैपेसिटी पर निर्भर करता है. हमारे डेटासेट्स इतने बड़े हैं कि कई रीजन अपने हिस्से के यूज़र ट्रैफ़िक के लिए ज़रूरी भारी स्टोरेज कैपेसिटी उपलब्ध नहीं करा सकते.

जिन रीजन में डेटासेंटर कैपेसिटी, बिजली या कूलिंग की कमी होती है, वहाँ हमें कई बार दो ऑप्शन्स में से एक चुनना पड़ता है. या तो स्टोरेज को कंप्यूट के पास रखने के लिए कैपेसिटी बचाकर रखें, ताकि Habitat की लेटेंसी कम हो. या फिर उसी कैपेसिटी का इस्तेमाल अतिरिक्त कंप्यूट के लिए करें और स्टोरेज रिक्वेस्ट्स को दूर के रीजन में भेजें.

इसलिए डेटा और कंप्यूट कहाँ रखने हैं, यह तय करते समय अक्सर दो चीज़ों के बीच बैलेंस बनाना पड़ता है: A) अलग-अलग प्रोडक्ट्स और यूज़र ग्रुप्स के लिए लेटेंसी कम करना और B) उपलब्ध स्टोरेज व कंप्यूट कैपेसिटी का इस्तेमाल करना.

जिन वर्कलोड्स में कम लेटेंसी बेहद ज़रूरी है, जैसे हर रिक्वेस्ट के लिए इस्तेमाल होने वाला ऑथेंटिकेशन मेटाडेटा, उनके लिए हम कंप्यूट और Habitat के बीच RTT कम करते हैं. इसके लिए ऐसे Azure Cosmos DB अकाउंट्स इस्तेमाल किए जाते हैं, जिनका डेटा कई सेकंडरी रीजन में रेप्लिकेट होता है. कुछ अकाउंट्स का डेटा उन सभी 40 Azure रीजन में रेप्लिकेट होता है, जहाँ से हम ट्रैफ़िक सँभालते हैं. वहीं, कुछ का डेटा हर महाद्वीप में कम-से-कम एक रीजन में रेप्लिकेट होता है.

हमें तय समय से पहले ही Habitat में एक ऐसा डेटा मूवमेंट और रूटिंग लेयर बनाना पड़ा, जो बैकग्राउंड में काम करे. इससे हम अलग-अलग रेप्लिकेशन सेटअप वाले अकाउंट्स के बीच डेटासेट्स ट्रांसफ़र कर सकते हैं.

हालाँकि, यह तरीका भी आखिरकार कैपेसिटी कितनी है, इस पर निर्भर करता है. इसलिए हम इसे सिर्फ़ कुछ खास तौर पर चुने गए डेटासेट्स के लिए इस्तेमाल कर सकते हैं.

Habitat के ज़्यादातर वर्कलोड्स में डेटा रीड करने का काम होता है. ऐप्लिकेशन्स लगातार सेटिंग्स, स्टेट और दूसरी प्रॉपर्टीज़ का डेटा फ़ेच करती रहती हैं. कुल ट्रैफ़िक का बड़ा हिस्सा कुछ ही तरह के डेटा से आता है, जिसे बार-बार एक्सेस किया जाता है. इसलिए यह सिस्टम डिस्ट्रिब्यूटेड कैशिंग के लिए बहुत अच्छा है. कैशिंग से सिंगल-रीजन इंफ़्रास्ट्रक्चर में परफ़ॉर्मेंस बेहतर होती है, लेकिन कई रीजन में इसका फ़ायदा और बढ़ जाता है. इससे अलग-अलग रीजन के बीच डेटा एक्सेस करने में लगने वाला अतिरिक्त समय लगभग छिपाया जा सकता है.

हमने Habitat में डिस्ट्रिब्यूटेड लुकअसाइड कैशिंग लेयर जोड़ी है. यह हाल ही में एक्सेस किए गए ऑब्जेक्ट्स और एजेज़ की कॉपी Valkey सर्वर्स में स्टोर करती है. ये सर्वर्स हमारे इंफ़्रास्ट्रक्चर में उन जगहों के करीब हैं, जहाँ यूज़र्स की रिक्वेस्ट्स प्रोसेस होती हैं. आम तौर पर इस तरह की कैशिंग में TTL का इस्तेमाल होता है, जहाँ कैश हिट रेट और पुराने डेटा मिलने की संभावना के बीच बैलेंस बनाना पड़ता है. कम TTL रखने से पुराना डेटा मिलने की संभावना घटती है, लेकिन कैशिंग का फ़ायदा भी कम हो जाता है. ऐसा इसलिए, क्योंकि डेटा जल्दी एक्सपायर हो जाता है और उसे बार-बार दोबारा फ़ेच करना पड़ता है. ज़्यादा TTL रखने से कैश हिट रेट बेहतर होता है, लेकिन लंबे समय तक पुराना डेटा मिल सकता है. इससे यूज़र एक्सपीरियंस खराब होता है और प्रोडक्ट का व्यवहार उम्मीद से अलग हो सकता है.

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

हमने कैश इनवैलिडेशन के लिए Meta के TAO जैसे सिस्टम्स से सीखते हुए एक ज़्यादा एडवांस्ड तरीका अपनाया है. Habitat का इंटीग्रेटेड कैश, Azure Cosmos DB के चेंज फ़ीड के ज़रिए चेंज डेटा कैप्चर (CDC) का इस्तेमाल करता है. इससे डेटा में बदलाव होने पर कुछ ही सेकंड में दुनिया भर के कैश को इनवैलिडेशन की जानकारी भेजी जा सकती है. इस तरह कैश हिट रेट अच्छा रहता है और पुराना डेटा मिलने की संभावना कम होती है. हमारे इंफ़्रास्ट्रक्चर की एक सर्विस इस चेंज फ़ीड को पढ़ती है और मुख्य डेटा अपडेट होने पर लोकल कैश में मौजूद पुरानी कॉपी को इनवैलिडेट कर देती है. इससे अगली बार डेटा रीड करने पर कैश मिस होता है और कैश में डेटा का नया वर्ज़न स्टोर हो जाता है.

हमने Habitat सर्विस के कोड को Rust में दोबारा लिखकर अतिरिक्त प्रोसेसिंग का लोड भी कम किया है. Rust में लिखा कोड पहले इस्तेमाल किए गए Python कोड के मुकाबले बेहतर परफ़ॉर्म करता है. इससे लेटेंसी में काफ़ी कमी आई है.

इन सभी बदलावों से हमारी कुल ग्लोबल रीड p50 लेटेंसी लगभग 120 मिलीसेकंड से घटकर 10 मिलीसेकंड रह गई है. इस साल की शुरुआत में परफ़ॉर्मेंस बेहतर बनाने पर फ़ोकस करने के बाद से यह 12x सुधार है.

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

भरोसेमंद और बड़े पैमाने पर काम करने वाला CDC, यानी डेटाबेस में हुए बदलावों की जानकारी आगे के सिस्टम्स तक पहुँचाना, सिर्फ़ Habitat की कैशिंग स्ट्रैटेजी के लिए ही नहीं, बल्कि कई दूसरे कामों के लिए भी अहम है. हज़ारों कंटेनर्स और लाखों कंटेनर पार्टिशन्स में हर सेकंड लाखों बदलाव कैप्चर होते हैं. यह डेटा 100 से ज़्यादा Kafka टॉपिक्स से होकर गुज़रता है और सेकंडरी इंडेक्सेस, डेटा मूवमेंट पाइपलाइन्स, ऑफ़लाइन एनालिटिक्स और दूसरे रियल-टाइम प्रोडक्ट फ़ीचर्स को सपोर्ट करता है. इन सेकंडरी इंडेक्सेस में डेटा थोड़ी देरी से अपडेट हो सकता है. जैसे-जैसे हमारा इंफ़्रास्ट्रक्चर दुनिया भर में बढ़ा है, डेटाबेस की रो में होने वाले बदलावों को ट्रैक करना मुश्किल होता गया है. अगर कोई क्लाइंट चाहता है कि उसकी किसी खास तरह की रो बदलने पर एक कॉलबैक चले, तो उसे कई बातें पता करनी होंगी. जैसे, उसका डेटा किन Cosmos अकाउंट्स और कंटेनर्स में है, संबंधित रीजन में कौन-सा CDC सर्विस डिप्लॉयमेंट उन कंटेनर्स के बदलाव ट्रैक कर रहा है और CDC सर्विस वर्कर्स, Kafka व डेटा इस्तेमाल करने वाले सिस्टम की कैपेसिटी कैसे बढ़ानी है. हमारा CDC प्लेटफ़ॉर्म इन सभी मुश्किल कामों को प्रोडक्ट डेवलपर्स से अलग रखना चाहता है. डेवलपर्स को सिर्फ़ एक आसान इंटरफ़ेस मिलता है, जहाँ वे रो में बदलाव होने पर चलने वाला फ़ंक्शन रजिस्टर करते हैं. बाकी कनेक्शन, प्रोसेसिंग और स्केलिंग हम सँभालते हैं.

हमारा इंटरनल कंट्रोल प्लेन लगातार यह देखता है कि सभी ज़रूरी कंटेनर्स में होने वाले बदलाव कैप्चर हो रहे हैं या नहीं. यह तय करता है कि किन Cosmos रीजन से डेटा पढ़ना है और अलग-अलग रीजन में मौजूद हज़ारों वर्कर्स के बीच काम बेहतर तरीके से बाँटता है. रेप्लिका रीजन और कम प्रायोरिटी वाली फ़ीड रीड्स का इस्तेमाल करके हम बैकग्राउंड में चलने वाले डेटा कैप्चर वर्कलोड्स से Habitat के उन ट्रैफ़िक को बचाते हैं, जिनके लिए कम लेटेंसी ज़रूरी है. इतने बड़े सिस्टम में वर्कर्स का क्रैश होना, कंटेनर से जुड़ी समस्याएँ, लीज़-स्टोर एरर्स, गलत कॉन्फ़िगरेशन और डेटा भेजने में फ़ेलियर लगातार होते रहते हैं. हमने CDC वर्कर्स के लाइफ़साइकल और लीज़ हैंडलिंग को ज़्यादा भरोसेमंद बनाया, अलग-अलग स्ट्रीम्स की समस्याओं को एक-दूसरे से अलग रखा और कॉन्फ़िगरेशन में बदलाव व रोलआउट के लिए सुरक्षा के उपाय जोड़े. हम डेड लेटर क्यूज़ का इस्तेमाल करते हैं, ताकि किसी मैसेज की डिलीवरी बार-बार फ़ेल होने से उसके पीछे मौजूद दूसरे मैसेज रुक न जाएँ. किसी रीजन में आउटेज होने पर हम डेटा रीड करने वाले वर्कर्स को दूसरे Cosmos रीजन में शिफ़्ट कर देते हैं. हमारे सिस्टम के इतने बड़े पैमाने पर काम करने की वजह से हमें Azure के CDC SDK में भी बदलाव करने पड़े. चेकपॉइंटिंग को ज़्यादा एफ़िशिएंट बनाने के लिए हम चेकपॉइंट्स को पहले मेमोरी में बैच करते हैं और फिर समय-समय पर उन्हें स्टोरेज में लिखते हैं.

Habitat के अंदर Azure Cosmos DB का इस्तेमाल काफ़ी मुश्किल और कई लेवल्स पर होता है. लेकिन Habitat का मकसद हमेशा से इंफ़्रास्ट्रक्चर की टेक्निकल डिटेल्स को प्रोडक्ट डेवलपर्स से दूर रखना रहा है, ताकि वे तेज़ी से प्रोडक्ट्स बना सकें. हमारा CDC प्लेटफ़ॉर्म भी इसी सोच पर काम करता है.

एक छोटी टीम भी तेज़ी से बढ़ते स्टोरेज प्लेटफ़ॉर्म को सपोर्ट कर पाई, क्योंकि हमने स्टोरेज API का दायरा जानबूझकर सीमित रखा, Python सर्विस की कैपेसिटी लगातार बढ़ाई और सबसे ज़रूरी इंजीनियरिंग चैलेंज को पहले हल किया. हमारा फ़ोकस पहले प्रोडक्ट्स के सबसे अहम ट्रैफ़िक को भरोसेमंद तरीके से सँभालने पर था. इसके बाद दुनिया भर के यूज़र्स के लिए रीड परफ़ॉर्मेंस बेहतर बनाई और आखिर में बड़े पैमाने पर ऑपरेशन्स को ज़्यादा एफ़िशिएंट बनाया. इस तरीके से हम भरोसेमंद परफ़ॉर्मेंस, स्पीड और प्रोडक्ट डेवलपमेंट की रफ़्तार बेहतर बनाते हुए तेज़ी से बढ़ पाए और नए यूज़ केसेज़ सपोर्ट कर सके.

अगले एक अरब यूज़र्स के लिए Habitat और बातचीत के स्टोरेज को बढ़ाने के लिए, हमें अपने इंफ़्रास्ट्रक्चर में अपने डेटा को और भी बड़े पैमाने पर कॉपी करने की मुश्किल को हल करना होगा. इसे रोकने के लिए, हम एक कस्टम इन-हाउस एक्साबाइट-स्केल ऑनलाइन स्टोरेज सिस्टम बना रहे हैं, जिसे Habitat के बड़े साइज़ वाले डेटा टाइप के लिए ऑप्टिमाइज़ किया गया है. यह इन-डेवलपमेंट सिस्टम Rockset के RocksDB Cloud कोर को Raft-बेस्ड रेप्लिकेशन के साथ जोड़ता है. यह Azure Cosmos DB जैसा ही डॉक्यूमेंट मॉडल लागू करता है, लेकिन कम पीक qps के बदले में, ज़रूरी फ़्लैश कैपेसिटी की मात्रा को कम करने के लिए डिसएग्रीगेटेड स्टोरेज और फ़िज़िकल रेप्लिकेशन का इस्तेमाल करता है.

अगर आप इतने बड़े और अत्याधुनिक स्तर पर डेटा इंफ़्रास्ट्रक्चर से जुड़े काम करना चाहते हैं, तो हमारे यहाँ नौकरी के मौजूदा मौकों⁠ को देखें.