Neste vídeo, vamos falar sobre os erros cometidos no segundo ano do projeto, onde desenvolvemos uma API de alta performance em 3 meses com LoopbackJS/ExpressJS e como um CDN e um API Gateway nos ajudaram na solução dos problemas enfrentados.

Perdeu o primeiro vídeo? Clique no link abaixo para conferir:
https://youtu.be/BzGTJRMwKxY

Conforme falamos no vídeo anterior, o sucesso do projeto no primeiro ano, onde alcançamos o pico de 26.000 usuários simultâneos, os servidores não passaram de 4% de CPU e o banco de dados não passou de 7%, só foi possível, porque utilizamos o Framework Loopback JS. Ele é baseado no Express JS, que é o framework mais utilizado em Node JS para o desenvolvimento de API’s.

Já no segundo ano, a história não se repetiu.

Foram cometidos erros que afetaram a performance e a segurança da aplicação. Além de, termos sofrido um ataque DDoS massivo.

Ataques DDoS tentam desabilitar ou sobre-carregar serviços da sua aplicação e por vezes descobrir falhas e vulnerabilidades na aplicação.

Para enfretarmos estes ataques, realizamos a implementação do Cloudflare CDN (Content Delivery Network). Porém, como todas as boas soluções, o Cloudflare possuía limitações e não conseguimos segurar todas as requisições vindas de aproximadamente 300.000 IPs diferentes.

Lembre-se:

Nenhum WAF (Web Application Firewall) é capaz de proteger sua aplicação se houverem métodos abertos ou expostos para serem explorados por hackers.

Para complementar a camada do Cloudflare e reduzir drasticamente o impacto na aplicação, é possível utilizar o CDN em conjunto com soluções de API Gateway.

Uma dessas soluções, é o Kong HQ um API Gateway.

Ele é baseado no NGinx, que é um dos servidores HTTP mais utilizados atualmente. Ambas as ferramentas são Open Source.

Links para maiores detalhes:

📌 Cloudflare:
https://www.cloudflare.com/

📌 Kong API Gateway:
https://konghq.com/

📌 NGinx:
https://www.nginx.com/

Quer saber mais sobre como desenvolver um Plugin com o Kong e LUA (Linguagem de Programação) capaz de detectar comportamentos suspeitos, integrá-lo com a API do Cloudflare e reduzir ainda mais o impacto na performance e consumo de recursos computacionais?

Fica ligado nos próximos vídeos, que vamos te trazer mais detalhes sobre este assunto!

Acompanhe mais vídeos da série “Programando”:

📌Como e quando utilizar micro-serviços na sua aplicação
https://youtu.be/KZL20BCkRY8

📌Como economizar dinheiro com infra-estrutura em nuvem?
https://youtu.be/T3d2gFB_0-Q

📌Perguntas que você deveria fazer antes de implementar um CDN
https://youtu.be/q01_dhQztWQ

📌Amazon Web Services (AWS) – CURSO GRÁTIS!
https://youtu.be/Q-eZHw7iRBw

📌Como desenvolvemos uma API de alta performance em 3 meses com LoopbackJS/ExpressJS
https://youtu.be/BzGTJRMwKxY

Um Inventor Qualquer em outras redes sociais:

Facebook: https://www.facebook.com/uminventorqualquer

Twitter: https://twitter.com/uminventorqquer

Blog: https://www.uminventorqualquer.com.br

Podcasts: https://uminventorqualquer.captivate.fm/

Está sem tempo para assistir ao Vídeo ou ouvir nosso Podcast?
Sem problemas, abaixo você poderá ler a Legenda do vídeo!
Ah... elas são geradas automaticamente 😉

