प्रतिनिधि इंटरव्यू विषय

System Design Interview: आप एक Progressive Delivery Controller को कैसे डिज़ाइन करेंगे?

सिस्टम डिज़ाइनकठिन
Offer.cc संपादकीय टीमप्रकाशित अपडेट किया गया

प्रश्न

एक कंपनी दिन में सैकड़ों बार डिप्लॉय करती है। एक नए वर्शन को 1% ट्रैफ़िक प्राप्त होना चाहिए, फिर यह क्रमशः 5%, 25%, 50%, और 100% तक आगे बढ़ना चाहिए। जब त्रुटियों, टेल लेटेंसी (tail latency), या किसी महत्वपूर्ण बिज़नेस मेट्रिक में गिरावट (regression) आए, तो कंट्रोलर को स्वचालित रूप से पॉज़ या रोलबैक करना होगा। इसे मैन्युअल अप्रूवल, इन-फ़्लाइट रिलीज़ की जगह नए रिलीज़ का आना, रीजनल अंतर और ऑडिटेबिलिटी का समर्थन करना चाहिए। सिस्टम को डिज़ाइन करें और कंसिस्टेंसी, मेट्रिक विंडोज़, रोलबैक बाउंड्रीज़ और विफलताओं की व्याख्या करें।

प्रॉम्प्ट और स्कोप

यह रिलीज़-कंट्रोल-प्लेन की समस्या है, न कि केवल एक Deployment की रेप्लिकेट काउंट को कई बार बदलना। कंट्रोलर वांछित वर्शन, वर्तमान चरण (step), ट्रैफ़िक वेट, एनालिसिस परिणाम और मानवीय निर्णयों को रिकॉर्ड करता है, फिर डेटा प्लेन में क्रियाओं को विश्वसनीयता से दर्शाता है। Google SRE एक कैनरी को आंशिक, समय-सीमित डिप्लॉयमेंट और मूल्यांकन के रूप में परिभाषित करता है। Kubernetes RollingUpdate बुनियादी उपलब्धता प्रदान करता है; प्रोग्रेसिव डिलीवरी ट्रैफ़िक-आधारित विश्लेषण, पॉज़, अप्रूवल और स्वचालित रोलबैक जोड़ती है।

इंटरव्यूअर क्या टेस्ट कर रहा है

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

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

  • क्या ट्रैफ़िक को रिक्वेस्ट, यूज़र, रीजन या रेप्लिका द्वारा विभाजित किया जाता है? क्या स्थिर बकेटिंग आवश्यक है?
  • कौन से मेट्रिक्स हार्ड गेट्स हैं और कौन से ऑब्ज़र्वेशन हैं? एरर बजट और न्यूनतम सैंपल कैसे परिभाषित किए जाते हैं?
  • क्या रोलबैक केवल ट्रैफ़िक को शिफ्ट करता है, या कैनरी को रोकता और स्केल डाउन भी करता है? डेटाबेस और मैसेज फॉर्मेट्स कैसे अनुकूल हैं?
  • क्या स्टेप्स ऑटोमैटिक हैं या मैन्युअल रूप से अप्रूव किए जाते हैं? अप्रूवल कैसे ऑथराइज़ किया जाता है?
  • क्या रीजन एक साथ आगे बढ़ते हैं, स्वतंत्र रूप से, या एक रीजनल विफलता ग्लोबल रोलआउट को रोक देती है?

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

“मैं रिलीज़ को स्टेप्स, टारगेट वेट्स, पॉज़ पॉलिसी, एनालिसिस टेम्पलेट, टाइमआउट और रोलबैक वर्शन वाली एक ड्यूरेबल स्टेट मशीन के रूप में मॉडल करूँगा। एक आइडम्पोटेंट रिकॉन्सिल लूप वर्कलोड और रूटिंग पर वांछित स्टेट लागू करता है, फिर वास्तविक स्टेट और वर्शन-स्कोप वाले मेट्रिक्स को पढ़ता है। प्रमोशन के लिए पर्याप्त सैंपल्स, एक पूरी विंडो, एरर, टेल-लेटेंसी और बिज़नेस गार्डरेल्स को पास करना आवश्यक है; मेट्रिक सोर्स गायब होने पर यह डिफ़ॉल्ट रूप से पॉज़ हो जाता है। प्रत्येक एक्शन में एक रिलीज़ और स्टेप वर्शन होता है, जिससे रीस्टार्ट सुरक्षित रूप से कन्वर्ज होते हैं। अप्रूवल्स, पॉज़, रोलबैक और रूटिंग परिवर्तन एक ऑडिट ट्रेल बन जाते हैं।”

गहन उत्तर

स्टेप 1: रिसोर्सेज़ और स्टेट्स को परिभाषित करें

