Kafka Streams को broker-driven rebalance protocol में कैसे माइग्रेट करना चाहिए?

प्रॉम्प्ट और दायरा

आपके पास क्लासिक ग्रुप प्रोटोकॉल का उपयोग करने वाला एक स्टेटफुल Kafka Streams एप्लिकेशन है। Kafka 4.2 में अपग्रेड करने के बाद, टीम ब्रोकर-ड्रिवन Streams Rebalance Protocol चाहती है ताकि इंस्टेंस के जुड़ने, हटने या फेल होने पर ग्लोबल कोऑर्डिनेशन पॉज़ को कम किया जा सके। इंटरव्यूअर आपसे माइग्रेशन प्लान, कम्पैटिबिलिटी बाउंड्री और रोलबैक के बारे में पूछता है।

मान लें कि Kafka Streams 4.2.x है, मौजूदा changelog और repartition टॉपिक्स मौजूद हैं, और कोई अनियोजित पूर्ण स्टेट रीबिल्ड नहीं है। आधिकारिक गाइड कहती है कि नया प्रोटोकॉल ब्रोकर्स पर लगातार टास्क असाइनमेंट की गणना करता है और एक डेडिकेटेड स्ट्रीम्स ग्रुप का उपयोग करता है। नए Kafka 4.2 क्लस्टर डिफ़ॉल्ट रूप से इस सुविधा को सक्षम करते हैं, लेकिन क्लाइंट अभी भी group.protocol=streams सेट करते हैं।

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

क्या आप किसी सेटिंग को केवल याद करके बोलने के बजाय यह समझाते हैं कि ब्रोकर-ड्रिवन कोऑर्डिनेशन क्लाइंट-साइड ग्लोबल बैरियर को कैसे हटाता है।
क्या आप एक नए स्ट्रीम्स ग्रुप, एक ऑनलाइन क्लासिक-ग्रुप अपग्रेड और समर्थित ऑफ़लाइन माइग्रेशन के बीच अंतर स्पष्ट करते हैं।
क्या आप ब्रोकर और क्लाइंट वर्शन और 4.2.0 में KAFKA-20254 जोखिम की जांच करते हैं।
क्या आप जानते हैं कि कमिटेड ऑफ़सेट सुरक्षित रहते हैं जबकि अन्य ग्रुप मेटाडेटा को रीबिल्ड किया जाता है।
क्या आप अनुपलब्ध स्टैटिक मेंबरशिप, टोपोलॉजी अपडेट और regex सपोर्ट को रिलीज़ गेट्स में बदलते हैं।

एक कमजोर उत्तर कहता है "सेटिंग बदलें और रोल आउट करें।" एक मजबूत उत्तर वर्शन और फीचर गैप्स का इन्वेंट्री लेता है, एक नए ग्रुप या मेंटेनेंस-विंडो माइग्रेशन का चयन करता है, और ऑफ़सेट, changelog, repartition टॉपिक्स और रिकवरी उद्देश्यों को रिकॉर्ड करता है।

उत्तर देने से पहले स्पष्टीकरण (Clarifications)

क्या Kafka और Streams क्लाइंट दोनों कम से कम 4.2 पर हैं? अन्यथा पूरे प्रोटोकॉल को सुरक्षित रूप से सक्षम नहीं किया जा सकता है।
क्या एप्लिकेशन स्टैटिक मेंबरशिप, ऑनलाइन टोपोलॉजी अपडेट, regex सब्सक्रिप्शन, या स्टैंडबाय/रैक-अवेयर असाइनमेंट पर निर्भर करता है? कोई भी निर्भरता माइग्रेशन को ब्लॉक कर सकती है।
क्या ग्रुप के खाली होने के दौरान प्रत्येक इंस्टेंस रुक सकता है? आधिकारिक 4.2 पाथ केवल ऑफ़लाइन माइग्रेशन का समर्थन करता है।
क्या वर्शन 4.2.0 है या 4.2.1 और बाद का है? 4.2.0 में ऑफ़लाइन माइग्रेशन में एक ज्ञात ब्रोकर बग है, जिसे 4.2.1 में ठीक किया गया है।
क्या एक नए application.id का उपयोग किया जा सकता है? एक नया ग्रुप जोखिम को अलग करता है लेकिन स्टेट को रीबिल्ड करता है और ऑफ़सेट मैनेजमेंट को बदलता है।

ये उत्तर योजना को बदल देते हैं: यदि डाउनटाइम असंभव है, तो ऑनलाइन माइग्रेशन का दावा न करें; यदि किसी असमर्थित सुविधा की आवश्यकता है, तो क्लासिक प्रोटोकॉल पर बने रहें या पहले रीफैक्टर करें।

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

