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

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

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

Na primeira parte , nos concentramos em estratégias de curto e médio prazo, agora é hora de continuar a evoluir.

O Longo Prazo

Finalmente, atingimos o longo prazo, uma etapa que visa transformar a arquitetura do comércio eletrônico em uma solução moderna a todos os níveis, onde os principais objetivos serão:

• Desacoplar e modularizar o front-end.
• Adotar um modelo assíncrono de comunicação entre micro serviços.
• Reduza custos e simplifique a operação.
• Faça um uso mais eficiente dos bancos de dados.

Vale ressaltar que o conjunto de recomendações, serviços e tecnologias apresentadas abaixo aborda os principais desafios encontrados em varejistas globais e é projetado para escalar até centenas de milhares de usuários que compram simultaneamente.
Vamos começar olhando para o projeto arquitetônico proposto para esta etapa.

Como você pode ver as grandes mudanças são encontradas no front-end. Vamos falar agora sobre cada uma das mudanças.

Melhore as comunicações front-end usando filas e mensagens.

Em arquiteturas de comércio eletrônico geralmente existem diferentes processos que são assíncronos por natureza, como processamento de pedidos, notificação a sistemas logísticos, gestão de estados de compra, comunicação com sistemas de terceiros e muitos outros. Essa natureza assíncrona não significa que seu back-end opera dessa maneira, mas é, sem dúvida, um excelente candidato para re-arquitetar a comunicação e transformá-la em assíncrona.
Para conseguir isso, você pode implementar um paradigma de arquitetura dissociado. Este paradigma tem como principal benefício permitir que seus componentes individuais funcionem de forma independente e, ao mesmo tempo, continuem a funcionar mesmo quando outros componentes falham ou são incapazes de fornecer serviço.

Agora vem a pergunta, como fazemos isso?

A técnica mais usada que recomendamos para atingir esse objetivo é o uso de filas de mensagens e barramento de eventos. Esses componentes estão localizados entre diferentes serviços e armazenam temporariamente solicitações enviadas por um micro serviço de origem, até que o micro serviço de destino esteja pronto para consumi-los. Desta forma, diante de qualquer problema ou atraso no micro serviço do consumidor, os dados não são perdidos e podem ser consumidos assim que sua disponibilidade for restaurada. Outra vantagem de tais arquiteturas é a capacidade de dimensionar de forma independente componentes individuais. Sem comunicação síncrona, os aumentos na demanda de recursos em um componente específico não se traduzem diretamente em aumento da demanda para outros serviços, pois os mecanismos de mensagens e eventos servem como um “Buffer” que pode crescer elasticamente no caso de um aumento repentino na quantidade de transações. A AWS tem alternativas diferentes para atender a essa necessidade, como Amazon SQS, Amazon SNS e AmazonEventBridge que oferecem diferentes formas de integrar serviços e possibilitar uma comunicação desacoplada.

Refinar o uso de bancos de dados de acordo com a finalidade.

Em uma arquitetura baseada em microsserviços, recomendamos o uso de bancos de dados especializados e descentralizados porque eles podem ajudar aplicativos móveis e portais da web a alcançar melhorias significativas de desempenho de baixo custo, especialmente em situações de grandes variações. de demanda.
Na seção de médio prazo, eles viram como recomendamos a dissociação da camada de banco de dados incorporando diferentes serviços que buscavam aumentar a escalabilidade, a disponibilidade e o desempenho, no entanto, não especificamos detalhes sobre como os serviços de back-end seriam capazes de usá-los. É por isso que, no estágio de longo prazo, recomendamos que você reveja a implementação de seu back-end para que eles possam identificar quais micro serviços funcionariam melhor com outros bancos de dados.
Vejamos alguns exemplos que podem ajudá-lo neste processo.
O uso de bancos de dados de chave-valor, como o DynamoDB, pode facilitar o acesso rápido a dados, como catálogos de produtos, promoções ativas ou carrinho de compras. Esses micro serviços que exigem uma camada de persistência de dados podem perfeitamente ter sua própria tabela do DynamoDB.

Para perfis de clientes e cupons de desconto, bancos de dados baseados em documentos, como DocumentDB , oferecem a capacidade de pesquisar e indexar arquivos JSON de forma ágil e escalável.