एक रिलीज़ रिसोर्स में release_id, कैंडिडेट और स्टेबल वर्शन्स, स्टेप्स, वर्तमान स्टेप, टारगेट वेट, एनालिसिस टेम्पलेट, पॉज़ का कारण, टाइमआउट और रोलबैक पॉलिसी शामिल होती है। स्टेट्स PENDING, RUNNING, PAUSED, PROMOTING, ABORTING, SUCCEEDED, और FAILED हो सकती हैं। प्रत्येक ट्रांज़िशन के लिए स्पष्ट प्री-कंडीशन्स और आइडम्पोटेंट प्रभावों की आवश्यकता होती है।

स्टेप 2: कंट्रोल और डेटा प्लेन को अलग करें

कंट्रोल प्लेन वांछित स्टेट और एनालिसिस निष्कर्षों को स्टोर करता है; डेटा प्लेन Pods, Services, Ingress, या सर्विस मेश चलाता है। एक सफल API राइट रोलआउट की सफलता नहीं है। उपलब्ध रेप्लिका, वास्तविक वेट, रेडिनेस और वर्शन लेबल्स का निरीक्षण करें। Kubernetes maxUnavailable और maxSurge रिप्लेसमेंट को सीमित करते हैं, न कि रिक्वेस्ट-लेवल कैनरी ट्रैफ़िक को।

स्टेप 3: स्थिर ट्रैफ़िक एलोकेशन डिज़ाइन करें

एक कंसिस्टेंट रिक्वेस्ट या यूज़र की (key) का उपयोग करें ताकि एक ही यूज़र कैनरी और कंट्रोल के बीच न भटके। रूटिंग लेयर वास्तविक वेट्स और वर्शन-हिट काउंट्स की रिपोर्ट करती है। कई रीजन्स के लिए, प्रति रीजन टारगेट और वास्तविक वेट स्टोर करें; एक ग्लोबल औसत को 100% विफलता वाले किसी एक रीजन को छिपाना नहीं चाहिए।

स्टेप 4: एनालिसिस विंडोज़ और गार्डरेल्स को परिभाषित करें

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

स्टेप 5: रिकवरेबल रिकॉन्सिल लागू करें

कंट्रोलर अगले एक एक्शन की गणना करने के लिए रिलीज़, वर्कलोड, रूट और एनालिसिस परिणाम को समय-समय पर पढ़ता है। बाहरी राइट्स में release_id और स्टेप वर्शन शामिल होते हैं, ताकि दोबारा प्रयास करने पर नियम या अप्रूवल डुप्लिकेट न हों। रीस्टार्ट के बाद, यह पर्सिस्टेड और ऑब्ज़र्व्ड स्टेट से कन्वर्ज होता है। यदि वास्तविक वेट भिन्न होता है, तो प्रमोशन से पहले पॉज़ करें और ठीक करें।

स्टेप 6: पॉज़, अप्रूवल्स और टाइमआउट को संभालें

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

स्टेप 7: रोलबैक और कम्पैटिबिलिटी बाउंड्रीज़ डिज़ाइन करें

रोलबैक आमतौर पर पहले ट्रैफ़िक को स्टेबल वर्शन में शिफ्ट करता है, फिर यह तय करता है कि कैनरी को रोकना है या स्केल डाउन करना है। डेटाबेस माइग्रेशन, इवेंट स्कीमा और कैश फॉर्मेट्स को दोनों वर्शन्स के लिए एक ओवरलैप विंडो की आवश्यकता होती है; बाइनरी को रिवर्ट करने से इरिवर्सिबल राइट्स को पूर्ववत नहीं किया जा सकता है। रोलबैक स्वयं आइडम्पोटेंट, ऑब्ज़र्वेबल होना चाहिए और पिछले स्टेबल वर्शन को बनाए रखना चाहिए।

स्टेप 8: सत्यापित करें, ऑडिट करें और रिहर्सल करें

प्रमोशन, रूटिंग वेट्स, मेट्रिक ग्रुपिंग, पॉज़, कंट्रोलर रीस्टार्ट, मेट्रिक आउटेज, रीजनल आउटेज, डुप्लिकेट वेबहुक्स, और वर्तमान रिलीज़ की जगह नए रिलीज़ के आने का परीक्षण करें। वांछित और वास्तविक स्टेट, कर्ता (actor), समय, कारण और मेट्रिक स्नैपशॉट का ऑडिट करें। अभ्यास को यह साबित करना होगा कि एक खराब सिग्नल विस्तार को रोकता है, न कि केवल यह कि एक API ने 200 लौटाया।

ट्रेड-ऑफ़ और सीमाएं

नेटिव RollingUpdate बनाम एक प्रोग्रेसिव कंट्रोलर

RollingUpdate उन सर्विसेज़ के लिए उपयुक्त है जिन्हें क्रमिक रेप्लिका रिप्लेसमेंट और रेडिनेस चेक की आवश्यकता होती है। ट्रैफ़िक, बिज़नेस मेट्रिक्स, अप्रूवल और स्वचालित रोलबैक के लिए अतिरिक्त कंट्रोलर या प्लेटफ़ॉर्म क्षमता की आवश्यकता होती है; रेप्लिका प्रतिशत रिक्वेस्ट प्रतिशत नहीं होता है।