[Legendas geradas automaticamente]
Fala galera sejam bem-vindos ao canal
 do inventor qualquer e se você não
 acompanha na semana passada você perder
 um vídeo onde a gente falou como nós
 desenvolvemos em apenas dois
 desenvolvedores e três meses de projeto
 uma aplicação que bateu mais de 40 mil
 usuários simultâneos dentro da
 plataforma e hoje eu vou pagar uma
 dívida que eu tenho com vocês desde a
 semana passada eu vou contar para vocês
 Qual foi o nosso erro no segundo ano de
 operação e fez a gente demorar muito
 para conseguir vender a mesma quantidade
 que foi vendida no primeiro ano em
 apenas 40 minutos então fica ligado no
 vídeo e ficar atento aos erros que nós
 cometemos para você não cometer aí
 também
 é bom se você perdeu o vídeo da semana
 passada eu vou deixar ele aqui no
 cantinho no card e vou colocar o link na
 descrição desse vídeo também volta lá e
 dá uma assistida para você entender o
 contexto entender as ferramentas que nós
 utilizamos para montar essa plataforma
 que foi fenomenal e foi uma surpresa
 para nós tudo que a gente fez lá dentro
 obviamente com a melhor das intenções e
 com foco em performance mas os
 resultados que nós alcançamos foram
 impressionantes então dá uma olhadinha
 lá no vídeo e não se esqueça de se
 inscrever aqui no canal porque a gente
 está produzindo vários vídeos como esses
 contando não só casos de uso e casos de
 sucesso e mais dando dica pra vocês de
 como otimizar a aplicação de vocês e
 também consegui uma alta performance com
 um custo baixo aí utilizando o Cláudio
 compre hoje eu quero falar para vocês a
 respeito de dois erros básicos que nós
 cometemos no segundo ano de operação do
 primeiro ano de operação nós batemos um
 a absurda de usuário nós alcançamos um
 pico de 26 mil usuários dentro da
 plataforma e os servidores que nós
 estávamos utilizando não passaram de
 quatro por cento de CPU de consumo e o
 nosso banco não passou de 7 por cento de
 consumo de CPU também e o que aconteceu
 logo na sequência nós olhamos para
 plataforma e pensamos Nossa essa
 plataforma tá muito bem tá muito
 performática e agora a gente pode
 implementar novas Fitness em cima dela e
 vai sobrar recurso
 E ai que erro feio o que aconteceu
 naquele ano foi que no decorrer do ano
 tanto a área de negócios quando nós do
 lado técnico Ficamos muito permissivos
 com relação a novos recursos dentro da
 plataforma E esquecemos que era muito
 provável do tráfego será ainda maior no
 segundo ano e os recursos precisariam
 ser bem mais enxutos para que a gente
 pudesse continuar crescendo o que
 aconteceu foi que no decorrer do ano a
 área de negócios demandou muitos mas
 muitas filhos e foram implementadas sem
 a gente se preocupar muito com
 performance porque na nossa cabeça tudo
 estava tão bem que ultrapassou todas as
 expectativas nós planejamos o sistema
 para suportar cinco mil requisições por
 segundo ela suportou 26 mil usuários e o
 consumo de recursos de hardware foi
 muito pequeno
 bom então durante aquele ano nós
 desenvolvemos e implementamos features
 que consumiam muito mais banco de dados
 principalmente banco de dados banco de
 dados é a parte mais sensível e na
 maioria das vezes é o grande gargalo da
 aplicação mesmo considerando todas as
 pequenas nuances da aplicação como não
 poder ter Cash fazer queres muito
 pesadas dentro de tabelas com alto nível
 de concorrência no banco de dados e
 fazer cálculos matemáticos extensivos
 para fazer o cálculo do estoque de
 produtos para poder entregar e não
 deixar uma falha sequer ocorrer em
 .000 vendas que ocorreram em apenas 40
 minutos de operação você não pode
 esquecer que cada Harry a mais que você
 faz no banco de dados baseado numa
 requisição de usuário é exponencialmente
 prejudicial para
 a aplicação na prévia de lançamento do
 º ano nós fizemos benchmark mas os
 benchmark se não mostram exatamente o
 comportamento do usuário como eu falei
 lá no outro vídeo também você precisa
 prestar atenção no perfil do seu usuário
 no perfil dos usuários que consomem a
 sua plataforma no nosso caso nós não
 tínhamos muita opção Porque nós não
 tínhamos como testar a plataforma antes
 já que basicamente todas as vendas do
 ano são feitas no Único dia então a
 nossa chance era de analisar os dados
 que nós tivemos no primeiro ano e tentar
 estimar mais ou menos como é o perfil do
 usuário esse consorte e esse perfil se
 mantivesse o mesmo no segundo ano nós
 poderíamos ter uma previsão de como o
 sistema iria se comportar e quais eram
 os pontos mais críticos da aplicação
 porém nossa
 é não considerar as novas features que
 foram implementadas e também foram muito
 utilizadas não só na parte de compra mas
 as features complementares foram
 consumidas exaustivamente no horário de
 pico mais importante e aplicação
 precisava tá estável o que agravou o
 problema naquele ano foi que nós
 sofremos um ataque massivo de ddos que é
 um ataque que tenta desabilitar os
 serviços da sua aplicação e derrubar ela
 em alguns casos esse tipo de ataque é
 utilizado para tentar descobrir falhas
 na aplicação e vulnerabilidades que
 possibilitem o hacker a invadir a
 aplicação ou roubar informações de
 dentro dela neste caso o que nós podemos
 identificar através dos logs depois é
 claro de toda a situação caótica foi que
 a intenção dos hackers não era de tentar
 invadir o sistema
 a fim de tirar ele do Ar O problema foi
 que todos os cálculos e os benchmarks
 que nós fizemos para garantir que a
 aplicação teria performance suficiente
 para aguentar novamente 20 ou talvez 30
 mil usuários simultâneos foi tudo por
 água abaixo Porque no momento em que a
 aplicação foi ao ar os hackers já
 estavam preparados para disparar o
 ataque e o ataque veio de
 aproximadamente 300 mil equipes
 diferentes em direção a nossa plataforma
 em ondas e pioravam a cada minuto e
 faziam com que a aplicação simplesmente
 não conseguisse ficar no ar o Que Nós
 aprendemos a partir dessa situação e dos
 erros que foram cometidos foram: muito
 importantes um de comportamento e o
 outro técnico o primeiro de
 comportamento que é o mais importante é
 que
 e quando a área de negócios de mandar
 alguma coisa para a área técnica a área
 de negócios não faz ideia de quanto o
 recurso computacional aquela Fisher vai
 consumir no seu sistema você que é o
 desenvolvedor o gestor técnico ou team
 leader você que tá com a mão na massa é
 o responsável por fazer essa análise por
 olhar para dentro do seu sistema por
 olhar para Fischer que você está
 desenvolvendo e falar para a área de
 negócios que talvez a regra de negócio
 tenha que ser adaptada ou melhorada para
 que não impacte tanto na parte de
 performance da sua aplicação como eu
 falei agora pouquinho performance não
 inclui somente o site rápido ou Raul com
 rápido usuário vai acessar o meu site ai
 aquelas regras que você ouve na internet
 eu lembro tutoriais que falam que a cada
 milissegundo que você perde na hora de
 entregar a página
 tá perdendo não sei quantos milhões em
 Venda Não é só isso Pare para pensar no
 seguinte a axa websites ocorrem das mais
 diversas maneiras e as falhas são
 exploradas enquanto a aplicação está
 instável muitas aplicações no momento em
 que ela tá fazendo o boot da aplicação
 ela expõe certas vulnerabilidades ou
 pior ainda no momento em que ela tá se
 levantando dentro do Servidor camadas
 como as camadas de autenticação e
 autorização de acesso ainda não foram
 carregadas e não ataque massivo com 300
 mil e p disparando diversas requisições
 por segundo para dentro da sua aplicação
 em algum momento ele vai conseguir
 capturar certas características da sua
 aplicação para que ela Entenda como a
 sua aplicação funciona por trás e é
 neste momento que
 a entender que que ele deve fazer para
 invadir a sua aplicação ou pior para ele
 conseguir derrubar sua aplicação com
 muito menos máquinas do que ele tá
 utilizando nesse primeiro ataque massivo
 então a preocupação com a performance da
 aplicação vai Muito Além da questão de
 venda ou o tempo de carga da página pelo
 lado do usuário ela entra num quesito
 muito mais crítico da aplicação e pode
 imputar inclusive em risco reputacional
 para a empresa Imaginem só um ataque
 hacker descobre vulnerabilidades na sua
 aplicação naquele momento você acha que
 é só alguém tentando derrubar sua
 aplicação Mas eles descobriram falhas
 graves de segurança dentro do seu código
 e através dessas falhas eles conseguem
 capturar dados ou roubar sessões de
 usuário e invadir aplicação coletando
 dados ou mesmo fazendo compras em nome
 desses usuários e cai na mídia que houve
 um vazamento
 um gigantesco vindo da empresa onde você
 é o responsável pelo desenvolvimento da
 aplicação onde você acha que a sua
 reputação como bom profissional vai
 parar a lenha Claro da reputação dessa
 empresa como uma empresa confiável para
 os clientes Mas voltando ao ponto
 principal desse assunto sempre que a
 área de negócios de mandar algo ela não
 tem obrigação de saber como aquele
 recurso vai afetar a performance EA
 segurança da aplicação e a obrigação sua
 como líder técnico ou mesmo como
 desenvolvedor levantar esses Fatos e
 apresentar para a área de negócios e se
 você souber apresentar se você souber
 argumentar a área de negócios pode
 adaptar as regras de negócios para que a
 implementação fique mais fácil mais
 segura e mais performática agora vamos
 para a solução técnica em primeiro lugar
 no segundo para o terceiro ano
 nós fizemos a implementação de uma
 camada Extra na frente da aplicação que
 até então ela não era tão crítica para
 nós já que a parte do front-end da nossa
 aplicação rodava como um spa uma vez
 carregado na máquina do usuário Tudo
 tava ok cacheada lá no lado do usuário e
 a gente não precisava se preocupar com
 mais nada mas a solução que eu vou
 relembrar vocês agora já foi citada em
 outro vídeo que eu vou deixar aqui no
 card também e aqui embaixo na descrição
 que é o CDN algumas soluções e CDN do
 mercado oferece mais do que simplesmente
 cachear conteúdo estático entregar para
 o seu usuário no nosso caso nós adotamos
 o cloudflare que tem várias camadas de
 segurança e vários dispositivos e
 algoritmos que vão aprendendo com o
 tempo e vão criando bloqueios e
 protegendo a sua aplicação Contra esse
 tipo de ataque que no final das contas
 se você tem um ataque bobo mas que pode
 causar grandes prejuízos o seu projeto e
 para a empresa onde você trabalha além
 do cloudflare que é claro Ele oferece
 muitas soluções de segurança mas todas
 essas soluções prontas que você encontra
 no mercado Elas têm um limite e o limite
 delas é justamente Aonde a sua aplicação
 começa a expor certas vulnerabilidades
 ou certas características que prejudicam
 ela mesmo e aí a sua camada de CDN ou
 falhou que você tá usando na frente da
 sua aplicação ou como muita gente
 conhece também o Afe o Web application
 Firewall não vai conseguir proteger algo
 que você mesmo pediu para ela para
 deixar liberado para que os usuários
 tivessem acesso nesse caso é sua
 obrigação verificar a aplicação e
 garantir que você não tá deixando nada
 exposto e aberto para poder ser
 explorado para que a
 e se complementar a camada do Cláudio
 berkheim Dulce drasticamente o impacto
 na camada de aplicação nós utilizamos
 uma outra ferramenta uma ferramenta open
 source que também já salvou muitos dos
 nossos projetos chama-se Kong isso mesmo
 k o n g igual King Kong o Kong é um api
 Gateway ou seja ela é uma camada que
 fica entre a sua up e quem está
 consumindo ela seja outra p i ou seja um
 aplicativo utilizado pelo usuário final
 o app Itaú e tem a função de mapear as
 rotas controlar a autenticação do
 usuário na hora dele e acesso a certos
 recursos dentro da ATI e ele também tem
 alguns recursos muito interessantes como
 fazer a comutação de várias apis e expor
 ela como uma única veículo seu usuário
 final ficando transparente para ele como
 funciona o seu ecossistema
 Ah e dessa maneira possibilitando você
 quebrar o seu sistema em serviços
 menores Ou micro serviços e mapear todos
 eles num único lugar aonde você consegue
 ter uma noção completa de como o seu
 ecossistema funciona reagir quanto tempo
 ele demora para dar resposta e muito
 mais o Kong é desenvolvido em cima do
 and next que é um dos Servidores http
 mais utilizados no mundo hoje por
 grandes corporações que também é uma
 plataforma open-source mas eu vou fazer
 um vídeo especial só falando sobre Kong
 e sobre todos os recursos que você
 consegue criar utilizando esse aqui
 gueitore que é desenvolvido na linguagem
 Lua em cima do and next e que
 possibilita você desenvolver plugins
 personalizados com o que nós
 desenvolvemos para poder utilizar no
 terceiro ano de operação e que segurou
 todo o tráfego ruim devemos assim que o
 cloudflare
 e conseguiu segurar nós queremos um
 plugin inteligente e detectava
 comportamentos baseados na nossa
 aplicação hoje é que o cloudflare jamais
 conseguiria fazer porque ele não conhece
 a nossa aplicação então nós
 desenvolvemos esse plugin dentro do
 conde que detectava esses comportamentos
 suspeitos e criava a camadas de bloqueio
 inclusive integrado com a própria ferido
 cloudflare evitando até mesmo que esse
 tráfego batesse no próprio Conde e
 reduzindo ainda mais um impacto na
 performance no consumo de recursos
 computacionais pelo nosso próprio e
 Heitor e por consequência na nossa aí
 então ela e as duas dicas uma de
 comportamento não partam do princípio de
 que sua aplicação é boa agora
 implementando novos recursos você vai
 conseguir ter performance infinita nele
 sempre sempre Fique atento a cada linha
 de código que você coloca a mais dentro
 da sua aplicação
 a segunda delas é utilize CDN porque ele
 complementa a camada de segurança da sua
 aplicação e a respeito do Kong fica
 ligado se inscreve aqui no canal clica
 no Sininho porque assim que a gente
 lançar o nosso vídeo falando sobre tudo
 que o Kong pode fazer por você você vai
 ser um dos primeiros a ser notificado e
 vai poder entrar aqui e aprender como
 implementar uma camada ó de ouro aí na
 sua aplicação galera vão aparecer dois
 vídeos aqui que são dois vídeos o nosso
 canal que são super legais também tá
 cheio de conteúdo aqui fica ligado
 grande abraço até o próximo