WEBVTT

00:00.660 --> 00:01.710
Professor: Nesta lição,

00:01.710 --> 00:04.920
falaremos sobre a importância dos balanceadores de carga.

00:04.920 --> 00:06.120
Agora, os balanceadores de

00:06.120 --> 00:08.340
carga, que também são conhecidos como switch de conteúdo,

00:08.340 --> 00:10.410
são usados para distribuir as solicitações de

00:10.410 --> 00:11.910
entrada em vários servidores dentro

00:11.910 --> 00:15.330
de um formulário de servidor ou em uma infraestrutura de nuvem.

00:15.330 --> 00:17.370
Se você estiver executando um site ou serviço

00:17.370 --> 00:20.040
grande, não poderá fazer tudo isso em um único servidor.

00:20.040 --> 00:22.680
Por exemplo, tenho várias centenas de milhares de alunos

00:22.680 --> 00:23.513
neste momento, fazendo

00:23.513 --> 00:25.680
meus cursos e assistindo a meus vídeos.

00:25.680 --> 00:29.100
Não é possível que um único servidor consiga lidar com essa carga.

00:29.100 --> 00:30.630
Portanto, temos que distribuí-lo

00:30.630 --> 00:32.460
em vários servidores diferentes

00:32.460 --> 00:33.810
em todo o mundo.

00:33.810 --> 00:36.300
Mas quando um aluno deseja acessar meu site, ele não precisa

00:36.300 --> 00:38.340
escolher um servidor específico.

00:38.340 --> 00:41.070
Em vez disso, eles simplesmente vão para o treinamento de diones. com e nosso balanceador de

00:41.070 --> 00:43.230
carga e switch de conteúdo redirecionam

00:43.230 --> 00:45.960
essa solicitação para o próximo servidor disponível

00:45.960 --> 00:47.460
para poder processá-la.

00:47.460 --> 00:49.590
Na verdade, temos vários servidores diferentes

00:49.590 --> 00:50.880
em todo o mundo para lidar com

00:50.880 --> 00:53.100
todas essas solicitações diferentes.

00:53.100 --> 00:55.230
Exatamente a mesma coisa acontece com

00:55.230 --> 00:57.480
a Netflix, o Hulu, o Facebook ou a Amazon,

00:57.480 --> 00:59.280
mas em uma escala muito maior.

00:59.280 --> 01:01.920
Todos esses sites grandes precisam usar um balanceador

01:01.920 --> 01:03.570
de carga, caso contrário, um único

01:03.570 --> 01:05.430
servidor simplesmente travaria sob a

01:05.430 --> 01:06.263
carga e eles sofreriam

01:06.263 --> 01:08.400
um ataque de negação de serviço autoimposto

01:08.400 --> 01:10.650
devido à popularidade do site.

01:10.650 --> 01:12.510
Agora, um balanceador de carga atua essencialmente

01:12.510 --> 01:13.500
como um policial de tráfego,

01:13.500 --> 01:15.120
ficando na frente de seus servidores e encaminhando

01:15.120 --> 01:17.310
a solicitação do cliente para os servidores que estão mais

01:17.310 --> 01:19.410
disponíveis para atender a essas solicitações em um determinado

01:19.410 --> 01:20.970
momento.

01:20.970 --> 01:23.940
Isso maximiza a velocidade de resposta ao usuário e usa

01:23.940 --> 01:25.530
com mais eficiência toda a capacidade

01:25.530 --> 01:28.170
existente dos servidores para todas as solicitações

01:28.170 --> 01:30.060
dos usuários.

01:30.060 --> 01:32.220
O motivo pelo qual um balanceador de carga é tão importante

01:32.220 --> 01:34.230
é que ele é uma das principais coisas que podemos fazer

01:34.230 --> 01:36.750
para ajudar na defesa contra um ataque de negação de serviço ou

01:36.750 --> 01:39.270
um ataque de negação de serviço distribuído.

01:39.270 --> 01:41.730
Agora, o que é um ataque de negação de serviço?

01:41.730 --> 01:43.560
Bem, um ataque de negação de serviço

01:43.560 --> 01:46.410
envolve uma inundação contínua dos sistemas da vítima

01:46.410 --> 01:48.090
com solicitações de serviços, fazendo

01:48.090 --> 01:50.070
com que o sistema fique sem memória e acabe

01:50.070 --> 01:51.570
travando.

01:51.570 --> 01:52.830
No entanto, a maioria dos sistemas

01:52.830 --> 01:55.230
modernos não pode ser derrubada por uma única máquina.

01:55.230 --> 01:58.230
Portanto, em vez disso, os invasores usam um ataque DDoS

01:58.230 --> 02:00.540
(Distributed Denial of Service Attack).

02:00.540 --> 02:02.490
Em um ataque distribuído de negação de

02:02.490 --> 02:04.920
serviço, em vez de um único invasor atacar um servidor,

02:04.920 --> 02:07.200
há centenas ou até milhares de máquinas lançando

02:07.200 --> 02:10.050
simultaneamente esse ataque no servidor, para forçá-lo

02:10.050 --> 02:11.670
a ficar off-line.

02:11.670 --> 02:14.040
Em março de 2018, por exemplo, o GitHub foi atingido

