9.7 क्षमता योजना और मांग पूर्वानुमान

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

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

यह अध्याय दो पड़ोसी अध्यायों के बीच स्थित है और दोनों का पूरक बना रहता है। अध्याय 3.5 स्केलेबिलिटी को एक आर्किटेक्चरल गुण के रूप में शामिल करता है: यह कि किसी सिस्टम को स्टेटलेसनेस, शार्डिंग, और हॉरिज़ॉन्टल स्केलिंग के माध्यम से इस तरह कैसे बनाया जाए कि वह बढ़ ही सके। अध्याय 9.1 साइट रिलायबिलिटी इंजीनियरिंग (SRE) को शामिल करता है, जो वे विश्वसनीयता लक्ष्य तय करता है जिनकी रक्षा क्षमता को करनी होती है। यहां आप आर्किटेक्चर को दिया हुआ और लक्ष्यों को स्थिर मानकर एक मात्रात्मक प्रश्न का उत्तर देते हैं: सिस्टम को अपने सर्विस लेवल ऑब्जेक्टिव (SLOs, अध्याय 9.1 के विश्वसनीयता लक्ष्य) को पूर्वानुमानित मांग और उन उछालों दोनों के दौरान पूरा करने के लिए, जिनका आपने पूर्वानुमान नहीं लगाया था, कितनी हर चीज़ खरीदनी, आरक्षित करनी, और रिज़र्व में रखनी होगी। ऑटोस्केलिंग और परफॉर्मेंस इंजीनियरिंग (अध्याय 2.16) यहां उपयोग किए जाने वाले उपकरण हैं, लेकिन वे योजना का विकल्प नहीं हैं, और उन्हें योजना समझ लेना एक सामान्य और महंगी गलती है।

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

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

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

सिफारिशें

क्षमता योजना, ऑटोस्केलिंग, और परफॉर्मेंस इंजीनियरिंग को अलग रखें

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

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

रुझान, मौसमी प्रवृत्ति, घटनाओं, और व्यावसायिक वृद्धि से मांग का पूर्वानुमान लगाएं

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

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

उपयोगिता लक्ष्य निर्धारित करें और क्यूइंग-थ्योरी की खाई का सम्मान करें

पैसे बचाने के लिए इन्फ्रास्ट्रक्चर को 90% उपयोगिता पर “गर्म” चलाने की सहज प्रवृत्ति एक जाल है, और इसका कारण है क्यूइंग थ्योरी, जिसे अध्याय 11.3 में गहराई से शामिल किया गया है। जैसे-जैसे कोई संसाधन पूर्ण उपयोगिता के करीब पहुंचता है, प्रतीक्षा समय धीरे-धीरे और रैखिक रूप से नहीं बढ़ता; वह विस्फोटक रूप से बढ़ता है। 50% उपयोगिता पर एक सर्वर के पास आरामदायक हेडरूम होता है; वही सर्वर 90% पर कई गुना बदतर लेटेंसी दिखा सकता है, और 95% पर कतार पूरी तरह बेकाबू हो सकती है। संतृप्ति के निकट लेटेंसी एक ढलान नहीं बल्कि एक खाई है, और आपके उपयोगकर्ता उस खाई को टाइमआउट, रीट्राई, और त्रुटियों के रूप में तब महसूस करते हैं, जब तक संसाधन तकनीकी रूप से “पूरी तरह भरा” भी नहीं हुआ होता।

यही कारण है कि क्षमता योजनाकार उपयोगिता लक्ष्य 100% से काफी नीचे रखते हैं, लेटेंसी-संवेदनशील सेवाओं के लिए सामान्यतः 50% से 70% की सीमा में, और थ्रूपुट-उन्मुख बैच कार्य के लिए इससे अधिक, जो कतार को सहन कर सकता है। यह लक्ष्य बर्बादी नहीं है; यह पूर्वानुमेय लेटेंसी की कीमत है। लक्ष्य को SLO से चुनें: यदि आपका लेटेंसी उद्देश्य कठोर है, तो आपकी उपयोगिता सीमा कम होगी, क्योंकि कतार से उत्पन्न टेल लेटेंसी ही वह चीज़ है जो SLO को तोड़ देती है। हेडरूम और सुरक्षा मार्जिन एक ही विचार को दो दिशाओं से देखना है। हेडरूम सामान्य लोड और क्षमता के बीच का अंतर है; सुरक्षा मार्जिन उसी अंतर को उस बीमा के रूप में व्यक्त करता है जो एक ऊंचे निकलने वाले पूर्वानुमान, लोड को केंद्रित करने वाले फेलओवर, या किसी अनदेखे उछाल के विरुद्ध काम आता है।

