WEBVTT 1 00:00:00.660 --> 00:00:01.710 In this lesson, 2 00:00:01.710 --> 00:00:04.920 we're going to talk about the importance of load balancers. 3 00:00:04.920 --> 00:00:06.120 Now load balancers, 4 00:00:06.120 --> 00:00:08.340 which are also known as a content switch, 5 00:00:08.340 --> 00:00:10.410 are used to distribute the incoming requests 6 00:00:10.410 --> 00:00:11.910 across a number of servers 7 00:00:11.910 --> 00:00:15.330 inside of a server form or a cloud infrastructure. 8 00:00:15.330 --> 00:00:17.370 If you're running a large website or service, 9 00:00:17.370 --> 00:00:20.040 you cannot do all of that on a single server. 10 00:00:20.040 --> 00:00:22.680 For example, I have several hundred thousand students 11 00:00:22.680 --> 00:00:23.513 at this point, 12 00:00:23.513 --> 00:00:25.680 taking my courses and watching my videos. 13 00:00:25.680 --> 00:00:29.100 There is no way a single server can handle that much load. 14 00:00:29.100 --> 00:00:30.630 So we have to distribute it 15 00:00:30.630 --> 00:00:32.460 across a lot of different servers 16 00:00:32.460 --> 00:00:33.810 all over the world. 17 00:00:33.810 --> 00:00:36.300 But when a student wants to visit my website, 18 00:00:36.300 --> 00:00:38.340 they don't have to choose a specific server. 19 00:00:38.340 --> 00:00:41.070 Instead, they just go to diontraining.com 20 00:00:41.070 --> 00:00:43.230 and our load balancer and content switch 21 00:00:43.230 --> 00:00:45.960 redirects that request to the next available server 22 00:00:45.960 --> 00:00:47.460 to be able to process it. 23 00:00:47.460 --> 00:00:49.590 In fact, we have tons of different servers 24 00:00:49.590 --> 00:00:50.880 sitting all over the world 25 00:00:50.880 --> 00:00:53.100 to handle all of those different requests. 26 00:00:53.100 --> 00:00:55.230 The exact same thing happens with Netflix 27 00:00:55.230 --> 00:00:57.480 or Hulu or Facebook or Amazon, 28 00:00:57.480 --> 00:00:59.280 but on a much larger scale. 29 00:00:59.280 --> 00:01:01.920 All these large websites have to use a load balancer, 30 00:01:01.920 --> 00:01:03.570 otherwise a single server 31 00:01:03.570 --> 00:01:05.430 would simply crash under the load 32 00:01:05.430 --> 00:01:06.263 and they would suffer 33 00:01:06.263 --> 00:01:08.400 a self-imposed Denial of Service Attack 34 00:01:08.400 --> 00:01:10.650 because of their website's popularity. 35 00:01:10.650 --> 00:01:12.510 Now a load balancer essentially acts 36 00:01:12.510 --> 00:01:13.500 as a traffic cop 37 00:01:13.500 --> 00:01:15.120 by sitting in front of your servers 38 00:01:15.120 --> 00:01:17.310 and routing the client's request to the servers 39 00:01:17.310 --> 00:01:19.410 who are most available to fulfill those requests 40 00:01:19.410 --> 00:01:20.970 at any given time. 41 00:01:20.970 --> 00:01:23.940 this maximizes the speed to responding to the user 42 00:01:23.940 --> 00:01:25.530 and it more efficiently uses 43 00:01:25.530 --> 00:01:28.170 all of your existing capacity for your servers 44 00:01:28.170 --> 00:01:30.060 for all of your user requests. 45 00:01:30.060 --> 00:01:32.220 The reason a load balancer is so important, 46 00:01:32.220 --> 00:01:34.230 is that it is one of the key things we can do 47 00:01:34.230 --> 00:01:36.750 to help defend against a Denial of Service Attack 48 00:01:36.750 --> 00:01:39.270 or a Distributed Denial of Service Attack. 49 00:01:39.270 --> 00:01:41.730 Now, what is a Denial of Service Attack? 50 00:01:41.730 --> 00:01:43.560 Well, a Denial of Service Attack 51 00:01:43.560 --> 00:01:46.410 involves a continual flooding of victim systems 52 00:01:46.410 --> 00:01:48.090 with requests for services, 53 00:01:48.090 --> 00:01:50.070 causing the system to run out of memory 54 00:01:50.070 --> 00:01:51.570 and eventually crash. 55 00:01:51.570 --> 00:01:52.830 Now most modern systems 56 00:01:52.830 --> 00:01:55.230 can't be taken down by a single machine though. 57 00:01:55.230 --> 00:01:58.230 So instead, attackers use a DDoS 58 00:01:58.230 --> 00:02:00.540 or Distributed Denial of Service Attack. 59 00:02:00.540 --> 00:02:02.490 In a Distributed Denial of Service Attack, 60 00:02:02.490 --> 00:02:04.920 instead of a single attacker targeting a server, 61 00:02:04.920 --> 00:02:07.200 there are hundreds or even thousands of machines 62 00:02:07.200 --> 00:02:10.050 simultaneously launching that attack on the server, 63 00:02:10.050 --> 00:02:11.670 to force it offline. 64 00:02:11.670 --> 00:02:14.040 In March of 2018, for example, 65 00:02:14.040 --> 00:02:16.410 GitHub was hit by the largest DDoS to date, 66 00:02:16.410 --> 00:02:18.570 where tens of thousands of unique endpoints 67 00:02:18.570 --> 00:02:20.160 conducted a coordinated attack 68 00:02:20.160 --> 00:02:22.230 to hit that server with a spike in traffic 69 00:02:22.230 --> 00:02:25.620 that measured 1.35 terabits per second. 70 00:02:25.620 --> 00:02:28.980 This forced the site offline for all of five minutes. 71 00:02:28.980 --> 00:02:30.750 But the real question is, 72 00:02:30.750 --> 00:02:32.670 how can we survive one of these attacks 73 00:02:32.670 --> 00:02:35.760 and prevent it from taking down our organization's servers? 74 00:02:35.760 --> 00:02:37.620 Well, we just need to look at Amazon 75 00:02:37.620 --> 00:02:39.330 for some of the best practices. 76 00:02:39.330 --> 00:02:41.520 You see, in February of 2020, 77 00:02:41.520 --> 00:02:44.130 Amazon was hit by the largest DDoS to date, 78 00:02:44.130 --> 00:02:45.630 even larger than GitHub. 79 00:02:45.630 --> 00:02:47.130 And there was a coordinated attack 80 00:02:47.130 --> 00:02:49.230 to hit that server with a spike in traffic 81 00:02:49.230 --> 00:02:52.410 that measured 2.3 terabits per second, 82 00:02:52.410 --> 00:02:55.470 but due to the good security architecture they have 83 00:02:55.470 --> 00:02:57.480 and their ability to scale up resources 84 00:02:57.480 --> 00:02:58.950 to sustain that attack, 85 00:02:58.950 --> 00:03:01.650 they suffered no downtime during the attack, 86 00:03:01.650 --> 00:03:03.900 even though it was 70% larger 87 00:03:03.900 --> 00:03:05.880 than the one that took down GitHub. 88 00:03:05.880 --> 00:03:07.410 Now, the first technique they used 89 00:03:07.410 --> 00:03:09.750 is known as blackholing or sinkholing. 90 00:03:09.750 --> 00:03:10.800 This is a technique 91 00:03:10.800 --> 00:03:13.020 that identifies any attacking IP addresses 92 00:03:13.020 --> 00:03:14.400 and routes all their traffic 93 00:03:14.400 --> 00:03:17.160 to a non-existent server through a null interface, 94 00:03:17.160 --> 00:03:19.410 effectively stopping the attack. 95 00:03:19.410 --> 00:03:22.050 Unfortunately, the attackers can always move to a new IP 96 00:03:22.050 --> 00:03:23.760 and restart the attack again. 97 00:03:23.760 --> 00:03:25.950 So it won't prevent a DDoS forever, 98 00:03:25.950 --> 00:03:27.480 but it will buy you some time 99 00:03:27.480 --> 00:03:29.640 as you work on other mitigations. 100 00:03:29.640 --> 00:03:32.070 IPSs, or Intrusion Prevention Systems, 101 00:03:32.070 --> 00:03:33.510 can also be used to identify 102 00:03:33.510 --> 00:03:35.730 and respond to Denial of Service Attacks. 103 00:03:35.730 --> 00:03:37.560 This may work well for small scale attacks 104 00:03:37.560 --> 00:03:38.520 against your network, 105 00:03:38.520 --> 00:03:40.920 but it's not going to have enough processing power 106 00:03:40.920 --> 00:03:42.780 to handle a truly large scale attack, 107 00:03:42.780 --> 00:03:45.060 like the one Amazon was targeted with. 108 00:03:45.060 --> 00:03:46.920 Now one of the most effective methods is 109 00:03:46.920 --> 00:03:49.140 to use elastic cloud infrastructure, 110 00:03:49.140 --> 00:03:52.290 because it allows you to scale up on demand as needed, 111 00:03:52.290 --> 00:03:54.300 so you can ride out the attack. 112 00:03:54.300 --> 00:03:55.770 The issue with this strategy though, 113 00:03:55.770 --> 00:03:57.090 is that most service providers 114 00:03:57.090 --> 00:03:58.920 will charge you based on capacity 115 00:03:58.920 --> 00:04:00.510 and resources that you're using. 116 00:04:00.510 --> 00:04:02.190 So as you scale up, 117 00:04:02.190 --> 00:04:04.380 this causes us to receive a much larger bill 118 00:04:04.380 --> 00:04:05.940 from our cloud service provider 119 00:04:05.940 --> 00:04:07.320 and this can be something 120 00:04:07.320 --> 00:04:09.390 that we're not getting any return on investment for, 121 00:04:09.390 --> 00:04:12.030 because all that traffic wasn't generating any revenue 122 00:04:12.030 --> 00:04:13.110 for our organization, 123 00:04:13.110 --> 00:04:15.090 it was all just part of the attack. 124 00:04:15.090 --> 00:04:17.280 That said, at least you're remaining online 125 00:04:17.280 --> 00:04:18.750 to serve your paying customers. 126 00:04:18.750 --> 00:04:20.400 So it just becomes a matter of 127 00:04:20.400 --> 00:04:22.140 if you can afford to last longer 128 00:04:22.140 --> 00:04:24.213 than the DDoS attack can keep going on.