02:14.040 --> 02:16.410
pelo maior DDoS até o momento, em que dezenas de

02:16.410 --> 02:18.570
milhares de pontos de extremidade exclusivos

02:18.570 --> 02:20.160
realizaram um ataque coordenado

02:20.160 --> 02:22.230
para atingir esse servidor com um pico de

02:22.230 --> 02:25.620
tráfego que mediu 1. 35 terabits por segundo.

02:25.620 --> 02:28.980
Isso forçou o site a ficar off-line por apenas cinco minutos.

02:28.980 --> 02:30.750
Mas a verdadeira questão é: como podemos

02:30.750 --> 02:32.670
sobreviver a um desses ataques e evitar

02:32.670 --> 02:35.760
que ele derrube os servidores de nossa organização?

02:35.760 --> 02:37.620
Bem, basta olhar para a Amazon para conhecer

02:37.620 --> 02:39.330
algumas das práticas recomendadas.

02:39.330 --> 02:41.520
Veja, em fevereiro de 2020, a Amazon

02:41.520 --> 02:44.130
foi atingida pelo maior DDoS até hoje, ainda

02:44.130 --> 02:45.630
maior que o GitHub.

02:45.630 --> 02:47.130
E houve um ataque coordenado

02:47.130 --> 02:49.230
para atingir esse servidor com um pico

02:49.230 --> 02:52.410
de tráfego que mediu 2. 3 terabits por segundo, mas devido

02:52.410 --> 02:55.470
à boa arquitetura de segurança que eles têm e à sua capacidade

02:55.470 --> 02:57.480
de aumentar os recursos para sustentar

02:57.480 --> 02:58.950
esse ataque, eles não sofreram

02:58.950 --> 03:01.650
nenhum tempo de inatividade durante o ataque, embora

03:01.650 --> 03:03.900
ele tenha sido 70% maior do que o que derrubou

03:03.900 --> 03:05.880
o GitHub.

03:05.880 --> 03:07.410
Agora, a primeira técnica que eles

03:07.410 --> 03:09.750
usaram é conhecida como blackholing ou sinkholing.

03:09.750 --> 03:10.800
Essa é uma técnica que

03:10.800 --> 03:13.020
identifica todos os endereços IP de ataque e

03:13.020 --> 03:14.400
encaminha todo o tráfego para

03:14.400 --> 03:17.160
um servidor inexistente por meio de uma interface nula,

03:17.160 --> 03:19.410
interrompendo efetivamente o ataque.

03:19.410 --> 03:22.050
Infelizmente, os invasores sempre podem mudar para um novo

03:22.050 --> 03:23.760
IP e reiniciar o ataque novamente.

03:23.760 --> 03:25.950
Portanto, isso não evitará um DDoS para sempre,

03:25.950 --> 03:27.480
mas lhe dará algum tempo enquanto

03:27.480 --> 03:29.640
você trabalha em outras atenuações.

03:29.640 --> 03:32.070
Os IPSs, ou sistemas de prevenção de intrusões, também

03:32.070 --> 03:33.510
podem ser usados para identificar

03:33.510 --> 03:35.730
e responder a ataques de negação de serviço.

03:35.730 --> 03:37.560
Isso pode funcionar bem para ataques de pequena

03:37.560 --> 03:38.520
escala contra a sua rede,

03:38.520 --> 03:40.920
mas não terá capacidade de processamento suficiente

03:40.920 --> 03:42.780
para lidar com um ataque realmente de grande

03:42.780 --> 03:45.060
escala, como o que atingiu a Amazon.

03:45.060 --> 03:46.920
Agora, um dos métodos mais eficazes é usar

03:46.920 --> 03:49.140
a infraestrutura de nuvem elástica, pois ela permite

03:49.140 --> 03:52.290
que você aumente a escala sob demanda, conforme necessário, para que

03:52.290 --> 03:54.300
você possa superar o ataque.

03:54.300 --> 03:55.770
O problema com essa estratégia, porém,

03:55.770 --> 03:57.090
é que a maioria dos provedores de

03:57.090 --> 03:58.920
serviços cobrará com base na capacidade e nos

03:58.920 --> 04:00.510
recursos que você estiver usando.

04:00.510 --> 04:02.190
Portanto, à medida que você aumenta a escala,

04:02.190 --> 04:04.380
isso faz com que recebamos uma conta muito maior do

04:04.380 --> 04:05.940
nosso provedor de serviços em nuvem

04:05.940 --> 04:07.320
e isso pode ser algo pelo qual não

04:07.320 --> 04:09.390
estamos obtendo nenhum retorno sobre o investimento,

04:09.390 --> 04:12.030
porque todo esse tráfego não estava gerando nenhuma receita

04:12.030 --> 04:13.110
para a nossa organização,

04:13.110 --> 04:15.090
era apenas parte do ataque.

04:15.090 --> 04:17.280
Dito isso, pelo menos você continua on-line para atender

04:17.280 --> 04:18.750
aos seus clientes pagantes.

04:18.750 --> 04:20.400
Portanto, é apenas uma questão de saber

04:20.400 --> 04:22.140
se você pode se dar ao luxo de durar mais

04:22.140 --> 04:24.213
do que o ataque DDoS pode continuar.