लोड टेस्टिंग और बेंचमार्किंग के माध्यम से वास्तविक सीमाएं खोजें

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

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

प्रावधान रणनीतियां जानबूझकर चुनें

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

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

उन कठोर बाधाओं (हार्ड बॉटलनेक) का मानचित्रण करें जो ऑटोस्केल नहीं होंगी

ऑटोस्केलिंग एक खतरनाक आत्मविश्वास पैदा करती है, क्योंकि बहुत सी सीमाएं उस चीज़ के डाउनस्ट्रीम बैठी होती हैं जो स्केल होती है, और जब वह स्केल होती है तो ये सीमाएं नहीं हिलतीं। डेटाबेस कनेक्शन पूल इसका क्लासिक उदाहरण हैं: अपनी स्टेटलेस परत को 10 से 100 इंस्टेंस तक स्केल करें और प्रत्येक उसी डेटाबेस से कनेक्शन खोलता है, जिसकी समवर्ती कनेक्शनों पर एक कठोर सीमा होती है और वह नए कनेक्शनों को अस्वीकार करना शुरू कर देगा। क्लाउड अकाउंट लगभग हर चीज़ पर कोटा रखते हैं: प्रति क्षेत्र इंस्टेंस, IP पते, प्रति सेकंड API कॉल, फ़ंक्शन समवर्तीता। आर्किटेक्चर का कोई भी एकल बिंदु (एक प्राथमिक डेटाबेस, एक लीडर नोड, एक साझा कैश, एक लाइसेंस प्राप्त उपकरण) एक ऐसी सीमा है जिसे कहीं और की हॉरिज़ॉन्टल स्केलिंग नहीं बढ़ा सकती।

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

केवल औसत के लिए नहीं, बल्कि शिखर घटनाओं के लिए प्रावधान करें

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

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

क्षमता को इंस्ट्रुमेंट करें और उसे एक निश्चित अंतराल पर समीक्षा करें

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

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

समझौते: लाभ और हानि

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

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

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

1. क्या हम वास्तव में जानते हैं कि हमारी प्रत्येक कठोर बाधा किस लोड पर बंध जाती है, या हम यह मान रहे हैं कि ऑटोस्केलिंग हमें बचा लेगी? अधिकतर टीमें आपको बता सकती हैं कि उनके इंस्टेंस ऑटोस्केल होते हैं, लेकिन अधिकतर यह नहीं बता सकतीं कि उनके प्राथमिक डेटाबेस की समवर्ती-कनेक्शन सीमा क्या है, उनके सबसे महत्वपूर्ण तृतीय-पक्ष की API दर सीमा क्या है, या वह अकाउंट कोटा क्या है जो उनकी फ़ंक्शन समवर्तीता को सीमित करता है। यही वे सीमाएं हैं जो लॉन्च को समाप्त कर देती हैं, और जब स्टेटलेस परत स्केल होती है तब भी ये नहीं हिलतीं। यदि आपके पास कठोर सीमाओं की लिखित सूची है तो उसे लाएं, और यदि नहीं है, तो यह अनुपस्थिति ही निष्कर्ष है। प्रत्येक सीमा के लिए, आपको तीन संख्याएं चाहिए: सीमा, आज का उपयोग, और वह मांग स्तर जिस पर वे दोनों मिलते हैं। जहां भी आप ये तीनों प्रस्तुत नहीं कर सकते, वहां आप एक ऐसी बाधा को उम्मीद के सहारे संभाल रहे हैं।

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

