Sensedia Webinar | Auto Scaling como Serviço

Tudo bem, pessoal? Vamos lá para mais um conteúdo construtivo. Prosseguimos com mais uma das iniciativas da Sensedia, essa aqui em especial para propagar informações sobre ambientes mais escaláveis e resilientes, com viés voltado em trazer temas úteis para a comunidade. O objetivo aqui é engajar novas ideias, iniciativas, promovendo todo um conhecimento em cima dessa base que a Sensedia já carrega. Meu nome é Igor Guimarães, eu sou arquiteto de soluções do time de Solutions da Sensedia. Para quem não sabe, a Sensedia é líder no mercado de APIs, oferecendo soluções de integração e consultoria, adotando uma estratégia mais digital, conectada e aberta, numa variedade de setores, indústrias e, por consequência, gera muito conhecimento.

Beleza. Então, um alinhamento pela amplitude do assunto. Existe uma literatura grande, suficiente para falarmos horas aqui de autoscaling, não é o objetivo. Se falarmos de escalada, já teríamos particularidade de cada ambiente, de forma que abordaremos diferentes técnicas para cada nó que existe dentro desse ciclo de requisição. Então, nesse momento, estaremos chegando ao nível de Netflix, por exemplo, que tem uma estrutura de escalada bem agressiva. Então, são exemplos mais complexos, tratando de streaming em detrimento de APIs com requisições assíncronas, por exemplo. Então, envolve mais complexidade sistêmica. Seria quase que olhar um universo com a lupa. Então, o conteúdo aqui dessa forma. A ideia é focar na atuação de um gateway de APIs como um nó importante do ecossistema completo. Abordaremos alguns itens essenciais nesse aspecto de arquitetura da solução.

Para fechar, a ideia é correlacionar algumas etapas que estão atreladas aos processos de negócio, dando suporte para esse time, garantindo a resiliência dos serviços. Essa nossa agenda aqui, o objetivo dela é cobrir, como podemos ver, essa parte do gateway, fazendo algumas analogias para nos ajudar a fixar o conteúdo como um todo. Então, primeiramente, é contextualizar o momento que a tecnologia se encontra. A gente vai abordar, dar um passo atrás e entender esse ciclo. Então, a cada nova arquitetura, enfrentaremos novos desafios a serem trabalhados até que essa arquitetura amadureça o suficiente para ser utilizada com nível de abstração, que resolva os problemas do mercado naturalmente. Então, a arquitetura vai nascer, ela vai vir com uma proposta e isso vai sendo trabalhado no decorrer do tempo. Isso vai sendo ajustado, vão vindo parâmetros e permitir que isso seja utilizado num nível de abstração. Essa aqui é a ideia. Porém, isso vai criar novos problemas, problemas ainda mais complexos, seguindo um fluxo de evolução mesmo. Então, com isso, nós não vamos ter uma arquitetura bala de prata para resolver um problema de escalabilidade como um todo. A ideia é que, dentro de um contexto tecnológico, abordar o que pode ser feito diante desse cenário.

Então, busquei algumas inspirações no Everest, como referência de escalada do ser humano e como funciona essa preparação. Como dizem os esportistas, o preparo para o ataque ao cume. E para termos um mapa do ambiente atual, faremos um discover dessa arquitetura abordando esses itens essenciais.

Beleza, então, iniciando aqui, abordando qual seria esse período de transição. Então, como eu informei anteriormente, a arquitetura vai evoluindo no decorrer desse processo de liberações de versões. Tudo que acontece em um determinado contexto, ele segue um fluxo de desenvolvimento e essa transição acaba ocorrendo, porém, algumas coisas não são desmembráveis. Então, por exemplo, essas três camadas de negócio podem ser subdivididas como um todo. Essas barreiras conseguem ser ajustadas, porém, são três camadas distintas. A camada de apresentação, que é onde o usuário vai ter a relação interface homem-máquina. Isso é um contexto como um todo. A escalabilidade dessa camada tem algumas particularidades. Depois, uma camada que vai absorver as lógicas de negócio, que seriam de fato voltadas a cada um dos cenários a serem resolvidos dentro de um contexto de negócio mesmo, digamos. Então, aplicações, integrações, tudo vai residir nessa camada. E a camada de armazenamento de dados, de informação. Nesse caso, seria um terceiro grupo. Cada um desses grupos tem a sua escalada definida de maneira voltada para esse contexto.

Então, escalar o front é diferente de escalar um back-end, que tem outras orientações, por exemplo, para escalar a base de dados. A replicação, redundância de estudo, tem suas particularidades. O objetivo aqui não é entrar dentro de cada um desses mundos, é dar uma dimensão completa.

E aí, para termos essa dimensão, nós vamos falar aqui de uma transição que ocorreu entre o monolito e os microserviços. Então, se a gente der um passo até anteriormente aos sistemas monolitos, quando tudo isso estava, por exemplo, em uma base de mainframe. Seria uma outra parte dessa linha do tempo, mas focando aqui nessas duas, por quê? Quando eu comecei com o desenvolvimento, estavam surgindo os servidores. Foi uma época de transição já dessa segunda camada de cliente-servidor, vindo para uma pegada mais web, por exemplo. Então, os sistemas começaram a ser estruturados em cima de application servers. Esses sim estavam sobre uma segunda plataforma do sistema operacional. Então, eram muitas camadas até a gente chegar no nível da aplicação.

