Comércio eletrônico bem-sucedido na Black Friday com a AWS – Parte 1

Por Adler Oliveira, Arquiteto de Soluções AWS e
Bruno Laurenti, Arquiteto de Soluções AWS

Bem-vindo à primeira parte deste post de blog dedicado ao comércio eletrônico e datas de negócios de alta demanda.

Vamos começar com um pequeno contexto.

Não há dúvida de que a indústria de comércio eletrônico assumiu um papel importante durante 2020 e datas comerciais como Black Friday e Cyber Monday se estabeleceram como fundamentais para o sucesso de qualquer empresa que vende produtos virtualmente. Sabemos que durante estes períodos há uma grande expectativa dos compradores, não só para encontrar bons negócios, mas também por ter uma boa experiência de compra e que inclui, ter um site que lhes permita navegar sem problemas, ter boas imagens e detalhes claros dos produtos, ter um sistema eficiente de pesquisa e um processo de pagamento simples e consistente. Todos esses fatores e muitos outros contribuem significativamente para a decisão dos clientes sobre onde comprar.
Por outro lado, durante as datas de alta demanda há inúmeros desafios que tornam a tarefa de preparar a infraestrutura tecnológica para apoiar um evento maciço e alguns exemplos são: Tempos limitados para melhorar a infraestrutura, baixo orçamento, capacidade tecnológica limitada, processos burocráticos que atrasam os processos de mudança, entre outros.

Para nossos clientes de varejo, eles conseguiram mitigar esses desafios usando os serviços da AWS, recuperando a agilidade necessária para os negócios, incorporando novas técnicas de implantação ágil, recursos elásticos para se adaptar dinamicamente à demanda e, fundamentalmente, conseguiram fortalecer os níveis de disponibilidade incorporando serviços gerenciados nativos e da AWS que já possuem esses recursos.
Com base no que vimos nestes eventos com nossos clientes, nossa intenção é poder compartilhar neste post em duas partes, as diferentes estratégias tecnológicas que permitem preparar seus sites de e-commerce da melhor maneira possível, considerando os períodos de tempo que eles têm disponíveis para fazê-lo. Abordaremos ações desde as mais rápidas e simples que podem entregar valor imediato, até as mais complexas, como a refatoração usando práticas de desenvolvimento modernas, visando transformar seu e-commerce em uma solução elástica e ágil para se adaptar às mudanças.

Por onde começamos?

Conhecendo os números como primeiro passo

Um dos pontos mais importantes no processo de planejamento para um evento de massa é certificar-se de que você sabe muito bem como seu site de comércio eletrônico se comportou em datas passadas. Como ponto de partida, procurar métricas históricas para algumas dessas datas será útil para definir as bases do trabalho que eles terão que fazer para o próximo evento. Exemplos dessas métricas podem incluir: Usuários simultâneos conectados, tempos médios de carregamento de página, transações por segundo (TPS), número de chamadas simultâneas para APIs, consumo de recursos computacionais (CPU, memória, armazenamento e rede) para bancos de dados e serviços de back-end, entre muitos outros.
Depois de ter essas informações, recomendamos ajustar a arquitetura, com base nas projeções de vendas que sua empresa definiu como alvo, para que elas comecem a trabalhar na próxima etapa.

É hora de definir como projetar…

… E a chave é o tempo que você tem para se preparar para o evento mais o número de profissionais que poderão se concentrar nas tarefas.
Estamos claros que nem todas as empresas podem gastar a mesma quantidade de tempo para se concentrar em seu site de comércio eletrônico. Alguns têm pouco tempo, então suas decisões de design devem ser cuidadosamente selecionadas e priorizadas. Outros, por exemplo, planejam com bastante antecedência o que eles irão fazer. Também estamos claros que as equipes que operam com nossa nuvem são diversas em conhecimento e número de pessoas, o que também pode afetar o tempo total necessário para implementar mudanças evolutivas em seus sites.
Por estas razões, decidimos estruturar esta seção em três estratégias arquitetônicas que são baseadas no curto, médio e longo prazo. É importante entender que, para cada empresa, essas três estratégias podem significar prazos diferentes. Isso significa basicamente que o que alguns podem implementar no médio prazo outros poderiam fazê-lo em breve, dependendo dos recursos que eles têm para executá-lo.
Para o exercício vamos assumir uma arquitetura genérica e simplificada que poderia representar a maioria do e-commerce no mercado. Vamos considerar uma arquitetura de três camadas com uma conexão com um ambiente local (através de uma VPN Site a Site) que permite que o comércio eletrônico se comunique com sistemas legados. Também consideramos que as réplicas dos serviços e servidores já existem em todas as camadas para oferecer alta disponibilidade, mas não necessariamente implantadas em diferentes zonas de disponibilidade. Para nossa revisão, consideraremos boas práticas baseadas no Well Architected Framework, que nos ajudará a criar uma arquitetura segura, de alto desempenho, resiliente e eficiente:

