3.5 स्केलेबिलिटी, प्रदर्शन, और रेज़िलिएंस

अवलोकन और प्रेरणा

स्केलेबिलिटी, प्रदर्शन, और रेज़िलिएंस तीन अलग-अलग गुण हैं, और लोग अक्सर इन्हें एक-दूसरे में मिला देते हैं। प्रदर्शन (Performance) यह है कि सिस्टम कितनी तेज़ी से प्रतिक्रिया देता है और प्रति यूनिट संसाधन कितना काम करता है। स्केलेबिलिटी यह है कि भार बढ़ने पर सिस्टम प्रदर्शन को कितनी अच्छी तरह बनाए रखता है। रेज़िलिएंस यह है कि चीज़ें विफल होने पर सिस्टम कितनी अच्छी तरह काम करता रहता है, या सुचारू रूप से घटता है। एक सिस्टम तेज़ लेकिन अस्केलेबल हो सकता है (कम भार पर बढ़िया, उच्च भार पर ढह जाता है), स्केलेबल लेकिन नाज़ुक (मात्रा संभालता है लेकिन एक घटक विफल होने पर गिर जाता है), या रेज़िलिएंट लेकिन धीमा। एक बड़े संगठन को शुरुआत से ही डिज़ाइन में शामिल तीनों की ज़रूरत होती है, क्योंकि लॉन्च के बाद इनमें से किसी को भी पीछे जोड़ना महंगा और बाधाकारी होता है।

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

यह अध्याय क्षैतिज बनाम ऊर्ध्वाधर स्केलिंग, स्केल के सक्षमकर्ताओं के रूप में स्टेटलेसनेस और शार्डिंग, लोड बैलेंसिंग, ऑटोस्केलिंग और क्षमता योजना, स्पष्ट बजट के साथ प्रदर्शन इंजीनियरिंग, रेज़िलिएंस पैटर्न और chaos engineering, और RTO, RPO, और व्यवसाय निरंतरता द्वारा तैयार बहु-क्षेत्र disaster recovery को कवर करता है। एकीकृत संदेश यह है कि ये गुण जानबूझकर किए गए डिज़ाइन और निरंतर टेस्टिंग का परिणाम हैं, आशा का नहीं।

यह भी देखें: अध्याय 3.3 (वितरित सिस्टम), अध्याय 9.1 (साइट रिलायबिलिटी इंजीनियरिंग), और अध्याय 9.2 (ऑब्ज़र्वेबिलिटी और निगरानी)।

मुख्य सिद्धांत

स्केल-अप के लिए नहीं, स्केल-आउट के लिए डिज़ाइन करें। ऊर्ध्वाधर स्केलिंग की एक सीमा होती है और एक single point of failure होता है; क्षैतिज स्केलिंग वह तरीका है जिससे आप बड़े, रेज़िलिएंट पैमाने तक पहुंचते हैं।
स्टेटलेसनेस क्षैतिज स्केल का सक्षमकर्ता है। यदि कोई भी रिक्वेस्ट किसी भी इंस्टेंस पर जा सकती है, तो आप क्षमता को स्वतंत्र रूप से जोड़ और हटा सकते हैं।
आप जो मापते नहीं उसे सुधार नहीं सकते। प्रदर्शन का काम प्रोफाइलिंग और स्पष्ट बजट के मुकाबले लोड टेस्टिंग से संचालित होता है, कभी अनुमान से नहीं।
हर चीज़ विफल होती है; उसके लिए डिज़ाइन करें। मान लें कि घटक विफल होंगे और ऐसा बनाएं कि सिस्टम उनकी विफलता से बच जाए।
सुचारू क्षरण कठोर विफलता से बेहतर है। एक आंशिक रूप से काम करने वाला सिस्टम जो गैर-आवश्यक फ़ीचर छोड़ देता है, एक पूर्ण आउटेज से बेहतर है।
क्षमता की योजना बनाई जाती है, उछाल को अवशोषित किया जाता है। पूर्वानुमेय भार का पूर्वानुमान लगाएं; बाकी के लिए ऑटोस्केलिंग और हेडरूम का उपयोग करें।
पुनर्प्राप्ति लक्ष्य व्यावसायिक निर्णय हैं। RTO और RPO लागत के मुकाबले व्यवसाय द्वारा चुने जाते हैं, फिर उनके लिए इंजीनियरिंग की जाती है।
रेज़िलिएंस को जानबूझकर टेस्ट करें। जब तक आपने किसी सिस्टम को जानबूझकर विफल नहीं किया, आप नहीं जानते कि वह रेज़िलिएंट है।

सिफारिशें

क्षैतिज स्केलिंग को प्राथमिकता दें और स्टेटलेस सेवाएं डिज़ाइन करें