Qual foi a ideia do pessoal? Começar a quebrar isso. Começou a ficar muito complexo. Como eu falei, começou a absorver inteligência demais, muitas funcionalidades, requisitos não funcionais, transação de banco, a parte de log. Tudo isso começou a ser incorporado nesses application servers e o tempo de startup disso era muito longo. Então, subir um servidor de aplicação, por exemplo, contendo lá dentro várias aplicações depuradas, isso demandava um tempo muito grande e não era nada fácil de escalar.

Então, o dimensionamento desses sistemas era muito complexo de ser feito. A gente tinha ali que exaurir mesmo a capacidade de pensar quantos usuários concorrentes a gente vai ter em cima dessas requisições, qual vai ser esse fluxo, o que o banco aguenta, o que a camada de divisão de presentation vai processar. O processamento, então, ele não era feito no browser, era um processamento feito todo no backend, esse bind das informações entre a informação lógica e o HTML, para isso ser enviado.

Então, os microserviços vieram resolver uma boa parte desses problemas. A parte de startup, ter sistemas mais coesos, a parte de implementação mais voltada para o negócio. E isso, dependendo da utilização, você consegue escalar o microserviço e o outro, por exemplo, que não tem tanta necessidade, você pode mantê-lo ali no nível de processamento mais baixo.

O que nós temos, então? Um sistema monolito, a diferença no caso do microserviço para a escalada, ela seria grande porque o monolito você não vai ter margem para fazer isso dinamicamente, dependendo do contexto. Por exemplo, colocar um novo application server por trás de um load balance, tudo isso dentro de uma infraestrutura que não tinha esse suporte a auto-scaling. Facilmente, isso era complexo.

Então, os microserviços trouxeram essa facilidade, onde o monolito tinha dificuldades em setar esses parâmetros para manter esse modo dinâmico, a gente veio com o microserviço, porém ele trouxe outras complexidades em relação a funcional. Então, seria necessário voltar para uma base e entender, diante de um cenário onde a minha infraestrutura pode ser alocada diante de um player de cloud, uma AWS, uma GCP, por exemplo, eu já tenho ali mais facilidadeem promover esse tipo de arquitetura.

Então, uma outra transição foi quando a gente deixou de criar esses microserviços. Deixou de criar esses micro serviços, que seriam micro servidores ali, e passamos a criar de fato aplicações serverless, onde não teria, portanto, o papel do servidor. O setup ficaria baseado em funções, por exemplo. Então, cada ação demanda todo um ciclo dentro dessa própria requisição. Então, o que antes a gente tinha um startup do servidor, abrir uma conexão com o banco, manter essa conexão aberta dentro de um pool, aguardando esses requestes, tudo isso é feito naquela transação. É muito atômico. Isso aí, mais uma vez, mexeu um pouco com a parte financeira, porque entre a gente prover um ambiente monolito e um ambiente de micro serviço, eu já posso escalar. Porém, eu vou ter o mínimo necessário para manter esse ecossistema funcional. Já na parte aqui do serverless, a gente não precisa de manter esse mínimo. Isso vai ser sob demanda. Você pode provisionar ali alguma frente de espera para isso. Vão vir outras técnicas para trazer resiliência e até mesmo eficiência desses serviços. Mas existem esses contextos.

Então, quando a gente vai falar de escalabilidade, por exemplo, trabalhando em um ambiente serverless, a gente tem algumas facilidades maiores que a gente vai abordar no decorrer do material. Então, aqui a gente vai abordar um cenário, quando a intenção é boa e o resultado é inesperado. Esse aí é um desenho da Marcia Urso. Foi o episódio mais visto dessa temporada, que é a receita para o desastre. E nesse caso ela teve uma escalada. Então, quem tiver curiosidade pode acompanhar. Vai ter essa dimensão do tanto que essa receita escalou. Trouxe aqui para a gente alguns cenários, fazendo uma analogia. O primeiro, que é embasar em alguns pontos. Então, existem vários tipos de escalada. Então, eu vou dar aqui alguns exemplos:

Escalada relâmpago:

Contextualizando. Super Bowl, campeonato americano de futebol. Então, tem essa liga, a NFL. O que acontece? Bastante telespectador e foi feita uma promoção. Esse QR Code foi exibido e nesse momento a empresa estava com essa iniciativa de Bitcoin grátis. Então, é muito acessível. Você está ali de frente, você está com o celular na mão. Você já buscou o QR Code. Nesse caso, um time de usuários por trás, acompanhando tudo isso, foi lá e marcou um touchdown. Então, os servidores não aguentaram o número de requisições. Então, durante esse evento, no caso, derrubou o site. A quantidade de acesso não estava condizente. Não estamos aqui, no caso, para entender essas razões. Cada cenário desse, essas razões, se bobear, não foram uma. Foi uma união de fatores que levou a essa queda. Então, entender tudo isso depois para limpar essa bagunça que fica o complexo. Abordaremos também o que a gente precisa para entender esses cenários no decorrer do tempo. Quais ferramentas, logs e tudo mais.

Demanda esperada:

Um pouco parecido, porém aqui, qual é a diferença dos dois? Aqui a demanda era esperada e a quantidade de salas e cadeiras, isso é muito limitado. Então, o que acontece? O usuário vai ter ali uma ansiedade em cima disso, a quantidade de refresh para conseguir uma daquelas vagas ali. Ela se baseia em tentativos. Então, é um cenário que trouxe aí os Vingadores. Nessa oportunidade foi a pré-vinda dos ingressos e o pessoal tentando comprar, tentando comprar e tudo se rompeu. Então, precisamos entender, no caso, a Fandango correu atrás, buscou informação, o que aconteceu? Ela conseguiu ver essa característica que a gente pontuou aqui. E para o lançamento do Ultimato, ela já trouxe uma funcionalidade que seria essa sala de espera. Então, o usuário não ficava mais com essa tentativa em cima de tentativa e tudo isso aí aumentando o throughput

Bem específico, né? E para fechar aqui o terceiro, né? Então, trazendo um pouco da última Black Friday, o que que foi, né? O diferencial e dos requestes.

Terceiro cenário:

Para fechar aqui o terceiro.

foi justamente essa parte das entregas expressas. Então, nessa oportunidade, o custo, né? O diferencial estaria sendo a entrega que chegasse mais rápida, né? Então, a expectativa ali era grande de comprar, ter todo esse tracking ocorrendo, onde está minha entrega, num centro de distribuição mais próximo, que dia que isso vai chegar na minha casa.

Também gera ali todo um processamento que vai além da loja virtual, né? Então, a gente pensa ali da loja virtual como interface, mas por trás vai ter toda uma engine de pagamentos, por exemplo, a parte da cadeia logística, tudo isso ali processando essas informações derivadas da compra, organizar esse material, despachar, tudo isso aí são etapas, um fluxo de processo que tem que ocorrer de maneira rápida, né? E o que que acontece? Muitas vezes esses cenários, eles são previstos, né? Essa volumetria aí, porém, tem toda uma necessidade de mercado que pode trazer um fluxo além do esperado.

Então, uma das reclamações dessa última Black Friday foi justamente essa parte de entrega, né? Essa visibilidade de informação, né? O time da entrega, de fato, era para ser uma entrega expressa voltada ali em trazer mais agilidade, porém, o cenário foi um pouco mais complexo do que isso, né? Até pela proximidade ali do Natal, né? Tudo isso aí trouxe, além do Black Friday, outras frentes de compra que foram prosseguindo ali no mês subsequente. Então, olha para você ver, já emendou uma sequência grande de janelas de compras.

Então, tudo isso aí trouxe uma necessidade de revisitar todos esses sistemas, identificar ali quais são esses nós, né? Que estão trazendo uma baixa produtividade ali, né? Para esse fluxo como um todo e atuações, né? Então, aí a gente entra aí, quais são essas atuações que a gente precisa, né? Pelo menos identificar e promover dentro desse contexto para evitar uma queda, né? O que que acontece muitas vezes é entender os limites dentro desse ecossistema. Isso aí gera um investimento grande de tempo ali, né? De toda a equipe, entendendo o racional, desenhando, elevando, fazendo testes. Então, depois desses tombos aí, né? Entender, de fato, o que levou a essa queda.

E aí vêm essas preocupações, como que a gente vai manter essa arquitetura resiliente. Foi feita toda uma escolha de arquitetura baseada em serviços resilientes, porém, a arquitetura ainda rompeu, né? Onde foi a falha, né? O que levou aí a degradação de alguma funcionalidade é algo, de fato, da arquitetura, é algo sistêmico ali da parte de desenvolvimento que cabe algumas otimizações, né? Do ponto de vista técnico, né? Até mesmo de algum algoritmo. Então, assim, são N pontos aí de observações, né? De estudos que a gente tem que manter.

E com isso, a gente precisa entender, por exemplo, essas rajadas de processamento. Olha pra você ver nos três exemplos, né? No primeiro, né? Era esperado, mas não com a volumetria talvez que chegou, mas foi um grande pico durante um curto espaço de tempo, né? Então, assim, nos próximos três minutos, quem conseguir focalizar e disparar uma requisição vai ter acesso aí a um volume de Bitcoin grátis, por exemplo. Isso vai ocorrer num espaço curto de tempo, vai ser durante o intervalo, depois vai fechar essa janela. Então, é um pico grande.

No segundo ali dos Vingadores, por exemplo, esse tempo já é determinado pelo consumo, então existe um pool de cadeiras, né? E conforme isso aí vai sendo vendido, vai zerar esse, entre aspas, estoque, mas vai ser pontual. E no terceiro cenário, né? De lojas online, por exemplo, já é um volume que ele vai crescendo, crescendo, até chegar num volume alto e vai se manter aí durante um tempo. Esses produtos vão acabando, né? Essas promoções vão se finalizando, então o processamento ali ele vai reduzindo, né? Então, são duas partes, né? Crescer essa infraestrutura e depois como reduzir, né? Todas essas máquinas aí que foram provisionadas que trazem custo.

Então, trazendo aí para a nossa realidade, né? O que nós temos aqui, né? Como ser humano? O que seria um exemplo de escalada para o ser humano dentro do contexto que nós vivemos, né? Agora, vamos pensar assim, uma escalada agressiva, seria o Monte Everest, né? Não tem como, né? Pode até existir outros aí com nível de dificuldade maior, mas isso aí é algo cobiçado, né? Para esse pessoal que tem esse tipo de atividade esportista.

