Infrastructure Scaling: Horizontal vs Vertical, Load Balancing & Auto-Scaling

नेटफ्लिक्स वास्तविक समय की मांग के आधार पर हजारों उदाहरणों को गतिशील रूप से स्केल करके 190 देशों में 260 मिलियन ग्राहकों को सेवा प्रदान करता है। जबकि अधिकांश व्यवसाय नेटफ्लिक्स पैमाने पर काम नहीं करते हैं, स्केलिंग सिद्धांत समान हैं: मैन्युअल हस्तक्षेप के बिना और निष्क्रिय संसाधनों के लिए भुगतान किए बिना, स्वचालित रूप से ट्रैफ़िक की मांग के लिए बुनियादी ढांचे की क्षमता का मिलान करें। क्षैतिज और ऊर्ध्वाधर स्केलिंग, एल4 और एल7 लोड बैलेंसर्स और प्रतिक्रियाशील और पूर्वानुमानित ऑटो-स्केलिंग के बीच आपके द्वारा चुने गए विकल्प यह निर्धारित करते हैं कि आपका प्लेटफ़ॉर्म शानदार ढंग से बढ़ता है या दीवार से टकराता है।

मुख्य बातें

• सरलता के लिए ऊर्ध्वाधर (बड़ी मशीनें) शुरू करें, फिर जब आपको उच्च उपलब्धता की आवश्यकता हो या एकल-मशीन सीमा से अधिक की आवश्यकता हो तो क्षैतिज (अधिक मशीनों) पर स्विच करें
• L7 लोड बैलेंसर आधुनिक अनुप्रयोगों के लिए आवश्यक सामग्री-आधारित रूटिंग प्रदान करते हैं, जबकि L4 बैलेंसर सरल टीसीपी वितरण के लिए कच्चा थ्रूपुट प्रदान करते हैं।
• ऑटो-स्केलिंग नीतियों को ज्ञात ट्रैफ़िक पैटर्न के लिए पूर्वानुमानित स्केलिंग के साथ मीट्रिक-आधारित ट्रिगर्स (सीपीयू, मेमोरी) को संयोजित करना चाहिए
• डेटाबेस स्केलिंग एप्लिकेशन स्केलिंग की तुलना में भिन्न नियमों का पालन करती है - रीड-हैवी लोड के लिए प्रतिकृतियां पढ़ें, राइट-हैवी लोड के लिए विभाजन

---

क्षैतिज बनाम लंबवत स्केलिंग

मौलिक स्केलिंग निर्णय यह है कि क्या मौजूदा मशीनों को बड़ा (ऊर्ध्वाधर) बनाया जाए या अधिक मशीनें (क्षैतिज) जोड़ी जाएं। प्रत्येक दृष्टिकोण में अलग-अलग ट्रेडऑफ़ होते हैं।

लंबवत स्केल कब करना है

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

ऊर्ध्वाधर स्केल करें जब:

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

ऊर्ध्वाधर स्केलिंग बंद करें जब:

• आपको उच्च उपलब्धता की आवश्यकता है (एकल उदाहरण = विफलता का एकल बिंदु)
• सबसे बड़ा उपलब्ध उदाहरण पर्याप्त नहीं है
• आप चरम क्षमता के लिए भुगतान कर रहे हैं जो 90% समय निष्क्रिय रहती है
• आपको विलंबता के लिए भौगोलिक वितरण की आवश्यकता है

क्षैतिज रूप से कब स्केल करना है

क्षैतिज स्केलिंग के लिए आवश्यक है कि आपका एप्लिकेशन स्टेटलेस हो - किसी भी अनुरोध को किसी भी उदाहरण द्वारा नियंत्रित किया जा सकता है। इसका मतलब है:

• सत्र रेडिस या डेटाबेस में संग्रहीत हैं, मेमोरी में नहीं
• फ़ाइल अपलोड ऑब्जेक्ट स्टोरेज (S3) में संग्रहीत हैं, स्थानीय डिस्क में नहीं
• प्रतिकृति के बिना कोई उदाहरण-विशिष्ट कॉन्फ़िगरेशन या स्थानीय कैशिंग नहीं
• इंस्टेंस समाप्ति (स्वास्थ्य जांच, कनेक्शन ड्रेनिंग) का ग्रेसफुल हैंडलिंग

क्षैतिज रूप से स्केल करें जब:

• उच्च उपलब्धता एक आवश्यकता है (आपका व्यवसाय मिनटों के डाउनटाइम को बर्दाश्त नहीं कर सकता)
• ट्रैफ़िक परिवर्तनशील है और ऑटो-स्केलिंग शांत अवधि के दौरान कम करके लागत बचा सकती है
• आपको बिना डाउनटाइम के तैनात करने की आवश्यकता है (उदाहरणों में रोलिंग तैनाती)
• प्रदर्शन आवश्यकताएँ एकल-मशीन क्षमता से अधिक हैं

---

लोड बैलेंसिंग डीप डाइव

एक लोड बैलेंसर आने वाले ट्रैफ़िक को कई बैकएंड सर्वरों में वितरित करता है। लोड बैलेंसर का प्रकार निर्धारित करता है कि कौन से रूटिंग निर्णय संभव हैं।

L4 (ट्रांसपोर्ट लेयर) लोड संतुलन

L4 लोड बैलेंसर टीसीपी/यूडीपी स्तर पर काम करते हैं। वे पैकेट सामग्री का निरीक्षण किए बिना आईपी पते और पोर्ट के आधार पर कनेक्शन रूट करते हैं। वे तेज़, सरल हैं और किसी भी टीसीपी-आधारित प्रोटोकॉल को संभालते हैं।

इसके लिए सर्वोत्तम: रॉ टीसीपी वितरण, डेटाबेस कनेक्शन प्रॉक्सीइंग (पीजीबाउंसर), गैर-HTTP प्रोटोकॉल, अत्यधिक उच्च थ्रूपुट आवश्यकताएं

सीमाएं: यूआरएल पथ, हेडर या कुकीज़ के आधार पर रूटिंग निर्णय नहीं ले सकते। एसएसएल को समाप्त नहीं किया जा सकता (बैकएंड पर किया जाना चाहिए)।

L7 (एप्लिकेशन लेयर) लोड संतुलन

L7 लोड बैलेंसर HTTP स्तर पर काम करते हैं। वे अनुरोध हेडर, यूआरएल, कुकीज़ का निरीक्षण करते हैं और यहां तक ​​कि रूटिंग निर्णय लेने के लिए अनुरोध निकायों का भी निरीक्षण करते हैं। वे एसएसएल समाप्ति, संपीड़न को संभालते हैं, और अनुरोधों और प्रतिक्रियाओं को संशोधित कर सकते हैं।

इसके लिए सर्वोत्तम: वेब एप्लिकेशन, एपीआई गेटवे, सामग्री-आधारित रूटिंग, एसएसएल समाप्ति, ए/बी परीक्षण, कैनरी तैनाती

लोड संतुलन एल्गोरिदम

स्वास्थ्य जांच और सुशोभित गिरावट

स्वास्थ्य जांच यह निर्धारित करती है कि बैकएंड सर्वर को ट्रैफ़िक प्राप्त होना चाहिए या नहीं। उन्हें सावधानीपूर्वक कॉन्फ़िगर करें:

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

---

ऑटो-स्केलिंग नीतियां

ऑटो-स्केलिंग मांग के आधार पर उदाहरणों की संख्या को समायोजित करती है, मैन्युअल हस्तक्षेप के बिना ट्रैफ़िक की क्षमता का मिलान करती है।

मीट्रिक-आधारित स्केलिंग

जब कोई मीट्रिक एक सीमा पार कर जाता है तो सबसे आम दृष्टिकोण स्केलिंग क्रियाओं को ट्रिगर करता है।