ऊर्ध्वाधर स्केलिंग (बड़ी मशीनें) सरल है और कभी-कभी सही पहला कदम है, लेकिन यह एक कठोर सीमा से टकराती है, ऊपरी छोर पर असमान रूप से महंगी हो जाती है, और एक single point of failure छोड़ जाती है। क्षैतिज स्केलिंग (लोड बैलेंसर के पीछे अधिक मशीनें) बहुत आगे तक स्केल करती है और उपलब्धता में सुधार करती है, क्योंकि एक इंस्टेंस खोना सहनीय है। पूर्वशर्त स्टेटलेसनेस है। इंस्टेंस पर कोई क्लाइंट सेशन या रिक्वेस्ट स्थिति न रखें; इसे एक साझा स्टोर (डेटाबेस, कैश, टोकन) में भेजें। स्टेटलेस सेवाओं को स्वतंत्र रूप से जोड़ा, हटाया, बदला, और लोड-बैलेंस किया जा सकता है, जो ऑटोस्केलिंग और रोलिंग डिप्लॉयमेंट दोनों को संभव बनाता है। जहां स्थिति को विभाजित करना ज़रूरी हो, ऐसी की (key) से शार्ड करें जो भार को समान रूप से वितरित करे और संबंधित डेटा को एक ही शार्ड पर रखे।

लोड-बैलेंस करें, ऑटोस्केल करें, और क्षमता की योजना बनाएं

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

स्पष्ट बजट के मुकाबले प्रदर्शन इंजीनियर करें

प्रदर्शन बजट सेट करें (ठोस लक्ष्य जैसे 200 ms से कम p95 API विलंबता, 2 सेकंड से कम पेज इंटरैक्टिव, या एक सीमा से कम प्रति-लेनदेन लागत) और इन्हें टेस्टिंग और निगरानी में लागू करें ताकि रिग्रेशन उपयोगकर्ताओं तक पहुंचने के बजाय पाइपलाइन को विफल कर दें। ऑप्टिमाइज़ेशन को मापन से संचालित करें। वास्तविक बाधा (bottleneck) खोजने के लिए प्रोफ़ाइल करें, जो शायद ही कभी वहां होती है जहां आप अनुमान लगाते हैं, और यह पता लगाने के लिए लोड-टेस्ट करें कि सिस्टम कहां टूटता है और उस सीमा के पास कैसा व्यवहार करता है। क्रिटिकल पाथ और पूंछ (p95/p99) पर ध्यान केंद्रित करें, क्योंकि पैमाने पर पूंछ की विलंबताएं उपयोगकर्ता अनुभव पर हावी रहती हैं। सबसे बड़ी बाधा को पहले ऑप्टिमाइज़ करें, फिर से मापें, और जब आप बजट पूरा कर लें तो रुक जाएं। पहले से पर्याप्त कोड को अति-ऑप्टिमाइज़ करना बर्बाद प्रयास है।

रेज़िलिएंस पैटर्न बनाएं और chaos engineering से सत्यापित करें

वितरित सिस्टम के रेज़िलिएंस पैटर्न लागू करें: टाइमआउट, बैकऑफ़ के साथ सीमित रीट्राई, circuit breakers (जो किसी डिपेंडेंसी के अस्वस्थ होने पर तेज़ी से विफल होते हैं), और bulkheads (जो संसाधन पूल को अलग करते हैं ताकि एक विफलता बाकी को समाप्त न कर सके), साथ ही सुचारू क्षरण (तनाव के तहत गैर-आवश्यक फ़ीचर छोड़ें या सरल बनाएं: सिफारिशें अक्षम करें, कैश की गई सामग्री परोसें, गैर-तत्काल काम को कतारबद्ध करें) और load shedding (मूल को सुरक्षित रखने के लिए अतिरिक्त रिक्वेस्ट को अस्वीकार या सीमित करें बजाय पूरी तरह ढहने के)। हर परत पर रिडंडेंसी के ज़रिए single points of failure को समाप्त करें। फिर chaos engineering से रेज़िलिएंस को सत्यापित करें। नियंत्रित प्रयोगों में जानबूझकर विफलताएं डालें (इंस्टेंस मारें, विलंबता जोड़ें, कोई डिपेंडेंसी काटें, एक ज़ोन विफल करें), टेस्ट में शुरू करके प्रोडक्शन गेम डे तक परिपक्व होते हुए, यह साबित करने के लिए कि सिस्टम डिज़ाइन के अनुसार व्यवहार करता है। कभी टेस्ट न की गई रेज़िलिएंस केवल एक परिकल्पना है।

बहु-क्षेत्र, disaster recovery, और व्यवसाय निरंतरता की योजना बनाएं

पुनर्प्राप्ति लक्ष्यों को स्पष्ट रूप से तय करें: RTO (Recovery Time Objective, आप कितनी देर डाउन रह सकते हैं) और RPO (Recovery Point Objective, आप कितना डेटा खोना सहन कर सकते हैं)। ये प्रत्यक्ष लागत परिणामों वाले व्यावसायिक निर्णय हैं, और ये आर्किटेक्चर को संचालित करते हैं। विकल्प लागत और गति में भिन्न होते हैं: बैकअप-और-रीस्टोर (सबसे सस्ता, सबसे धीमा), पायलट लाइट, वार्म स्टैंडबाय, और एक्टिव-एक्टिव बहु-क्षेत्र (सबसे महंगा, लगभग-शून्य RTO/RPO)। वह स्तर चुनें जिसे हर सिस्टम की गंभीरता उचित ठहराती है। हर चीज़ को एक्टिव-एक्टिव की ज़रूरत नहीं होती। चुने गए RPO के अनुरूप क्षेत्रों में डेटा को प्रतिकृत (replicate) करें, फ़ेलओवर को स्वचालित करें, और, सबसे बढ़कर, फ़ेलओवर का नियमित रूप से परीक्षण करें। कभी टेस्ट न की गई disaster recovery अंततः ज़रूरत पड़ने पर भरोसेमंद तरीके से विफल होती है। इस सबको लोगों, संचार, और मैनुअल फ़ॉलबैक को कवर करने वाली एक व्यवसाय निरंतरता योजना में लपेटें, केवल तकनीक को नहीं।

