सिस्टम डिज़ाइन इंटरव्यू: आप कैनेरी एनालिसिस और रोलबैक सर्विस को कैसे डिज़ाइन करेंगे?

प्रॉम्प्ट और संदर्भ

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

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

इंटरव्यू लेने वाला क्या परख रहा है

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

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

क्या लक्ष्य एक सर्विस है, मल्टी-सर्विस ऑर्केस्ट्रेशन है, या केवल Kubernetes वर्कलोड्स हैं?
क्या ट्रैफ़िक रैंडम अनुरोध, स्थिर यूज़र हैश, क्षेत्र या टेनेंट द्वारा विभाजित है, और क्या यूज़र्स के लिए स्टिकिनेस बनाए रखना आवश्यक है?
कौन से SLOs मायने रखते हैं: त्रुटि दर, लेटेंसी, व्यावसायिक रूपांतरण, या लागत, और स्थिर बेसलाइन कैसे चुनी जाती है?
प्रत्येक चरण कब तक चल सकता है, कितनी विफलताओं पर रोलबैक ट्रिगर होता है, और क्या अनिश्चित विश्लेषण को मानव के लिए रोक दिया जाना चाहिए?
क्या डेटाबेस स्कीमा, संदेश प्रारूप और बाहरी APIs बैकवर्ड कम्पैटिबल हैं, और क्या पुराने वर्शन पर रोलबैक सुरक्षित है?

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

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

चरण-दर-चरण समाधान

चरण 1: लक्ष्य और पैमाना परिभाषित करें

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

सुरक्षा का लक्ष्य ब्लास्ट रेडियस को सीमित करना है। 1% → 5% → 25% → 50% → 100% जैसा एक कॉन्फ़िगर करने योग्य क्रम केवल उदाहरणात्मक है, सार्वभौमिक सीमा नहीं। प्रत्येक चरण के लिए न्यूनतम अवलोकन समय और अधिकतम प्रतीक्षा की आवश्यकता होती है ताकि कोई अनुपलब्ध सिग्नल हमेशा के लिए रिलीज़ स्लॉट पर कब्जा न कर ले।

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

कंट्रोल प्लेन रिलीज़ स्पेसिफिकेशन, वर्शन डाइजेस्ट, वर्तमान चरण, लक्षित वेट, एनालिसिस परिणाम और कर्ता (actor) को संग्रहीत करता है। डेटा प्लेन अनुरोधों को स्थिर या कैनेरी ReplicaSet पर रूट करने के लिए गेटवे या सर्विस मेश का उपयोग करता है। Argo Rollouts की वास्तुकला Rollout, दो वर्शन्ड ReplicaSets, Services/Ingress, और AnalysisTemplate/AnalysisRun को अलग करती है, जो उन सीमाओं को प्रदर्शित करती है जो स्वतंत्र रूप से विकसित हो सकती हैं।

मेट्रिक एडेप्टर केवल Prometheus जैसे प्रदाताओं के विरुद्ध क्वेरी चलाता है और उनकी समय विंडो के साथ अवलोकन लौटाता है। निर्णय इंजन नीतियां लागू करता है और सीधे रूट्स को संपादित नहीं करता है, इसलिए मेट्रिक्स बैकएंड को बदलने से रोलआउट स्टेट मशीन में कोई बदलाव नहीं होता है।

चरण 3: एक रिकवरेबल स्टेट मशीन बनाएं

Draft → Running → Paused → Promoting → Succeeded जैसी स्टेट्स का उपयोग करें, जिसमें Running या Paused से Aborting → RolledBack में जाने की क्षमता हो। प्रत्येक संक्रमण में एक rollout_id, वांछित वर्शन, चरण संख्या और आइडेम्पोटेंसी की होती है। एक अद्वितीय बाधा (unique constraint) या compare-and-set दो कंट्रोलर्स को एक ही रोलआउट को आगे बढ़ाने से रोकता है।

text

Running + analysis=success      -> Promoting(next_weight)
Running + analysis=failure      -> Aborting(weight=0)
Running + analysis=inconclusive -> Paused(reason=insufficient_signal)
Paused + operator=resume        -> Running
Aborting + route=stable          -> RolledBack

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

चरण 4: मेट्रिक्स और विंडो चुनें

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

विंडो को संग्रह विलंब को कवर करना चाहिए और चरण के टाइमआउट के भीतर रहना चाहिए। Google का SRE कैनेरी मार्गदर्शन कैनेरी की तुलना कंट्रोल से करता है और चेतावनी देता है कि एक संक्षिप्त कैनेरी चरण से लंबी मेट्रिक अवधि एक अस्पष्ट सिग्नल उत्पन्न करती है। छोटे नमूनों को अनिर्णायक चिह्नित करें; कमजोर साक्ष्य पर विस्तार करने से बेहतर है कि रोक दिया जाए।

चरण 5: ट्रैफ़िक विभाजन और स्टिकिनेस को संभालें

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

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

चरण 6: रोलबैक, पॉज़ और मानवीय हस्तक्षेप डिज़ाइन करें

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

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

चरण 7: विश्वसनीयता, अनुमतियाँ और ऑडिट