"मैं पहले सत्यापित करता हूं कि ब्रोकर्स और क्लाइंट्स 4.2.x पर हैं और उन सुविधाओं की इन्वेंट्री करता हूं जिनका नया प्रोटोकॉल समर्थन नहीं करता है। Streams Rebalance Protocol टास्क कोऑर्डिनेशन को ब्रोकर्स पर ले जाता है और क्लाइंट-साइड ग्लोबल बैरियर को हटाता है, लेकिन यह माइग्रेशन एक सामान्य रोलिंग डिप्लॉयमेंट नहीं है। प्रलेखित पाथ ग्रुप को खाली करता है, group.protocol=streams सेट करता है, और इंस्टेंस शुरू करता है। केवल कमिटेड ऑफ़सेट सुरक्षित रहते हैं; changelog और repartition टॉपिक्स बने रहते हैं, जबकि अन्य ग्रुप मेटाडेटा रीबिल्ड होता है। मैं 4.2.0 से बचूंगा और 4.2.1 या बाद के वर्शन का उपयोग करूंगा, ऑफ़सेट और स्टेट चेकपॉइंट रिकॉर्ड करूंगा, रिकवरी, लेटेंसी और रीबैलेंस मेट्रिक्स को सत्यापित करूंगा, और यदि जांच विफल हो जाती है तो क्लासिक पर रोलबैक करूंगा या एक नए एप्लिकेशन आईडी के साथ रीबिल्ड करूंगा।"

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

1. समझाएं कि क्या बदलता है

क्लासिक Streams ग्रुप क्लाइंट्स पर मेंबर टास्क असाइनमेंट की गणना करते हैं, जो मेंबरशिप परिवर्तनों के दौरान एक ग्लोबल कोऑर्डिनेशन पॉइंट बना सकता है। नया प्रोटोकॉल स्ट्रीम्स-ग्रुप मेटाडेटा और टास्क असाइनमेंट को ब्रोकर्स पर स्टोर करता है; एप्लिकेशन एक डेडिकेटेड हार्टबीट और स्ट्रीम्स ग्रुप के माध्यम से समन्वय करते हैं। आधिकारिक गाइड इसे ब्रोकर-ड्रिवन बताती है और अलग स्ट्रीम्स-ग्रुप स्टेट्स और Admin APIs प्रदान करती है।

2. क्षमता अंतरालों (capability gaps) की इन्वेंट्री करें

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

3. माइग्रेशन पाथ चुनें

प्रलेखित ऑफ़लाइन पाथ है: प्रत्येक इंस्टेंस को रोकें, session.timeout.ms की प्रतीक्षा करें या स्पष्ट रूप से छोड़ दें ताकि ग्रुप खाली हो जाए, group.protocol=streams सेट करें, और इंस्टेंस शुरू करें। ब्रोकर पर केवल कमिटेड ऑफ़सेट बनाए रखे जाते हैं। Changelog और repartition टॉपिक्स सामान्य आंतरिक टॉपिक्स बने रहते हैं; अन्य ग्रुप मेटाडेटा को रीबिल्ड किया जाता है।

text

Stop all instances
      ↓
Confirm an empty streams group and record committed offsets
      ↓
Upgrade brokers and clients to a compatible version
      ↓
Set group.protocol=streams
      ↓
Start instances and observe recovery and rebalance metrics

यदि मेंटेनेंस विंडो अस्वीकार्य है, तो क्लासिक प्रोटोकॉल रखें या शैडो वैलिडेशन के लिए एक नए application.id का उपयोग करें। क्लासिक कंज्यूमर्स के रोलिंग-अपग्रेड मान्यताओं को Streams Rebalance Protocol पर स्थानांतरित न करें।

4. वर्शन जोखिम को संभालें

Kafka अपग्रेड गाइड चेतावनी देती है कि 4.2.0 में क्लासिक-टू-स्ट्रीम्स ऑफ़लाइन माइग्रेशन KAFKA-20254 ब्रोकर-साइड बग से प्रभावित है और इसके विरुद्ध अनुशंसा करती है। इसका फिक्स 4.2.1 में है। एक इंटरव्यू में, केवल यह कहने के बजाय कि "Kafka 4.2 इसका समर्थन करता है", 4.2.1 को न्यूनतम माइग्रेशन वर्शन बनाएं।

5. स्टेट और ऑफ़सेट जांच डिज़ाइन करें

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

6. मॉनिटर करें और रोल बैक करें

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

उच्च-गुणवत्ता वाला नमूना उत्तर

"मैं इसे एक सामान्य रोलिंग रिलीज़ के रूप में नहीं मानूंगा। सबसे पहले मैं 4.2.x ब्रोकर्स और क्लाइंट्स को सत्यापित करता हूं और स्टैटिक मेंबरशिप, ऑनलाइन टोपोलॉजी अपडेट, regex सब्सक्रिप्शन, वार्मअप, या रैक-अवेयर असाइनमेंट की जांच करता हूं। चूंकि आधिकारिक पाथ ऑफ़लाइन है, मैं 4.2.1 या बाद का वर्शन चुनता हूं, मेंटेनेंस विंडो में प्रत्येक इंस्टेंस को रोकता हूं, एक खाली ग्रुप की पुष्टि करता हूं, कमिटेड ऑफ़सेट और स्टेट-स्टोर चेकपॉइंट रिकॉर्ड करता हूं, और फिर group.protocol=streams सेट करता हूं।

