सिस्टम डिज़ाइन इंटरव्यू: एक सर्विस डिस्कवरी सिस्टम डिज़ाइन करें

समस्या और दायरा

3 रीजन्स में फैली 2,000 लॉजिकल सर्विसेज और 100,000 डायनामिक इंस्टेंसेस के लिए एक इंटरनल सर्विस डिस्कवरी सिस्टम डिज़ाइन करें। कंटेनर रीशेड्यूलिंग, ऑटोस्केलिंग और रोलिंग डिप्लॉयमेंट्स लगातार एड्रेस बदलते रहते हैं। एक बड़ा डिप्लॉयमेंट 2 मिनट में 10,000 एंडपॉइंट्स को बदल सकता है। कॉलर कई प्रोग्रामिंग भाषाओं का उपयोग करते हैं, इसलिए हर टीम से एक परिष्कृत (sophisticated) डिस्कवरी SDK बनाए रखने की अपेक्षा नहीं की जा सकती।

यह समस्या दो डेडलाइन्स को अलग करती है। कंट्रोल प्लेन द्वारा किसी इंस्टेंस के सेवा से बाहर जाने के जानबूझकर किए गए ट्रांज़िशन को देखे जाने के बाद, उस अवलोकन से लेकर नए ट्रैफ़िक को रोकने तक का p99 अधिकतम 3 सेकंड है। यदि कोई प्रोसेस या नोड बिना किसी सूचना के गायब हो जाता है, तो हार्ड-फेलियर डिटेक्शन का p99 अधिकतम 15 सेकंड है। 10 मिनट के डिस्कवरी कंट्रोल-प्लेन आउटेज के दौरान मौजूदा कॉल्स को अंतिम-ज्ञात (last-known) एंडपॉइंट्स के साथ जारी रहना चाहिए। इसका यह अर्थ नहीं है कि आउटेज के दौरान नए इंस्टेंस दिखाई देने लगेंगे या कैश्ड इंस्टेंस जीवित रहेंगे।

सर्विस की संख्या, इंस्टेंस की संख्या, रीजन की संख्या, डिप्लॉयमेंट का आकार और SLOs इंटरव्यू की धारणाएं हैं। दायरे में रजिस्ट्रेशन, लीज, हेल्थ स्टेट, एंडपॉइंट क्वेरी और इंक्रीमेंटल डिलीवरी, कैशिंग, ड्रेनिंग, मल्टी-रीजन व्यवहार और सत्यापन शामिल हैं। रिक्वेस्ट बैलेंसिंग को केवल वहीं कवर किया गया है जहाँ डिस्कवरी को इसकी आवश्यकता है; बिज़नेस APIs, एक पूर्ण सर्विस-मेश डेटा प्लेन और पब्लिक DNS दायरे से बाहर हैं। यह system-design है क्योंकि मुख्य कार्य एक कंट्रोल प्लेन, प्रॉक्सीज, हेल्थ सिग्नल्स और एंड-टू-एंड ट्रैफ़िक व्यवहार तक फैला हुआ है।

इंटरव्यूअर्स क्या मूल्यांकन करते हैं

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

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

तीसरा सिग्नल यह स्वीकार करना है कि डिस्कवरी की जानकारी हमेशा बासी (stale) हो सकती है। DNS TTLs, प्रॉक्सी कैशे, वॉच डिले, विफलता का पता लगाना और रोलिंग शटडाउन समय के अंतराल (windows) बनाते हैं। एक मजबूत उत्तर यह परिभाषित करता है कि कौन सा इवेंट प्रत्येक क्लॉक को शुरू करता है, जानबूझकर हटने (deliberate withdrawal) और हार्ड विफलता के लिए अलग-अलग SLOs असाइन करता है, और जांच की आवृत्ति (probe cadence), थ्रेशोल्ड और प्रोपेगेशन का बजट बनाता है। “मजबूत कंसिस्टेंसी मृत इंस्टेंसेस को कॉल करने से रोकती है” विभाजनों (partitions) और रीड के तुरंत बाद किसी इंस्टेंस के विफल होने की उपेक्षा करता है।

