Kafka Tiered Storage: आप Local और Remote Retention कैसे डिज़ाइन करते हैं?

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

एक साक्षात्कारकर्ता पूछ सकता है: "यदि किसी Kafka topic को वर्षों का इतिहास बनाए रखना है, तो आप Tiered Storage की local और remote retention नीतियों को कैसे डिज़ाइन करेंगे?"

मूल बात किसी कॉन्फ़िगरेशन नाम को याद रखना नहीं है। यह local और remote tiers में log segments के जीवनचक्र (lifecycle) को समझाना है। KIP-405 Kafka brokers पर एक local tier बनाए रखता है जबकि पूरे हो चुके log segments को बाहरी स्टोरेज में अपलोड करता है; broker डिस्क के दबाव को कम करने के लिए local retention को remote retention की तुलना में छोटा रखा जा सकता है। एक संपूर्ण उत्तर में object-store की विफलताएं, ऐतिहासिक-रीड विलंबता (read latency), डिलीशन का स्वामित्व और रिकवरी भी शामिल होती है।

साक्षात्कारकर्ता क्या जांच रहा है

क्या आप tiered storage को log-segment के hot/cold प्लेसमेंट के रूप में समझते हैं, न कि इसे Kafka का object store बनना मानते हैं।
क्या आप क्लस्टर क्षमता, topic-स्तर के remote.storage.enable, और retention नीतियों को अलग-अलग समझ सकते हैं।
क्या आप hot-disk क्षमता, remote क्षमता, upload lag, और replay bandwidth का अनुमान लगा सकते हैं।
क्या आप remote आउटेज, metadata स्थिरता (consistency), partition मूवमेंट, और consumer replay पर विचार करते हैं।
क्या आप आकस्मिक या असीमित वृद्धि के बिना remote deletion के लिए स्पष्ट स्वामित्व सौंपते हैं।

स्पष्टीकरण के लिए प्रश्न

किन topics को ऐतिहासिक स्टोरेज की आवश्यकता है, और क्या प्रत्येक topic को सक्षम किया जाना चाहिए?
Hot-read latency और ऐतिहासिक-replay थ्रूपुट के लक्ष्य क्या हैं?
Local-disk बजट, remote storage class, क्षेत्रीय, और अनुपालन (compliance) आवश्यकताएं क्या हैं?
Object-store आउटेज के दौरान, प्रोडक्शन, रियल-टाइम consumers, और ऐतिहासिक readers कैसे डिग्रेड होते हैं?
क्या डिलीशन समय, आकार, किसी अनुपालन घटना, या tenant नीति द्वारा संचालित होता है?

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

आप कह सकते हैं:

मैं Kafka के local tier को कम विलंबता (low-latency) वाले hot cache के रूप में मानूँगा, पूर्ण हो चुके segments को remote tier में अपलोड करूँगा, और local तथा remote retention को अलग-अलग परिभाषित करूँगा। केवल उन्हीं topics के लिए remote.storage.enable सक्षम करें जिन्हें इसकी आवश्यकता है; broker डिस्क को नियंत्रित करने के लिए local retention और ऑडिट तथा replay आवश्यकताओं को पूरा करने के लिए remote retention का उपयोग करें। मैं upload lag, remote-read latency, object-store विफलताओं और partition मूवमेंट को मापूँगा, फिर remote cleanup के लिए एक ओनर असाइन करूँगा। रियल-टाइम consumers local पाथ पर रहते हैं; ऐतिहासिक replay थ्रॉटलिंग और मॉनिटरिंग के साथ अतिरिक्त लेटेंसी स्वीकार करता है।

चरण-दर-चरण तर्क

दो-स्तरीय जीवनचक्र (two-tier lifecycle) स्थापित करें

Kafka अभी भी partition log segments को बुनियादी इकाई के रूप में उपयोग करता है। Active segments स्थानीय रूप से लिखे जाते हैं; रोलिंग के बाद, remote-log घटक कॉन्फ़िगर किए गए remote storage में segments और index जानकारी अपलोड करता है। क्लाइंट को यह मानकर नहीं चलना चाहिए कि प्रत्येक ऐतिहासिक बाइट broker डिस्क पर ही रहता है:

text

producer -> leader broker local segment
                    | segment roll
                    v
             remote object store
consumer <---- local cache or remote fetch

Local tier कम विलंबता वाले उपभोग की सेवा करता है और remote tier अधिक समय के retention को संभालता है। अपलोड पूरा होने और स्थानीय डिलीशन के बीच एक दृश्यमान (observable) सुरक्षा विंडो रखें; केवल ऑब्जेक्ट का निर्माण इस बात का प्रमाण नहीं है कि इंडेक्स और मेटाडेटा उपयोग योग्य हैं।

प्रति-topic सुविधा का दायरा निर्धारित करें

Apache Kafka दस्तावेज़ बताता है कि broker-साइड कॉन्फ़िगरेशन के बाद, एक topic अभी भी remote.storage.enable के साथ ऑप्ट-इन करता है। बताएं कि गवर्नेंस मॉडल ऑप्ट-इन है या डिफ़ॉल्ट-ऑन, क्योंकि प्रत्येक topic को सक्षम करने से लागत और विफलता का दायरा बढ़ सकता है।

Local और remote retention को अलग करें