Vejamos a arquitetura que usaremos como ponto de partida.

Agora vamos começar com o mais simples e imediato.

O Curto Prazo

Alterações de curto prazo são ideais para quando a data do evento em massa está a algumas semanas de distância, ou quando há um orçamento limitado que não permite outras alternativas. Consequentemente, as recomendações a seguir são baseadas em mudanças de infra-estrutura que exigem muito poucas mudanças no nível de implementação. Desta forma, ele pode ser executado e testado pela equipe de infraestrutura fora dos ciclos de desenvolvimento.

Abaixo estão as alterações que recomendamos para o curto prazo.

Aprimoramentos de front-end usando a Rede de Entrega de Conteúdo (CDN)

O front-end é a face digital visível do negócio, dependendo de como a arquitetura de comércio eletrônico é projetada, o acesso ao conteúdo e a renderização de páginas da web podem consumir muitos recursos de computação. Esses processos geralmente incorporam latência extra ao tempo total de carregamento das páginas e, assim, proporcionam uma experiência unideal aos consumidores. Uma maneira eficiente que recomendamos acelerar os tempos de carregamento e também aliviar os recursos de computação é usar o serviço Amazon CloudFront para criar uma camada de cache para conteúdo estático (Imagens, Scripts, Estilo). O CloudFront armazena uma cópia desses conteúdos em um local geograficamente mais próximo dos consumidores, reduzindo assim os tempos de carregamento associados à distância entre a origem do conteúdo, em relação aos usuários.

Adicionar alta disponibilidade com zonas de disponibilidade

Todas as nossas regiões são projetadas com duas ou mais zonas de disponibilidade (clusters de data center geograficamente dispersos). A ideia é que, com pouca complexidade adicional, eles podem aumentar a disponibilidade e eliminar pontos únicos de falha, distribuindo componentes de comércio eletrônico em duas ou mais zonas de disponibilidade, atenuando assim a perda de serviço que pode ocorrer a qualquer um deles. Para o exemplo desta arquitetura, recomendamos duas zonas para uma questão de simplicidade, mas o seu e-commerce, se necessário, poderia ser distribuído em mais de dois.
Da mesma forma que para a camada de computação, com o Amazon Relational Database Service (RDS), você pode habilitar a “Implantação Multi-AZ” que disponibilizará um banco de dados Standby com replicação síncrona em outra zona de disponibilidade pronto para receber carga em o evento de uma falha ou manutenção programada na base primária. É importante mencionar que assumimos o uso do RDS para o banco de dados, mas se você tiver instâncias de computação do EC2, você precisará projetar alta disponibilidade com as tecnologias fornecidas pelo mecanismo de banco de dados que você está usando.

Aumentar a capacidade com réplicas de leitura para bancos de dados

Uma das maneiras mais escaláveis e eficientes que recomendamos para garantir a capacidade durante uma situação de alta demanda é o dimensionamento horizontal. Essa estratégia de escalabilidade permite que você adicione mais capacidade com o mínimo de interrupção aos sistemas que estão em execução. O RDS permite que você trabalhe com réplicas de leitura em mecanismos como: MySQL, MariaDB, PostgreSQL, Oracle e SQL Server. Além disso, o uso de réplicas de leitura permite a distribuição correta dessas solicitações para mais de um servidor, impedindo que o banco de dados principal seja sobrecarregado com solicitações.

Aumente a capacidade de computação com grupos de Auto Scaling

Para a camada de computação, recomendamos a implantação de grupos de Auto Scaling, que consiste em uma coleção de instâncias do Amazon EC2 que são tratadas como um único pool lógico para escalabilidade e gerenciamento. O dimensionamento pode ocorrer em resposta ao aumento da demanda por diferentes métricas ou mesmo de forma programada. Além disso, os grupos Auto Scaling podem realizar verificações de integridade do servidor e gerenciar sua substituição em caso de perda no serviço.
Tenha em mente que durante as variações de demanda experimentadas nas datas de negociação, é importante manter uma resposta rápida às possíveis flutuações de tráfego, para as quais os grupos Auto Scaling fazem parte da primeira linha de defesa em uma arquitetura robusta e elástica.

