R.I.B.H.U. Academy^®

Scaling Amazon EC2 | अमेज़न EC2 स्केलिंग

Scalability | अनुमापकता

Scalability involves beginning with only the resources you need and designing your architecture to automatically respond to changing demand by scaling out or in. As a result, you pay for only the resources you use. You don’t have to worry about a lack of computing capacity to meet your customers’ needs.

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

If you wanted the scaling process to happen automatically, which AWS service would you use? The AWS service that provides this functionality for Amazon EC2 instances is Amazon EC2 Auto Scaling.

यदि आप चाहते हैं कि स्केलिंग प्रक्रिया स्वचालित रूप से हो, तो आप किस AWS सेवा का उपयोग करेंगे? AWS सेवा जो Amazon EC2 इंस्टेंसेस के लिए यह कार्यक्षमता प्रदान करती है वह Amazon EC2 ऑटो स्केलिंग है।

Amazon EC2 Auto Scaling | अमेज़न EC2 ऑटो स्केलिंग

If you’ve tried to access a website that wouldn’t load and frequently timed out, the website might have received more requests than it was able to handle. This situation is similar to waiting in a long line at a coffee shop, when there is only one barista present to take orders from customers.

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

Bar graph depicting demand and unused capacity over a 7-day period. (image)

7 दिन की अवधि में मांग और अप्रयुक्त क्षमता को दर्शाने वाला बार ग्राफ। (छवि)

Amazon EC2 Auto Scaling enables you to automatically add or remove Amazon EC2 instances in response to changing application demand. By automatically scaling your instances in and out as needed, you can maintain a greater sense of application availability.

Amazon EC2 ऑटो स्केलिंग आपको बदलती एप्लिकेशन मांग के जवाब में Amazon EC2 इंस्टेंस को स्वचालित रूप से जोड़ने या हटाने में सक्षम बनाता है। आवश्यकतानुसार अपने इंस्टेंस को स्वचालित रूप से अंदर और बाहर स्केल करके, आप एप्लिकेशन उपलब्धता की बेहतर समझ बनाए रख सकते हैं।

Within Amazon EC2 Auto Scaling, you can use two approaches: dynamic scaling and predictive scaling.

अमेज़ॅन EC2 ऑटो स्केलिंग के भीतर, आप दो दृष्टिकोणों का उपयोग कर सकते हैं: गतिशील स्केलिंग और पूर्वानुमानित स्केलिंग।

• Dynamic scaling responds to changing demand.
  डायनामिक स्केलिंग बदलती मांग पर प्रतिक्रिया करता है।
• Predictive scaling automatically schedules the right number of Amazon EC2 instances based on predicted demand.
  भविष्य कहनेवाला स्केलिंग स्वचालित रूप से अनुमानित मांग के आधार पर अमेज़ॅन EC2 उदाहरणों की सही संख्या निर्धारित करता है।

Example: Amazon EC2 Auto Scaling | उदाहरण: अमेज़न EC2 ऑटो स्केलिंग

In the cloud, computing power is a programmatic resource, so you can take a more flexible approach to the issue of scaling. By adding Amazon EC2 Auto Scaling to an application, you can add new instances to the application when necessary and terminate them when no longer needed.

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

Suppose that you are preparing to launch an application on Amazon EC2 instances. When configuring the size of your Auto Scaling group, you might set the minimum number of Amazon EC2 instances at one. This means that at all times, there must be at least one Amazon EC2 instance running.

मान लीजिए कि आप Amazon EC2 इंस्टेंसेस पर एक एप्लिकेशन लॉन्च करने की तैयारी कर रहे हैं। अपने ऑटो स्केलिंग समूह के आकार को कॉन्फ़िगर करते समय, आप Amazon EC2 इंस्टेंस की न्यूनतम संख्या एक पर सेट कर सकते हैं। इसका मतलब है कि हर समय, कम से कम एक Amazon EC2 इंस्टेंस चालू रहना चाहिए।

Amazon EC2 instances scaling in and out as part of an Auto Scaling group. (image)

अमेज़ॅन EC2 उदाहरण ऑटो स्केलिंग समूह के हिस्से के रूप में अंदर और बाहर स्केलिंग करता है। (छवि)

When you create an Auto Scaling group, you can set the minimum number of Amazon EC2 instances. The minimum capacity is the number of Amazon EC2 instances that launch immediately after you have created the Auto Scaling group. In this example, the Auto Scaling group has a minimum capacity of one Amazon EC2 instance.

