1 00:00:06,665 --> 00:00:09,401 - Now let's talk about Load Balancing Algorithms 2 00:00:09,401 --> 00:00:11,616 for the Elastic Load Balancer. 3 00:00:11,616 --> 00:00:14,167 Under the hood, behind the scenes 4 00:00:14,167 --> 00:00:17,532 of the Elastic Load Balancer, the way that this works 5 00:00:17,532 --> 00:00:21,189 is that it creates what we call nodes, and of course, 6 00:00:21,189 --> 00:00:24,018 this is not something that we really have to worry about, 7 00:00:24,018 --> 00:00:25,896 it's just interesting technical knowledge 8 00:00:25,896 --> 00:00:27,844 so that you can understand the behavior 9 00:00:27,844 --> 00:00:30,656 of the Elastic Load Balancer. 10 00:00:30,656 --> 00:00:33,318 So we have nodes, you'll notice here, 11 00:00:33,318 --> 00:00:35,342 that the Elastic Load Balancing service 12 00:00:35,342 --> 00:00:38,092 will place a node in every subnet 13 00:00:39,320 --> 00:00:42,141 that we say we want to use. 14 00:00:42,141 --> 00:00:45,242 And again, it's a good practice to use every available 15 00:00:45,242 --> 00:00:49,679 availability zone in that particular region. 16 00:00:49,679 --> 00:00:51,441 So we have these multiple nodes. 17 00:00:51,441 --> 00:00:54,432 Each one of them will get its own IP address. 18 00:00:54,432 --> 00:00:58,281 If you're using an internet-facing ELB, 19 00:00:58,281 --> 00:01:01,266 these nodes will get public IP addresses. 20 00:01:01,266 --> 00:01:04,865 If you're using internal Elastic Load Balancer, 21 00:01:04,865 --> 00:01:08,717 then these nodes will get a private IP address. 22 00:01:08,717 --> 00:01:13,694 Now, as requests come in from either the internet, 23 00:01:13,694 --> 00:01:16,119 or they come in from a private service, 24 00:01:16,119 --> 00:01:17,819 wherever they come in from, 25 00:01:17,819 --> 00:01:21,931 once they reach the Load Balancer they are distributed 26 00:01:21,931 --> 00:01:25,598 between these two nodes via DNS round robin. 27 00:01:26,921 --> 00:01:29,459 So it's just going, essentially, back and forth 28 00:01:29,459 --> 00:01:31,549 between these nodes. 29 00:01:31,549 --> 00:01:35,208 Now, as your traffic grows and as you start to receive 30 00:01:35,208 --> 00:01:38,253 more and more requests, the Elastic Load Balancer 31 00:01:38,253 --> 00:01:41,493 will automatically scale the number of nodes 32 00:01:41,493 --> 00:01:44,870 to handle that incoming traffic. 33 00:01:44,870 --> 00:01:49,337 Now there are times when traffic is spiking faster 34 00:01:49,337 --> 00:01:53,234 than the Elastic Load Balancer is scaling. 35 00:01:53,234 --> 00:01:56,035 And some people seem to find that 36 00:01:56,035 --> 00:01:59,974 the Elastic Load Balancer doesn't scale fast enough 37 00:01:59,974 --> 00:02:03,411 for their particular traffic patterns, so in those cases, 38 00:02:03,411 --> 00:02:06,374 cases where you do expect traffic to spike, 39 00:02:06,374 --> 00:02:10,165 you can submit a ticket to Amazon's support 40 00:02:10,165 --> 00:02:13,624 and ask them to quote unquote pre-warm 41 00:02:13,624 --> 00:02:18,615 your Elastic Load Balancer and go ahead and initiate 42 00:02:18,615 --> 00:02:22,613 that scaling event ahead of that wave of traffic, 43 00:02:22,613 --> 00:02:26,550 and that will get you more nodes here under the hood. 44 00:02:26,550 --> 00:02:30,962 So again, as traffic is coming in, it is being distributed 45 00:02:30,962 --> 00:02:34,613 among these nodes via DNS round robin. 46 00:02:34,613 --> 00:02:38,569 Between the node and the back-end instances, 47 00:02:38,569 --> 00:02:42,652 we're going to use the least outstanding requests 48 00:02:43,677 --> 00:02:47,406 as a way to determine which back-end node 49 00:02:47,406 --> 00:02:50,253 should handle that particular request. 50 00:02:50,253 --> 00:02:52,510 You can see here, again, we're leveraging multiple 51 00:02:52,510 --> 00:02:54,611 availability zones. 52 00:02:54,611 --> 00:02:57,073 As our traffic begins to scale, 53 00:02:57,073 --> 00:02:59,580 we would see that we would start to add, 54 00:02:59,580 --> 00:03:02,734 probably through the auto-scaling service 55 00:03:02,734 --> 00:03:04,711 that we'll talk about here, coming up, 56 00:03:04,711 --> 00:03:07,837 but we would start to add multiple EC2 instances, 57 00:03:07,837 --> 00:03:10,391 maintaining a balance across 58 00:03:10,391 --> 00:03:13,472 these multiple availability zones. 59 00:03:13,472 --> 00:03:17,013 Now you'll notice here that we have multiple instances 60 00:03:17,013 --> 00:03:20,070 across multiple availability zones, in this case, 61 00:03:20,070 --> 00:03:22,934 we're using us-west-2, so in this example, 62 00:03:22,934 --> 00:03:27,101 we have 2a and 2c, it's possible for a Load Balancer node, 63 00:03:30,082 --> 00:03:34,249 over here in 2a, to send a request off to a back-end 64 00:03:39,259 --> 00:03:42,469 instance in another availability zone, 65 00:03:42,469 --> 00:03:45,943 and we call the Cross-Zone load balancing. 66 00:03:45,943 --> 00:03:48,839 That is an option that is enabled by default, 67 00:03:48,839 --> 00:03:51,584 we can turn that off if we want to, 68 00:03:51,584 --> 00:03:56,272 but it's important to know that it can help maintain 69 00:03:56,272 --> 00:04:00,578 an even balance of requests across our servers, 70 00:04:00,578 --> 00:04:03,787 but it does incur an additional cost. 71 00:04:03,787 --> 00:04:07,118 The data being transferred across availability zones 72 00:04:07,118 --> 00:04:10,502 will cost us an additional bandwidth charge. 73 00:04:10,502 --> 00:04:13,835 So again, requests coming in, initially, 74 00:04:15,392 --> 00:04:18,903 are balanced between nodes of the Load Balancer 75 00:04:18,903 --> 00:04:23,014 via DNS round robin, between the Load Balancer node 76 00:04:23,014 --> 00:04:26,536 and the back-end service, those are handled 77 00:04:26,536 --> 00:04:29,119 via least outstanding requests.