पूर्वानुमानित स्केलिंग

यदि आपका ट्रैफ़िक पूर्वानुमानित पैटर्न (दैनिक शिखर, साप्ताहिक चक्र, मौसमी घटनाएँ) का अनुसरण करता है, तो ट्रैफ़िक आने से पहले पूर्वानुमानित स्केलिंग प्रावधान क्षमता। AWS ऑटो स्केलिंग भविष्य कहनेवाला स्केलिंग का समर्थन करता है जो ऐतिहासिक पैटर्न और पैमानों से सक्रिय रूप से सीखता है।

भविष्यवाणी और प्रतिक्रियाशील को संयोजित करें: ज्ञात पैटर्न (सुबह यातायात रैंप, ब्लैक फ्राइडे पूर्व-प्रावधान) के लिए पूर्वानुमानित स्केलिंग और अप्रत्याशित उछाल के लिए प्रतिक्रियाशील स्केलिंग का उपयोग करें।

स्केलिंग सर्वोत्तम अभ्यास

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

---

डेटाबेस स्केलिंग रणनीतियाँ

डेटाबेस उसी तरह क्षैतिज रूप से स्केल नहीं करते जैसे एप्लिकेशन सर्वर करते हैं। लिखने के संचालन के लिए आम सहमति की आवश्यकता होती है, और मजबूत स्थिरता वितरण विकल्पों को सीमित करती है।

प्रतिकृतियाँ पढ़ें

पढ़ें प्रतिकृतियां प्राथमिक डेटाबेस से डेटा कॉपी करें और पढ़ी गई क्वेरीज़ प्रस्तुत करें। वे रीड थ्रूपुट को रैखिक रूप से मापते हैं लेकिन थ्रूपुट लिखने में मदद नहीं करते हैं।

कार्यान्वयन संबंधी विचार:

• प्रतिकृति अंतराल -- प्रतिकृतियां अंततः सुसंगत होती हैं। लिखने के तुरंत बाद की गई क्वेरी में परिवर्तन नहीं दिख सकता है। पढ़ने-बाद-लिखने के लिए प्राथमिक का उपयोग करें।
• कनेक्शन रूटिंग -- आपके एप्लिकेशन को रीड को प्रतिकृतियों तक रूट करने और प्राइमरी में लिखने के लिए तर्क की आवश्यकता होती है। ORM और कनेक्शन प्रॉक्सी (ProxySQL, PgBouncer) इसे स्वचालित कर सकते हैं।
• फ़ेलओवर -- यदि प्राथमिक विफल रहता है, तो एक प्रतिकृति को बढ़ावा दिया जा सकता है। स्वचालित विफलता (एडब्ल्यूएस आरडीएस मल्टी-एजेड, एडब्ल्यूएस ऑरोरा) डाउनटाइम को सेकंड तक कम कर देता है।

टेबल विभाजन

बड़ी तालिकाओं पर लिखने-भारी कार्यभार के लिए, एकल तार्किक इंटरफ़ेस को बनाए रखते हुए विभाजन एक तालिका को छोटे भौतिक खंडों में विभाजित करता है। विस्तृत विभाजन रणनीतियों के लिए, हमारी डेटाबेस अनुकूलन मार्गदर्शिका देखें।

कनेक्शन पूलिंग

डेटाबेस कनेक्शन बनाना महंगा है और संख्या में सीमित है। PgBouncer जैसे कनेक्शन पूलर कई एप्लिकेशन इंस्टेंस से कम संख्या में डेटाबेस कनेक्शन में कनेक्शन पूल करते हैं।

पूलिंग के बिना: 20 एप्लिकेशन इंस्टेंस x 20 कनेक्शन प्रत्येक = 400 डेटाबेस कनेक्शन (संभवतः PostgreSQL सीमा से अधिक)

PgBouncer के साथ: 20 एप्लिकेशन इंस्टेंसेस PgBouncer से कनेक्ट होते हैं, जो PostgreSQL से 50-100 कनेक्शन बनाए रखता है, अनुरोधों को कुशलतापूर्वक मल्टीप्लेक्स करता है।