अंत में, इंटरव्यूअर बड़े पैमाने (scale) और परिचालन निर्णय (operational judgment) की तलाश करता है। यदि 100,000 इंस्टेंसेस हर 10 सेकंड में सीधे लीज रिन्यू करते हैं, तो रोलआउट परिवर्तनों और वॉच फैनआउट से पहले रजिस्ट्री को प्रति सेकंड 10,000 रिन्यूअल प्राप्त होते हैं। डिज़ाइन में केवल Consul, etcd या Kubernetes का नाम लेने के बजाय राइट एम्प्लीफिकेशन, रीकनेक्ट स्टॉर्म, पूर्ण स्नैपशॉट, रीजनल फेलियर डोमेन और खराब हेल्थ चेक को नियंत्रित करना चाहिए।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

• रजिस्ट्रेशन ट्रूथ का स्रोत क्या है? यदि कोई ऑर्केस्ट्रेटर पॉड लाइफसाइकिल का मालिक है, तो एक कंट्रोलर को रजिस्ट्रेशन उत्पन्न करना चाहिए। वर्कलोड पहचान वाला एक लोकल एजेंट VMs या बाहरी प्रक्रियाओं को रजिस्टर कर सकता है। अनअथेंटिकेटेड सेल्फ़-रजिस्ट्रेशन की अनुमति देने से कैटलॉग दूषित हो जाता है।
• 3-सेकंड की क्लॉक कब शुरू होती है? यहाँ यह तब शुरू होती है जब कंट्रोल प्लेन READY से DRAINING या not-ready को स्वीकार करता है। यदि कोई एप्लिकेशन रिपोर्ट करने से पहले फ़्रीज़ हो जाती है, तो हार्ड-फेलियर डिटेक्शन इसे संभालता है।
• 15-सेकंड का लक्ष्य कितने गलत निष्कासनों (false removals) को सहन कर सकता है? लगातार तीन विफलताएं क्षणिक पैकेट-नुकसान त्रुटियों को कम करती हैं, लेकिन 5-सेकंड का अंतराल और टाइमआउट लगभग पूरे बजट का उपभोग कर लेते हैं। पैसिव त्रुटि दर, रीजनल अतिरिक्त क्षमता और पुष्टि की समय-सीमा (confirmation windows) इस विकल्प को बदल देते हैं।
• क्या कॉलर्स को इंस्टेंस एड्रेस की आवश्यकता है या एक स्थिर सर्विस एड्रेस की? एक स्थिर VIP के लिए DNS प्लस प्लेटफ़ॉर्म लोड बैलेंसिंग सबसे सरल है। जब कॉलर्स को वर्ज़न, रीजन या शार्ड मेटाडेटा की आवश्यकता होती है, तो एक प्रॉक्सी या क्लाइंट डिस्कवरी अधिक उपयुक्त होती है।
• क्या कंट्रोल-प्लेन आउटेज फ़ेल ओपन होता है या फ़ेल क्लोज़्ड? सामान्य आंतरिक सेवाएं अंतिम-ज्ञात स्नैपशॉट से जारी रह सकती हैं। सुरक्षा निरस्तीकरण (security revocation) और हार्ड आइसोलेशन एक पुराने डिस्कवरी कैश पर निर्भर नहीं हो सकते; एक स्वतंत्र पहचान और प्राधिकरण लेयर को उन्हें अस्वीकार करना चाहिए।
• क्या स्वचालित क्रॉस-रीजन फ़ेलओवर की अनुमति है? स्टेटलेस रीड्स नीति के अनुसार फ़ेलओवर हो सकते हैं। डेटा रेजिडेंसी, सिंगल-राइटर स्टेट, या उच्च क्रॉस-रीजन लागत को स्पष्ट रूप से लक्ष्य सेट को प्रतिबंधित करना चाहिए।

30-सेकंड का उत्तर