समझौते: फ़ायदे और नुकसान

विकल्प	फ़ायदे	नुकसान
ऊर्ध्वाधर स्केलिंग	सरल, कोई कोड बदलाव नहीं, कम प्रारंभिक प्रयास	कठोर सीमा, ऊपरी छोर पर महंगा, single point of failure
क्षैतिज स्केलिंग	लगभग-असीमित पैमाना, उपलब्धता में सुधार	स्टेटलेसनेस, लोड बैलेंसिंग, अधिक ऑप्स की आवश्यकता
ऑटोस्केलिंग	मांग के अनुसार लागत, परिवर्तनशील भार संभालता है	देरी से प्रतिक्रिया; कोल्ड स्टार्ट; गलत ट्यूनिंग पर थ्रैश हो सकता है
एक्टिव-एक्टिव बहु-क्षेत्र	लगभग-शून्य RTO/RPO, क्षेत्रीय हानि में बचा रहता है	उच्चतम लागत और जटिलता, कठिन डेटा स्थिरता
बैकअप-और-रीस्टोर DR	सबसे सस्ता, सबसे सरल	लंबा RTO, बड़ी डेटा-हानि विंडो

केंद्रीय समझौता लागत बनाम आश्वासन है। स्केलेबिलिटी हेडरूम, प्रदर्शन, और पुनर्प्राप्ति क्षमता की हर वृद्धि पैसा और जटिलता खर्च करती है, और रिटर्न गैर-रैखिक होते हैं। 99.9% से 99.99% उपलब्धता तक जाना, या एक घंटे के RTO से सेकंडों तक जाना, लागत को कई गुना बढ़ा सकता है। अनुशासन यह है कि हर निवेश को सिस्टम की वास्तविक गंभीरता और व्यवसाय की डाउनटाइम व डेटा हानि की सहनशीलता के अनुरूप आकार दें, बजाय सब कुछ रिफ्लेक्सिव रूप से उच्चतम स्तर पर इंजीनियर करने के। एक नागरिक-सामना करने वाला भुगतान सिस्टम एक्टिव-एक्टिव रिडंडेंसी अर्जित करता है; एक आंतरिक रिपोर्टिंग टूल नहीं।

अपनी टीम के साथ चर्चा करने के लिए सवाल