"बदलाव के बाद मैं सत्यापित करता हूं कि ऑफ़सेट जारी रहते हैं, changelogs स्टेट स्टोर्स को रिस्टोर करते हैं, repartition टॉपिक्स बने रहते हैं, और स्ट्रीम्स-ग्रुप स्टेट, रीबैलेंस मेट्रिक्स, रिकवरी समय और बिज़नेस लेटेंसी सामान्य हैं। केवल कमिटेड ऑफ़सेट सुरक्षित रहते हैं; अन्य ग्रुप मेटाडेटा को रीबिल्ड किया जाता है। 4.2.0 KAFKA-20254 का जोखिम रखता है, इसलिए मैं इसे एक सुरक्षित माइग्रेशन वर्शन नहीं कहूंगा। यदि वैलिडेशन विफल हो जाता है, तो मैं नए ग्रुप को रोकता हूं, क्लासिक पर वापस लौटता हूं, या एक नए एप्लिकेशन आईडी के साथ रीबिल्ड करता हूं और समीक्षा के लिए साक्ष्य बनाए रखता हूं।"

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

गलती: group.protocol=streams को रोलिंग स्विच के रूप में मानना → यह क्यों विफल होता है: ऑनलाइन माइग्रेशन असमर्थित है → समाधान: एक खाली-ग्रुप मेंटेनेंस विंडो शेड्यूल करें।
गलती: 4.2.0 पर माइग्रेट करना → यह क्यों विफल होता है: आधिकारिक अपग्रेड गाइड KAFKA-20254 को रिकॉर्ड करती है → समाधान: फिक्स के साथ 4.2.1 या बाद के वर्शन का उपयोग करें।
गलती: वादा करना कि हर ग्रुप स्टेट सुरक्षित है → यह क्यों विफल होता है: केवल कमिटेड ऑफ़सेट रहते हैं और अन्य मेटाडेटा रीबिल्ड होता है → समाधान: अलग ऑफ़सेट, स्टेट-स्टोर और टॉपिक जांच रिकॉर्ड करें।
गलती: स्टैटिक मेंबरशिप या टोपोलॉजी अपडेट को अनदेखा करना → यह क्यों विफल होता है: नया प्रोटोकॉल अभी उनका समर्थन नहीं करता है → समाधान: सुविधाओं की इन्वेंट्री करें और आवश्यकता पड़ने पर क्लासिक पर बने रहें।

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

बिज़नेस रुक नहीं सकता। क्या दो इंस्टेंस बैच धीरे-धीरे स्विच कर सकते हैं?

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

यदि कमिटेड ऑफ़सेट सुरक्षित रहते हैं तो स्टेट स्टोर को क्यों वैलिडेट करें?

एक ऑफ़सेट बताता है कि आगे कहाँ से पढ़ना है, न कि यह कि स्थानीय स्टेट पूर्ण है। Changelog रीप्ले, असंगति या प्रोसेसिंग विफलताएं स्टेट स्टोर को ऑफ़सेट के साथ असंगत छोड़ सकती हैं, इसलिए स्टेट और बिज़नेस परिणामों को वैलिडेट करें।

4.2.0 GA है। इससे क्यों बचें?

GA का मतलब है कि सुविधा रिलीज़ हो गई थी, न कि यह कि प्रत्येक माइग्रेशन पाथ ज्ञात दोषों से मुक्त है। आधिकारिक गाइड ऑफ़लाइन माइग्रेशन में KAFKA-20254 की पहचान करती है और कहती है कि इसे 4.2.1 में ठीक किया गया है; फिक्स वर्शन चुनें, GA लेबल नहीं।

एप्लिकेशन regex सब्सक्रिप्शन का उपयोग करता है। अब क्या करें?

नया स्ट्रीम्स प्रोटोकॉल पैटर्न-आधारित टॉपिक सब्सक्रिप्शन का समर्थन नहीं करता है। माइग्रेशन पर पुनर्विचार करने से पहले क्लासिक पर बने रहें या डिस्कवरी को एक स्पष्ट टॉपिक सूची में बदलें; केवल ग्रुप प्रोटोकॉल बदलना अपर्याप्त है।

आप कैसे तय करते हैं कि नए एप्लिकेशन आईडी का उपयोग करना है या नहीं?

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

संदर्भ (References)

Apache Kafka Streams Rebalance Protocol डेवलपर गाइड।
Apache Kafka 4.2 Streams Upgrade Guide।
Apache Kafka 4.2.0 Release Announcement।