3. प्रोडक्ट, मार्केटिंग, और ऑपरेशंस किसी उछाल के होने से पहले इंजीनियरिंग को कैसे बताते हैं, और कितने पहले? सबसे महंगी क्षमता विफलताएं मॉडलिंग की गलतियां नहीं होतीं; वे ऐसी घटनाएं होती हैं जिनके बारे में इंजीनियरिंग को ट्रैफ़िक आने तक कभी पता ही नहीं चला। एक पूर्वानुमान इतिहास से रुझान और मौसमी प्रवृत्ति का एक्सट्रापोलेशन कर सकता है, लेकिन किसी घटना का कोई इतिहास नहीं होता, इसलिए वह केवल उन लोगों से आ सकता है जो उसकी योजना बना रहे हैं। पिछले तीन मांग उछालों को लाएं और प्रत्येक के लिए पूछें कि इंजीनियरिंग को कितने दिनों की चेतावनी मिली और क्या वह क्षमता आरक्षित करने और लोड टेस्ट करने के लिए पर्याप्त थी। जो प्रमाण आप चाहते हैं वह एक ऐसा स्थायी चैनल है जिसकी लीड टाइम प्रावधान करने के लिए पर्याप्त लंबी हो, क्योंकि अकेले क्लाउड कोटा बढ़ाने में ही कई दिन लग सकते हैं। यदि यह चैनल मौजूद नहीं है, तो आपकी क्षमता योजना ठीक उन्हीं क्षणों के प्रति अंधी है जिनकी रक्षा के लिए वह बनी है।

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

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

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

क्षेत्रीय दृष्टिकोण

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

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

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

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

उदाहरण

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

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

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

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

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

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

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

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

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

• स्तर 1, आरंभ: क्षमता प्रतिक्रियात्मक और तदर्थ (ad hoc) है। टीमें संसाधनों के समाप्त होने के बाद उन्हें जोड़ती हैं, हर चीज़ संभालने के लिए ऑटोस्केलिंग पर भरोसा करती हैं, और उनके पास कोई पूर्वानुमान, कोई हार्ड-लिमिट सूची, और कोई लोड टेस्टिंग नहीं होती। शिखर घटनाओं का सामना उम्मीद से किया जाता है, और लॉन्च तथा अंतिम तिथियों के दौरान आउटेज को बुरी किस्मत माना जाता है।
• स्तर 2, विकास: बुनियादी अभ्यास दिखाई देते हैं लेकिन टीम-दर-टीम अलग होते हैं। कुछ निगरानी उपयोगिता दिखाती है, कुछ लोड टेस्टिंग बड़ी घटनाओं से पहले होती है, प्रमुख कोटा ज्ञात हैं, और कहीं-कहीं एक मोटा पूर्वानुमान मौजूद है, लेकिन मॉडल बनाए नहीं रखा जाता, डाउनस्ट्रीम बाधाएं अक्सर छूट जाती हैं, और हेडरूम SLO से नहीं बल्कि अंगूठे के नियम (rule of thumb) से तय होता है।
• स्तर 3, मानकीकरण: क्षमता योजना एक दस्तावेज़ीकृत अनुशासन है जो संगठन-व्यापी लागू है। एक मांग पूर्वानुमान रुझान, मौसमी प्रवृत्ति, घटनाओं, और व्यावसायिक वृद्धि को जोड़ता है; एक लिखित हार्ड-लिमिट सूची बनाए रखी जाती है; उपयोगिता लक्ष्य SLOs से प्राप्त होते हैं; लोड, स्ट्रेस, सोक, और स्पाइक परीक्षण एक निश्चित अंतराल पर उत्पादन-सदृश डेटा के विरुद्ध चलते हैं; और प्रावधान आरक्षित, ऑन-डिमांड, और स्पॉट को जानबूझकर मिलाता है। एक स्थायी चैनल प्रोडक्ट और मार्केटिंग से इंजीनियरिंग तक घटना की चेतावनियां पहुंचाता है।
• स्तर 4, प्रबंधन: क्षमता को आधार रेखाओं के विरुद्ध मापा और नियंत्रित किया जाता है। हर चक्र में पूर्वानुमान की वास्तविक मांग से तुलना की जाती है और त्रुटि को ट्रैक करके घटाया जाता है; उपयोगिता, संतृप्ति संकेत, और हर हार्ड लिमिट के विरुद्ध हेडरूम को वर्तमान मानों के बजाय प्रक्षेपण के रूप में ट्रेंड और अलर्ट किया जाता है; शिखर घटनाओं की बाद में वास्तविक देखे गए शिखर के विरुद्ध समीक्षा की जाती है; और प्रावधान मिश्रण, आरक्षित-प्रतिबद्धता कवरेज, और प्रति-SLO लागत को ऐसे मेट्रिक्स के रूप में रिपोर्ट किया जाता है जो गो या नो-गो निर्णयों को नियंत्रित करते हैं। अंतर्ज्ञान नहीं बल्कि डेटा यह तय करता है कि क्या आरक्षित, बढ़ाना, या सेवामुक्त करना है।
• स्तर 5, ऑर्केस्ट्रेट: क्षमता योजना निरंतर सुधारी जाती है और पूरे संगठन में एकीकृत होती है। पूर्वानुमान स्वचालित रूप से सत्यापित और परिष्कृत किए जाते हैं, संतृप्ति के आने से पहले उसका प्रक्षेपण और उसके विरुद्ध प्रावधान किया जाता है, प्रावधान मिश्रण को लाइव कीमतों के विरुद्ध अनुकूलित किया जाता है, शिखर घटनाएं पूर्वाभ्यास की गई रनबुक से चलती हैं, और लागत तथा विश्वसनीयता को पूरे प्लेटफ़ॉर्म में SLO के विरुद्ध जानबूझकर संतुलित किया जाता है। क्षमता मॉडल एक साझा, अनुकूलनशील संपत्ति है जो मांग के स्वरूप और प्रदाता की कीमतों के बदलने पर बेड़े को फिर से संतुलित करता है।

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