“मैं एक रीजनल कंट्रोल प्लेन और लोकल डेटा प्लेन का निर्माण करूँगा। एक ऑर्केस्ट्रेटर या प्रमाणित एजेंट इंस्टेंसेस को STARTING, READY, DRAINING, UNHEALTHY, और EXPIRED स्टेट्स वाले एक शार्ड किए गए कैटलॉग में लिखता है। केवल READY ही रूटेबल है। ग्रेसफुल शटडाउन कनेक्शन ड्रेन होने से पहले DRAINING में प्रवेश करता है। एक रीजनल लीडर मोनोटोनिक रिवीज़न के साथ परिवर्तनों को क्रमित करता है। एक डिस्ट्रीब्यूशन टियर 5,000 नोड प्रॉक्सीज को डेल्टा भेजता है, और जब कोई प्रॉक्सी रिवीज़न गैप का पता लगाती है, तो वह एक पूर्ण स्नैपशॉट प्राप्त करती है।

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

स्टेप-बाय-स्टेप डीप डाइव

स्टेप 1: डेटा मॉडल और स्टेट मशीन को परिभाषित करें

कैटलॉग की में कम से कम नेमस्पेस, सर्विस का नाम और पोर्ट का नाम शामिल होता है ताकि वातावरण और प्रोटोकॉल आपस में न टकराएं। एक एंडपॉइंट में एक स्थिर इंस्टेंस ID, एड्रेस, रीजन, ज़ोन, वर्ज़न, वेट, कैपेबिलिटी लेबल्स, स्टेट, लीज समाप्ति और रिवीज़न शामिल होता है। केवल पूर्वनिर्धारित लेबल डाइमेंशन की अनुमति है; मनमाना हाई-कार्डिनैलिटी डेटा डिस्कवरी प्लेन से संबंधित नहीं है।

एक स्टेट मशीन एकल healthy बूलियन की तुलना में अधिक अर्थ रखती है। STARTING को कोई ट्रैफ़िक प्राप्त नहीं होता है। READY नए ट्रैफ़िक को स्वीकार करता है। DRAINING मौजूदा कनेक्शन समाप्त होने के दौरान नए अनुरोधों को रोकता है। UNHEALTHY एक सक्रिय या निष्क्रिय विफलता निर्णय को दर्शाता है। EXPIRED का अर्थ है कि लीज रिन्यू नहीं की गई थी। प्रत्येक ट्रांज़िशन अपने कारण, स्रोत और मोनोटोनिक रिवीज़न को रिकॉर्ड करता है ताकि आउट-ऑफ़-ऑर्डर अपडेट्स ऑडिट करने योग्य हों।

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

स्टेप 2: प्रत्येक भाषा में जटिलता की नकल किए बिना एक डिस्कवरी पैटर्न चुनें

DNS प्लस एक स्थिर VIP तब काम करता है जब कॉलर्स को केवल एक सर्विस नाम की आवश्यकता होती है और प्लेटफ़ॉर्म पहले से ही एंडपॉइंट्स और हेल्थ को संभालता है। DNS के माध्यम से सीधे इंस्टेंस एड्रेस लौटाना सरल है, लेकिन TTL क्वेरी लोड और स्टेल समय के बीच एक ट्रेडऑफ़ बनाता है। छोटे TTL को अनदेखा करने वाले क्लाइंट्स जोखिम को बढ़ाते हैं।

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

यदि प्रत्येक वर्कलोड पहले से ही Kubernetes पर चलता है, तो Service, DNS, और EndpointSlice आमतौर पर बुनियादी डिस्कवरी को कवर करते हैं। दूसरी रजिस्ट्री बनाने से प्लेटफ़ॉर्म का दोहराव होगा। केवल वास्तविक क्रॉस-VM, क्रॉस-क्लस्टर, उन्नत राउटिंग या नीतिगत आवश्यकता के लिए एक अलग कंट्रोल प्लेन पेश करें, और ऑर्केस्ट्रेटर एंडपॉइंट ट्रूथ का उपभोग करने को प्राथमिकता दें।

स्टेप 3: स्टेल रीड्स की अनुमति देते हुए राइट्स को क्रमित करें

