प्रश्न और यह कब लागू होता है
एक कंट्रोल-प्लेन API हेल्थ चेक, कंट्रोलर राइट्स, टेनेंट क्वेरीज़ और लंबे समय तक चलने वाले वॉचेस को सर्व करता है। ट्रैफ़िक में अचानक उछाल या कोई एक अधिक शोर करने वाला टेनेंट (noisy tenant) हर अनुरोध को धीमा कर सकता है। प्राथमिकता और निष्पक्षता नियंत्रण डिज़ाइन करें, और बताएं कि वर्गीकरण, कॉनक्रेन्सी सीमाएं, कतारें, टाइमआउट और डिग्रेडेशन एक साथ कैसे काम करते हैं।
साक्षात्कारकर्ता क्या मूल्यांकन करता है
- "महत्वपूर्ण" को टीम के स्थायी विशेषाधिकार के बजाय ऑडिट करने योग्य अनुरोध श्रेणियों में बदलना।
- केवल इनग्रेस रेट लिमिटर के बजाय सीट्स, कतारों और कोटा के साथ कंट्रोल प्लेन की सुरक्षा करना।
- निष्पक्षता ग्रैन्युलैरिटी, लंबे अनुरोधों का ऑक्यूपेंसी प्रभाव, टेनेंट आइसोलेशन और विफलता डिग्रेडेशन को स्पष्ट करना।
- लेटेंसी, रिजेक्शन रेट, कतार की आयु (queue age), और कंट्रोलर रिकवरी समय के साथ डिज़ाइन को सत्यापित करना।
उत्तर देने से पहले स्पष्टीकरण हेतु प्रश्न
- कौन से अनुरोध सुरक्षा की दृष्टि से महत्वपूर्ण राइट्स (writes) हैं, और किन रीड्स या वॉचेस में देरी की जा सकती है?
- क्या निष्पक्षता की गणना टेनेंट, पहचान (identity), वर्कलोड या रिसोर्स प्रकार के आधार पर की जाती है? क्या आपातकालीन एडमिन पाथ की अनुमति है?
- क्या आप API सर्वर, डाउनस्ट्रीम स्टोरेज, या दोनों की सुरक्षा कर रहे हैं?
- क्या लंबे अनुरोध कई सीट्स का उपभोग करते हैं, और डिस्कनेक्ट होने पर सीट्स कैसे रिलीज़ होती हैं?
- क्या ओवरलोड होने पर 429 लौटाया जा सकता है, या सिस्टम को न्यूनतम सफलता दर और पुनः प्रयास (retry) सिग्नल बनाए रखना चाहिए?
30-सेकंड का उत्तर ढांचा
मैं पहचान, मेथड और रिसोर्स के आधार पर अनुरोधों को बाउंडेड प्राथमिकता प्रवाहों (flows) में मैप करूँगा, फिर प्रत्येक प्रवाह को कॉनक्रेन्सी सीट्स और एक निष्पक्ष कतार दूंगा। उच्च प्राथमिकता को बाउंडेड बेसलाइन क्षमता मिलती है; दबाव के तहत कम प्राथमिकता वाले अनुरोध कतारबद्ध होते हैं या अस्वीकार कर दिए जाते हैं। लंबे अनुरोधों को अलग से वर्गीकृत किया जाता है और निरंतर ऑक्यूपेंसी के लिए चार्ज किया जाता है। प्रत्येक अस्वीकृति में एक कार्रवाई योग्य पुनः प्रयास संकेत होता है। मैं p99 लेटेंसी, कतार की आयु, 429 दर, डाउनस्ट्रीम संतृप्ति (saturation), और महत्वपूर्ण कंट्रोलर्स के लिए रिकवरी समय के आधार पर रोलआउट को नियंत्रित करूँगा।
चरण-दर-चरण गहन विश्लेषण
चरण 1: स्पष्ट करने योग्य अनुरोध श्रेणियां बनाएं
सत्यापन योग्य पहचान, HTTP मेथड, लक्षित रिसोर्स और लंबे समय तक चलने की स्थिति के आधार पर वर्गीकरण करें। क्लाइंट्स को कोई भी मनमाना "उच्च प्राथमिकता" फ़ील्ड सबमिट न करने दें। कंट्रोलर राइट्स, नोड हार्टबीट्स, एडमिन क्वेरीज़ और बल्क लिस्ट्स को अलग-अलग प्रवाहों में विभाजित करें, और मैचिंग नियम को लॉग करें।
चरण 2: क्षमता को सीट्स के रूप में मॉडल करें
सीट्स केवल अनुरोधों की संख्या के बजाय एक साथ सेवा देने की क्षमता का प्रतिनिधित्व करती हैं। एक तेज़ रीड एक सीट का उपभोग कर सकता है; एक धीमी क्वेरी या वॉच को अधिक की आवश्यकता हो सकती है। पूरा होने या रद्द होने पर सीट्स को रिलीज़ करें। प्रत्येक प्राथमिकता को एक नाममात्र सीमा दें जबकि एक वैश्विक सीट कैप बनाए रखें ताकि बेसलाइन सुरक्षित क्षमता से अधिक न हो सके।
चरण 3: प्रत्येक प्राथमिकता के भीतर निष्पक्ष कतार लागू करें
एक प्राथमिकता के भीतर, टेनेंट या फ्लो पहचान द्वारा की (key) की गई वेटेड फेयर कतार (weighted fair queue) का उपयोग करें ताकि एक टेनेंट पूरी श्रेणी को न भर सके। ऐसे गैर-रिक्त प्रवाह को प्रेषित (dispatch) करें जो अपनी वर्तमान सीमा से नीचे है। उम्र बढ़ने (aging) से बार-बार विलंबित अनुरोध का भार बढ़ सकता है, लेकिन इसे वैश्विक सीट कैप को बायपास नहीं करना चाहिए।
चरण 4: लंबे अनुरोधों और निर्भरताओं को संभालें
वॉचेस और लॉग टेल्स को अलग बजट, अधिकतम अवधि और हार्टबीट रद्दीकरण दें। स्टोरेज, कैश और बाहरी सेवाओं के चारों ओर स्वतंत्र कॉनक्रेन्सी बल्कहेड्स लगाएं; इनग्रेस कतार को डाउनस्ट्रीम पर असीमित दबाव स्थानांतरित नहीं करना चाहिए। केवल पुनः प्रयास करने योग्य विफलताओं का ही पुनः प्रयास करें, वह भी एक्सपोनेंशियल बैकऑफ और जिटर के साथ।
चरण 5: ओवरलोड कार्रवाइयों को परिभाषित करें
जैसे-जैसे दबाव बढ़ता है, नए कम प्राथमिकता वाले कार्य को रोकें, फिर बल्क लिस्ट्स और महंगे फ़िल्टरों को प्रतिबंधित करें, और अंत में जब कोई अनुरोध कतार में न जा सके तो 429 लौटाएं। प्रतिक्रिया में स्पष्ट प्रतीक्षा संकेत शामिल करें; क्लाइंट्स को अभी भी पुनः प्रयास कैप, जिटर और समय सीमा (deadlines) की आवश्यकता होती है। यदि कोई महत्वपूर्ण राइट नहीं छोड़ा जा सकता है, तो इसे एक ड्यूरेबल कतार में रखें और एक क्वेरी करने योग्य ऑपरेशन आईडी लौटाएं।
चरण 6: केवल औसत लेटेंसी ही नहीं, निष्पक्षता का भी अवलोकन करें
प्राथमिकता, टेनेंट और अनुरोध प्रकार के अनुसार p50, p99, कतार की आयु, सीट ऑक्यूपेंसी, 429s, रद्दीकरण और डाउनस्ट्रीम त्रुटियों की निगरानी करें। अधिकतम प्रतीक्षा, महत्वपूर्ण-राइट सफलता, रिकवरी समय और टेनेंट्स के बीच सेवा असमानता पर अलर्ट सेट करें। लोड परीक्षणों में सिंगल-टेनेंट बर्स्ट्स, लंबे अनुरोधों द्वारा सीट की कमी, गलत वर्गीकरण और कंट्रोलर रिकवरी शामिल होनी चाहिए।
चरण 7: सुरक्षित रूप से विकसित और रोलबैक करें
सीमाएं लागू करने से पहले केवल-अवलोकन (observe-only) मोड में नए वर्गीकरण मिलानों को रिकॉर्ड करें। कॉन्फ़िगरेशन को वर्शन और ऑडिट करें, और एक सीमित परिचालन पाथ बनाए रखें। जब सीट्स या प्राथमिकताएं बदलती हैं, तो डाउनस्ट्रीम क्षमता और ऐतिहासिक कतार वितरण की तुलना करें; केवल API-परत मेट्रिक्स पर निर्भर न रहें।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं कंट्रोल-प्लेन क्षमता को एक वैश्विक सीट पूल के रूप में मॉडल करूँगा। अनुरोध पहचान, मेथड, रिसोर्स और लंबे समय तक चलने वाले गुणों का उपयोग करके प्राथमिकता प्रवाहों में मैप होते हैं। कंट्रोलर राइट्स और नोड हार्टबीट्स को बेसलाइन सीट्स मिलती हैं, लेकिन बेसलाइन्स का योग सुरक्षित क्षमता से कम रहता है। सामान्य टेनेंट रीड्स एक वेटेड फेयर कतार साझा करते हैं। वॉचेस के लिए अलग से शुल्क लिया जाता है और उनकी अधिकतम अवधि होती है; रद्दीकरण पर सीट्स तुरंत रिलीज़ हो जाती हैं। ओवरलोड के दौरान, बल्क रीड्स को रोकें, महंगे फ़िल्टरों को सीमित करें, और जब कार्य कतार में न जा सके तो प्रतीक्षा संकेत के साथ 429 लौटाएं। जिन राइट्स को पूरा होना ही चाहिए वे एक ड्यूरेबल कतार में जाते हैं। लागू करने से पहले, मैं वर्गीकरण मिलान और टेनेंट कतार की आयु को मापूँगा; रोलआउट के बाद, महत्वपूर्ण-राइट सफलता, p99, 429s, डाउनस्ट्रीम संतृप्ति और रिकवरी समय रोलबैक के निर्णय बिंदु (gates) बन जाते हैं।
सामान्य गलतियाँ
- केवल एक वैश्विक QPS सीमा निर्धारित करना, जिससे लंबे अनुरोधों को कॉनक्रेन्सी समाप्त करने की अनुमति मिल जाती है।
- किसी एडमिन या टेनेंट को असीमित प्राथमिकता देना और गैर-ऑडिट योग्य भुखमरी (starvation) उत्पन्न करना।
- रीड्स, लिस्ट्स और वॉचेस को अलग-अलग मॉडल किए बिना केवल अनुरोध संख्या के आधार पर शुल्क लेना।
- प्रत्येक क्लाइंट को 429 का तुरंत पुनः प्रयास करने के लिए बाध्य करना और एक सिंक्रनाइज़्ड रिट्राय स्टॉर्म उत्पन्न करना।
- केवल औसत लेटेंसी को देखना और कम प्राथमिकता वाली कतारों के अधिकतम प्रतीक्षा समय को छोड़ देना।
- बिना कैनरी, वर्शन या रोलबैक पाथ के सीमाओं को बदलना।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: केवल टोकन बकेट का उपयोग क्यों नहीं किया जाता?
टोकन बकेट आगमन दर (arrival rate) को सीमित करता है लेकिन विभिन्न कॉनक्रेन्सी लागतों, लंबे अनुरोधों के ऑक्यूपेंसी, या टेनेंट निष्पक्षता को व्यक्त नहीं करता है। यह एक इनग्रेस परत हो सकती है, लेकिन सीट्स और कतारों की अभी भी आवश्यकता है।
फॉलो-अप 2: क्या उच्च प्राथमिकता कम प्राथमिकता को भूखा (starve) रख सकती है?
हाँ, जब तक कि उच्च प्राथमिकता की भी सीमाएं न हों और सिस्टम आरक्षित शेयर, अधिकतम निरंतर सेवा, या उम्र बढ़ने (aging) को लागू न करे। एक आपातकालीन पाथ को हमेशा ऑडिटेड और क्षमता-सीमित रहना चाहिए।
फॉलो-अप 3: एक वॉच को कितनी सीट्स का उपभोग करना चाहिए?
इसका कोई सार्वभौमिक स्थिरांक नहीं है। कनेक्शन, इवेंट दर, सीरियलाइज़ेशन लागत और डाउनस्ट्रीम क्वेरी दबाव को मापें, एक रूढ़िवादी बेसलाइन चुनें, और लोड परीक्षणों के साथ कैलिब्रेट करें। टाइमआउट और डिस्कनेक्ट पर सीट्स रिलीज़ होनी चाहिए।
फॉलो-अप 4: 429 पुनः प्रयास समय कौन तय करता है?
सर्वर अपेक्षित रिकवरी के आधार पर न्यूनतम प्रतीक्षा संकेत प्रदान करता है; क्लाइंट एक्सपोनेंशियल बैकऑफ, जिटर और एक डेडलाइन जोड़ता है। यह संकेत क्षमता की गारंटी नहीं है, इसलिए क्लाइंट्स अभी भी प्रयासों को सीमित रखते हैं।
फॉलो-अप 5: आप निष्पक्षता कैसे साबित करते हैं?
एक प्राथमिकता के भीतर सीट शेयर, अधिकतम कतार आयु और समापन दर जैसे टेनेंट-स्तरीय उद्देश्यों को परिभाषित करें। केवल एक वैश्विक माध्य की रिपोर्ट करने के बजाय सिंगल-टेनेंट बर्स्ट और मिश्रित लोड के दौरान वितरण की तुलना करें।
फॉलो-अप 6: क्या होगा यदि कोई नियम किसी महत्वपूर्ण राइट को गलती से कम प्राथमिकता के रूप में वर्गीकृत कर दे?
नियम-मिलान लॉग और मानवीय समीक्षा बनाए रखें, और कॉन्फ़िगरेशन को एक वर्शन वाले आर्टिफ़ैक्ट के रूप में शिप करें। यदि महत्वपूर्ण-राइट सफलता दर गिरती है, तो वर्गीकरण वर्शन को तुरंत रोलबैक करें और कतारबद्ध कार्य के लिए एक सीमित सुरक्षा पाथ का उपयोग करें।