प्रश्न
किसी प्रोडक्शन क्लस्टर को Kafka 4.3.0 से 4.3.1 में अपग्रेड करने से पहले, आप यह कैसे साबित करेंगे कि अपग्रेड को डेटा-जोखिम वाली घटना बनाए बिना Kafka Streams RocksDB नेटिव-मेमोरी लीक नियंत्रित है?
संदर्भ और सीमाएं
यह प्रश्न RocksDB स्टेट स्टोर्स का उपयोग करने वाले Kafka Streams एप्लिकेशन्स के रोलिंग अपग्रेड से संबंधित है। Apache Kafka का कहना है कि 4.3.1 को 25 जून 2026 को लगभग 15 फिक्स के साथ एक बग-फिक्स रिलीज के रूप में जारी किया गया था, जिसमें KAFKA-20616 के रूप में ट्रैक किया गया Kafka Streams RocksDB नेटिव-मेमोरी लीक भी शामिल है। उत्तर में साक्ष्य, क्षमता, रोलआउट और रोलबैक शामिल होने चाहिए; केवल एक वर्जन नंबर इस बात का प्रमाण नहीं है कि मेमोरी की हर समस्या समाप्त हो गई है।
पहले स्पष्ट करें: क्या फ्लीट Kafka 4.3.0 पर है या किसी अन्य वर्जन पर? स्टेट-स्टोर का आकार, रीस्टार्ट-रिकवरी समय, ऑफ-हीप बजट और अधिकतम सहनशील लैग क्या हैं? क्या Streams इंस्टेंसेस को धीरे-धीरे माइग्रेट किया जा सकता है?
इंटरव्यूअर क्या जांच रहा है
इंटरव्यूअर यह देख रहा है कि क्या आप अपस्ट्रीम फिक्स को एक ऑपरेशनल स्ट्रीमिंग योजना में बदल सकते हैं: नेटिव मेमोरी को JVM हीप से अलग करना, अपग्रेड से पहले की बेसलाइन स्थापित करना, छोटे रोलआउट के साथ लीक के स्लोप को मान्य करना, और स्टेट रिकवरी, प्रोसेसिंग प्रगति और रोलबैक की सुरक्षा करना।
30-सेकंड का उत्तर
पहले 4.3.1 रिलीज की घोषणा, बदलावों की सूची और प्रभावित घटक को सत्यापित करें। फिर अपग्रेड से पहले का RSS, ऑफ-हीप मेमोरी, RocksDB स्टेट साइज़, GC, प्रोसेसिंग लेटेंसी और रीस्टार्ट-रिकवरी बेसलाइन कैप्चर करें। एक निश्चित विंडो के लिए एक Streams इंस्टेंस पर कैनरी चलाएं, रिकवरी और लैग को मान्य करें, और विफलता डोमेन (failure domain) के आधार पर विस्तार करें। यदि स्लोप या रिकवरी गेट्स विफल होते हैं, तो प्रसार को रोकें और changelog और स्टेट-डायरेक्टरी साक्ष्य को संरक्षित करते हुए सत्यापित वर्जन पर रोलबैक करें।
चरण-दर-चरण विस्तृत विवरण
- साक्ष्य: बाइनरी, इमेज और कॉन्फ़िगरेशन वर्जन्स को पिन करें; किसी अनौपचारिक दावे पर निर्भर रहने के बजाय 4.3.1 की घोषणा, अपग्रेड नोट्स और KAFKA-20616 लिंकेज को रिकॉर्ड करें।
- बेसलाइन: प्रति इंस्टेंस JVM हीप, प्रोसेस RSS, कंटेनर वर्किंग सेट, RocksDB स्टेट-डायरेक्टरी साइज़, फाइल डिस्क्रिप्टर, GC, कंज्यूमर लैग, थ्रूपुट और रिकवरी समय रिकॉर्ड करें। जब हीप मेट्रिक्स स्थिर रहते हैं, तब भी नेटिव लीक निरंतर RSS या वर्किंग-सेट वृद्धि दिखा सकता है।
- प्रयोग: प्रोडक्शन जैसे स्टेट साइज़ और अपडेट पैटर्न का उपयोग करें, ऑब्जर्वेशन विंडो तय करें, और अपग्रेड से पहले और बाद में इनपुट की प्रति यूनिट RSS वृद्धि की तुलना करें। इसके अलावा रीस्टार्ट, रिस्टोर और रीबैलेंस का परीक्षण करें।
- रोलआउट: पहले एक गैर-महत्वपूर्ण (non-critical) इंस्टेंस को अपग्रेड करें। टास्क स्टेट, changelog कैच-अप और लैग गेट्स की पुष्टि करें, फिर रैक या पार्टीशन विफलता डोमेन द्वारा आगे बढ़ें। समवर्ती (concurrent) रीस्टार्ट को सीमित करें ताकि स्टेट रिकवरी के कारण हर जगह अचानक स्पाइक न आए।
- क्षमता और अलर्ट: RSS, वर्किंग सेट, ऑफ-हीप बजट और RocksDB स्टेट वृद्धि पर अलर्ट लगाएं। रिकवरी के छोटे स्पाइक और रिकवरी के बाद के निरंतर स्लोप के बीच अंतर करें और प्रत्येक इंस्टेंस के लिए हेडरूम आरक्षित रखें।
- रोलबैक और डेटा सुरक्षा: विफलता होने पर बाद के बैचों को रोकें और सत्यापित वर्जन पर लौटें। changelog ऑफसेट, टास्क स्टेट, लैग और वर्जन मैपिंग को सुरक्षित रखें; सत्यापित करें कि पुराना प्रोसेस स्टेट को पढ़ सकता है, आवश्यकता पड़ने पर changelog से फिर से निर्माण करें, और आउटपुट की तुलना करें।
आदर्श उत्तर
मैं इस प्रश्न को 4.3.1 लेबल के आधार पर सुरक्षित घोषित करने के बजाय इस रूप में परिभाषित करूंगा कि "क्या फिक्स ने नेटिव-मेमोरी वृद्धि को स्वीकार्य स्लोप पर वापस ला दिया है?" आधिकारिक रिलीज की जानकारी कहती है कि 4.3.1 लगभग 15 मुद्दों को ठीक करता है और विशेष रूप से Kafka Streams RocksDB नेटिव-मेमोरी लीक का उल्लेख करता है। मैं उस घोषणा, अपग्रेड नोट्स और वास्तविक बिल्ड आर्टिफैक्ट डाइजेस्ट को चेंज रिकॉर्ड में रखूंगा।
अपग्रेड करने से पहले, प्रति इंस्टेंस हीप, RSS, कंटेनर वर्किंग सेट, RocksDB स्टेट साइज़, GC, लैग, थ्रूपुट और रिकवरी समय एकत्र करें। प्रोडक्शन जैसे स्टेट साइज़ पर एक निश्चित विंडो चलाएं और प्रति दस लाख इनपुट रिकॉर्ड पर RSS वृद्धि की तुलना करें। प्रोडक्शन में, एक इंस्टेंस पर कैनरी करें, टास्क रीस्टार्ट, changelog कैच-अप, रीबैलेंस और लैग गेट्स को सत्यापित करें, फिर विफलता डोमेन के अनुसार विस्तार करें। पूर्ण मानों (absolute values) और स्लोप दोनों पर अलर्ट करें ताकि रिकवरी स्पाइक को लीक न समझ लिया जाए।
canary_gate:
rss_growth_per_million_records: <= baseline_slope * 1.2
consumer_lag: <= 2 minutes
restore_time: <= baseline_restore_time * 1.25
task_errors: 0
rollback:
stop_rollout: true
preserve_changelog_offsets: true
preserve_version_mapping: trueयदि कैनरी निरंतर RSS वृद्धि, रिकवरी टाइमआउट, या टास्क त्रुटियां दिखाता है, तो मैं रोलआउट रोक दूंगा और ऑफसेट, स्टेट और लॉग साक्ष्य को संरक्षित करते हुए पिछले वर्जन पर वापस लौट जाऊंगा। मैं स्टेट रिकवरी और आउटपुट समानता साबित करने के बाद ही आगे बढ़ूंगा। यह अपस्ट्रीम फिक्स, ऑब्जर्वेबिलिटी और डेटा सुरक्षा को एक ऑडिट योग्य अपग्रेड गेट से जोड़ता है।
सामान्य गलतियां
- रिलीज साक्ष्य, प्रभावित घटक, या फील्ड बेसलाइन के बिना "4.3.1 लीक को ठीक करता है" का हवाला देना।
- केवल JVM हीप को देखना और RocksDB नेटिव मेमोरी और कंटेनर वर्किंग सेट को छोड़ देना।
- पूरे क्लस्टर को एक साथ रीस्टार्ट करना और रिकवरी, रीबैलेंस और लैग विफलताओं को एक साथ जोड़ देना।
- रिकवरी के छोटे स्पाइक को लीक मानना, या इसके विकास स्लोप को देखे बिना केवल निरपेक्ष RSS को देखना।
- प्रसार रोकने (stop-propagation), रोलबैक, या changelog/ऑफसेट संगति का कोई साक्ष्य प्रदान न करना।
एक मजबूत उत्तर वर्जन साक्ष्य, एक दोहराने योग्य प्रयोग, रोलआउट गेट्स, क्षमता अलर्ट और एक डेटा-रिकवरी योजना प्रदान करता है। "अपग्रेड करें और डैशबोर्ड देखें" यह साबित नहीं करता कि जोखिम नियंत्रित है।
फॉलो-अप प्रश्न और उत्तर
JVM हीप स्थिर रहने पर भी RSS क्यों बढ़ सकता है?
RocksDB और इसी तरह के घटक Java हीप के बाहर नेटिव मेमोरी और फाइल मैपिंग का उपयोग करते हैं। प्रोसेस RSS, कंटेनर वर्किंग सेट, स्टेट-डायरेक्टरी साइज़ और RocksDB सिग्नल्स का एक साथ निरीक्षण करें, और वृद्धि को इनपुट वॉल्यूम से जोड़कर देखें।
क्या कैनरी पर अस्थायी लैग वृद्धि से तत्काल रोलबैक शुरू होना चाहिए?
पूर्वनिर्धारित विंडो और थ्रेसहोल्ड का उपयोग करें। यदि रिकवरी के बाद लैग कम हो जाता है और RSS स्लोप सामान्य रहता है, तो निगरानी जारी रखें। यदि लैग गेट से ऊपर बना रहता है, रिकवरी सीमा से अधिक हो जाती है, या टास्क त्रुटियां दिखाई देती हैं, तो प्रसार रोकें और रोलबैक करें।
रोलबैक के दौरान असंगत स्टेट (incompatible state) से कैसे बचें?
वर्जन-टू-टास्क मैपिंग, changelog ऑफसेट, स्टेट-डायरेक्टरी मेटाडेटा और कॉन्फ़िगरेशन डाइजेस्ट को सुरक्षित रखें। सत्यापित करें कि पुराना वर्जन अलग से स्टेट को पढ़ सकता है; आवश्यकता पड़ने पर changelog से पुनर्निर्माण करें और ट्रैफ़िक बहाल करने से पहले महत्वपूर्ण आउटपुट की तुलना करें।
एक वाक्य में सारांश
4.3.1 को एक साक्ष्य-समर्थित संभावित फिक्स के रूप में मानें, फिर नेटिव-मेमोरी बेसलाइन, कैनरी गेट्स और एक सत्यापन योग्य रोलबैक का उपयोग करके यह साबित करें कि Kafka Streams का जोखिम वास्तव में कम हुआ है।