ऑटोमैटिक रोलबैक बनाम मानवीय निर्णय

हार्ड गेट्स उच्च-विश्वास वाली, तेज़ी से पता चलने योग्य विफलताओं के लिए उपयुक्त हैं। विलंबित या अस्पष्ट बिज़नेस मेट्रिक्स के लिए, ऑटोमेशन को पॉज़ करना चाहिए और एक ओनर को सूचित करना चाहिए। पॉलिसी में अंतिम स्टॉप अथॉरिटी का नाम होना चाहिए।

ग्लोबल बनाम रीजनल प्रोग्रेशन

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

फ़ेलियर ड्रिल्स और इवोल्यूशन

विफलता: कैनरी रेप्लिका अनुपात को ट्रैफ़िक अनुपात मानना

रेप्लिका काउंट रिक्वेस्ट काउंट नहीं है; कनेक्शन रीयूज़ और रीजनल ट्रैफ़िक वास्तविक वेट को प्रभावित करते हैं। रूटिंग लेयर पर एलोकेट करें और हिट्स रिकॉर्ड करें।

विफलता: मेट्रिक्स गायब होने पर प्रमोट करना

क्वेरी डिले, लेबल एरर्स या छोटे सैंपल्स खाली परिणाम दे सकते हैं। गायब डेटा पर पॉज़ करें और रिकवरी के बाद एक पूरी विंडो फिर से बनाएं।

विफलता: केवल एप्लिकेशन इमेज को रोलबैक करना

इरिवर्सिबल स्कीमा, इवेंट या कैश राइट्स पुराने वर्शन को अपठनीय बना सकते हैं। रोलआउट से पहले कम्पैटिबिलिटी गेट्स जोड़ें और डेटा रेमेडिएशन से पहले ट्रैफ़िक को शिफ्ट करें।

सामान्य गलतियाँ और फ़ॉलो-अप

गलती: स्टेट मशीन को केवल कंट्रोलर मेमोरी में रखना

रीस्टार्ट होने पर स्टेप्स, अप्रूवल और रोलबैक वर्शन खो जाते हैं। रिलीज़ रिसोर्सेज़ और ऑडिट इवेंट्स को पर्सिस्ट करें; मेमोरी केवल एक कैश है।

फ़ॉलो-अप: आप एक पुराने कंट्रोलर को नए रिलीज़ को ओवरराइट करने से कैसे रोकते हैं?

कंडीशनल अपडेट्स के साथ रिसोर्स और स्टेप वर्शन्स का उपयोग करें। राइट्स से पहले दोबारा पढ़ें और वर्शन बदलने पर पुरानी क्रियाओं को रोकें।

फ़ॉलो-अप: आप एक साथ दो रिलीज़ को कैसे संभालते हैं?

एक सर्विस या रूट म्यूटेक्स (mutex) का उपयोग करें, या कैंडिडेट्स के बीच ट्रैफ़िक बजट को स्पष्ट रूप से विभाजित करें। दो कंट्रोलर्स को स्वतंत्र रूप से एक वेट में बदलाव नहीं करना चाहिए।

फ़ॉलो-अप: औसत लेटेंसी सामान्य होने पर भी p99 क्यों ख़राब हो सकता है?

औसत गंभीर रूप से धीमी रिक्वेस्ट्स के एक छोटे समूह को छिपा देता है। समान वर्शन, रीजन और डिनॉमिनेटर के साथ टेल लेटेंसी और एरर्स की तुलना करें।

फ़ॉलो-अप: यदि मेट्रिक्स सिस्टम डाउन हो तो क्या होगा?

वर्तमान वेट को बनाए रखते हुए पॉज़ करें और ANALYSIS_UNAVAILABLE मार्क करें। रिकवरी के बाद विंडो को फिर से चलाएँ; डेटा गायब होना सफलता नहीं है।

फ़ॉलो-अप: आप स्वयं कंट्रोलर को कैसे मापते हैं?

स्टेप ड्वेल टाइम, वास्तविक बनाम टारगेट वेट एरर, फ़ाल्स रोलबैक रेट, डिटेक्शन डिले, रिकवरी टाइम, ऑडिट कंप्लीटनेस और मैन्युअल ओवरराइड्स को ट्रैक करें।

सार्वजनिक स्रोत

संबंधित प्रश्न

संबंधित इंटरव्यू टूल

सिस्टम डिज़ाइन उत्तर के लिए हल करें का उपयोग करें

पहले आवश्यकताओं को स्पष्ट करें, फिर स्केल, आर्किटेक्चर, कंपोनेंट चयन और ट्रेड-ऑफ की ओर बढ़ें।

टूल देखें