Qualquer analogia que a gente vai fazer, né? Eu, por exemplo, eu não vou escalar o Everest sem um preparo, sem um condicionamento, sem ter o conhecimento, por exemplo, do caminho que eu vou percorrer, quais são... Na verdade, quais serão essas etapas no decorrer aí dessa jornada, né? Então, o que a gente pode entender aqui? Seriam de seis a dez semanas, né? Para prosseguir aí com esse caminho. Mas seis ou dez semanas num caminho tão curto como esse? Seria um monte, né? Então, tirando aí a dificuldade, colocando isso numa linha reta, né? Linear aí, seria feito bem mais rápido, né? Porém, tem todo um contexto ali, né? O primeiro, a altitude, né? Então, a tarefa é de reunir esses suprimentos, caminhar até os acampamentos base, né? Ajustar-se a essa altitude. A altitude ali, a gente precisa de realizar uma aclimatação do nosso corpo, né? Porque você vai subindo e o corpo vai perdendo oxigenação, ele vai ter que acostumar.

Então, tudo isso, olha pra você ver, trazendo um pouco aqui pro contexto tecnológico, seria uma escalada bem no nível computacional. O sistema, ele vai crescer, né? A base ali de computadores, por exemplo, pra processar essa informação, vai demandar memória, vai demandar CPU, isso vai chegando ali num limite novamente. Mais uma etapa de crescimento, né? Então, são fases aí dentro dessa jornada que vai levar aí ao cume, né? Vai chegar lá aos 8.848 metros. Pensa pra você ver. Então, eu acredito ali que aquela faixa de 8.000 metros, a maioria dos alpinistas precisam de tanques de oxigênio, isso aí a gente denomina como a zona da morte, né? Então, esse acampamento ele fica mais ou menos a 8.000 metros de altura, né? E o perigo é depois da subida ali a gente vai ter que descer. Então, a maioria dos acidentes, né? Elas acontecem na descida, onde o montanhista ali, no caso, ele já tá cansado, né?

Então, mais uma vez trazendo a analogia aqui pra gente. Além de escalar todo esse sistema, depois você tem que reduzir conforme, né? Essa pressão aí vai, essa pressão de requisição, ela vai diminuindo, a gente tem que reduzir esse complexo computacional, porque tudo isso é custo, né? Manter isso aí ativo gera despesa. Então, tem esse trade-off aí pra gente acompanhar. Então, fica aí essa dica, né? Essa escalada aí do Everest, por exemplo, eu trouxe aqui mais pra contextualizar essas dificuldades e baseando no estudo, né? A gente precisa de uma estratégia, né? Um preparo aí pra gente ter o sucesso dessa operação.

Então, o ponto principal aqui é entender nosso contexto, né? Ver ali baseado no que a gente já teve de experiências. Navegar em todo esse ecossistema, né? E entender essa dinâmica, né? Como que eu vou crescer, né? Vai ser um pico, vai ser um crescimento no estilo, um gráfico de baleias, por exemplo, que vai começar ali com a margem pequena, vai chegar no ápice, vai manter isso durante um tempo e depois ter um fluxo de requisição reduzido, né? Tem que entender esses eventos sazonais, né? Se é Black Friday, se é uma promoção.

Aqui entra alguns cenários que nós temos, né? Como cases, por exemplo, onde a escalada, ela precisou ocorrer, né? Baseado, de fato, em alguns eventos. Então, o gateway, ele traz consigo alguma capacidade de segurar isso aí, por exemplo, né? Uma das funcionalidades dele como um todo seria justamente essa, né? Então, na borda ali, seria dar essa segurança para a nossa camada de back-end. Então, seria um pouco desse desenho, né? Fazendo a referência aqui no gateway como a borda aí dessas requisições, né? A gente pode ter tanto serviços externos quanto esses clientes fazendo essas requisições, disparando ali eventos para o gateway. O gateway, ele vai ter que receber isso. Então, o primeiro ponto de escalada que a gente vê seria justamente o gateway. Dali para trás, né? A gente pode manter uma sinergia conforme essas demandas vão crescendo. A gentecomeçar aí com essas notificações para quê? Para dar informação para o back-end se preparando, né? Para a gente ter ali então uma escala. Para dar informação para o back-end se preparando, né, para a gente ter ali, então, uma escalada preditiva. A maioria dos players hoje, eles já englobam esse tipo de funcionalidade, né, essa escalada preditiva baseada no crescimento computacional. Então, se a memória está crescendo, se o processamento, se essa CPU ali está tendo mais demanda, tudo isso vai sendo monitorado através de eventos no decorrer do tempo para não pegar esse sistema aí de maneira que ele não consiga reagir. Então, o sistema tem um tempo de reação, né.

O que a gente vê é que não dá para escalar automaticamente, a não ser que você traga para uma arquitetura bem serverless, por exemplo, e você já não vai ter aquele ramp-up do servidor como um todo. Mas fazer toda essa arquitetura também em cima, na verdade, fazer todo esse sistema em cima dessa arquitetura é complexo, né. São vários nós ali, tem muita coisa referente a um legado, talvez. Então, tem partes que têm que ser avaliadas e ver, de fato, qual que é, dentre esses pontos aí, o meu nó mais fraco. E aí, através desse nó, conseguir trazer para dentro do gate essa blindagem dessas requisições aí para garantir um fluxo contínuo, manter uma cadência dentro desse fluxo de processamento.

Então, aqui a gente vê um exemplo da demanda crescendo, a escalada ocorrendo diante de um pico. Ali a gente pode ver que durante o meio do dia é onde o sistema está mais ativo, a quantidade de usuários está fazendo mais utilização como um todo. Porém, esse cenário pode se repetir em outros. Por exemplo, num cenário de uma promoção já seria diferente. Então, projetar um sistema que escala é bem diferente de utilizar uma arquitetura escalável. Então, você conseguir que essa arquitetura escale diante dessa necessidade, mais próximo dessa necessidade, pelo menos, é o que traz um custo operacional justo, enxuto.