---

माइक्रोसर्विसेज अपघटन

जब एक एकल टीम के कुशलतापूर्वक विकास और तैनाती के लिए एक मोनोलिथ बहुत बड़ा हो जाता है, तो माइक्रोसर्विसेज अपघटन विभिन्न घटकों की स्वतंत्र स्केलिंग की अनुमति देता है।

कब विघटित करना है

माइक्रोसर्विसेज़ से शुरुआत न करें. एक अच्छी तरह से संरचित मोनोलिथ से प्रारंभ करें और विघटित करें जब:

• विभिन्न घटकों की स्केलिंग आवश्यकताएं काफी भिन्न होती हैं (खोज के लिए 20 उदाहरणों की आवश्यकता होती है, चेकआउट के लिए 5 की आवश्यकता होती है)
• विभिन्न टीमों को रिलीज़ शेड्यूल के समन्वय के बिना स्वतंत्र रूप से तैनात करने की आवश्यकता है
• एक विशिष्ट घटक को एक अलग प्रौद्योगिकी स्टैक की आवश्यकता होती है (पायथन में मशीन लर्निंग, Node.js में एपीआई)
• कोडबेस आकार के कारण मोनोलिथ की तैनाती का समय 30 मिनट से अधिक है

पहले क्या निकालें

---

अक्सर पूछे जाने वाले प्रश्न

मुझे कैसे पता चलेगा कि मुझे कब स्केल करने की आवश्यकता है?

चार प्रमुख मेट्रिक्स की निगरानी करें: सीपीयू उपयोग (लगातार 70% से ऊपर), मेमोरी उपयोग (80% से ऊपर), प्रतिक्रिया समय पी95 (आपके एसएलओ से ऊपर), और त्रुटि दर (0.1% से ऊपर)। जब कोई मीट्रिक लगातार अपनी सीमा का उल्लंघन करता है, तो आपको स्केल करने की आवश्यकता होती है। अलर्ट के साथ सक्रिय निगरानी उपयोगकर्ताओं के नोटिस करने से पहले इन रुझानों को पकड़ लेती है। हमारी निगरानी मार्गदर्शिका देखें।

क्या ऑटो-स्केलिंग या पूर्व-प्रावधान अधिक लागत प्रभावी है?

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

क्या मुझे कंटेनर (डॉकर/कुबेरनेट्स) या पारंपरिक वीएम का उपयोग करना चाहिए?

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

मैं डेटा हानि के बिना डेटाबेस विफलता को कैसे संभालूं?

शून्य डेटा हानि फ़ेलओवर के लिए सिंक्रोनस प्रतिकृति का उपयोग करें - जब तक प्रतिकृति इसकी पुष्टि नहीं करती तब तक प्राथमिक किसी लेखन को स्वीकार नहीं करता है। यह लेखन विलंबता (आमतौर पर एक ही क्षेत्र में 1-5ms) जोड़ता है लेकिन विफलता के दौरान कोई डेटा हानि नहीं होने की गारंटी देता है। AWS RDS मल्टी-एज़ेड और ऑरोरा स्वचालित फ़ेलओवर के साथ प्रबंधित सिंक्रोनस प्रतिकृति प्रदान करते हैं।

---

अगला क्या है

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

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

ECOSIRE AWS और मल्टी-क्लाउड वातावरण पर व्यावसायिक प्लेटफार्मों के लिए स्केलेबल बुनियादी ढांचे को डिजाइन और कार्यान्वित करता है। बुनियादी ढांचे के स्केलिंग मूल्यांकन के लिए हमारी DevOps टीम से संपर्क करें।

---

ECOSIRE द्वारा प्रकाशित - Odoo ERP, Shopify eCommerce, और OpenClaw AI में AI-संचालित समाधानों के साथ व्यवसायों को बढ़ाने में मदद करना।