Amplie o uso de bancos de dados na memória, como o Amazon ElastiCache para fornecer acesso a dados de baixa latência e alto processamento, ideal para pesquisas frequentes, catálogos, inventários e todos os tipos de dados que precisam ser visualizados de forma consistente repetidamente.
Há certamente muitos outros exemplos, mas o objetivo é claro. Você pode lembrar que mencionamos essas recomendações a médio prazo, mas agora a idéia é aprofundar seu uso ao máximo. Sabemos que, quando alcançados, os resultados colaboram significativamente no desempenho geral de todo o comércio eletrônico.

Incorporar serviços sem servidor no Front-End

Nesta fase de longo prazo, possivelmente o seu e-commerce já tem uma complexidade componente significativa e carga operacional. Neste cenário, devemos procurar uma solução mais eficiente para continuar a escalar e expandir as capacidades do e-commerce sem perder velocidade e eficiência. Por estas razões, nossa principal recomendação é “re-arquitetar” com um paradigma de construção de arquitetura amplamente conhecido como Serverless. Esse paradigma traz benefícios substanciais na operação e manutenção do comércio eletrônico, porque por não ter que gerenciar qualquer tipo de infraestrutura, essas responsabilidades são delegadas à AWS e economizam tempo que podem ser investidos em inovação e construção de novos recursos que proporcionem melhores experiências para os clientes.
Este tipo de serviço também está muito alinhado com a construção de arquiteturas baseadas em micro-serviços, uma vez que são projetadas para trabalhar de forma dissociada. Também deve ser notado que o uso destes, é dado através de APIs e SDKs e trazer ferramentas de monitoramento, logs, tunning e parametrização que são fundamentais para uma operação de comércio eletrônico em grande escala, tópico que vamos falar em maior profundidade mais tarde.
Também queremos enfatizar que esses serviços sem servidor têm principalmente o modelo pay-as-you-go, que oferece eficiência de custo no momento do uso.

Como você viu, ao longo dos diferentes estágios evolutivos, temos vindo a recomendar a incorporação de serviços sem servidor, tais como: CloudFront, S3, DynamoDB, Fargate, API Gateway, Cognito, Route53, Lambda, SQS e Event Bridge são hoje os pilares fundamentais das arquiteturas modernas para o comércio eletrônico.

Tempo para medir o desempenho e a capacidade do comércio eletrônico

Depois de definir a arquitetura a ser usada, a próxima etapa consiste em definir testes de carga, validação de limite e monitoramento.
Para atingir esse objetivo, nossos clientes realizam todos os tipos de testes de carga nos diferentes componentes da arquitetura, procurando encontrar limites que não foram capazes de identificar anteriormente e, em seguida, aumentá-los com antecedência. Recomendamos que você revise os “Limites Suaves” facilmente modificáveis usando as “Cotas de Serviço” ou criando um ticket de suporte e “Limites rígidos” não modificáveis, vinculados à funcionalidade e arquitetura de cada serviço.

Existem limites por uma razão simples: Proteja o cliente contra usos inadequados e padrões de design incorretos que podem consumir recursos de forma inadequada.

Ninguém gostaria de ter uma arquitetura perfeita cujos limites não foram validados e analisados e, consequentemente, experimentar perdas de serviço para este tópico. O sucesso de um evento de massa depende da realização desta etapa com planejamento e tempo.

Operando Durante o Evento

Para as equipes de TI, atravessar um evento de alta demanda pode ser análogo à situação vivida por uma tripulação em um navio que tem que navegar por uma grande tempestade no meio do mar. Eles são claros que a tempestade está chegando, eles têm informações, mas há incerteza sobre o que pode acontecer.

Há uma realidade. Não importa quantos testes sejam feitos na solução, você sempre precisa estar preparado para eventos inesperados e ter visibilidade suficiente para saber como agir de acordo. Por esse motivo, recomendamos que você crie painéis de monitoramento em ambientes de várias contas usando o serviço Amazon CloudWatch mencionado acima.
Alguns exemplos dos painéis mais comuns são:

• Utilização da CPU e da memória do computador.
• Número de chamadas de API.
• Número de conexões com bancos de dados.
• Latência entre micro serviços

E a lista pode seguir muito mais, tanto quanto cada área de TI o exija.
Vamos ver como alguns desses exemplos se parecem.