Então, por exemplo, pensa numa empresa que tem alto volume, uma Netflix. Então, isso aí é um ponto bem peculiar ali dentro do algoritmo deles. Eles querem escalar sob demanda, eles querem estar mais próximos dessa curva da realidade. Antecipando, é claro, para não ter uma queda provocada talvez pela ausência de força, mas tendo toda essa preocupação com o fator custo.

Aqui alguns exemplos de escaladas:

Um workload preditivo.

Um plano de escalada.

Requisições por segundo com picos, onde vão ter talvez várias promoções, vários eventos que vão trazer essa necessidade do sistema de processar informação como um todo.

Então, entender essas características e ver onde o seu contexto se encaixa é algo primordial para a gente ter esse dimensionamento. Então, a ideia é trazer esses pontos de atenção, ter essas reações preditivas além de um cenário programado. Seria dar base para o ecossistema como um todo trabalhar em uma produtividade máxima, porém sem derrubar algum desses nós. Aí sim seria o desastre, no caso.

Aí já tem que ter um plano de desastre recovery, para garantir que após essa queda, por exemplo, esse sistema se restabeleça. Pensa isso diante de um cenário de alto fluxo de requisição. O gateway teria que agir também ali rapidamente, evitar passar essas requisições para o backend, por exemplo, porque ele vai saber que lá vai estar tomando, por exemplo, um erro 500, algum erro HTTP condizente. Então, essa inteligência no gateway daria talvez um fôlego para esse recovery ocorrer.

Diante de um cenário onde tudo isso estivesse exposto, o sistema ia estar ali em startup, o usuário tentando requisitar funcionalidade, talvez toda a parte operacional ainda, essa cadeia não esteja pronta, então pode ocorrer mais uma queda.Então, é um ciclo que pode ocorrer. É algo cíclico diante dos usuários derrubarem o sistema tentar subir, cair novamente, então cenários aí para serem evitados. Então, o que a gente já vem falando aqui, né? Traçar esse perfil de consumo, né? Entender esse trupo cotidiano, chamadas por dia, por hora, como que o meu crescimento ele se dá, né? E como que eu estou prevendo essa ocorrência aí num dia, por exemplo, de alguma promoção, né? Tentar trazer um pouco dos números cotidianos para fazer essa preditiva, né? Entender esse tipo de sazonalidade, né? Vai ser um pico de conexão e depois isso vai parar, né? Vai ser um crescimento constante até eu chegar no meu limite, né? Qual é o meu limite, né? Determinar esse consumo para eu ter ali um gol e conseguir travar essas aquisições, por exemplo, e até mesmo evitar que ocorra uma queda.

E aí, depois disso tudo, né? Tem que entrar em um exercício de validação, né? Não vai dar para validar isso no dia, né? Assim, esperar que tudo isso funcione e comporte como o esperado. Então, ter um ambiente de homologação de testes aí é super importante. Muitas vezes até mesmo fazer algum cenário ali já formatado, né? Com exceções, por exemplo, tentando cobrir todo o ecossistema a nível de funcionalidades para evitar uma surpresa aí em tempo de produção.

Então, pessoal, a primeira técnica aqui, né? O primeiro ponto de atenção é justamente esse warm-up, né? Esse pré-aquecimento dos ambientes. Então, por exemplo, dependendo da situação, o tempo de warm-up de um servidor pode ser de 2 a 5 minutos, né? Depende do que esse nó tende a processar, né? A representar diante de um cenário de computação mesmo como um todo, né? Ah, é uma parte que vai envolver dados? É uma parte que é só front, por exemplo? Cada uma aí vai ter uma necessidade de um warm-up, né? De um preparo, de um pré-aquecimento para garantir, né? Que vai ter um volume mínimo de funcionamento, porém, quando eu tiver a necessidade de uma escala, eu vou condicionar um ambiente disponível ali com a base maior, né? Eu já vou preparar esses recursos aí.

Por quê? Porque eu quero que isso cresça linearmente, né? Eu não preciso esperar uma máquina, por exemplo, topar o processamento dela para eu ter a iniciativa ali de criar uma nova. Não. A ideia já é, olha que vê que o processamento já está ficando, assim, perto do esperado ali 60%, por exemplo, já criar mais uma estrutura, dividir essas duas, crescer as duas em conjunto e isso ocorrer de maneira mais linear.

Então, entra aqui uma parte de otimizações, uma parte bem importante, por sinal, né? Ali, o primeiro tópico, trabalhando com limites, por exemplo, entender esse throughput, né? Determinar esse rate limits, né? Através ali de rotinas, por exemplo, um spike array, onde eu vou garantir que a conectividade com esse servidor, né? Seja garantida através de parâmetros, ok? Então, entender esses números, analisar, manter essa calibragem quase que em tempo real ali, chega a ser um ponto de observação diante de um cenário de promoção, por exemplo, de uma API de missão crítica, né? A API, ela não pode cair, né? Ela vai ter que ter uma monitoria em cima dela e garantir que esse limite esteja sendo utilizado ali, caso alguma coisa aconteça, a gente tem que ter cenários alternativos, né? Para garantir que isso não se rompa.

E uma abordagem seria a utilização de cache para fazer acessos rápidos, né? A informação. Então, o cache, ele vem, de fato, como uma ferramenta importante, né? Você vai evitar que a requisição, ela percorra por todo o fluxo de requisição, né? Talvez em uma base de dados que é mais complexo de retirar a informação ali, né? Fazer uma leitura, uma escrita. O cache, ele está no nível 1 ali da requisição, por exemplo, e isso traz, né? Além de agilidade, ele traz um respiro para todo o back-end. A partir do momento que essas consultas, né? Baseadas aí em requisições, elas têm uma volumetria até maior, né? Isso pode ser cruzado de uma maneira que a informação vai ser trabalhada ali de uma forma mesmo de matriz. Pensa, por exemplo, um produto com cores, tamanhos, tudo isso traz aí um nível de complexidade maior para a pesquisa como um todo. Então entra o gráfico ali para nos ajudar, né? Como um mecanismo que disponibiliza essa possibilidade de solicitar via GET atributos, né? Baseado em filtros.

Então seria um terceiro ponto, né? Através desses dois de cima aí, a gente pode ter o terceiro ali que é a utilização de hipermídia, né? Então o resultado, em vez dele trazer todo um complexo de informações, ele vai trazer um hyperlink para facilitar ainda mais a obtenção de novas informações. Então tudo isso vai otimizar a utilização do sistema como um todo. Através de hipermídia eu posso ter conexões via GET, por exemplo, né? Então tudo isso aí eu já vou trazer mais a utilização de cache, né? Olha para você ver.

E para fechar esse raciocínio, serviços idempotentes, né? Isso aí também traz, é uma técnica que evita o processamento em duplicidade, né? Então ele traz uma garantia de funcionamento, isso aí por si só já traz benefícios, mas além disso dá para conciliar, por exemplo, um serviço com cache, né? Então você vai evitar fazer todo um reprocessamento de regras de negócio baseado num formulado disparado, por exemplo, né? Você já vai estar levando isso aí para uma... na verdade vai estar deixando esse processamento de forma mais simples na primeira camada, evitando o fluxo, né?

A Sensedia aborda esses tópicos, ela faz o uso dessas práticas aí, inclusive nas nossas consultorias aos nossos clientes. Então, por exemplo, o Banco Topazio, né? Que impulsionou os negócios aí e multiplicou em 4 mil vezes a emissão de empréstimos. Então pensa essa arquitetura, o tanto que ela teve que ser trabalhada, né? Para um crescimento dessa... com a volumetria como essa. Então as coisas começam a fazer sentido, né? A partir do momento que a pressão ali começa a aumentar, né? Talvez o comportamento esperado para uma requisição, quando a gente faz o uso de aplicativos aí que vão ter API de missão crítica, por exemplo, tem que ser o mesmo raciocínio aplicado a 100 TPS, né? Tem que ter garantia ali de funcionamento como um todo.

Outros exemplos são essas maquininhas, né? Da Cielo, da Ticket, que a Sensydia também atuou com consultoria em cima, né? Desse desenvolvimento como um todo, garantindo aí a estabilidade dos serviços, né? Trazendo aí resiliência, porque, mais uma vez, a API de missão crítica não dá para ter falhas em cima de um pagamento, por exemplo. Tem que ter toda uma restrição de negócio aí para garantir essa entrega.

E um vilão aqui, né? Quando a gente fala aí de escalabilidade, né? Eu já tive bastante cenários aí que eu já trabalhei e foram evidenciados que o timeout, de fato, ele jogava o processamento do gateway no chão, né? Então, o que é que acontece? Qual que é o cenário, né? Ilustrando. A partir do momento que o seu backend começa a demorar a responder, né? Essas threads, elas vão começar a ficar presas no gateway, né? Então, o gateway, ele continua recebendo essas requisições, porém o trabalho dele está ali aguardando uma thread do backend responder. Então, o gateway, ele vai cada vez recebendo mais requisições. Isso aí vai travando, né? O pool de threads ali que ele tem para processar a informação.

Então, talvez a CPU, ela não vai estar crescendo, né? Nem a memória, porque as threads vão estar consumindo baixo processamento, mas tudo isso aguardando o backend responder. E cada vez mais o gateway disparando ali para o backend mais requisições. Então, o ciclo, ele vai continuando aí, né? Trazendo um risco. Então, qual que seria o problema nesse caso? Seria identificar que essas requisições estão ficando presas no gateway, né? Ter esse dimensionamento, né? É algo complexo, né? Ter isso, então, em tempo de produção é mais custoso ainda, operacionalmente falando, porque você tem que manter ali um log. Esse log, ele vai ter que ser processado, ele vai ter que virar informação e chegar até o indicador. Então, tudo isso traz um impacto aí, né? Para a análise caso não seja feito.

E tem algumas opções, né? Identificando ali dentro de um fluxo de requisição síncrono, o que que dá para a gente tirar de dentro desse fluxo? Esse aqui é o exercício, né? Então, como que eu pego um fluxo e tiro ali, né? Informações que eu posso trazer para um fluxo assíncrono, deixando essa requisição mais leve, por exemplo, e não deixando de processar o que deve ser feito, por exemplo. Só não vou fazer isso naquele exato momento da requisição. Então eu vou usar a requisição para disparar vários eventos assíncronos que vão ser processados ali, cada um no seu tempo, e no final vou juntar isso tudo dentro de um fluxo de trabalho.