Incorpore visibilidade e monitoramento por meio do CloudWatch

Para poder monitorar a saúde dos componentes do comércio eletrônico e responder adequadamente a qualquer evento anormal durante as datas comerciais, é necessário ter visibilidade dos recursos e aplicativos responsáveis pela entrega da experiência de compra aos clientes. Para isso, recomendamos configurar o Amazon CloudWatch para monitoramento centralizado do seu ambiente. Com o CloudWatch, a ideia é que eles podem coletar, visualizar e correlacionar recursos, aplicativos e serviços da AWS, bem como recursos no data center local.
Você também pode definir alarmes e automatizar ações com base em limites predefinidos ou algoritmos de aprendizado de máquina que identificam comportamentos anormais em suas métricas. A ideia por trás dessas configurações é poder responder rapidamente de forma automatizada e com as informações apropriadas sobre eventos anômalos. A resposta rápida em caso de problemas é fundamental para oferecer a melhor experiência de compra, especialmente quando ocorrem instabilidades no ambiente. Vamos falar mais sobre este tópico, na seção “Operando durante o evento”

O Médio Prazo

Continuando com o médio prazo e assumindo que as mudanças de curto prazo foram implementadas, nosso próximo passo consistirá principalmente em procurar dissociação e micro-segmentação de vários componentes de arquitetura usando armazenamento em cache, pool de conexões, armazenamento e serviços de contêiner. Por outro lado, reforçar a solução final do ponto de vista da segurança e das comunicações é outro objectivo que pretendemos alcançar para esta estratégia a médio prazo.

Vamos ver como seria a arquitetura no diagrama a seguir.

Desacoplar o Front-end

Como você pode ver no diagrama, ainda mantemos o front-end com o grupo de escalonamento automático, mas a diferença é que várias das funcionalidades foram dissociadas da computação e delegadas aos serviços sem servidor, gerenciados pela AWS. Primeiro, incorporar a API Gateway permite mover toda a lógica e gerenciamento de API para um serviço que seja escalável nativamente e altamente disponível e, em segundo lugar, a adição do S3 Object Storage Service destina-se a armazenar todo o conteúdo estático que o site tem em forma redundante e desacoplada a partir do front-end.

Desacoplando o back-end

Usar um paradigma de desenvolvimento de aplicativos baseado em microsserviços tem muitas vantagens. Implementado para um caso de uso como um e-commerce, este paradigma é particularmente eficiente, pois combina bem com a natureza da segregação de responsabilidade muitas vezes encontrada em tais soluções. Uma loja virtual geralmente é feita de componentes que têm limites claros. Recursos como carrinho de compras, processamento de pedidos, pesquisa de produtos, recomendações de produtos, gerenciamento de logística, gerenciamento de estoque e processos de pagamento, podem ser tratados de forma independente, usando diferentes tecnologias e até mesmo bancos de dados diferentes. Portanto, em busca de ter um backend mais modularizado, procuramos desacoplar a camada de computação EC2 em micro serviços e para alcançar essa tarefa você pode optar por trabalhar com contêineres. A ideia é ter uma tecnologia que permita adotar metodologias mais robustas para orquestrar e operar micro serviços em larga escala e que se adaptem nativamente a metodologias de implantação mais ágeis.
Ao selecionar uma tecnologia de orquestração de contêiner, recomendamos que você avalie três coisas principalmente: Primeiro seu conhecimento da AWS, segundo o nível de especialização que a equipe possui e, em terceiro lugar, o nível de responsabilidade pela operação que deseja ter na plataforma de contêineres. A partir dessas informações, eles serão mais capazes de selecionar se devem usar ECS ou EKS e usar o Fargate como um mecanismo de computação para delegar a tarefa definida as configurações de computação e escalonamento automático para um serviço gerenciado.
Finalmente, olhando também para dissociar o fluxo de comunicações, este back-end tem como um recurso que é acessado diretamente a partir do API Gateway, onde para cada micro serviço há uma API diferente que representa uma funcionalidade do site de e-commerce.
Como mensagem final, queremos dizer-lhe que o uso de micro serviços para a construção de e-commerce não é apenas uma boa idéia, mas também permite isolar o escopo que uma falha potencial poderia gerar. Além disso, permite que diferentes equipes de desenvolvimento trabalhem de forma independente em cada um desses módulos, garantindo que o processo de melhoria contínua possa ser executado em paralelo e de forma mais eficiente.

Desacoplando a camada de banco de dados

Na camada de banco de dados, o objetivo que é procurado com essa arquitetura dissociada é reduzir a carga para os bancos de dados principais usando um ElastiCache Redis em alta disponibilidade, também permitindo que o back-end do banco de dados seja ainda mais independente, reduzindo a impacto que pode resultar na aplicação das novas configurações que exigem reinicialização ou mesmo um problema que afeta a disponibilidade nesta camada.
Em particular para e-commerce com catálogos de produtos longos, a possibilidade de ter uma camada de cache intermediária pode ajudar a melhorar os tempos de resposta do cliente durante essas datas de alta demanda.
Por outro lado, essa arquitetura incorpora o DynamoDB como um banco de dados não relacional que atua como uma fonte de informações para esses micro serviços de back-end que exigem respostas rápidas sem a necessidade de consultas complexas ou informações relacionais cumpre sua função, tornando os bancos de dados primários ainda mais independentes.
Finalmente, incorporamos o serviço Proxy do RDS para desacoplar o gerenciamento do pool de conexões de banco de dados e delegá-lo a um serviço gerenciado que também possui alta disponibilidade nativa. Como o gerenciamento de conexões é um processo demorado computacionalmente caro, esse serviço também ajuda a reduzir os tempos de resposta, especialmente quando trabalhamos em grande escala com milhares de conexões simultâneas.

Melhorias na segurança de front-end

A médio prazo, recomendamos fortalecer a segurança front-end com serviços que se integram perfeitamente com o resto dos serviços. Primeiro, use o AWS WAF para bloquear/mitigar ataques de camada de aplicação (Layer 7), usando regras fornecidas pela AWS ou pelos principais fabricantes de segurança do setor.
Em segundo lugar para ataques DDOS, fazer uso do Shield Advance que traz melhorias sobre o serviço padrão em termos de detecção de ataques mais sofisticados na camada de rede e transporte, proteção de custos e, finalmente, a possibilidade de ter o suporte proativo de uma equipe de resposta da AWS responsável por ajudá-los a mitigar esses ataques em um momento tão crítico quanto o de um evento em massa.
Recomendamos que você avalie o uso desses serviços, não como uma despesa adicional, mas como um investimento que permite evitar ou ajudar a mitigar rapidamente ataques, o que, de outra forma, poderia significar uma perda financeira significativa que os manteria longe de ser capaz de atingir os objetivos de negócios do negócios.

Aprimoramentos de conectividade

Por último, mas não menos importante, sabemos que muitos clientes optaram por arquiteturas híbridas onde vários componentes críticos de comércio eletrônico ainda funcionam em seus data centers locais. Por esta razão, sugerimos incorporar um design de conectividade mais robusto na arquitetura com a adição do serviço de conectividade Direct Connect. Este serviço, fornecido por um provedor de comunicações, oferece um SLA de serviço e largura de banda e latências mais consistentes do que os links VPN tradicionais. O projeto, embora simplificado, visa demonstrar que a solução deve ter um link de conectividade primário e secundário para evitar a perda de serviço que uma falha potencial de link de rede poderia causar no site de comércio eletrônico.

O próximo passo

Nesta primeira parte, focamos em estratégias evolutivas para o seu e-commerce focadas em mudanças de baixa e média complexidade para o curto e médio prazo, o que lhes permitirá lidar melhor com períodos de alta demanda garantindo uma melhor experiência de compra.

Mas esta jornada continua e há muito mais caminho a percorrer.

É por isso que convidamos você para a segunda parte, para que você possa aprofundar as grandes mudanças que eles poderiam implementar para operar de forma mais eficiente e escalável à medida que seu e-commerce continua a crescer.

Sobre os Autores

Adler Oliveira é um arquiteto de soluções na AWS com foco em clientes de varejo corporativo.

Bruno Laurenti é um arquiteto de soluções da AWS com foco em clientes corporativos financeiros e de varejo.

Sobre os revisores

Sergio Barraza é gerente técnico de contas da AWS com foco em clientes de varejo corporativo.

Angel Goñi é um arquiteto de soluções da AWS com foco na SAP e no setor de CPG (Consumer Packaged Goods).

Clerinsom Sant’Ana é um arquiteto de soluções da AWS com foco em clientes corporativos na área de Mineração, Logística & Transporte, Manufatura e Aeroespacial.