आपकी आखिरी गंभीर घटना के समय, तीनों में से (प्रदर्शन, स्केलेबिलिटी, रेज़िलिएंस) वास्तव में क्या विफल हुआ, और क्या आपने सही चीज़ को ठीक किया? यह अध्याय इन्हें जानबूझकर अलग करता है: एक सिस्टम तेज़ हो सकता है फिर भी भार के तहत ढह सकता है, स्केल कर सकता है फिर भी एक घटक मरने पर गिर सकता है, या धीमा होते हुए भी विफलताओं में बच सकता है। टीमें अक्सर गलत निदान करती हैं, एक रेज़िलिएंस समस्या में क्षमता जोड़ती हैं या एक ऐसे सिस्टम को मज़बूत बनाती हैं जो केवल किसी उछाल के लिए कम-प्रावधानित था। पिछली दो गंभीर घटनाओं को देखें और नाम दें कि कौन सा गुण टूटा और प्रतिक्रिया ने वास्तव में क्या सुधारा। यह भेद समाधान को बदल देता है: स्केल के लिए स्टेटलेसनेस और शार्डिंग, रेज़िलिएंस के लिए रिडंडेंसी और circuit breakers, प्रदर्शन के लिए प्रोफाइलिंग और बजट। श्रेणी को सही पाना इलाज पर खर्च करने और एक लक्षण पर खर्च करने के बीच का अंतर है।
क्या प्रदर्शन रिग्रेशन आपकी पाइपलाइन को विफल करते हैं, या वे किसी के नोटिस करने से पहले उपयोगकर्ताओं तक पहुंच जाते हैं? एक प्रदर्शन बजट (p95 विलंबता, पेज-इंटरैक्टिव समय, प्रति-लेनदेन लागत) उपयोगकर्ताओं की रक्षा तभी करता है जब इसे स्वचालित रूप से लागू किया जाए, ताकि इसे तोड़ने वाला बदलाव शिप होने के बजाय बिल्ड को विफल कर दे। कई योगदानकर्ताओं वाली एक बड़ी टीम पर, विलंबता हज़ारों छोटे कमिट के ज़रिए रेंगकर आती है, और बिना किसी गेट के पूंछ धीरे-धीरे सड़ती जाती है जब तक कोई लॉन्च इसे उजागर न कर दे। अपने वर्तमान बजट लाएं और जांचें कि क्या वे CI और निगरानी में जुड़े हैं, और क्या वे औसत के बजाय p95 और p99 को लक्षित करते हैं, क्योंकि पैमाने पर उपयोगकर्ता पूंछ को ही महसूस करते हैं। जहां कोई बजट मौजूद नहीं, एक सेट करना पहला कदम है। लागू करना ही वह है जो एक अच्छे इरादे को ऐसी संपत्ति में बदलता है जो टीम के विकास से बच जाती है।
तनाव के तहत, सबसे पहले क्या छोड़ा जाता है, और क्या आपने उस क्रम को डिज़ाइन किया या आप इसे आउटेज में खोजेंगे? सुचारू क्षरण और load shedding का मतलब है कि सिस्टम मूल की रक्षा के लिए गैर-आवश्यक काम छोड़ देता है, लेकिन केवल तभी जब आपने पहले से तय किया हो कि आवश्यक क्या है। एक नागरिक-सामना करने वाली सेवा के लिए वह प्राथमिकता अक्सर एक नीतिगत निर्णय होता है: एक कर रिटर्न जमा करना तब भी जीवित रहना चाहिए भले ही स्थिति डैशबोर्ड और ऐतिहासिक लुकअप बंद हो जाएं। यदि किसी ने नहीं चुना, तो सिस्टम जो भी पहले विफल होता है उसे छोड़ देता है, जो ठीक वही चीज़ हो सकती है जिसकी उपयोगकर्ताओं को सबसे अधिक ज़रूरत है। अपने फ़ीचर को प्राथमिकता क्रम में सूचीबद्ध करें और पुष्टि करें कि आर्किटेक्चर कम-प्राथमिकता वाले (कैश की गई प्रतिक्रियाएं, अक्षम सिफारिशें, कतारबद्ध गैर-तत्काल काम) को क्रिटिकल पाथ को साथ लिए बिना छोड़ सकता है। फिर इसे वास्तविक भार के तहत टेस्ट करें, क्योंकि बिना टेस्ट किया गया क्षरण केवल एक आशा है।
आपके सबसे महत्वपूर्ण सिस्टम के लिए, RTO और RPO क्या हैं, वास्तव में उन संख्याओं को किसने चुना, और आपने आखिरी बार कब साबित किया कि आप उन्हें पूरा कर सकते हैं? Recovery Time Objective (आप कितनी देर डाउन रह सकते हैं) और Recovery Point Objective (आप कितना डेटा खोना सहन कर सकते हैं) प्रत्यक्ष लागत परिणामों वाले व्यावसायिक निर्णय हैं, फिर भी एक बड़ी टीम पर इन्हें अक्सर उसी ने बनाया होता है जिसने रनबुक लिखी थी, न कि उन लोगों के स्वामित्व में जो सेवा के लिए जवाबदेह हैं। प्रतिस्पर्धी खिंचाव लागत बनाम आश्वासन है: RTO को एक घंटे से सेकंडों तक या RPO को मिनटों से शून्य तक सिकोड़ना इन्फ्रास्ट्रक्चर बिल को कई गुना बढ़ा सकता है, इसलिए सही संख्या वह है जिसे व्यवसाय वास्तव में चुकाएगा, सबसे प्रभावशाली वाली नहीं। दस्तावेज़ीकृत लक्ष्य, आखिरी वास्तविक फ़ेलओवर टेस्ट की तारीख, और उस टेस्ट से मापा गया समय और डेटा हानि लाएं, क्योंकि एक बिना टेस्ट किया गया लक्ष्य केवल एक इच्छा है। एंटरप्राइज़ और सरकारी परिवेशों में ये संख्याएं क़ानून, अनुबंध, या SLA द्वारा तय की जा सकती हैं, इसलिए बताएं कि इन पर कौन हस्ताक्षर करता है और क्या आखिरी रिहर्सल ने बाध्यता पूरी की या चुपचाप चूक गई।
अपने सबसे बड़े पूर्वानुमेय उछाल के लिए, क्या आप ऑटोस्केलिंग पर भरोसा कर रहे हैं कि वह उसी क्षण प्रतिक्रिया देगी, या आपने भार का पूर्वानुमान लगाया, पूर्व-प्रावधान किया, और उस लक्ष्य के लिए लोड-टेस्ट किया? ऑटोस्केलिंग देरी से प्रतिक्रिया देती है और कोल्ड स्टार्ट ठीक तब विलंबता जोड़ते हैं जब आप इसे सबसे कम सहन कर सकते हैं, इसलिए एक ज्ञात कदम-परिवर्तन (एक फाइलिंग डेडलाइन, एक नामांकन विंडो, एक बिक्री कार्यक्रम) ठीक वही मामला है जहां प्रतिक्रियाशील स्केलिंग विफल होती है और जानबूझकर क्षमता योजना जीतती है। तनाव लागत है: पीक के लिए क्षमता को पूर्व-वार्म करने का मतलब है ऐसे हेडरूम के लिए भुगतान करना जो साल के अधिकांश समय निष्क्रिय रहता है, और प्रलोभन यह आशा करना है कि ऑटोस्केलिंग इसे मुफ़्त में संभाल लेगी। पिछले साल की पीक संख्याएं, इस साल का वृद्धि के साथ पूर्वानुमान, और उस पूर्वानुमान के कई गुना तक चलाए गए लोड टेस्ट के परिणाम लाएं, न कि आज के औसत ट्रैफ़िक तक। एक सरकारी या एंटरप्राइज़ सेवा के लिए जो कानूनी रूप से समयबद्ध उछाल का सामना करती है, इसे गलत करने का परिणाम जोड़ें, क्योंकि एक लाभ पोर्टल या कर सिस्टम जो पहले दिन ही लड़खड़ा जाता है वह एक सार्वजनिक जांच बन जाता है, केवल एक धीमी दोपहर नहीं।
क्या आपने कभी प्रोडक्शन में जानबूझकर किसी घटक को विफल किया है, और क्या हर सिस्टम की रिडंडेंसी स्तर वास्तव में उसकी गंभीरता और लागत से मेल खाती है? कभी टेस्ट न की गई रेज़िलिएंस एक परिकल्पना है, और जो स्तर आप खरीद सकते हैं वे सस्ते बैकअप-और-रीस्टोर से लेकर वार्म स्टैंडबाय होते हुए महंगे एक्टिव-एक्टिव बहु-क्षेत्र तक होते हैं, इसलिए अनुशासन यह है कि आश्वासन वहां खर्च करें जहां यह उचित है, न कि सब कुछ सजाना या कुछ भी सुरक्षित न करना। प्रतिस्पर्धी विचार विस्फोट त्रिज्या (blast radius) और बजट हैं: chaos प्रयोगों में गार्डरेल और एक अबॉर्ट स्विच होना चाहिए, और एक आंतरिक रिपोर्टिंग टूल के लिए एक्टिव-एक्टिव बर्बादी है जबकि एक भुगतान प्लेटफ़ॉर्म के लिए केवल-बैकअप लापरवाही है। अपने single points of failure की एक सूची, हर क्रिटिकल सिस्टम की रिडंडेंसी स्तर, और आखिरी नियंत्रित विफलता इंजेक्शन का प्रमाण और उसने क्या उजागर किया लाएं। एंटरप्राइज़ और सरकारी पोर्टफोलियो में, हर स्तर को एक दस्तावेज़ीकृत गंभीरता रेटिंग से मैप करें ताकि एक ऑडिटर देख सके कि पैसा जोखिम का अनुसरण करता है, और ताकि किसी को आउटेज के दौरान पहली बार खर्च का बचाव न करना पड़े।

क्षेत्र लेंस

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

लघु व्यवसाय। बिना किसी रिलायबिलिटी विशेषज्ञ और सीमित बजट के, खरीदने-बनाम-बनाने का चुनाव खरीदने की ओर ज़ोरदार झुकता है: एक प्रबंधित प्लेटफ़ॉर्म या सर्वरलेस स्टैक स्केलिंग और फ़ेलओवर को प्रदाता का काम बना देता है, और आमतौर पर एक ही अच्छी तरह चलाया गया क्षेत्र पर्याप्त होता है। रेज़िलिएंस को कुछ ठोस वादों के रूप में फ़्रेम करें जिन्हें आप निभा सकते हैं, जैसे एक रात्रिकालीन बैकअप जिससे आपने वास्तव में एक बार रीस्टोर किया हो और एक यथार्थवादी पुनर्प्राप्ति विंडो जो आपने ग्राहकों को बताई हो। ऐसे एक्टिव-एक्टिव या निरंतर लोड टेस्टिंग के लिए भुगतान करने से बचें जिसका न आपके पास ट्रैफ़िक है न स्टाफ़।

एंटरप्राइज़। समस्या कई टीमों में स्थिरता की है: CI में लागू प्रदर्शन बजट, रेज़िलिएंस पैटर्न (टाइमआउट, circuit breakers, bulkheads) की एक साझा लाइब्रेरी, और हर सिस्टम की गंभीरता से जुड़ी एक दस्तावेज़ीकृत रिडंडेंसी स्तर को मानकीकृत करें। टियर-वन सेवाओं के लिए एक्टिव-एक्टिव बहु-क्षेत्र सुरक्षित रखें, गार्डरेल और प्रोडक्शन गेम डे के साथ एक chaos engineering कार्यक्रम चलाएं, और ज्ञात उछाल के लिए क्षमता योजना को एक बाद की सोच के बजाय एक निर्धारित अनुशासन मानें। RTO और RPO को केंद्रीय रूप से शासित करें ताकि हर क्रिटिकल सिस्टम के पास स्वामित्व वाले, टेस्ट किए गए लक्ष्य हों जिन्हें एक ऑडिटर सत्यापित कर सके।

सरकार। भार अक्सर कानूनी रूप से समयबद्ध होता है और उपलब्धता बाध्यताएं वैधानिक होती हैं, इसलिए क्षमता योजना उसी क्षण प्रतिक्रिया देने वाली ऑटोस्केलिंग पर निर्भर नहीं हो सकती: डेडलाइन उछाल का पूर्वानुमान लगाएं, पूर्व-प्रावधान करें, और पूर्वानुमान से काफ़ी ऊपर तक लोड-टेस्ट करें। खरीद में RTO, RPO, और रिहर्सल किए गए फ़ेलओवर की एक अनुसूची को वेंडर के वादों के बजाय संविदात्मक आवश्यकताओं के रूप में निर्दिष्ट करना चाहिए, और क्रिटिकल सेवाओं के लिए एकल-क्षेत्र लॉक-इन से बचना चाहिए। पहले से तय करें कि कौन सा रास्ता कानूनी रूप से आवश्यक है (एक रिटर्न जमा करना, एक लाभ का दावा करना) ताकि क्षरण पहले स्थिति डैशबोर्ड और लुकअप को छोड़े, और आउटेज व पुनर्प्राप्ति के बारे में जनता के साथ पारदर्शी रहें बजाय यह आशा करने के कि किसी को पता नहीं चलेगा।

उदाहरण

स्टार्टअप। Product Hunt पर लॉन्च करने वाला एक छोटा स्टार्टअप पूर्वानुमान नहीं लगा सकता कि उसे पचास साइनअप मिलेंगे या पचास हज़ार, इसलिए यह एक प्रबंधित लोड बैलेंसर के पीछे अपनी सेवाओं को स्टेटलेस रखता है और प्लेटफ़ॉर्म को रिक्वेस्ट दर पर ऑटोस्केल करने देता है। यह एक मामूली प्रदर्शन बजट सेट करता है (95वें प्रतिशतक पर पेज 300ms से कम में प्रतिक्रिया देते हैं) और एक प्रबंधित डेटाबेस चुनता है ताकि ट्रैफ़िक उछाल इसे रात 2 बजे की री-आर्किटेक्चर के लिए मजबूर न करे। जब लॉन्च-दिन का उछाल आता है, साइट थोड़ी धीमी हो जाती है बजाय गिरने के, और टीम आउटेज से लड़ने के बजाय नए उपयोगकर्ताओं से बात करते हुए दिन बिताती है।

एंटरप्राइज़। एक स्ट्रीमिंग मीडिया कंपनी वैश्विक लोड बैलेंसिंग के पीछे कई क्षेत्रों में स्टेटलेस सेवाएं चलाती है, दैनिक प्राइम-टाइम लहर का पालन करने के लिए रिक्वेस्ट दर पर ऑटोस्केलिंग करती है। प्रदर्शन बजट p99 स्टार्टअप विलंबता पर हर रिलीज़ को गेट करते हैं। एक क्षेत्रीय विफलता के तहत, ट्रैफ़िक स्वचालित रूप से स्वस्थ क्षेत्रों में स्थानांतरित हो जाता है, और गैर-आवश्यक फ़ीचर (व्यक्तिगत आर्टवर्क, सिफारिश ताज़गी) प्लेबैक की रक्षा के लिए पहले घटते हैं। कंपनी प्रोडक्शन में निरंतर chaos प्रयोग चलाती है, नियमित रूप से इंस्टेंस समाप्त करती है और विलंबता डालती है, ताकि वास्तविक विफलताएं ड्रिल से अप्रभेद्य हों और कोई ग्राहक-दृश्य आउटेज न बने।

सरकार। एक कर एजेंसी जानती है कि उसका फाइलिंग सिस्टम हर साल एक विशाल, कानूनी रूप से तय डेडलाइन उछाल का सामना करता है। उसी क्षण प्रतिक्रिया देने के लिए ऑटोस्केलिंग पर भरोसा करने के बजाय, यह पिछले वर्षों से पीक भार का पूर्वानुमान लगाती है, हफ्तों पहले क्षमता को पूर्व-प्रावधानित करती है, और पूर्वानुमान के 150% तक लोड-टेस्ट करती है। आर्किटेक्चर एक वार्म-स्टैंडबाय दूसरे क्षेत्र के साथ लोड बैलेंसर के पीछे स्टेटलेस है। RTO और RPO नीति द्वारा तय किए जाते हैं (जमा किए गए रिटर्न के लिए 15 मिनट से अधिक डाउनटाइम नहीं और लगभग-शून्य डेटा हानि), और फ़ेलओवर की तिमाही रिहर्सल होती है। अत्यधिक भार के तहत, गैर-क्रिटिकल फ़ीचर (स्थिति डैशबोर्ड, ऐतिहासिक लुकअप) पहले छूटते हैं ताकि रिटर्न सबमिशन, कानूनी रूप से आवश्यक रास्ता, उपलब्ध रहे।

व्यावसायिक मामला: प्रेरणाएं, ROI, और TCO

स्केलेबिलिटी, प्रदर्शन, और रेज़िलिएंस क्लासिक मामले हैं जहां विफलता की लागत रोकथाम की लागत से बहुत अधिक होती है। लेकिन रोकथाम बजट पर दिखाई देती है और विफलता केवल संभावित होती है, यही कारण है कि इन्हें पहली आपदा तक लगातार कम-वित्तपोषित रखा जाता है। अपनाने की लागत वास्तविक है: अनावश्यक इन्फ्रास्ट्रक्चर, बहु-क्षेत्र क्षमता, लोड-टेस्टिंग और chaos टूलिंग, और स्टेटलेसनेस व रेज़िलिएंस पैटर्न बनाने का इंजीनियरिंग समय। निवेश न करने की लागत पीक मांग के दौरान एक हाई-प्रोफ़ाइल आउटेज है: वाणिज्य के लिए हर मिनट खोया राजस्व, सरकार के लिए चूकी गई वैधानिक बाध्यताएं और सार्वजनिक जांच, service-level agreement (SLA) दंड, और स्थायी प्रतिष्ठा क्षति।

नेतृत्व के सामने मामला ऐसी संख्याओं से रखें जिन्हें व्यवसाय पहले से समझता है। पीक के दौरान एक घंटे के डाउनटाइम की लागत का अनुमान लगाएं (खोए गए लेनदेन, दंड, सुधार, प्रतिष्ठा), फिर इसकी तुलना उस रिडंडेंसी और टेस्टिंग की वार्षिक लागत से करें जो इसे रोकती है। क्रिटिकल सिस्टम के लिए रोकथाम लगभग हमेशा एक बड़ी घटना के एक अंश के बराबर होती है। RTO और RPO को स्पष्ट पैसे से जोड़ें: डाउनटाइम के प्रति घंटे कितना राजस्व या कितने लेनदेन, और कानूनी या व्यावसायिक रूप से कितनी डेटा हानि सहनीय है। प्रदर्शन को राजस्व और संतुष्टि लीवर के रूप में प्रस्तुत करें, क्योंकि तेज़ सिस्टम बेहतर रूपांतरित होते हैं और प्रति लेनदेन कम खर्च करते हैं, और रेज़िलिएंस को ऐसे बीमा के रूप में प्रस्तुत करें जिसका प्रीमियम कवर की गई हानि के मुकाबले छोटा है। सबसे मज़बूत तर्क यह है कि ये गुण डिज़ाइन में शामिल करना सस्ता है और उस आउटेज के बाद पीछे जोड़ना विनाशकारी है जो मुद्दे को मजबूर करता है।

एंटी-पैटर्न और नुकसान

स्टिकी सेशन और इन-इंस्टेंस स्थिति। सर्वर पर सेशन स्थिति संग्रहीत करना, जो स्वतंत्र क्षैतिज स्केलिंग और सुरक्षित इंस्टेंस प्रतिस्थापन को रोकता है।
क्षमता योजना के रूप में ऑटोस्केलिंग। यह मान लेना कि ऑटोस्केलिंग एक ज्ञात कदम-परिवर्तन उछाल को अवशोषित कर लेगी जिस पर प्रतिक्रिया देने में यह बहुत धीमी है।
बिना हेडरूम के गर्म चलना। लगभग-100% उपयोग पर संचालन करना, उछाल या विफलताओं को अवशोषित करने के लिए कुछ भी न छोड़ना।
बिना प्रोफाइलिंग के ऑप्टिमाइज़ करना। ऐसे कोड को ट्यून करना जो बाधा नहीं है जबकि वास्तविक बाधा अछूती रह जाती है।
पूंछ को नज़रअंदाज़ करना। औसत विलंबता रिपोर्ट करना जबकि p99 उपयोगकर्ता पीड़ित होते हैं; औसत पैमाने पर दर्द छुपा देते हैं।
बिना टेस्ट किया गया disaster recovery। एक DR योजना और बैकअप जिनका कभी अभ्यास नहीं किया गया और जो ज़रूरत पड़ने पर विफल होंगे।
Single points of failure। एक लोड बैलेंसर, एक डेटाबेस प्राइमरी, एक क्षेत्र: एक अनावश्यक घटक जो सब कुछ गिरा देता है।
बिना गार्डरेल के chaos engineering। बिना किसी blast-radius नियंत्रण या अबॉर्ट स्विच के विफलताएं डालना, जिससे वही आउटेज होता है जिसे आप रोकना चाहते थे।

परिपक्वता मॉडल

स्तर 1: आरंभ करें। तदर्थ और प्रतिक्रियाशील। एकल-इंस्टेंस या ऊर्ध्वाधर रूप से स्केल किया गया, स्थिति सर्वर पर रखी गई। कोई लोड टेस्टिंग नहीं, कोई प्रदर्शन बजट नहीं, और कभी-कभार बैकअप के अलावा कोई disaster recovery नहीं जिनसे किसी ने कभी रीस्टोर नहीं किया। कोई भी घटक विफलता पूर्ण आउटेज का कारण बनती है, और स्केल समस्याएं प्रोडक्शन में खोजी जाती हैं।
स्तर 2: विकसित करें। बुनियादी प्रैक्टिस दिखाई देती हैं लेकिन टीम-दर-टीम भिन्न होती हैं। कुछ सेवाएं एक लोड बैलेंसर के पीछे क्षैतिज रूप से स्केल और स्टेटलेस हैं, उनमें से कुछ पर बुनियादी ऑटोस्केलिंग है। बड़े लॉन्च से पहले लोड टेस्टिंग होती है लेकिन नियमित रूप से नहीं, और बैकअप मौजूद हैं जबकि disaster recovery दस्तावेज़ीकृत है लेकिन शायद ही कभी अभ्यास किया जाता है। जो एक टीम अच्छी तरह करती है वह दूसरी ने शुरू भी नहीं किया।
स्तर 3: मानकीकृत करें। प्रैक्टिस पूरे संगठन में दस्तावेज़ीकृत और लागू हैं। हेडरूम के साथ ज्ञात उछाल के लिए क्षमता की योजना बनाई जाती है, प्रदर्शन बजट CI में लागू किए जाते हैं ताकि रिग्रेशन बिल्ड को विफल करें, और रेज़िलिएंस पैटर्न (टाइमआउट, सीमित रीट्राई, circuit breakers, bulkheads) प्लस सुचारू क्षरण डिफ़ॉल्ट हैं। RTO और RPO प्रति सिस्टम परिभाषित हैं, रिडंडेंसी स्तर गंभीरता के अनुसार सौंपे जाते हैं, और disaster-recovery फ़ेलओवर टीमों में नियमित अनुसूची पर टेस्ट किया जाता है।
स्तर 4: प्रबंधित करें। गुणों को बेसलाइन के मुकाबले मापा और नियंत्रित किया जाता है। टीमें p95 और p99 विलंबता, एरर बजट, और पूर्वानुमान के मुकाबले उपयोग व हेडरूम को ट्रैक करती हैं, और उल्लंघनों पर अलर्ट करती हैं बजाय उन्हें लॉन्च पर खोजने के। टेस्ट किए गए फ़ेलओवर समय की तुलना लक्ष्य RTO और RPO से की जाती है, क्षरण और load-shedding सीमाओं को मेट्रिक्स से सत्यापित किया जाता है, और रिलीज़ व क्षमता पर गो या नो-गो निर्णय डेटा द्वारा संचालित होते हैं। जहां संख्याएं बेसलाइन से भटकती हैं, वह अंतर औसतों के पीछे छुपे रहने के बजाय दिखाई देता है और स्वामित्व में लिया जाता है।
स्तर 5: समन्वयित करें। स्केलेबिलिटी, प्रदर्शन, और रेज़िलिएंस पूरे संगठन में लगातार सुधारे और एकीकृत किए जाते हैं। एक्टिव-एक्टिव बहु-क्षेत्र का उपयोग वहां किया जाता है जहां गंभीरता इसे उचित ठहराती है, chaos engineering प्रोडक्शन गेम डे सहित निरंतर चलता है, और क्षमता पूर्वानुमान सीधे योजना और खरीद में फ़ीड होता है। रेज़िलिएंस का निरंतर आधार पर सत्यापन किया जाता है, पुनर्प्राप्ति लक्ष्य लगातार पूरे और साबित किए जाते हैं, और आर्किटेक्चर व्यवसाय निरंतरता व जोखिम योजना से जुड़ते हुए, भार पैटर्न और जोखिम चित्र बदलने पर अनुकूलित होता है।

चर्चा के लिए विचार

आपकी कौन सी सेवाएं अभी भी इंस्टेंस पर स्थिति रखती हैं, और आपको उन्हें स्टेटलेस बनाने से क्या रोकता है?
आपके सबसे महत्वपूर्ण सिस्टम के लिए, RTO और RPO क्या हैं, उन्हें किसने तय किया, और आपने आखिरी बार कब साबित किया कि आप उन्हें पूरा कर सकते हैं?
क्या ऑटोस्केलिंग वास्तव में आपके सबसे बड़े ज्ञात उछाल के खिलाफ आपकी रक्षा करती है, या आप इससे कुछ ऐसा करवाने पर भरोसा कर रहे हैं जो यह नहीं कर सकती?
आपका शेष single point of failure कहां है, और इसे हटाने की योजना क्या है?
क्या आप p99 विलंबता माप और बजट कर रहे हैं, या औसतों के पीछे छुप रहे हैं?
क्या आपने कभी प्रोडक्शन में जानबूझकर किसी घटक को विफल किया है? यदि नहीं, तो आपको कैसे पता कि आपकी रेज़िलिएंस काम करती है?

मुख्य निष्कर्ष

प्रदर्शन, स्केलेबिलिटी, और रेज़िलिएंस के बीच अंतर करें; एक बड़े सिस्टम को शुरुआत से ही डिज़ाइन में शामिल तीनों की ज़रूरत होती है।
क्षैतिज स्केलिंग और स्टेटलेस सेवाएं पैमाने, उपलब्धता, और सुरक्षित डिप्लॉयमेंट की नींव हैं।
पूर्वानुमेय, व्यवसाय-महत्वपूर्ण उछाल के लिए ऑटोस्केलिंग को वास्तविक क्षमता योजना और हेडरूम के साथ जोड़ें।
क्रिटिकल पाथ और पूंछ पर ध्यान केंद्रित करते हुए, प्रोफाइलिंग और स्पष्ट बजट के मुकाबले लोड टेस्टिंग से प्रदर्शन संचालित करें।
टाइमआउट, circuit breakers, bulkheads, सुचारू क्षरण, और रिडंडेंसी से रेज़िलिएंस बनाएं, फिर इसे chaos engineering से सत्यापित करें।
RTO और RPO को व्यावसायिक निर्णयों के रूप में सेट करें, हर सिस्टम की गंभीरता से मेल खाने के लिए DR इंजीनियर करें, और फ़ेलओवर का नियमित रूप से परीक्षण करें।

संदर्भ और आगे पढ़ने के लिए

Martin Kleppmann, Designing Data-Intensive Applications
Michael Nygard, Release It!: Design and Deploy Production-Ready Software
Betsy Beyer et al. (Google), Site Reliability Engineering and The Site Reliability Workbook
Casey Rosenthal and Nora Jones, Chaos Engineering
Brendan Gregg, Systems Performance: Enterprise and the Cloud
John Allspaw, The Art of Capacity Planning
Ilya Grigorik, High Performance Browser Networking
Nassim Nicholas Taleb, Antifragile