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

डेटा इंजीनियरिंग इंटरव्यू: Kinesis on-demand या provisioned capacity?

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

प्रश्न

एक रियल-टाइम बिहेवियर स्ट्रीम में स्पष्ट दैनिक पीक (peaks) हैं, और टीम को on-demand और provisioned Kinesis Data Streams के बीच चयन करना है। आप इस निर्णय का मूल्यांकन और सत्यापन कैसे करेंगे?

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

आप एक ऐसे डेटा प्लेटफॉर्म के ओनर हैं जो कई रियल-टाइम कंज्यूमर्स के लिए यूजर इवेंट्स को इनजेस्ट करता है। दिन के अधिकांश समय ट्रैफिक स्थिर रहता है और अभियानों (campaigns) के दौरान इसमें स्पाइक (spike) आते हैं। व्यवसाय लगातार थ्रॉटलिंग (throttling) सहन नहीं कर सकता, लेकिन वह मंदी (trough) के समय के लिए क्षमता का अग्रिम भुगतान भी नहीं करना चाहता। मान लें कि आप प्रोड्यूसर थ्रूपुट, रीड लेटेंसी, थ्रॉटलिंग और कंज्यूमर लैग (lag) को पढ़ सकते हैं, और मेंटेनेंस विंडो के दौरान कैपेसिटी मोड को बदल सकते हैं।

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

इंटरव्यूअर यह परख रहा है कि क्या आप समझते हैं कि कैपेसिटी मोड ऑपरेशनल जिम्मेदारी और लागत को बदलता है, डिलीवरी सेमेंटिक्स को नहीं। एक मजबूत उत्तर ऐतिहासिक पीक्स और बर्स्ट शेप का उपयोग करके यह तय करता है कि स्वचालित स्केलिंग उपयोगी है या नहीं, और फिर प्रति-शार्ड लिमिट, कंज्यूमर की संख्या, पुनः प्रयास (retries), और लैग रिकवरी की जांच करता है। एक कमजोर उत्तर केवल यह कहता है कि जब भी ट्रैफिक में बदलाव हो, on-demand चुन लें।

पहले पूछे जाने वाले स्पष्टीकरण

  • पीक्स कितने समय तक चलते हैं, और क्या वे अनुमानित (predictable) हैं? छोटे, अप्रत्याशित स्पाइक्स ऑटोमेटेड कैपेसिटी मैनेजमेंट के पक्ष में होते हैं।
  • क्या राइट्स (writes) और रीड्स (reads) एक ही समय पर बाधित होते हैं? बाइट्स, रिकॉर्ड्स, रीड्स और कंज्यूमर बिहेवियर को अलग-अलग मापें।
  • क्या कोई सख्त लागत सीमा (cost ceiling) या कैपेसिटी बजट है? कड़े बजट वाले स्थिर ट्रैफिक को provisioned मोड में ऑप्टिमाइज़ करना आसान होता है।
  • क्या कंज्यूमर्स थ्रूपुट साझा करते हैं या उन्हें डेडिकेटेड रीड्स की आवश्यकता होती है? कई कंज्यूमर्स रीड कोटा और लागत को बदल देते हैं।
  • क्या टीम एक छोटे स्टेट ट्रांज़िशन को सहन कर सकती है? स्विचिंग और बर्स्ट रिट्राइज़ के लिए एक स्पष्ट रनबुक (runbook) की आवश्यकता होती है।

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

"मैं प्रति घंटे राइट MB/s, रिकॉर्ड रेट, रीड MB/s, लैग और थ्रॉटलिंग को मापूंगा, जिससे अनुमानित पीक्स को बर्स्ट्स से अलग किया जा सके। स्थिर, अनुमानित ट्रैफिक स्केलिंग शेड्यूल के साथ provisioned capacity का उपयोग कर सकता है; तेज़ या अप्रत्याशित बदलाव on-demand के पक्ष में होते हैं, लेकिन मैं रैंप-अप, कोटा और लागत को वैलिडेट करूंगा। किसी भी विकल्प को थ्रॉटलिंग, लैग रिकवरी, एंड-टू-एंड लेटेंसी और मासिक खर्च के गार्डरेल्स को पास करना होगा।"

चरण-दर-चरण विस्तृत उत्तर

  1. एक कैपेसिटी बेसलाइन बनाएं। मिनट के आधार पर राइट्स और रीड्स को एग्रीगेट करें, P50, P95, P99, पीक अवधि और हॉट पार्टिशन कीज़ (hot partition keys) को रिकॉर्ड करें; औसत मान बर्स्ट्स को छुपा देते हैं।
  2. थ्रूपुट सीमाओं की जांच करें। AWS राइट्स के लिए 1 MB/s या 1,000 रिकॉर्ड प्रति सेकंड और रीड्स के लिए 2 MB/s की डिफ़ॉल्ट शार्ड सीमा का दस्तावेजीकरण करता है। रिकॉर्ड साइज और बैचिंग को बाइट्स और रिकॉर्ड दोनों में बदलें।
  3. एक मोड चुनें। स्थिर लोड के लिए स्केलिंग प्लान के साथ provisioned capacity का उपयोग करें; जब लोड तेजी से बदलता है या भविष्यवाणी करना कठिन होता है, तो on-demand को प्राथमिकता दें, और ऑटोमैटिक-एडजस्टमेंट लेटेंसी को रिकॉर्ड करें।
  4. कंज्यूमर्स को मॉडल करें। शेयर्ड रीड्स, enhanced fan-out, रिट्राइज़ और डुप्लिकेट प्रोसेसिंग रीड कोटा को प्रभावित करते हैं। कंज्यूमर लैग कैपेसिटी प्लानिंग का हिस्सा है, केवल प्रोड्यूसर मेट्रिक्स का नहीं।
  5. लागत का मॉडल बनाएं। Provisioned मोड के लिए, शार्ड-ऑवर्स (shard-hours) और स्केलिंग हेडरूम को शामिल करें। On-demand के लिए, वास्तविक थ्रूपुट और पीक बिलिंग, साथ ही रीप्ले और बर्स्ट डबल-राइट्स को शामिल करें।
  6. पायलट और रोलबैक करें। एक नॉन-क्रिटिकल स्ट्रीम को स्विच करें, थ्रॉटलिंग, लैग रिकवरी, P99 लेटेंसी और मासिक खर्च पर नज़र रखें। यदि कोई गार्डरेल विफल हो जाता है, तो ऑर्डरिंग और रिट्राइ बिहेवियर को बनाए रखते हुए वैलिडेटेड मोड पर वापस लौटें।

विकल्पों में हॉट पार्टिशन कीज़ को विभाजित करना, राइट्स को बैच करना, इवेंट्स का आकार छोटा करना, Firehose के साथ बफर करना, या अनुमानित अभियानों के लिए प्री-स्केलिंग शामिल है। कैपेसिटी मोड विषम कीज़ (skewed keys), धीमे कंज्यूमर्स या अनंत पुनः प्रयासों को ठीक नहीं कर सकता है।

मॉडल उत्तर

"मैं प्रति-मिनट राइट और रीड कर्व्स के 30 दिनों का निरीक्षण करूंगा, P95/P99, पीक अवधि और पार्टिशन-की विषमता (skew) की गणना करूंगा। मैं AWS शार्ड सीमाओं के माध्यम से रिकॉर्ड साइज को राइट MB/s और रिकॉर्ड रेट में बदलूंगा, फिर शेयर्ड कंज्यूमर थ्रूपुट और लैग रिकवरी की जांच करूंगा। घंटों तक चलने वाले अनुमानित पीक्स के लिए, मैं provisioned capacity का उपयोग करूंगा और अभियानों से पहले प्री-स्केल करूंगा। छोटे, अप्रत्याशित पीक्स के लिए, मैं थ्रॉटलिंग 0.1% से कम, लैग-रिकवरी p99 5 मिनट से कम, एंड-टू-एंड लेटेंसी बेसलाइन के 20% के भीतर, और मासिक लागत सीमा के साथ एक नॉन-क्रिटिकल स्ट्रीम पर on-demand का पायलट परीक्षण करूंगा। मैं दोनों मोड में हॉट पार्टिशन्स और डुप्लिकेट्स की निगरानी करूंगा; कैपेसिटी मोड बदलने से मूल कारण (root cause) नहीं छिपना चाहिए।"

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

  • गलती: औसत थ्रूपुट से अनुमान लगाना → यह क्यों विफल होता है: बर्स्ट्स और हॉट कीज़ स्थानीय थ्रॉटलिंग का कारण बनते हैं → सुधार: P95/P99, पीक अवधि और की-डिस्ट्रिब्यूशन का उपयोग करें।
  • गलती: On-demand को असीमित थ्रूपुट मानना → यह क्यों विफल होता है: सर्विस कोटा और रैंप-अप अभी भी मायने रखते हैं → सुधार: रैंप बिहेवियर, कोटा और बर्स्ट टेस्ट को वैलिडेट करें।
  • गलती: केवल प्रोड्यूसर की लागत की गणना करना → यह क्यों विफल होता है: कंज्यूमर्स, रिट्राइज़ और रीप्ले थ्रूपुट को बढ़ाते हैं → सुधार: एंड-टू-एंड लागत परिदृश्यों का निर्माण करें।
  • गलती: डिलीवरी सेमेंटिक्स को अनदेखा करना → यह क्यों विफल होता है: कैपेसिटी मोड कम-से-कम-एक-बार (at-least-once) और डुप्लिकेट-प्रोसेसिंग जोखिमों को समाप्त नहीं करता है → सुधार: आइडेम्पोटेंसी, चेकपॉइंट्स और लैग रिकवरी को बनाए रखें।

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

On-demand में अभी भी थ्रॉटलिंग हो रही है; आप पहले क्या ट्यून करेंगे?

कुल थ्रूपुट की कमी, हॉट पार्टिशन कीज़ और पिछड़े हुए (lagging) कंज्यूमर को अलग करें। बैकऑफ, पुनः पार्टिशनिंग या अधिक कंज्यूमर्स चुनने से पहले रिकॉर्ड रेट, की-डिस्ट्रिब्यूशन और स्केलिंग इवेंट्स की जांच करें।

Provisioned capacity कब सस्ती होती है?

जब राइट्स और रीड्स स्थिर हों, पीक्स को शेड्यूल किया जा सके और उपयोग (utilization) उच्च बना रहे, तब शार्ड-ऑवर्स और स्केलिंग हेडरूम का मॉडल बनाएं। केवल यूनिट प्राइस की तुलना न करें।

क्या होगा यदि अभियान का ट्रैफिक दस गुना बढ़ जाए?

पहले on-demand कोटा और ऐतिहासिक रैंप बिहेवियर को सत्यापित करें। अनुमानित अभियानों को प्री-स्केल करें, प्रोड्यूसर बैकऑफ और लैग अलर्ट जोड़ें, और गैर-महत्वपूर्ण इवेंट्स के लिए डिग्रेडेशन को परिभाषित करें।

आप कैसे साबित करेंगे कि चयन सही है?

समान परिभाषाओं के साथ पायलट से पहले और बाद में थ्रॉटलिंग, लैग-रिकवरी p99, एंड-टू-एंड लेटेंसी, डुप्लिकेट रेट और मासिक लागत की तुलना करें। दो व्यावसायिक चक्रों द्वारा गार्डरेल्स को पूरा करने के बाद इसे विस्तारित करें।

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

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