रजिस्ट्रेशन और स्टेट ट्रांज़िशन के लिए सर्वसम्मति लीडर (consensus leader) का उपयोग करते हुए, प्रति रीजन 3 या 5 कैटलॉग रेप्लिकास डिप्लॉय करें। सर्विस की या टेनेंट द्वारा शार्ड करें ताकि एक ग्लोबल लीडर सभी 100,000 इंस्टेंसेस का मालिक न हो। रीजन्स में प्रत्येक राइट को सिंक्रोनस रूप से रेप्लिकेट न करें; एक रिमोट विभाजन स्वस्थ रीजन्स को ब्लॉक नहीं करना चाहिए। ग्लोबल लेयर सर्विस नीति और अनुमत फ़ेलओवर गंतव्यों को सिंक्रनाइज़ करती है।

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

रीड पाथ उपलब्धता के बदले सीमित बासीपन (bounded staleness) का आदान-प्रदान करता है। एक प्रॉक्सी स्नैपशॉट की आयु, अंतिम कंट्रोल-प्लेन संपर्क और वॉच लैग को रिकॉर्ड करता है। यह सामान्य आयु बजट से परे अलर्ट करता है लेकिन फिर भी बताए गए 10-मिनट के आउटेज के दौरान अंतिम सेट का उपयोग करता है। यदि प्रत्येक ज्ञात एंडपॉइंट विफल हो जाता है, तो यह किसी भी रीजन में चुपचाप नीति को बायपास करने के बजाय एक स्पष्ट 'no-backend' परिणाम देता है।

स्टेप 4: जानबूझकर हटने (deliberate withdrawal) को हार्ड-फेलियर डिटेक्शन से अलग करें

ग्रेसफुल शटडाउन के लिए, एप्लिकेशन पहले रेडीनेस वापस लेता है। कैटलॉग DRAINING में प्रवेश करता है, और प्रोपेगेशन के बाद प्रॉक्सीज उस एंडपॉइंट को चुनना बंद कर देती हैं। प्रोसेस बाहर निकलने से पहले अधिकतम कनेक्शन-ड्रेन अवधि तक प्रतीक्षा करती है। एप्लिकेशन नया काम स्वीकार करना भी बंद कर देता है क्योंकि डिस्कवरी प्रोपेगेशन तात्कालिक नहीं होता है; पुरानी प्रॉक्सीज या लंबे समय तक चलने वाले कनेक्शन अभी भी इसका एड्रेस रख सकते हैं।

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

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

स्टेप 5: राइट, परिवर्तन और फ़ैनआउट लोड की गणना करें

यदि 100,000 इंस्टेंसेस हर 10 सेकंड में सीधे रिन्यू होते हैं, तो स्थिर अवस्था (steady state) प्रति सेकंड 10,000 रिन्यूअल है। प्रति-इंस्टेंस हार्टबीट्स पर एक ऑर्केस्ट्रेटर वॉच को प्राथमिकता दें, या रैंडमाइज्ड जिटर के साथ नोड एजेंटों के माध्यम से रिन्यूअल को एकत्रित करें। लीज समाप्ति छोड़े गए रिकॉर्ड के लिए एक सुरक्षा जाल बनी हुई है, सामान्य रूप से हटने का मार्ग नहीं।

2 मिनट में 10,000 एंडपॉइंट्स को बदलने पर औसतन प्रति सेकंड लगभग 83 जोड़ और 83 निष्कासन होते हैं, या लगभग 167 सदस्यता परिवर्तन होते हैं। प्रत्येक परिवर्तन को सभी 5,000 नोड प्रॉक्सीज पर स्वतंत्र रूप से भेजने से प्रति सेकंड लगभग 835,000 डिलीवरी तक का लोड उत्पन्न होगा। वास्तविक सब्सक्रिप्शन प्रत्येक प्रॉक्सी की आवश्यकता वाली सेवाओं के अनुसार फ़िल्टर करते हैं, छोटी अवधियों में समान-सेवा परिवर्तनों को संयोजित (coalesce) करते हैं, और पदानुक्रमित वितरण (hierarchical distribution) का उपयोग करते हैं। इस संयोजन को 3-सेकंड के विड्रॉल SLO को एक मिनट के बैच में नहीं बदलना चाहिए।

पूर्ण स्नैपशॉट को भी एक बजट की आवश्यकता होती है। प्रति एंडपॉइंट 256 बाइट्स के एक उदाहरणात्मक सीरियलाइज़्ड आकार पर, एक ग्लोबल 100,000-एंडपॉइंट स्नैपशॉट लगभग 24.4 MiB है। एक सामान्य प्रॉक्सी केवल सब्सक्राइब की गई सेवाओं को प्राप्त करता है, न कि ग्लोबल कैटलॉग को। रीकनेक्ट जिटर के साथ एक्सपोनेंशियल बैकऑफ़ का उपयोग करता है, और डिस्ट्रीब्यूटर एक छोटा डेल्टा लॉग बनाए रखते हैं ताकि रिकवरी के बाद 5,000 प्रॉक्सीज एक साथ पूर्ण स्नैपशॉट का अनुरोध न करें।

स्टेप 6: रीजन और सुरक्षा सीमाओं को परिभाषित करें

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

सर्विस नीति यह घोषित करती है कि क्या क्रॉस-रीजन राउटिंग की अनुमति है, केवल-पढ़ने या लिखने योग्य व्यवहार, लक्ष्य क्रम, क्षमता सीमाएं और डेटा सीमाएं। स्पष्ट नीति ग्लोबल फ़ेलओवर को ट्रिगर करती है। स्टेटलेस रीड्स तेज़ी से स्विच कर सकते हैं; सिंगल-राइटर डेटाबेस के लिए एक प्रॉक्सी को पहले स्वामित्व हस्तांतरण (ownership transfer) स्थापित करना होगा। डिस्कवरी उम्मीदवार पते लौटाती है और किसी बिज़नेस कंसिस्टेंसी प्रोटोकॉल को प्रतिस्थापित नहीं कर सकती है।

रजिस्ट्रेशन, डीरजिस्ट्रेशन और वॉच के लिए वर्कलोड पहचान और न्यूनतम विशेषाधिकार (least privilege) की आवश्यकता होती है, जिसमें कैटलॉग परिवर्तन ऑडिट लॉग में होते हैं। प्रॉक्सीज कंट्रोल प्लेन को प्रमाणित करती हैं, और संवेदनशील सेवाएं डिस्कवरी को म्यूचुअल TLS के साथ जोड़ सकती हैं। एंडपॉइंट लेबल्स विश्वसनीय प्राधिकरण दावे नहीं हैं; कॉलर अभी भी कनेक्शन या अनुरोध के समय सर्विस पहचान और अनुमति को मान्य करते हैं।

स्टेप 7: टाइमलाइन और फॉल्ट इंजेक्शन के साथ सत्यापित करें

पहले रोलिंग रिप्लेसमेंट का परीक्षण करें। पुराना इंस्टेंस रेडीनेस वापस लेता है। रिकॉर्ड करें कि कैटलॉग कब रिवीज़न स्वीकार करता है, प्रॉक्सी इसे कब लागू करता है, अंतिम नया अनुरोध कब आता है, और प्रक्रिया कब समाप्त होती है। नया इंस्टेंस स्टार्टअप और रेडीनेस के बाद ही सेट में प्रवेश करता है। सक्रिय-विड्रॉल प्रोपेगेशन p99 3 सेकंड से कम, इन-फ़्लाइट कार्य के पूरा होने और नॉट-रेडी इंस्टेंसेस पर शून्य ट्रैफ़िक का दावा करें।

फिर डीरजिस्ट्रेशन के बिना किसी प्रोसेस को समाप्त (kill) करें और सत्यापित करें कि 5-सेकंड की जांच, विफलता सीमा और वितरण मिलकर 15-सेकंड के p99 को पूरा करते हैं। एक प्रॉक्सी नेटवर्क फॉल्ट, एक संपूर्ण-नोड विफलता, लैगिंग कैटलॉग फॉलोअर्स, लीडर परिवर्तन, रीजनल कोरम हानि, एक डेल्टा गैप, एक दूषित स्नैपशॉट और 10-मिनट के कंट्रोल-प्लेन आउटेज को इंजेक्ट करें। रिकवरी जिटर के साथ फिर से जुड़ती है और पूर्ण-स्नैपशॉट भगदड़ (stampede) का कारण नहीं बनती है।

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