जब आप एक ऑटो स्केलिंग समूह बनाते हैं, तो आप Amazon EC2 इंस्टेंसेस की न्यूनतम संख्या निर्धारित कर सकते हैं। न्यूनतम क्षमता अमेज़ॅन EC2 इंस्टेंसेस की संख्या है जो आपके द्वारा ऑटो स्केलिंग समूह बनाने के तुरंत बाद लॉन्च होती है। इस उदाहरण में, ऑटो स्केलिंग समूह की न्यूनतम क्षमता एक Amazon EC2 इंस्टेंस है।

Next, you can set the desired capacity at two Amazon EC2 instances even though your application needs a minimum of a single Amazon EC2 instance to run.

इसके बाद, आप वांछित क्षमता को दो Amazon EC2 इंस्टेंसेस पर सेट कर सकते हैं, भले ही आपके एप्लिकेशन को चलाने के लिए कम से कम एक Amazon EC2 इंस्टेंस की आवश्यकता हो।

If you do not specify the desired number of Amazon EC2 instances in an Auto Scaling group, the desired capacity defaults to your minimum capacity.

यदि आप ऑटो स्केलिंग समूह में अमेज़ॅन ईसी2 इंस्टेंसेस की वांछित संख्या निर्दिष्ट नहीं करते हैं, तो वांछित क्षमता आपकी न्यूनतम क्षमता पर डिफ़ॉल्ट हो जाती है।

The third configuration that you can set in an Auto Scaling group is the maximum capacity. For example, you might configure the Auto Scaling group to scale out in response to increased demand, but only to a maximum of four Amazon EC2 instances.

तीसरा कॉन्फ़िगरेशन जिसे आप ऑटो स्केलिंग समूह में सेट कर सकते हैं वह अधिकतम क्षमता है। उदाहरण के लिए, आप बढ़ी हुई मांग के जवाब में स्केल आउट करने के लिए ऑटो स्केलिंग समूह को कॉन्फ़िगर कर सकते हैं, लेकिन केवल अधिकतम चार अमेज़ॅन EC2 उदाहरणों के लिए।

Because Amazon EC2 Auto Scaling uses Amazon EC2 instances, you pay for only the instances you use, when you use them. You now have a cost-effective architecture that provides the best customer experience while reducing expenses.

क्योंकि अमेज़ॅन ईसी2 ऑटो स्केलिंग अमेज़ॅन ईसी2 इंस्टेंसेस का उपयोग करता है, आप केवल उन इंस्टेंसेस के लिए भुगतान करते हैं जिनका आप उपयोग करते हैं, जब आप उनका उपयोग करते हैं। अब आपके पास एक लागत प्रभावी वास्तुकला है जो खर्चों को कम करते हुए सर्वोत्तम ग्राहक अनुभव प्रदान करती है।

Transcript (part-1)

So we have a good idea now on the basics of EC2 and how it can help with any compute needs, like making coffee. Well, like metaphorically making coffee. The coffee represents the, whatever your instance is producing. The next thing we want to talk about is another major benefit of AWS, scalability and elasticity, or how capacity can grow and shrink, based on business needs.

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

Here is the on-prem data center dilemma. If your business is like 99% of all businesses out in the world, your customer workloads vary over time: perhaps over a simple 24 hour period, or you might have seasons where you're busy, and weeks that are not in demand. If you're building out a data center, the question is, what is the right amount of hardware to purchase? If you buy for the average amount, the average usage, you won't be wasting money on average. But when the peak loads come in, you won't have the hardware to service the customers, especially during the critical moments to expect to be making all your results.

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

Now, if you buy for the top max load, you might have happy customers, but for most of the year, you'll have idle resources. Which means your average utilization is very low. And I've seen data centers with average utilization under 10%, just out of fear of missing peak demand. So how do you solve the problem on-premises? Well the truth is, you can't. And here's where AWS changes the conversation entirely.

अब, यदि आप शीर्ष अधिकतम लोड के लिए खरीदारी करते हैं, तो आपके पास खुश ग्राहक हो सकते हैं, लेकिन वर्ष के अधिकांश समय में, आपके पास निष्क्रिय संसाधन होंगे। इसका मतलब है कि आपका औसत उपयोग बहुत कम है। और मैंने 10% से कम औसत उपयोग वाले डेटा सेंटर देखे हैं, सिर्फ चरम मांग के गायब होने के डर से। तो आप ऑन-प्रिमाइसेस में समस्या का समाधान कैसे करते हैं? खैर सच तो यह है, आप ऐसा नहीं कर सकते। और यहीं पर AWS बातचीत को पूरी तरह से बदल देता है।

What if you could provision your workload to exactly the demand, every hour, every day? Well, now you have happy customers, because they can always get the services they want. And you have a happy financial officer because they get the ROI your company needs.

क्या होगा यदि आप अपने कार्यभार को हर घंटे, हर दिन, बिल्कुल मांग के अनुसार व्यवस्थित कर सकें? खैर, अब आपके पास खुश ग्राहक हैं, क्योंकि उन्हें हमेशा वे सेवाएँ मिल सकती हैं जो वे चाहते हैं। और आपके पास एक खुश वित्तीय अधिकारी है क्योंकि उन्हें आपकी कंपनी के लिए आवश्यक आरओआई मिलता है।

And here's how it works. Morgan is behind the counter. She's taking orders and we have a decoupled system. Morgan isn't doing all of the work here, so we need somebody making the drinks. It looks like Rudy's up. Now, the first problem I wanna solve, is the idea that we plan for a disaster. There's a great quote by Werner Vogels that says, "Everything fails all the time, so plan for failure and nothing fails." Or in other words, we ask ourselves what would happen if we lost our order taking instance? Well, we'd be out of business until we'd get another person to work the line, sorry, another instance up and running.

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

So here is where AWS makes it really simple. Using the same programmatic method we used to create the original Morgan, we can create a second Morgan. So if one fails, we have another one already on the front line and taking orders. The customers never lose service. Well, don't forget about the backend. Let's make our processing instances redundant as well. So that gets our regular operating capacity. We now have a highly available system, with no single point of failure. And as long as the number of customers in line stays the same, we're good. But you know that's gonna change, right? So let's take a look at what's going to happen when we have a rush of customers, an increase in demand.

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

Transcript (part-2)

Now there are two ways to handle growing demands. You can scale up, or scale out. Scaling up means adding more power to the machines that are running, which might make sense in a few cases but think about it. When you have an increase in customers, a bigger instance of Morgan really can't take a customer's order any faster. Because that depends on the customer more than Morgan.

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

"I'll take an espresso. Oh, wait, is that organic? Make it a soy latte? Actually, I don't know. Do you just have tea?"

"मैं एक एस्प्रेसो लूंगा।" ओह, रुको, क्या वह जैविक है? इसे सोया लट्टे बनाओ? असल में, मैं नहीं जानता. क्या आपके पास बस चाय है?"

What we need are, well, more Morgans. Customers? Oh, no! Looks like the processing instances are about to get overloaded. So let's scale them as well.

हमें और अधिक मोर्गन की आवश्यकता है। ग्राहक? अरे नहीं! ऐसा लगता है कि प्रसंस्करण उदाहरण अतिभारित होने वाले हैं। तो आइए उन्हें भी मापें।

Obvious question is obvious. How come they are more order taking instances than order makers?

स्पष्ट प्रश्न स्पष्ट है. वे ऑर्डर निर्माताओं की तुलना में अधिक ऑर्डर लेने वाले उदाहरण कैसे हैं?

Well, in this case, the amount of work you can get done is still more than the order machines can send your way. You don't have a backlog. So no reason to add more worker instances. This is one of the great things about decoupling the system. You can end up with exactly the right amount of power for each part of your process, rather than over provisioning to solve a separate problem. Okay, looks like we just cleared that rush.

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

Now here is where AWS really makes a difference to your business. All these extra workers that are sitting around idle, if you don't need them, send them home or stop the instances. Amazon EC2 Auto Scaling. Adds instances based on demand and then decommissions instances when they are no longer needed. This means that every minute of the day, you always have the correct number of instances. Happy customers. Happy CFO. Happy architecture.

अब यहीं पर AWS वास्तव में आपके व्यवसाय में बदलाव लाता है। ये सभी अतिरिक्त कर्मचारी जो बेकार बैठे हैं, यदि आपको उनकी आवश्यकता नहीं है, तो उन्हें घर भेज दें या उदाहरण बंद कर दें। अमेज़न EC2 ऑटो स्केलिंग। मांग के आधार पर इंस्टेंसेस जोड़ता है और फिर जब उनकी जरूरत नहीं रह जाती है तो इंस्टेंसेस को डीकमीशन कर देता है। इसका मतलब यह है कि दिन के हर मिनट में, आपके पास हमेशा घटनाओं की सही संख्या होती है। खुश ग्राहक. खुश सीएफओ. शुभ वास्तु.