Qual seria essa abordagem? Por exemplo, a Sensedia tem o Event Sub, que é um produto que funciona juntamente com o Gator, permitindo esse tipo de implementação. Então tem toda uma dinâmica por trás disso, como garantir que esse fluxo se mantenha rápido o suficiente, que essa requisição bata no back-end e seja processada e devolvida, e tudo que for dependente disso seja processado no segundo passo.

Esse aqui é uma diretiva também que nos traz visibilidade do que está ocorrendo, então o que é manter um sistema vivo se a gente não tiver alertas para garantir que esse ecossistema fique funcionando e caso ocorra alguma anormalidade a gente seja alertado. Então são vários níveis de alertas que a gente pode basear no consumo de informação, monitoramento de alguma operação específica, por exemplo, esses disparos devem ocorrer bem próximos do real time, e fazer isso também dentro de um fluxo síncrono, ter ferramentas para fazer isso é complexo.

Então essa parte de alertas proativos tende a auxiliar bem o contexto de produção a partir do momento que o sistema vai identificando algumas anomalias, isso tem que ser propagado, isso tem que ser transferido para as pessoas tomarem decisões. Então esses níveis de alertas têm que ser usados moderadamente, porque se todo alerta for crítico, isso deixa de ser evidenciado quando ocorrer alguma coisa crítica mesmo.

Dentro desse fluxo de requisição, as ferramentas hoje, a partir do momento que já estão funcionando, é difícil o time de desenvolvimento ativar uma monitoria em tempo de produção. Então através do Gator, dentro de um fluxo que a gente consegue colocar um ponto de interceptação, extrair informações ou alertas, isso traz para a gente uma facilidade muito grande em manter isso vivo dentro de um fluxo organizacional.

Então é uma estratégia que deve ser utilizada de fato, principalmente em APIs de missão crítica, tudo isso tem que ser monitorado o tempo inteiro, garantindo a saúde do ecossistema como um todo. Então a partir de consumo de dados ou monitoramento de uma série de operações, eu posso ter esses alertas disparados, baseado em fluxos de requisição ou até mesmo alguma informação que está passando ali dentro.

Por exemplo, tem um contexto específico, opa, eu preciso de um alerta sempre que esse produto aqui for vendido, porque eu tenho o risco de dar um boom de vendas em cima de um cenário. Dá para a gente entrelaçar bastante objetivos do negócio com essa necessidade de disparos.

Voltando um pouco para a parte de autoscale, os alertas vão permitir que a gente regule, faça uma calibragem em tempo de execução em algo que está comportando ali fora da normalidade, por exemplo, ajustando o rate limit, trazendo ali algum spike ao resto para um cenário específico, todo esse controle de throughput no Gator, atrelado a alertas, traz bastante resiliência de modo que a operação tenha ali em mãos uma ferramenta para atuar.

Diante do nosso cenário, do Gator, por exemplo, seria o Sensedia of Flexible Actions, seria a parte que a gente consegue configurar esses alertas, ter esse dimensionamento do que está ocorrendo, então disparar para cada um dessas personas envolvidas nessas frentes.

Então, além dos alertas, pessoal, a gente tem que entender que essas informações têm que gerar indicadores, indicadores de desempenho do ambiente, como que está essa operação, quais eventos e momentos específicos a gente está tendo aqui dentro desseecossistema. Ter isso bem próximo ali do real time é caro, é custoso, é pegar uma informação, disparar através de log, processar esse log, né? Compilar isso em index, então trazer isso para um dashboard. Tudo isso traz para a gente dinamismo de atuação, porém tem toda uma complexidade de se manter. Então ter esse acompanhamento, né? Ter esse cockpit ali para ter a dimensão do que está ocorrendo até mesmo no momento de crise. Conseguir tomar decisões baseadas, né? Entendemos que o contexto aqui não está legal porque o sistema X, por exemplo, está aquém do que ele poderia, né? O que está ocorrendo ali naquele momento? É uma falha momentânea, né? É uma indisponibilidade ali que dá para tratar cirurgicamente ou foi um conglomerado de ações que levou a esse pico, né? Então tudo isso aí através de dashboards, conhecendo os objetivos ali a gente consegue definir gráficos específicos para cada situação que traria mais assertividade nessas tomadas de decisão.

Então o que a gente vê aí, né? A gente traz bastante o autoscaling como um serviço, né, pessoal? A gente tem uma arquitetura escalável, né? Mas manter isso aí escalando conforme o esperado vem como um serviço, né? Ter esse monitoramento, esse acompanhamento além de um plano de uma arquitetura resiliente. Seria extrair o máximo de uma arquitetura baseada em eventos que estão ocorrendo com o meu ambiente nesse momento, né? Como que eu vou me comportar aqui diante desse cenário? Qual seria esse background, né? E vamos colocar um cenário hipotético aqui no nosso contexto, né? Num cenário de vendas aí na Black Friday.

Então, né? Até mesmo aprendendo aí com tudo isso que a gente falou agora, né? Quais seriam essas etapas:

Ter esse histórico, né? Entender o meu ecossistema, entender meus ambientes, quais são os meus números, o que é que eu vou monitorar, né? Ter toda essa visibilidade e dar visibilidade para todo mundo que participa aí do ongoing dessa operação, né? Ferramentas para atuarem, né? Conforme as oportunidades vão surgindo.

