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

Directing Traffic with Elastic Load Balancing

इलास्टिक लोड संतुलन के साथ यातायात को निर्देशित करना

Elastic Load Balancing | लोचदार भार संतुलन

Elastic Load Balancing is the AWS service that automatically distributes incoming application traffic across multiple resources, such as Amazon EC2 instances.

इलास्टिक लोड बैलेंसिंग AWS सेवा है जो आने वाले एप्लिकेशन ट्रैफ़िक को Amazon EC2 इंस्टेंसेस जैसे कई संसाधनों में स्वचालित रूप से वितरित करती है।

A load balancer acts as a single point of contact for all incoming web traffic to your Auto Scaling group. This means that as you add or remove Amazon EC2 instances in response to the amount of incoming traffic, these requests route to the load balancer first. Then, the requests spread across multiple resources that will handle them. For example, if you have multiple Amazon EC2 instances, Elastic Load Balancing distributes the workload across the multiple instances so that no single instance has to carry the bulk of it.

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

Although Elastic Load Balancing and Amazon EC2 Auto Scaling are separate services, they work together to help ensure that applications running in Amazon EC2 can provide high performance and availability.

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

Example: Elastic Load Balancing | उदाहरण: लोचदार भार संतुलन

ELB pointing to two EC2 instances in an Auto Scaling group.

ELB एक ऑटो स्केलिंग समूह में दो EC2 उदाहरणों की ओर इशारा करता है।

Low-demand period | कम मांग वाली अवधि

Here’s an example of how Elastic Load Balancing works. Suppose that a few customers have come to the coffee shop and are ready to place their orders.

यहां एक उदाहरण दिया गया है कि इलास्टिक लोड बैलेंसिंग कैसे काम करती है। मान लीजिए कि कुछ ग्राहक कॉफ़ी शॉप में आए हैं और अपना ऑर्डर देने के लिए तैयार हैं।

If only a few registers are open, this matches the demand of customers who need service. The coffee shop is less likely to have open registers with no customers. In this example, you can think of the registers as Amazon EC2 instances.

यदि केवल कुछ रजिस्टर खुले हैं, तो यह उन ग्राहकों की मांग से मेल खाता है जिन्हें सेवा की आवश्यकता है। कॉफ़ी शॉप में बिना किसी ग्राहक के खुले रजिस्टर होने की संभावना कम है। इस उदाहरण में, आप रजिस्टरों को Amazon EC2 इंस्टेंसेस के रूप में सोच सकते हैं।

Elastic Load Balancing during a high-demand period.
उच्च मांग अवधि के दौरान लोचदार भार संतुलन।

High-demand period | उच्च मांग अवधि

Throughout the day, as the number of customers increases, the coffee shop opens more registers to accommodate them.

दिन भर में, जैसे-जैसे ग्राहकों की संख्या बढ़ती है, कॉफ़ी शॉप उन्हें समायोजित करने के लिए और अधिक रजिस्टर खोलती है।

Additionally, a coffee shop employee directs customers to the most appropriate register so that the number of requests can evenly distribute across the open registers. You can think of this coffee shop employee as a load balancer.

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

So we solved the scaling problem with Amazon EC2 Auto Scaling. But now we've got a bit of a traffic problem, don't we? Let's take a look at the situation. When customers come into the coffee shop, right now they have three options for which cashier to talk to to place an order. And oddly enough, most of them are lining up in one line, causing an uneven distribution of customers per line. Even though we have other cashiers waiting to take orders, standing around doing nothing. Customers come in and aren't sure exactly where to route their order. It would help a lot if we added a host to the situation.

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

A host stands at the door and when customers come into the coffee shop, they tell them which line to proceed to for placing their order. The host keeps an eye on the cashier's taking orders, and counts the number of people in line each cashier is serving. Then it will direct new customers to the cashier that has the shortest line, that's the least bogged down, thus allowing the lines to be even across cashiers and helping customers be served in the most efficient manner possible.

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

The same idea applies to your AWS environment. When you have multiple EC2 instances all running the same program, to serve the same purpose, and a request comes in, how does that request know which EC2 instance to go to? How can you ensure there's an even distribution of workload across EC2 instances? So not just one is backed up while the others are idle sitting by. You need a way to route requests to instances to process that request. What you need to solve this is called load balancing.

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

A load balancer is an application that takes in requests and routes them to the instances to be processed. Now, there are many off the shelf load balancers that work great on AWS. And if you have a favorite flavor that already does exactly what you want, then feel free to keep using it. In which case it will be up to your operations team to install, manage, update, scale, handle fail over, and availability. It's doable. Odds are what you really need is just to properly distribute traffic in a high performance, cost-efficient, highly available, automatically scalable system that you can just set and forget.

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

Introducing Elastic Load Balancing. Elastic Load Balancing, or ELB, is one of the first major managed services we're going to talk about in this course. And it's engineered to address the undifferentiated heavy lifting of load balancing. To illustrate this point, I need to zoom out a bit here. To begin with, Elastic Load Balancing is a regional construct, and we'll explain more of what that means in later videos. But the key value for you is that because it runs at the Region level rather than on individual EC2 instances, the service is automatically highly available with no additional effort on your part.

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

ELB is automatically scalable. As your traffic grows, ELB is designed to handle the additional throughput with no change to the hourly cost. When your EC2 fleet auto-scales out, as each instance comes online, the auto-scaling service just lets the Elastic Load Balancing service know that it's ready to handle the traffic, and off it goes. Once the fleet scales in, ELB first stops all new traffic, and waits for the existing requests to complete, to drain out. Once they do that, then the auto-scaling engine can terminate the instances without disruption to existing customers.

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

ELB is not only used for external traffic. Let's look at the ordering tier, and how it communicates with the production tier. Right now, each front end instance is aware of each backend instance. And if a new back end instance comes online, in this current architecture, it would have to tell every front end instance that it can now accept traffic. This is complicated enough with just half a dozen instances. Now imagine you have potentially hundreds of instances on both tiers. Each tier shifting constantly based on demand. Just keeping them networked efficiently is impossible.

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

Well, we solve the back end traffic chaos with an ELB as well. Because ELB is regional, it's a single URL that each front end instance uses. Then the ELB directs traffic to the back end that has the least outstanding requests. Now, if the back end scales, once the new instance is ready, it just tells the ELB that it can take traffic, and it gets to work. The front end doesn't know and doesn't care how many back end instances are running. This is true decoupled architecture.

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

There's even more that the ELB can do that we'll learn about later, but this is good enough for now. The key is choosing the right tool for the right job, which is one of the reasons AWS offers so many different services. For example, back end communication. There are many ways to handle it and ELB is just one method. Next, we'll talk about some other services that might work even better for some architectures.

ईएलबी और भी बहुत कुछ कर सकता है जिसके बारे में हम बाद में जानेंगे, लेकिन अभी के लिए यह काफी अच्छा है। मुख्य बात सही काम के लिए सही उपकरण चुनना है, यही एक कारण है कि AWS इतनी सारी अलग-अलग सेवाएँ प्रदान करता है। उदाहरण के लिए, बैक एंड संचार। इसे संभालने के कई तरीके हैं और ईएलबी सिर्फ एक तरीका है। आगे, हम कुछ अन्य सेवाओं के बारे में बात करेंगे जो कुछ आर्किटेक्चर के लिए और भी बेहतर काम कर सकती हैं।