एक मजबूत नमूना उत्तर

“मैं रजिस्ट्रेशन ट्रूथ, हेल्थ निर्णय, डिस्कवरी डिलीवरी और रिक्वेस्ट राउटिंग को अलग करता हूँ। एक रीजनल कंसिस्टेंसी समूह प्रमाणित इंस्टेंस परिवर्तनों को स्वीकार करता है। प्रत्येक रिकॉर्ड में एक सर्विस की, इंस्टेंस ID, स्टार्ट जेनरेशन, एड्रेस, रीजन, वर्ज़न, स्टेट, लीज और रिवीज़न होता है। केवल READY ही रूटेबल सेट में प्रवेश करता है। शटडाउन DRAINING में चला जाता है, नए ट्रैफ़िक को रोकता है, ड्रेन करता है, फिर बाहर निकलता है। हार्ड विफलताएं प्रोब और लीज समाप्ति का उपयोग करती हैं। पैसिव त्रुटियां स्थानीय रूप से बाहर निकालती हैं और तुरंत ग्लोबल ट्रूथ नहीं बनती हैं।

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

हर 10 सेकंड में रिन्यू होने वाले एक लाख इंस्टेंस प्रति सेकंड 10,000 राइट्स उत्पन्न करेंगे, इसलिए मैं ऑर्केस्ट्रेटर वॉच या नोड एग्रीगेशन को प्राथमिकता देता हूँ। 2 मिनट में 10,000 एंडपॉइंट्स को बदलने से प्रति सेकंड लगभग 167 जोड़ने और हटाने के परिवर्तन होते हैं। सब्सक्रिप्शन द्वारा फ़िल्टर करें, संक्षेप में संयोजित करें, और 3-सेकंड के विड्रॉल बजट का उपभोग किए बिना पदानुक्रमित रूप से वितरित करें। हर 5 सेकंड में जांच करना और 3 विफलताओं की आवश्यकता पहले से ही 15 सेकंड के करीब पहुंच जाती है, इसलिए टाइमआउट और प्रोपेगेशन बजट का हिस्सा हैं।

मैं ट्रैफ़िक टाइमलाइन के माध्यम से सत्यापित करता हूँ: स्वीकृत विड्रॉल के 3 सेकंड के भीतर कोई नया अनुरोध नहीं, और एक हार्ड-क्रैश एंडपॉइंट 15 सेकंड के भीतर उम्मीदवार सेट को छोड़ देता है। मौजूदा ट्रैफ़िक लीडर परिवर्तन, एक रीजनल विभाजन और 10-मिनट के कंट्रोल-प्लेन स्टॉप के दौरान जारी रहता है। अंत में, 5,000 प्रॉक्सी जिटर के साथ फिर से जुड़ते हैं, रिवीज़न गैप भरते हैं, और कैटलॉग पर भारी पड़े बिना कन्वर्ज होते हैं।”

सामान्य गलतियाँ