Aprender com esse histórico aí e promover algumas ativações, né? O que a gente vai precisar de alerta, deve ser configurado, gráficos alterados, né? Essa escalada preditiva como um todo ser revista, né? Para conseguir suportar essa questão.

E por fim, entra a parte de operação. Aí sim, né? É monitorar, entender ali o que está ocorrendo, se isso está de acordo com o esperado e se alguma coisa está desviando, o que pode ser feito, né? Naquele momento para evitar uma queda, né? Vamos, nesse cenário, o limite é o controle específico ali. A gente tendo essa dimensão de até onde o sistema consegue ir, a gente vai ter aí um sucesso na operação.

Lembrando que é difícil ter uma arquitetura completamente escalável, né? A maioria das vezes vai ter ali algum nó que ele vai ter que ser super dimensionado para garantir esse contexto como um todo e talvez a monitoria nesse ponto aí ela tem que ser até mais específica, né? Quais serviços dependem, né? Desse outro serviço terceiro, por exemplo, que pode trazer uma inoperabilidade. Todo mundo foi alertado dessa necessidade escalada, né? Muitas vezes pode ocorrer aí alguma falha de comunicação, né? Um fornecedor terceiro, até mesmo um fornecedor ter ali também naquele momento inúmeras demandas de escalada e isso comprometer a arquitetura como um todo.

Então, o que a Simcidia tem de expertise de mercado? Eu vou trazer aqui para a gente dois cases de atuação. O primeiro ali é um case da Natura, né? Para quem acompanha a novela aí vai lembrar que teve uma personagem na novela das nove que ela era consultora Natura, né? Isso aí, pessoal, foi uma estratégia de marketing baseada em monitoramento que foi feito ali em tempo de operação e viu que em uma determinada faixa de horário a utilização do aplicativo ela subia, né? Ela demandava ali uma escalada maior, né? Ela se tornava uma API crítica naquele momento, né? Por exemplo, era API de pedidos e o pessoal viu que nesse momento as consultoras passavam os pedidos, né? Então, esse personagem foi introduzido na novela justamente para trazer aí uma explicação,né? Ela fazia ali naquele horário, ela passava os pedidos dela utilizando o mobile. Então, deu para fazer toda essa monitoria através dessas células da Syncidia que é o API Care. Outro exemplo, por exemplo, a Cielo, que tem uma grande volumetria de requisições, então é um ambiente que ele já arranca pesado, por exemplo, para suportar todo esse request.

Então é um warm-up que tem um volume alto de gateways, justamente para garantir essa alta disponibilidade, resiliência, tudo isso demanda uma monitoria constante, uma observação pontual e atuações cirúrgicas em determinado momento, o que está acontecendo em determinadas situações, o volume de compras aumentar, então tudo isso faz parte de sazonalidade de mercado.

E como é feito isso? Essa equipe tem que entender essas definições, esses limites, então esse pessoal entra em contato, faz todo ali um levantamento, aplica essas melhorias baseadas em setup, justamente aquilo que a gente viu no roadmap e através de dashboards essa equipe tem segurança de que o ambiente está comportando, tem um reflexo da realidade, seria mais isso.

A partir desse momento, ter esse plano, esse ramp-up, esse pré-aquecimento, essa equipe atua juntamente com a nossa equipe de infraestrutura, traz mais agilidade em caso tenha algum cenário demandando ajuste, demandando uma aplicação operacional pontual e até mesmo um suporte com o War Rooms.

Então pensa numa campanha, por exemplo, de uma venda de ingressos, o Cinemark, por exemplo, o cliente Sensidia também, no caso a gente faz toda uma operação com eles onde a gente coloca os profissionais em contato, os profissionais de gate, de operação de APIs em contato com a equipe de ongoing, de back-end. A gente faz um War Rooms e garante que a comunicação vai ser efetiva.

Então essa equipe trabalha bem próximo do cliente, ela sai um pouco de contexto de gate como um todo, de infraestrutura, utiliza isso, porém trazendo toda essa expertise baseada em necessidades. Faz ali a utilização completa.

E é isso, pessoal. Estamos encerrando aqui mais esse conteúdo onde foi apresentado todo um overview sobre a arquitetura de APIs existentes, utilizando o gateway como uma ferramenta para garantir essa entrega aos consumidores, protegendo toda essa infraestrutura do cliente com controle de true-puf e outras técnicas para garantir a eficiência de performance do sistema como um todo.

Sabemos dessas dificuldades e com essa visão espero ter abertamente de todos para uma futura operação utilizando APIs de missão crítica. Então decisões sobre estrutura, crescimento preditivo, pré-aquecimento de ambiente, otimizações, isso deve ser pauta para o time responsável por essas questões e a Sensidia apoia os clientes garantindo esse reforço nessa demanda e nessa hora.

Então, pessoal, aqui vai essa receita para o sucesso que é contar com esse time de atendimento especializado como background. Isso são fatores decisivos nessa hora, onde a informação real nos traz assertividades na tomada de decisão como um todo.

Então eu agradeço aqui por mais essa visualização desse webinar. Espero que esse conteúdo tenha entregue, no caso, tudo o esperado, baseado no que o mercado utiliza de técnicas, o que o mercado trabalha em cima de operações escalares.

Caso surja alguma dúvida, seguem meus contatos. Vocês podem ficar à vontade e o nosso time de solutions aqui, a Sensedia como um todo, ela está à disposição para ajudar a construir um fantástico mundo sobre APIs.

‍