O último passo é definir como operar durante o evento e para essas situações mencionaremos algumas práticas operacionais que são denominadoras comuns em nossos clientes.

• Eles usam salas de guerra onde há equipamentos de diferentes verticais de tecnologia durante todas as horas do evento com a capacidade de compartilhar seus painéis de monitoramento.
• Ao trabalhar com o AWS Enterprise Support , o Technical Account Manager (TAM) trabalha e lidera um programa pró-ativo chamado Infrastructure Event Managament(IEM) que se concentra no planejamento e na definição atividades para mitigar os riscos associados a eventos críticos, como Black Friday. Da mesma forma, um cliente com Suporte Empresarial pode acessar esse serviço pagando por cada IEM.
• A data do evento pode ter chegado, talvez não tenha sido possível implementar todas as alterações desejadas, tendo que aceitar os riscos de que certos componentes da infraestrutura tenham apenas pontos de falha ou problemas que possam afetar o serviço. Se necessário, o que é feito é ter planos de contingência e que toda a equipe saiba como agir para mitigar e remediar cada incidente com velocidade.

Posso continuar a melhorar?

A resposta curta é: Claro que sim. Agora vamos cavar mais fundo.
Eles viram na seção de definição de arquitetura, que dividimos as mudanças evolutivas em três etapas que lhes permitirão amadurecer seu e-commerce ao longo do tempo. Uma vez que todas as etapas tenham sido alcançadas ou em paralelo com qualquer uma delas, você pode procurar pontos de melhorias relacionadas a:

• Redução de custos. Principalmente nossos clientes fazem uso intensivo de recursos de computação para que haja um grande investimento de tempo em como otimizar essa camada. E para conseguir isso, eles procuram usar modelos de pagamento por computação baseados em Instâncias Reservadas, Planos de Salvamento e Spot. Por uma questão de espaço e para a ampla deste tópico, gostaríamos de recomendar este post no blog sobre otimização, que tem várias das principais recomendações.
• Segurança e governança é outro ponto de melhoria contínua onde a base deste pilar começa com a estrutura multi-conta capaz de ajudar a controlar a segurança e os custos de diferentes ambientes de forma mais eficiente e nesta estrutura nós recomendo incorporar vários serviços de segurança para atingir o objetivo de um comércio eletrônico mais seguro.
• Implemente práticas de CI/CD para simplificar as implantações em toda a sua pilha de comércio eletrônico. Eles podem complementar essas práticas com recursos como “Serverless Appplication Model”, o “Cloud Development Kit” e ferramentas de terceiros.
• Otimize as comunicações de back-end com serviços como: AppMesh, CloudMap e VPC Endpoints ajudarão muito a melhorar a visibilidade e trazer maior controle, flexibilidade e inteligência às comunicações entre micro serviços.
• A incorporação do Route53 Resolve para melhorar a resolução de nomes entre ambientes de data center no local e a AWS será fundamental para simplificar a integração com sistemas legados.
• E, finalmente, a implementação de um datalake como o principal repositório de informações para a tomada de decisões e operação do e-commerce.

Como você vê, há muitos pontos de melhoria e, de acordo com as prioridades, cada empresa identificará qual caminho seguir. No entanto, estes apontam para um objetivo comum: Acompanhe as metas de crescimento dos negócios, crie, implemente e opere de forma mais ágil, reduzindo custos, melhorando a governança de serviços de nuvem e mais informações para tomar decisões.

Nossas Conclusões

Operar e inovar para um e-commerce sem dúvida tem seus desafios, sendo o principal deles, sendo capaz de ter uma plataforma robusta. Certamente existem outros desafios igualmente complexos, que vão além dos aspectos tecnológicos, como logística e gestão de inventário, entre muitos outros. No entanto, a base para proporcionar uma grande experiência de compra começa com o nível de maturidade que sua arquitetura tem sido capaz de adquirir ao longo do tempo.

Vimos como gradualmente um e-commerce pode ser transformado em um altamente escalável, ágil, capaz de se adaptar a mudanças, dissociado, sem servidor e focado em micro serviços capazes de sustentar os mais altos níveis de disponibilidade que o negócio requer.

Esperamos que essas duas postagens de blog lhes permitam projetar seu próprio caminho para uma melhor experiência de compra para seus clientes e não hesite em contactar-nos se eles precisam do nosso apoio para fazê-lo.

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.