Estamos a aproximadamente 4 meses da Black Friday, um bom momento para pensar se seu ecommerce está funcionando direitinho e a todo vapor, para bombar de vender – e não bombar o seu sistema no dia mais aguardado do ano pelos lojistas.

Então, para responder a pergunta do título deste post, nosso CEO Bruno Pereira conduziu um bate-papo com Luis Palacios, Engenheiro DevOps que atualmente é líder da equipe SRE na Amaro.

Palacios trabalha Observabilidade guiado por dados e métricas. Neste bate-papo informal, você vai entender a importância de aplicar a mesma lógica para o seu ecommerce de forma efetiva. E também as ferramentas disponíveis hoje em dia para isso.

Abaixo, compilamos os principais tópicos da conversa, que você também pode assistir na íntegra no nosso canal no YouTube.

Que tipo de estratégia você tem usado quando trata com parceiros externos? 

Palacios: A Amaro é uma empresa muito centrada em dados. Temos investido muito em Monitoramento, não só dos nossos sistemas internos como dos nossos parceiros externos também: gateway de pagamento e consulta de cálculo de frete por exemplo, entre tantas outras, acabam sendo dependências externas.
Mas o principal é: saber exatamente quais são suas dependências para trabalhar com um tipo de tolerância caso os parceiros apresentem algum tipo de falha.

Pereira: Quando falamos em Monitoramento e pensamos no que pode dar errado, o primeiro ponto que passa despercebido é conhecer o que existe. Por exemplo, em alguns ecommerces grandes, é impressionante a quantidade de tags de parceiro que aparecem, o que pode ser um desafio, porque se um parceiro não aguentar a carga, o ecommerce inteiro pode ficar mais lento. Então mapear o que existe e sobretudo saber o que é preciso monitorar é fundamental.

Como saber se um ecommerce aguentaria o volume de picos de acessos durante a Black Friday, pensando em um cenário guiado por dados?

Palacios: O fator importante para começar esse trabalho é entender nossos números: quantidade de acessos simultâneos, seja no site e em qualquer tipo de app, e com base nesse número, estabelecer uma premissa/referência. Algo como: “tenho x pico de acesso em um dia comum; como seria esse pico em datas comemorativas como Natal, Dia das Mães, Black Friday etc?”. Com esse número mapeado, a gente consegue começar a trabalhar em teste de carga, que é um grande aliado para preparar a nossa infraestrutura com a certeza de que na Black Friday não haverá problemas. É importante, contudo, diferenciar teste de carga de teste de stress.

Muitas vezes colocamos o dois na mesma balança, mas na verdade o teste de carga diz respeito à quantidade de usuários esperados e faz um teste com base nesse número. Atingiu o test load aceitável, tempo de resposta e porcentagem de erros tolerável, está feito o teste de carga; já o teste de stress tem o objetivo de ir até o limite, estressar realmente o sistema para detectar a quantidade de usuários que ele suporta simultaneamente.

Que tipo de Arquitetura poderia ser usada para otimização de recursos na Black Friday, sem que haja a necessidade de um investimento inicial alto?

Palacios: Acho que o principal ponto é ter uma Arquitetura tolerante a falhas. Com o uso da cloud, temos diferentes conceitos de disponibilidade oferecidos de uma forma muito mais simples hoje em dia. Ao usar a AWS ou qualquer outra nuvem, temos o conceito de Zona de Disponibilidade onde podemos trabalhar com datacenters distribuídos por cidades diferentes. Com isso, sabemos que se algum problema acontecer nesses datacenters, a aplicação não deve ser afetada.
Gosto da abordagem de usar serviços gerenciados de cloud, que já trabalha o conceito de tolerância a falha nativa, e usar serviços de cache para tudo isso é vital.
Também gosto de Arquiteturas Assíncronas, embora seja um assunto mais técnico, é bom mencionar por conta do tratamento dado à tolerância a falhas.

Elasticidade para que o ecommerce responda sob demanda

Palacios: Muitas pessoas pensam que só de usar a nuvem, já automaticamente ganhou elasticidade, ganhou escalabilidade, que o site não cai mais, que é tudo lindo e maravilhoso. Mas sabemos que a realidade não é bem assim: é preciso que tudo seja arquitetado do jeito certo para que haja ganhos de uso sob demanda. O principal é ter um modelo de Arquitetura que realmente desfrute do que a nuvem é capaz de oferecer. Hoje a nuvem disponibiliza load balancer para que seja possível fazer o balanceamento de carga de uma maneira mais otimizada, e quanto menor a unidade computacional que for possível dividir, melhor.