कंट्रोलर के लिए लीडर इलेक्शन या लीज का उपयोग करें। कतार वितरण कम से कम एक बार (at-least-once) हो सकता है, इसलिए उपभोक्ता आइडेम्पोटेंसी की द्वारा डिडुप्लिकेट करते हैं। रिलीज़ विनिर्देशों, नीति परिवर्तनों और अनुमोदनों को एक अपरिवर्तनीय ऑडिट लॉग में लिखें। केवल रिलीज़ के मालिक ही वेट बदलते हैं; मेट्रिक क्रेडेंशियल सीक्रेट मैनेजर से आते हैं; रोलबैक अनुमति सामान्य प्रमोशन से अलग होती है।

कंट्रोल-प्लेन SLOs को ट्रैक करें: ट्रांज़िशन लेटेंसी, अटके हुए रोलआउट, रोलबैक अवधि, वास्तविक-बनाम-वांछित वेट, और मेट्रिक-क्वेरी विफलताएं। जब कंट्रोल प्लेन विफल हो जाता है, तो अंतिम सुरक्षित रूट बनाए रखें और कैनेरी को स्वचालित रूप से 100% पर भेजने के बजाय किसी ऑपरेटर को पेज करें।

चरण 8: सत्यापन और लोड-टेस्ट

बढ़ती त्रुटि दर, कोई डेटा नहीं, विलंबित डेटा, राउटर टाइमआउट, कंट्रोलर रीस्टार्ट, डुप्लिकेट संदेश और असंगत डेटाबेस स्कीमा के लिए दोष (faults) इंजेक्ट करें। केवल सामान्य पथ की नहीं, बल्कि प्रत्येक दोष के लिए अंतिम स्थिति और अलर्ट की जांच करें।

एनालिसिस-क्वेरी लागत और कतार बैकलॉग को मापने के लिए ऐतिहासिक रिलीज़ को रीप्ले करें, और N+1 कंट्रोलर-विफलता परीक्षण चलाएं। उदाहरण लोड सीमा के रूप में एक सौ समवर्ती रोलआउट का उपयोग करें, स्टेट-स्टोर लॉक विवाद, मेट्रिक्स-प्रदाता QPS और रूट-अपडेट दर का निरीक्षण करें, फिर एक समवर्ती सीमा निर्धारित करें।

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

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

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

रोलआउट योजना और साक्ष्य

एक स्टेटलेस सर्विस के लिए केवल-पढ़ने के लिए विश्लेषण और मैनुअल पॉज़ से शुरू करें। stable/canary लेबल, मेट्रिक समूहीकरण और ऑडिट फ़ील्ड सत्यापित करें; फिर स्वचालित रोलबैक सक्षम करें; अंत में मल्टी-रीजन सिग्नल, व्यावसायिक मेट्रिक्स और एक समवर्ती सीमा जोड़ें। हर चरण में एक मानवीय किल स्विच और एक स्पष्ट मालिक रखें।

Google SRE कैनेरी को एक समय-सीमित, आंशिक परिनियोजन और मूल्यांकन के रूप में परिभाषित करता है और यह मांग करता है कि वह मूल्यांकन रिलीज़ प्रक्रिया को फ़ीड करे। Argo Rollouts AnalysisTemplate/AnalysisRun, मेट्रिक थ्रेशोल्ड और सफलता, विफलता और अनिर्णायक परिणाम प्रदान करता है। सार्वजनिक सिस्टम-डिज़ाइन इंटरव्यू सामग्री भी ट्रैफ़िक विभाजन, रेलिंग मूल्यांकन और स्वचालित रोलबैक को कैनेरी डिज़ाइन बिंदुओं के रूप में मानती है। इसलिए, Offer.cc का यह लेख परिनियोजन रणनीतियों की शब्दावली के बजाय एक रिकवरेबल कंट्रोल-प्लेन स्टेट मशीन पर केंद्रित है।

सामान्य गलतियाँ और अनुवर्ती प्रश्न

केवल "10% ट्रैफ़िक की निगरानी करें" कहना

जनसंख्या, अवधि, भाजक और विफलता कार्रवाई के बिना, सुरक्षा अप्रमाणित है। एक स्थिर बेसलाइन, विंडो, थ्रेशोल्ड, पॉज़ और रोलबैक पथ जोड़ें।

अनुपलब्ध मेट्रिक्स को सफलता मानना

एक कलेक्टर आउटेज एक स्वस्थ दिखने वाला सिग्नल बना सकता है। कोई डेटा नहीं, NaN, देरी और अपर्याप्त नमूनों को अनिर्णायक चिह्नित करें; रोकें और अलर्ट करें।

Deployment को रोलबैक करना लेकिन रूट को नहीं

स्वस्थ पुराने पॉड्स यह साबित नहीं करते कि अनुरोधों ने कैनेरी को छोड़ दिया है। प्रभावी वेट, सर्विस सिलेक्टर्स, और कैश या सेशन स्टिकिनेस सत्यापित करें।

डेटाबेस माइग्रेशन को अपरिवर्तनीय बनाना

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

यदि मेट्रिक्स प्रदाता डाउन हो तो क्या होगा?

अंतिम सुरक्षित वेट बनाए रखें, स्वचालित विस्तार रोकें, अधूरे विश्लेषण को रिकॉर्ड करें और मालिक को सूचित करें। रिकवरी के बाद, ड्यूरेबल स्टेट से फिर से शुरू करें; डिफ़ॉल्ट "पास" के साथ अंतर को कभी न भरें।