1. लेटेंसी-संवेदनशील सेवाओं के लिए आपका वर्तमान उपयोगिता लक्ष्य क्या है, और क्या आप इसे पैसे बचाने की इच्छा के बजाय अपने SLO और क्यूइंग व्यवहार से न्यायोचित ठहरा सकते हैं?
2. आपके कौन-से घटक बिल्कुल भी ऑटोस्केल नहीं हो सकते, और जब उनमें से कोई एक संतृप्त हो जाता है तो बाकी सिस्टम का क्या होता है?
3. यदि अगली तिमाही में आपका ट्रैफ़िक दोगुना हो जाए, तो कौन-सा संसाधन सबसे पहले अपनी सीमा तक पहुंचेगा, और उसे बढ़ाने के लिए आपको कितने दिनों की लीड टाइम चाहिए होगी?
4. आप आरक्षित, ऑन-डिमांड, और स्पॉट क्षमता का मिश्रण कैसे तय करते हैं, और आपने इसे अपनी वास्तविक मांग के स्वरूप के विरुद्ध आखिरी बार कब दोबारा देखा?
5. जब कोई शिखर घटना आने वाली होती है, तो पूर्व-वार्मिंग, कोटा बढ़ाने, और गो/नो-गो निर्णय का स्वामी कौन होता है, और क्या यह एक रनबुक के रूप में लिखा गया है?
6. क्या आपके क्षमता अलर्ट हफ्तों पहले प्रक्षेपित संतृप्ति पर सक्रिय होते हैं, या केवल वर्तमान उपयोगिता पर तब जब दीवार पहले से ही करीब हो?

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

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

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

• Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering: How Google Runs Production Systems
• Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, and Stephen Thorne (eds.), The Site Reliability Workbook: Practical Ways to Implement SRE
• John Allspaw, The Art of Capacity Planning: Scaling Web Resources in the Cloud
• Neil J. Gunther, Guerrilla Capacity Planning: A Tactical Approach to Planning for Highly Scalable Applications and Services
• Martin L. Abbott and Michael T. Fisher, The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise
• Brendan Gregg, Systems Performance: Enterprise and the Cloud
• Leonard Kleinrock, Queueing Systems, Volume 1: Theory
• J. R. Storment and Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management