Pereira: Antigamente, quando pensávamos em capacidade de processamento, primeiro precisava ter uma antecedência muito maior, usando servidores muito grandes, e eles na prática acompanhavam a vida daquele produto durante muito tempo, não tinha escalabilidade horizontal, do tipo “crescer para o lado” com um servidor adicional.
Eu lembro de casos de arquiteturas não preparadas onde o produto usava a nuvem em um esquema de auto-scaling (de automaticamente crescer o tamanho do conjunto de servidores na medida em que aumentam os acessos), mas aí pode ter o cliente que já estava logado, com produto no carrinho, o sistema não estava tão bem preparado, o cliente tenta fechar a transação mas cai em outro servidor… enfim, e é um cliente que acaba se perdendo. Então existe de fato essa preparação para que a sessão do cliente possa ser mantida ao longo de várias visitas/páginas que ele vai acompanhar.

Preparar a Arquitetura de fato permite que a empresa se beneficie dos recursos da nuvem, que não vêm de forma automática. Algumas coisas vêm sim, embutidas na preparação da própria plataforma, mas existe uma responsabilidade da própria empresa em cuidar do ecommerce para poder lidar melhor com esse cenário que também não pode ser ignorada.

Falando em modelos de contratação, que tipo de contratação você recomendaria para um uso econômico da nuvem durante a Black Friday?

Palacios: É importante ter uma noção da carga e servidores mínimos que irão atender a um determinado cenário. Pensando no conceito de reserva de instâncias, num momento de pico, como é o caso da Black Friday, com a necessidade de triplicar a quantidade de servidores, é possível reservar uma capacidade fixa, de outros cinco servidores, para provisionar os datacenters com maior previsibilidade.

E tem também as instâncias spot, que são servidores com capacidade ociosa que a nuvem nos oferece. Funciona assim: vamos supor que o datacenter da AWS tenha 1 mil servidores, sendo que 700 já são suficientes para atender todos os clientes. Os 300 restantes, ela quer vender mais barato – pelo menos vai ganhar alguma coisa em cima da capacidade ociosa restante. Então esse é o conceito de spot, vender a capacidade que está ociosa dentro da nuvem. E aí a gente consegue usufruir desse tipo de instância nos nossos workloads principalmente para essas máquinas que são efêmeras, ou seja, que vão nascer no momento de pico e vão morrer logo depois. Isso é bem interessante porque, por exemplo, em uma infraestrutura muito grande, toda a infraestrutura de aplicações kubernetes pode rodar em spot. 

Em um cenário de Arquitetura Distribuída, com containers por exemplo, como uma organização pode preparar a automação do site para passar por uma auditoria?

Palacios: Acho que temos aqui uma quebra de paradigma: o mundo cloud é diferente do mundo on-premises. Dificilmente você vai conseguir manter um CMDB atualizado se você trabalhar com escalabilidade horizontal. Acho que o principal ponto para ter uma auditoria com sucesso é persistir o que deve ser persistido: camada de logs, banco de dados, coisas que são menos voláteis, você vai acabar tendo servidores mais fixos naturalmente… já os servidores de aplicação, é um paradigma diferente: eles vão nascer e morrer ali centenas de vezes por dia e você não vai ter muito controle sobre isso. Na minha opinião não se deve trabalhar com CMDB em nuvem pública, não vejo uma forma de fazer isso.

Pereira: O CMDB tradicional torna de fato muito difícil trabalhar com um cenário muito mais dinâmico como é o caso da nuvem, já que o próprio inventário passa a ser mais dinâmico e efêmero. Na prática o que temos são seridores que podem durar muito pouco tempo. O que eu já vi na prática é trocar aquele CMDB “patrimonial” por algo como um catálogo de aplicações e serviços, que é um modelo mais dinâmico e que mantém tudo isso conectado de alguma forma. Acho que essa prática de gerência de configuração, de saber o que estou rodando no meu produto, quais são as aplicações e serviços, é bastante recomendável.

Muitas empresas não têm uma preocupação com relação a questões envolvendo Monitoramento e Gerenciamento de logs, mas a verdade é que você não monitora aquilo que você não conhece, então pelo menos uma Matriz de Resiliência que mostre quais serviços dependem de quais aplicações seria um bom ponto de partida. É uma visão bem mais programática e dinâmica do que era antigamente.

Assista ao vídeo com a íntegra do bate-papo com Luis Palacios, SRE da megastore Amaro: