अभ्यास में स्टेटफुल बनाम स्टेटलेस

स्टेट कभी गायब नहीं होता, यह बस स्थान बदलता है

स्टेटफुल कंपोनेंट: वह जानकारी रखता है जिसकी हानि से व्यवहार बदल जाता है। एक डेटाबेस जो उपयोगकर्ता खातों को रखता है। एक कैश जो सेशन टोकन्स को रखता है। एक वर्कर जो लंबे समय तक चलने वाली स्ट्रीमिंग कनेक्शन को किसी विशिष्ट उपयोगकर्ता से पिन करता है।

स्टेटलेस कंपोनेंट: वह कोई ऐसी जानकारी नहीं रखता जिसकी हानि का कोई महत्व हो। एक वेब टियर जो अनुरोध पढ़ता है, डेटाबेस से पूछता है, और प्रतिक्रिया लिखता है। हर अनुरोध अकेला खड़ा होता है; टियर अनुरोधों के बीच कुछ भी याद नहीं रखता।

मुख्य अंतर्दृष्टि: स्टेट किसी प्रणाली से कभी गायब नहीं होता। यह उस परत में चला जाता है जो इसे रखने के लिए डिज़ाइन की गई है (एक डेटाबेस, एक रेडिस क्लस्टर, एक ऑब्जेक्ट स्टोर)। तब ट्रैफ़िक का सामना करने वाली परतें स्टेटलेस हो सकती हैं, और स्टेटलेस परतें क्षैतिज रूप से स्केल करती हैं क्योंकि कोई भी रिप्लिका किसी भी अनुरोध का उत्तर दे सकता है।

व्यावहारिक परीक्षण: यदि आप इस टियर में एक प्रक्रिया को यादृच्छिक रूप से मार देते हैं और इसे पुनः आरंभ करते हैं, तो क्या किसी उपयोगकर्ता को गलत उत्तर या खोया हुआ सेशन अनुभव होगा? यदि हाँ, तो यह स्टेट रखता है। यदि नहीं, तो यह नहीं रखता।

उदाहरण

- एक पाइथॉन वेब प्रक्रिया जो अनुरोध पढ़ती है, पोस्टग्रेस से पूछती है, और JSON लौटाती है: स्टेटलेस। स्टेट पोस्टग्रेस में रहता है।

- एक पाइथॉन वेब प्रक्रिया जो उपयोगकर्ता की खरीदारी की टोकरी को स्थानीय मेमोरी में रखती है: स्टेटफुल। प्रक्रिया को मारने से टोकरी खो जाती है।

- एक WebSocket सर्वर जो चैट उपयोगकर्ताओं के साथ खुले कनेक्शन बनाए रखता है: कनेक्शन के संदर्भ में stateful। प्रक्रिया (process) को बंद करने पर कनेक्शन टूट जाते हैं; क्लाइंट्स को फिर से कनेक्ट करना पड़ता है। अक्सर, इनमें सावधानी के साथ (sticky sessions, consistent hashing के माध्यम से) क्षैतिज रूप से स्केलिंग की जा सकती है।

- Postgres के सामने एक Redis कैश: कैश की सामग्री के लिए stateful, लेकिन यदि कैश मिस (cache misses) सहनीय हैं तो यह स्वीकार्य है। रिप्लिका की विफलता का अर्थ है कैश मिस, डेटा हानि नहीं।

क्षैतिज स्केलिंग के लिए डिज़ाइन करना = उस परत (layer) से state को बाहर निकालना जिसकी स्केलिंग की आवश्यकता है।

एक संदिग्ध परत (Tier) का ऑडिट करें

एक टीम एक रिवर्स प्रॉक्सी के पीछे 6 बैकएंड VMs पर एक सिफारिश (recommendation) API चलाती है। एप्लिकेशन: अनुरोध से एक उपयोगकर्ता ID पढ़ता है, Postgres से उपयोगकर्ता की हालिया गतिविधि (recent activity) प्राप्त करता है, एक स्कोरिंग एल्गोरिदम चलाता है, और सिफारिशों की एक सूची लौटाता है। दो गैर-मानक व्यवहार:

- एप्लिकेशन प्रोसेस मेमोरी में 'हालिया उपयोगकर्ता गतिविधि' (recent user activity) का एक कैश बनाए रखता है, जो उपयोगकर्ता के लिए पहले अनुरोध पर भरा जाता है और बाद के अनुरोधों में पुनः उपयोग किया जाता है।

- एप्लिकेशन sticky sessions का उपयोग करता है: एक बार जब कोई उपयोगकर्ता VM #3 पर पहुँचता है, तो उसके सभी बाद के अनुरोध VM #3 पर जाते हैं (प्रॉक्सी कुकी पर आधारित sticky राउटिंग के लिए कॉन्फिगर किया गया है)।

रिप्लिका सूत्र

सबसे सरल क्षमता सूत्र

एक बार जब कोई टियर स्टेटलेस हो जाता है, तो उसका साइज़िंग अंकगणित बन जाता है। आपको इतने रिप्लिका चाहिए कि स्थिर-अवस्था (steady-state) का लोड उसी दर से आए और जाए, और सर्ज (surge) के लिए कुछ अतिरिक्त क्षमता (headroom) भी हो।

सूत्र:

replicas = ⌈ (peak_load × surge_factor) / per_replica_capacity ⌉ + headroom

जहाँ:

- peak_load: अधिकतम निरंतर अनुरोध/सेकंड (requests/second) जो आप सामान्य संचालन में अपेक्षा करते हैं

- surge_factor: एक गुणक जो पीक से ऊपर की अल्पकालिक झलक (bursts) को कवर करता है (प्रायः 1.5x से 2x पूर्वानुमानित ट्रैफिक के लिए, और वायरल / अप्रत्याशित के लिए 3x या उससे अधिक)

- per_replica_capacity: अनुरोध/सेकंड जो एक रिप्लिका स्वीकार्य लेटेंसी और उपयोग (utilization) पर संभालता है (प्रायः 70% CPU पर मापा जाता है, संतृप्ति (saturation) पर नहीं)

- headroom: अतिरिक्त रिप्लिका ताकि कुछ रिप्लिका विफलताएं टियर को गिरा न दें (प्रायः छोटे फ्लीट के लिए 1-2 रिप्लिका, और बड़े फ्लीट के लिए 10-20%)

उदाहरण: एक बैकएंड प्रति रिप्लिका पर 70% CPU के साथ 100 req/s संभालता है। पीक लोड 600 req/s है। आपको कभी-कभी 2x सर्ज (अचानक वृद्धि) की उम्मीद है। आप 2 रिप्लिका फेलियर (विरुद्ध) से बचना चाहते हैं।

replicas = ⌈ (600 × 2) / 100 ⌉ + 2 = 12 + 2 = 14 रिप्लिका

80% नियम

प्रति-रिप्लिका क्षमता संतृप्ति बिंदु (saturation point) नहीं है। क्षमता को 100% पर नहीं, बल्कि 70-80% CPU पर मापें।

लगभग 80% उपयोग (utilization) के बाद, क्यूइंग (queueing) वक्र तेजी से ऊपर उठते हैं: एक क्यू जो 60% उपयोग पर 10 ms में चलता था, वह 90% उपयोग पर 80 ms में चलता है। लेटेंसी (latency), थ्रूपुट (throughput) से पहले टूटती है। (संगत पाठ geometry_of_stateless_horizontal_scaling इस वक्र का गणितीय व्युत्पन्न प्रस्तुत करता है।)

ऑटोस्केलिंग बनाम स्थिर प्रोविज़निंग (Static Provisioning)

स्थिर (Static): पीक × सर्ज हेडरूम (surge headroom) के लिए प्रोविजन करें और ऑफ-पीक (off-peak) समय पर कम उपयोग पर चलने के खर्च को स्वीकार करें।

ऑटोस्केलिंग: एक कंट्रोलर (controller) देखा गया उपयोग (utilization), लक्ष्य लेटेंसी (target latency), या क्यू गहराई (queue depth) के आधार पर रिप्लिका जोड़ता और हटाता है।

ऑटोस्केलिंग की चेतावनी: कोल्ड-स्टार्ट समय महत्वपूर्ण है। यदि एक नए रिप्लिका को बूट होने में 2 मिनट लगते हैं, तो ऑटोस्केलिंग 30 सेकंड के सर्ज (अचानक बढ़ोतरी) का जवाब नहीं दे सकता। परिपक्व ऑटोस्केलिंग स्केल-अप थ्रेशोल्ड के ठीक नीचे प्री-प्रोविश्नड रिप्लिकाओं का एक वॉर्म पूल बनाए रखती है।

नए सर्विस के लिए फ्लीट का आकार तय करें

आपकी टीम एक वीडियो मेटाडेटा API लॉन्च करने की योजना बना रही है। बेंचमार्क्स दिखाते हैं कि एक अकेला रिप्लिका 70% CPU और 50 ms p99 लेटेंसी पर 250 req/s संभालता है। मार्केटिंग की भविष्यवाणी के अनुसार, प्राइम-टाइम घंटों में पीक लोड 4,000 req/s तक पहुंचेगा। एक नियोजित प्रमोशनल इवेंट अचानक 3x पीक तक सर्ज कर सकता है। आप चाहते हैं कि सर्विस 3 रिप्लिकाओं की एक साथ होने वाली विफलता (failures) के बावजूद बचने वाले (survivors) रिप्लिकाओं पर 80% उपयोग (utilization) से अधिक न जाए, इस स्थिति में भी टिके।

कोल्ड स्टार्ट, धीमा ड्रेन, और अन्य वास्तविक किनारे (Edges)

वास्तविक फ्लीट्स के पास वास्तविक किनारे (Edges) होते हैं

सूत्र मान लेता है कि रिप्लिका (replicas) तुरंत प्रकट होते हैं, तुरंत ट्रैफ़िक स्वीकार करते हैं, और तुरंत ट्रैफ़िक छोड़ देते हैं। प्रोडक्शन में इनमें से कोई भी सत्य नहीं है।

कोल्ड स्टार्ट: एक नए रिप्लिका को ऑपरेटिंग सिस्टम (OS) को बूट करने, प्रक्रिया शुरू करने, कॉन्फ़िगरेशन लोड करने, कैश को गर्म (warm) करने, और हेल्थ चेक्स पास करने में समय लगता है। यह कहीं 5 सेकंड (कंटेनर रीस्टार्ट) से लेकर 5 मिनट (पूरा VM बूट + इमेज पुल) तक हो सकता है। ऑटोस्केलिंग इस विलंब से छोटे बर्स्ट्स (bursts) के जवाब में नहीं दे सकता।

धीमा ड्रेन: पूल से हटाए जा रहे रिप्लिका को टर्मिनेट होने से पहले इन-फ्लाइट (in-flight) अनुरोधों को पूरा करने के लिए समय चाहिए। अन्यथा उपयोगकर्ताओं को कटौती (truncated) प्रतिक्रियाएं दिखती हैं। रिवर्स प्रॉक्सी ड्रेन का समर्थन करते हैं (नए अनुरोध स्वीकार करना बंद करें, सक्रिय अनुरोधों को पूरा करें), लेकिन इसके लिए सेकंड से मिनट तक का समय लगता है।

वार्म पूल: प्रोडक्शन फ्लीट्स एक पूल रखते हैं जिसमें प्री-प्रोविज़नड लेकिन आइडल रिप्लिकाएँ होती हैं, जो सिग्नल मिलते ही ट्रैफ़िक लेने के लिए तैयार रहती हैं। यह तेज़ सर्ज रिस्पॉन्स के लिए एक छोटी सी स्थिर लागत का समझौता करता है।

कनेक्शन ड्रेनिंग बनाम तुरंत किल: ग्रेसफुल शटडाउन महत्वपूर्ण है। एक SIGTERM जो ड्रेन को ट्रिगर करता है, SIGKILL की तुलना में अधिक समय लेता है, लेकिन यह यूज़र रिक्वेस्ट्स को तोड़ता नहीं है।

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

स्टिकीनेस क्रिप: नॉमिनली स्टेटलेस टियर्स समय के साथ स्टिकीनेस प्राप्त कर लेते हैं (CDN कैश, DNS रिज़ॉल्वर कैश, कनेक्शन पूल्स)। 'समान रिप्लिकाओं' के प्रति संदेह रखें जो फिर भी अलग-अलग व्यवहार करती हैं।

वार्म पूल या रिएक्टिव ऑटोस्केलिंग?

आपका वीडियो मेटाडेटा API (पिछले प्रश्न वाला ही, जो स्टेडी पीक + सर्ज के लिए 51 रिप्लिकाओं पर साइज़ किया गया है) तब 30 सेकंड का 5x सामान्य लोड तक का सर्ज अनुभव करता है जब कोई नया वायरल वीडियो अपलोड होता है। ऑटोस्केलिंग को एक नई रिप्लिका को कोल्ड से जोड़ने में 90 सेकंड लगते हैं (इमेज पुल + वार्मअप)। इस 90 सेकंड के अंतराल के दौरान, लेटेंसी तेजी से बढ़ती है और कुछ रिक्वेस्ट्स टाइम आउट हो जाती हैं।

संकटों के तहत एक स्टेटलेस टियर डिज़ाइन करें

संश्लेषण

आपने सीखा है कि छोटे सीमा के पार होकर क्षैतिज स्केलिंग (horizontal scaling) क्यों जीतती है, व्यावहारिक रूप से 'स्टेट' (state) का क्या अर्थ है, अपेक्षित और सर्ज लोड (surge load) के तहत एक फ्लीट (fleet) का आकार कैसे तय करें, और किन किन किनारों पर क्षैतिज स्केलिंग टूट जाती है।

सभी चारों लागू करें।

feed.example.com, एक सोशल-फीड API के लिए एक बैकएंड टियर डिज़ाइन करें। प्रतिबंध: प्रति-रिप्लिका क्षमता 70% CPU पर 200 req/s; अपेक्षित पीक लोड 1500 req/s; सर्ज गुणक 2.5x (कभी-कभी ट्रेंडिंग स्टोरीज़); 2 एक साथ रिप्लिका विफलताओं का सामना करना; कोल्ड-स्टार्ट समय 60 सेकंड; बर्स्ट 45 सेकंड तक चल सकते हैं; बजट कुछ आइडल क्षमता की अनुमति देता है, लेकिन 2.5x स्थायी प्रोविज़निंग की नहीं।

यह कोर्स अगला कहाँ जाता है

यह कोर्स आगे कहाँ जाता है

अब आपके पास एक stateless tier का एक कार्यशील मानसिक मॉडल है: यह स्केल क्यों होता है, इसका साइज़ कैसे तय करें, इसके किनारों पर क्या टूटता है, और जब आप इसे उस परत से बाहर धकेलते हैं जिसके बढ़ने की आवश्यकता होती है, तो state कहाँ जाना चाहिए।

इस कोर्स का अगला पाठ (cs_distsys_ingress_egress_separation) एक सूक्ष्म समस्या का सामना करता है: आगमन और प्रस्थान यातायात एक ही नेटवर्क पथ साझा करते हैं, तब भी एक पूरी तरह से साइज़ किया गया stateless tier आश्चर्यजनक तरीकों से विफल हो सकता है। क्लासिक उदाहरण एक प्रॉक्सी को खुद से कनेक्ट करने का शामिल है; समाधान एक परत को दो अलग-अलग ज़िम्मेदारियों के साथ दो भागों में बांटने का है।

सहपाठ: geometry_of_stateless_horizontal_scaling क्यूइंग वक्र (queueing curve) व्युत्पन्न करता है, रिप्लिका फ्लीट (replica fleet) पर लागू Little's Law, और 80% उपयोगिता घुटने (knee) की ज्यामितीय अर्थवत्ता।

बहुत अच्छा किया। आगे बढ़ें।