WEBVTT 00:00.660 --> 00:01.710 Lektor: W tej lekcji 00:01.710 --> 00:04.920 omówimy znaczenie load balancerów. 00:04.920 --> 00:06.120 Teraz load balancery, 00:06.120 --> 00:08.340 znane również jako przełączniki treści, 00:08.340 --> 00:10.410 są używane do dystrybucji przychodzących 00:10.410 --> 00:11.910 żądań na wielu serwerach wewnątrz 00:11.910 --> 00:15.330 formy serwera lub infrastruktury chmury. 00:15.330 --> 00:17.370 Jeśli prowadzisz dużą witrynę lub usługę, 00:17.370 --> 00:20.040 nie możesz zrobić tego wszystkiego na jednym serwerze. 00:20.040 --> 00:22.680 Na przykład, w tym momencie mam kilkaset tysięcy studentów, 00:22.680 --> 00:23.513 którzy biorą udział 00:23.513 --> 00:25.680 w moich kursach i oglądają moje filmy. 00:25.680 --> 00:29.100 Nie ma możliwości, by pojedynczy serwer poradził sobie z tak dużym obciążeniem. 00:29.100 --> 00:30.630 Musimy więc dystrybuować 00:30.630 --> 00:32.460 je na wielu różnych serwerach 00:32.460 --> 00:33.810 na całym świecie. 00:33.810 --> 00:36.300 Ale kiedy student chce odwiedzić moją stronę, nie 00:36.300 --> 00:38.340 musi wybierać konkretnego serwera. 00:38.340 --> 00:41.070 Zamiast tego po prostu idą na trening. com, a nasz load balancer 00:41.070 --> 00:43.230 i przełącznik treści przekierowuje 00:43.230 --> 00:45.960 to żądanie do następnego dostępnego serwera, aby 00:45.960 --> 00:47.460 móc je przetworzyć. 00:47.460 --> 00:49.590 W rzeczywistości mamy mnóstwo różnych serwerów 00:49.590 --> 00:50.880 na całym świecie, aby obsłużyć 00:50.880 --> 00:53.100 wszystkie te różne żądania. 00:53.100 --> 00:55.230 Dokładnie to samo dzieje się z Netflixem, 00:55.230 --> 00:57.480 Hulu, Facebookiem czy Amazonem, ale na 00:57.480 --> 00:59.280 znacznie większą skalę. 00:59.280 --> 01:01.920 Wszystkie te duże strony internetowe muszą korzystać z load 01:01.920 --> 01:03.570 balancera, w przeciwnym razie pojedynczy 01:03.570 --> 01:06.263 serwer po prostu zawiesiłby się pod obciążeniem, a oni sami 01:06.263 --> 01:08.400 ucierpieliby z powodu ataku odmowy usługi ze względu 01:08.400 --> 01:10.650 na popularność ich witryny. 01:10.650 --> 01:12.510 Teraz load balancer działa zasadniczo 01:12.510 --> 01:13.500 jako policjant ruchu, 01:13.500 --> 01:15.120 siedząc przed serwerami i kierując 01:15.120 --> 01:17.310 żądania klienta do serwerów, które są najbardziej 01:17.310 --> 01:19.410 dostępne do spełnienia tych żądań w danym 01:19.410 --> 01:20.970 momencie. 01:20.970 --> 01:23.940 Maksymalizuje to szybkość reagowania na użytkownika 01:23.940 --> 01:25.530 i bardziej efektywnie wykorzystuje 01:25.530 --> 01:28.170 całą istniejącą pojemność serwerów dla wszystkich 01:28.170 --> 01:30.060 żądań użytkowników. 01:30.060 --> 01:32.220 Powodem, dla którego load balancer jest tak ważny, 01:32.220 --> 01:34.230 jest to, że jest to jedna z kluczowych rzeczy, które 01:34.230 --> 01:36.750 możemy zrobić, aby pomóc w obronie przed atakiem typu Denial 01:36.750 --> 01:39.270 of Service lub Distributed Denial of Service Attack. 01:39.270 --> 01:41.730 Czym jest atak typu Denial of Service? 01:41.730 --> 01:43.560 Atak typu Denial of Service polega 01:43.560 --> 01:46.410 na ciągłym zalewaniu systemów ofiary żądaniami 01:46.410 --> 01:48.090 usług, powodując wyczerpanie 01:48.090 --> 01:51.570 pamięci i ostatecznie awarię systemu. 01:51.570 --> 01:52.830 Obecnie jednak większość nowoczesnych 01:52.830 --> 01:55.230 systemów nie może zostać zniszczona przez pojedynczą maszynę. 01:55.230 --> 01:58.230 Zamiast tego atakujący stosują atak DDoS (Distributed 01:58.230 --> 02:00.540 Denial of Service Attack). 02:00.540 --> 02:02.490 W rozproszonym ataku typu Denial of Service, 02:02.490 --> 02:04.920 zamiast pojedynczego napastnika atakującego serwer, 02:04.920 --> 02:07.200 setki lub nawet tysiące maszyn jednocześnie 02:07.200 --> 02:10.050 przeprowadzają atak na serwer, aby zmusić go do przejścia 02:10.050 --> 02:11.670 w tryb offline. 02:11.670 --> 02:14.040 Na przykład w marcu 2018 r. GitHub został zaatakowany 02:14.040 --> 02:16.410 przez największy jak dotąd DDoS, w którym dziesiątki 02:16.410 --> 02:18.570 tysięcy unikalnych punktów końcowych przeprowadziło 02:18.570 --> 02:20.160 skoordynowany atak, aby uderzyć 02:20.160 --> 02:22.230 w ten serwer z gwałtownym wzrostem ruchu, który 02:22.230 --> 02:25.620 wyniósł 1. 35 terabitów na sekundę. 02:25.620 --> 02:28.980 Spowodowało to wyłączenie strony na pięć minut. 02:28.980 --> 02:30.750 Ale prawdziwe pytanie brzmi: jak 02:30.750 --> 02:32.670 przetrwać jeden z tych ataków i zapobiec 02:32.670 --> 02:35.760 wyłączeniu serwerów naszej organizacji? 02:35.760 --> 02:37.620 Cóż, wystarczy spojrzeć na Amazon, aby poznać 02:37.620 --> 02:39.330 niektóre z najlepszych praktyk. 02:39.330 --> 02:41.520 W lutym 2020 r. Amazon został zaatakowany 02:41.520 --> 02:44.130 przez największy jak dotąd DDoS, nawet większy 02:44.130 --> 02:45.630 niż GitHub. 02:45.630 --> 02:47.130 Przeprowadzono skoordynowany 02:47.130 --> 02:49.230 atak na ten serwer, który spowodował wzrost 02:49.230 --> 02:52.410 ruchu mierzony 2. 3 terabity na sekundę, ale ze 02:52.410 --> 02:55.470 względu na dobrą architekturę bezpieczeństwa i zdolność 02:55.470 --> 02:57.480 do skalowania zasobów w celu utrzymania 02:57.480 --> 02:58.950 tego ataku, nie doświadczyli 02:58.950 --> 03:01.650 przestojów podczas ataku, mimo że był on o 70% większy 03:01.650 --> 03:05.880 niż ten, który doprowadził do awarii GitHub. 03:05.880 --> 03:07.410 Pierwsza technika, której użyli, 03:07.410 --> 03:09.750 znana jest jako blackholing lub sinkholing. 03:09.750 --> 03:10.800 Jest to technika, która 03:10.800 --> 03:13.020 identyfikuje wszystkie atakujące adresy 03:13.020 --> 03:14.400 IP i kieruje cały ich ruch do 03:14.400 --> 03:17.160 nieistniejącego serwera przez zerowy interfejs, 03:17.160 --> 03:19.410 skutecznie zatrzymując atak. 03:19.410 --> 03:22.050 Niestety, atakujący zawsze mogą przenieść się na nowy adres 03:22.050 --> 03:23.760 IP i ponownie rozpocząć atak. 03:23.760 --> 03:25.950 Nie zapobiegnie więc DDoS na zawsze, ale 03:25.950 --> 03:27.480 da ci trochę czasu na pracę 03:27.480 --> 03:29.640 nad innymi środkami zaradczymi. 03:29.640 --> 03:32.070 Systemy IPS (Intrusion Prevention Systems) mogą być również 03:32.070 --> 03:33.510 wykorzystywane do identyfikacji 03:33.510 --> 03:35.730 i reagowania na ataki typu Denial of Service. 03:35.730 --> 03:37.560 Może to działać dobrze w przypadku ataków na 03:37.560 --> 03:38.520 małą skalę na sieć, ale 03:38.520 --> 03:40.920 nie będzie miało wystarczającej mocy obliczeniowej, aby 03:40.920 --> 03:42.780 poradzić sobie z atakiem na naprawdę dużą skalę, 03:42.780 --> 03:45.060 takim jak ten, którego celem był Amazon. 03:45.060 --> 03:46.920 Obecnie jedną z najskuteczniejszych metod 03:46.920 --> 03:49.140 jest korzystanie z elastycznej infrastruktury chmurowej, 03:49.140 --> 03:52.290 ponieważ umożliwia ona skalowanie na żądanie w zależności od potrzeb, dzięki 03:52.290 --> 03:54.300 czemu można przetrwać atak. 03:54.300 --> 03:55.770 Problem z tą strategią polega jednak 03:55.770 --> 03:57.090 na tym, że większość dostawców 03:57.090 --> 03:58.920 usług nalicza opłaty w oparciu o pojemność 03:58.920 --> 04:00.510 i wykorzystywane zasoby. 04:00.510 --> 04:02.190 Tak więc w miarę skalowania powoduje 04:02.190 --> 04:04.380 to, że otrzymujemy znacznie większy rachunek 04:04.380 --> 04:05.940 od naszego dostawcy usług w chmurze 04:05.940 --> 04:07.320 i może to być coś, za co nie otrzymujemy 04:07.320 --> 04:09.390 żadnego zwrotu z inwestycji, ponieważ cały 04:09.390 --> 04:13.110 ten ruch nie generował żadnych przychodów dla naszej organizacji, wszystko to 04:13.110 --> 04:15.090 było tylko częścią ataku. 04:15.090 --> 04:17.280 To powiedziawszy, przynajmniej pozostajesz online, aby obsługiwać 04:17.280 --> 04:18.750 swoich płacących klientów. 04:18.750 --> 04:20.400 Staje się więc kwestią tego, czy 04:20.400 --> 04:22.140 możesz sobie pozwolić na przetrwanie 04:22.140 --> 04:24.213 dłużej niż atak DDoS może trwać.