Hot डेटा और reassignment के लिए आवश्यक रीड क्षमता को सुरक्षित रखने के लिए समय या आकार के आधार पर local retention सेट करें; ऑडिट, replay और अनुपालन के लिए remote retention सेट करें। इनवेरिएंट यह है कि एकमात्र स्थानीय प्रति तब तक डिलीट नहीं की जाती जब तक कि remote ऑब्जेक्ट्स, इंडेक्स, मेटाडेटा और रिकवरी परीक्षण सत्यापित न हो जाएं। Remote deletion के लिए स्वतंत्र ऑडिट और पुनः प्रयास (retry) हैंडलिंग की आवश्यकता होती है।

Reads और degradation को डिज़ाइन करें

रियल-टाइम consumers पहले local tier से पढ़ते हैं; local विंडो से परे का offset एक remote read को ट्रिगर करता है। जब remote storage धीमा हो जाता है, तो लाइव ट्रैफ़िक की सुरक्षा के लिए ऐतिहासिक replay को थ्रॉटल करें। जब यह अनुपलब्ध हो, तो बताएं कि कौन से offsets अस्थायी रूप से अपठनीय हैं, अलर्ट कैसे ट्रिगर होते हैं, और रिकवरी कैसे काम करती है। Partition मूवमेंट, leader परिवर्तन, और broker रीस्टार्ट के दौरान मेटाडेटा और कैश पुनर्निर्माण समय का परीक्षण करें।

मॉडल उच्च-गुणवत्ता वाला उत्तर

मैं पहले topic की hot-read विंडो, replay थ्रूपुट, retention अवधि, और अनुपालन आवश्यकताओं की पुष्टि करूँगा। KIP-405 के अनुसार, broker का local tier एक hot cache है और रोल्ड segments को remote object storage पर अपलोड किया जाता है; केवल वही topics जिन्हें इतिहास की आवश्यकता है, remote.storage.enable को सक्षम करते हैं। Local retention डिस्क बजट और रियल-टाइम replay आवश्यकताओं का पालन करता है, जबकि remote retention ऑडिट अवधि का पालन करता है। डिलीशन का गेट सत्यापित remote ऑब्जेक्ट्स, इंडेक्स और मेटाडेटा हैं, न कि केवल एक अपलोड अनुरोध। Consumers local विंडो के भीतर कम लेटेंसी बनाए रखते हैं; पुराना replay थ्रॉटलिंग के साथ remote reads का उपयोग करता है। मैं upload lag, remote-read latency, कैश हिट्स, ऑब्जेक्ट/मेटाडेटा बेमेल, डिलीशन विफलताओं और अपठनीय offsets की निगरानी करूँगा, और object-store आउटेज, broker रीस्टार्ट तथा partition-movement रिकवरी का अभ्यास करूँगा। Remote cleanup के लिए एक ओनर, ऑडिट ट्रेल और रीस्टोर प्रक्रिया की आवश्यकता होती है; broker फ़ाइलों को डिलीट करने से वह ज़िम्मेदारी समाप्त नहीं होती है।

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

यह दावा करना कि tiered storage प्रत्येक Kafka रिकॉर्ड को सीधे object storage में स्ट्रीम करता है और segment rolling को अनदेखा करना।
केवल एक क्लस्टर स्विच प्रदान करना और topic-स्तर के remote.storage.enable को छोड़ देना।
Remote-read latency, upload lag, और replay bandwidth को छोड़ते हुए केवल ऑब्जेक्ट लागत की गणना करना।
यह मान लेना कि broker फ़ाइलों को डिलीट करने से remote ऑब्जेक्ट्स अपने आप डिलीट हो जाते हैं।
Remote विफलता के दौरान ऐतिहासिक replay को लाइव ट्रैफ़िक के लिए आवश्यक संसाधनों का उपभोग करने देना।
ऑब्जेक्ट, इंडेक्स और मेटाडेटा स्थिरता के लिए मॉनिटरिंग और रिकवरी अभ्यास को छोड़ देना।

अनुवर्ती प्रश्न और उत्तर

1. आप local retention समय कैसे चुनते हैं?

सबसे बड़ी रियल-टाइम रिवाइंड विंडो, डिस्क बजट, reassignment रिकवरी समय और विफलता-अवधि सुरक्षा मार्जिन से उल्टी दिशा में गणना करें (work backward)। केवल औसत consumer lag के बजाय पीक replay और मेंटेनेंस विंडो को शामिल करें।

2. यदि remote object store कुछ समय के लिए अनुपलब्ध हो तो क्या होगा?

Local विंडो से परे रीड्स को रोकें (pause) या थ्रॉटल करें, सत्यापित स्थानीय सीमा को सुरक्षित रखें, और अपलोड व रीड विफलताओं पर अलर्ट करें। प्रोडक्शन और रियल-टाइम उपभोग मान्य स्थानीय क्षमता के भीतर जारी रहता है; ऐतिहासिक रीड्स रिकवरी के बाद स्थिति को संभाल लेते हैं। खाली डेटा लौटाने के बजाय अपठनीय offsets के लिए एक स्पष्ट स्थिति प्रदर्शित करें।

3. आप यह कैसे सिद्ध करते हैं कि डिलीशन सुरक्षित है?

किसी local segment को डिलीट करने से पहले, सत्यापित करें कि उसका remote ऑब्जेक्ट, इंडेक्स और मेटाडेटा पठनीय हैं और segment सीमा को रिकॉर्ड करें। Remote deletion के लिए, retention नीति का ऑडिट करें, रीड्स का नमूना लें, और रेस्टोरेशन अभ्यास चलाएं; विफल डिलीशन, अनाथ (orphan) ऑब्जेक्ट्स और मेटाडेटा अंतराल पर अलर्ट करें।