• प्रत्येक अनुरोध से पहले रजिस्ट्री से क्वेरी करना → कंट्रोल-प्लेन की देरी या विफलता बिज़नेस पाथ में प्रवेश करती है → वर्ज़न्ड एंडपॉइंट्स को स्थानीय रूप से कैश करें और बैकग्राउंड में परिवर्तन प्राप्त करें।
• एक एकल healthy बूलियन का उपयोग करना → स्टार्टअप, ट्रैफ़िक प्रवेश, ड्रेनिंग और पुनरारंभ सिमेंटिक्स आपस में मिल जाते हैं → ट्रांज़िशन स्रोतों के साथ एक स्पष्ट स्टेट मशीन का उपयोग करें।
• रेडीनेस विफलता पर पुनरारंभ (restart) करना → एक डाउनस्ट्रीम आउटेज पूरे सर्विस फ़्लीट को पुनरारंभ कर सकता है → रेडीनेस ट्रैफ़िक को हटाती है; लाइवनेस केवल अप्राप्य स्थानीय विफलता को कवर करती है।
• यह मान लेना कि एक छोटा DNS TTL बासी डेटा को समाप्त कर देता है → क्लाइंट कैशे, प्रोपेगेशन और डिटेक्शन अभी भी एक विंडो बनाते हैं जबकि क्वेरी लोड बढ़ता है → TTL ट्रेडऑफ़ को मापें और डेटा-प्लेन लचीलापन बनाए रखें।
• अनअथेंटिकेटेड सेल्फ़-रजिस्ट्रेशन की अनुमति देना → गलत या दुर्भावनापूर्ण एंडपॉइंट्स आंतरिक ट्रैफ़िक प्राप्त कर सकते हैं → ऑर्केस्ट्रेटर ट्रूथ या विवश वर्कलोड पहचान का उपयोग करें।
• प्रत्येक प्रॉक्सी को ग्लोबल कैटलॉग की सदस्यता देना → डिप्लॉयमेंट्स और रीकनेक्ट्स फ़ैनआउट और स्नैपशॉट स्टॉर्म बनाते हैं → सर्विस द्वारा फ़िल्टर करें, पदानुक्रमित रूप से वितरित करें, डेल्टा को वर्ज़न करें, और रीकनेक्ट्स में जिटर जोड़ें।
• रीजन्स में प्रत्येक हार्टबीट को दृढ़ता से रेप्लिकेट करना → रिमोट लेटेंसी या विभाजन स्वस्थ रीजन्स को ब्लॉक करता है → राइट्स को क्षेत्रीय रूप से क्रमित करें और केवल नीति और अनुमत फ़ेलओवर मेटाडेटा को सिंक्रनाइज़ करें।
• डिस्कवरी सफलता को अनुरोध सफलता मानना → लुकअप के तुरंत बाद एक एंडपॉइंट विफल हो सकता है → कॉल प्रोटोकॉल को अभी भी कनेक्शन टाइमआउट, बाउंडेड रीट्राय, सर्किट ब्रेकिंग और आइडेम्पोटेंसी की आवश्यकता है।
• हेल्थ के लिए प्रत्येक डिपेंडेंसी की जांच करना → एक साझा आउटेज एक साथ सभी इंस्टेंसेस को हटा देता है → शॉर्ट टाइमआउट और जिटर के साथ केवल महत्वपूर्ण ट्रैफ़िक-प्रवेश स्थितियों की जांच करें।

फॉलो-अप प्रश्न और उत्तर

फॉलो-अप 1: सभी 100,000 इंस्टेंसेस को सीधे क्लाइंट-साइड डिस्कवरी का उपयोग करने की अनुमति क्यों नहीं दी जाती?

क्लाइंट-साइड डिस्कवरी एक हॉप को हटा देती है और विस्तृत राउटिंग को सक्षम बनाती है, लेकिन यह वॉचेस, कैशे, रिवीज़न रिपेयर, बैलेंसिंग, इजेक्शन और अपग्रेड को हर भाषा और प्रक्रिया में कॉपी करती है। पॉलीग्लॉट टीमों के साथ, नोड प्रॉक्सी 100,000 क्लाइंट कनेक्शन को लगभग 5,000 डेटा-प्लेन इंस्टेंसेस तक कम कर देती हैं। बेहद कड़े लेटेंसी बजट वाला एक परिपक्व रनटाइम एक अनिवार्य SDK को उचित ठहरा सकता है, लेकिन फिर भी इसे प्रोटोकॉल अनुरूपता परीक्षण और अनिवार्य अपग्रेड की आवश्यकता होती है।

फॉलो-अप 2: कंट्रोल-प्लेन आउटेज के दौरान पुराने एंडपॉइंट्स का उपयोग करना सुरक्षित क्यों है?

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

फॉलो-अप 3: क्या 5-सेकंड के प्रोब और 3 विफलताएं वास्तव में 15 सेकंड को पूरा करती हैं?

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

फॉलो-अप 4: रोलिंग डिप्लॉयमेंट को तत्काल हटाने के बजाय DRAINING की आवश्यकता क्यों होती है?

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

फॉलो-अप 5: जब एक क्षेत्र कोरम खो देता है तो क्या दूसरे क्षेत्र को रजिस्ट्रेशन स्वीकार करना चाहिए?

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