O blog da AWS

Como o Grupo Boticário otimizou custos através da adoção de Graviton

Márcio Ribeiro, Especialista em cloud e
Thiago Couto, Arquiteto de Soluções na AWS

 

Grupo Boticário

O Grupo Boticário possui 7 marcas próprias e está presente em 16 países com lojas, e-commerce, marketplace e milhares de revendedoras. Além da distribuição exclusiva no Brasil de produtos reconhecidos internacionalmente.

Possui um ecossistema próprio de beleza, que vai da indústria ao ponto de venda, da logística ao varejo, do laboratório ao coração das consumidoras e das inovações até a palma da mão de cada cliente.

A marca-primogênita: “O Boticário”, foi eleita, pelo 4º ano consecutivo, a marca de cosméticos mais amada pelos brasileiros* e o Grupo Boticário a 7º companhia de beleza mais sustentável do planeta**.

Nasceu em Curitiba, há 45 anos, do sonho do fundador Miguel Krigsner. Seu sonho começou ao abrir uma farmácia de manipulação, onde descobriu que sua vida seria para sempre movida pela alquimia dos cosméticos e das relações humanas.

O que era uma farmácia logo se tornou a amada marca O Boticário, que depois abriu espaço para mais 6 marcas, uma Fundação e um Instituto.

 

Desafio

A jornada de uso de Cloud do Grupo Boticário começou há alguns anos, porém até 2019 a adoção ainda era muito tímida e basicamente limitada ao canal de e-commerce do Grupo. A partir de 2020, com a ajuda de um estudo técnico-financeiro, a Companhia decidiu por seguir com a estratégia de uso de Cloud majoritariamente. Essa decisão trouxe um grande crescimento no fluxo e consequentemente um novo olhar para os custos de nuvem.

Atualmente ainda existem muitos serviços que rodam em EC2 dentro do e-commerce, como mongoDBs, elasticsearch e claro, os nodes kubernetes. Porém, no início de 2020 o e-commerce respondia por 50% da fatura total AWS e dentro do e-commerce 70-80% do custo estava atrelado a EC2. E foi pensando nisso que tomamos a decisão de otimizar nossos custos.

 

Desafio

Em 2021 lançamos o desafio de reduzir em 15% nossos custos de cloud na AWS para o canal de e-commerce. Várias frentes foram mapeadas para atingir este objetivo, incluindo a migração de serviços em RDS, Elasticache e principalmente EC2 para ARM.

Dentro de instâncias EC2 e nodes EKS, que rodam em ec2, existiam os seguintes serviços rodando em X86:

  • Aplicações Java (11 ao 16).
  • Aplicações Node JS (12 ao 14).
  • MongoDB 4.xxx.
  • Elasticsearch 7.x

 

Solução

Para atingir a meta de redução no custo, listamos as migrações de recursos rodando em processadores Intel para Graviton. Fizemos isso nas 5 fases descritas abaixo.

  1. Migração MongoDBs em EC2 para Graviton.
  2. Migração Elasticache para Graviton.
  3. Migração RDS Postgresql para Graviton.
  4. Migração de clusters EKS de front-end / node JS para Graviton.
  5. Migração de clusters EKS back-end / Java para Graviton.

 

A migração foi iniciada pelos replica sets de MongoDB rodando em EC2. Ao todo eram 136 instâncias, destas, 29 replica sets estavam executando MongoDB dentro do e-commerce. Na sequência vamos descrever os passos de cada fase executados para a migração de todas as instâncias sem downtime:

Fase 1: Migração MongoDBs em EC2 para Graviton

Na primeira fase tivemos 04 pontos principais:

  • Nova instância EC2 Graviton lançada.
  • Pacote do MongoDB 4.4.7 em Graviton foi baixado do repositório oficial da MongoDB.
  • Uma vez instalado, foi gerada uma AMI e a partir dessa AMI foi iniciada a configuração de novos replica sets seguindo o roteiro abaixo para cada um deles:
    • 3 novas instâncias EC2 foram criadas a partir dessa AMI.
    • A configuração do replica set a ser migrado para Graviton era replicada em nível de configuração do banco, como por exemplo o nome do replica set, as chaves de comunicação, entre outros detalhes.
    • As novas instâncias em Graviton eram integradas ao replica set existente em produção para replicação dos dados.
    • Uma vez que os dados eram replicados dentro das 3 novas instâncias era iniciada a remoção de cada instância X86 do replica set. Para garantir uma remoção tranquila, foi importante assegurar que esta máquina não era a primária dentro do replica set. Porém, caso fosse, um etapa adicional era executada. A máquina era removida da configuração do replica set, desligada e excluída.
    • Uma vez removidas as 3 instâncias X86, o replica set passa a operar usando o mesmo DNS de conexão, ou seja, não é necessário ajustes ou downtime na aplicação.

 

Abaixo o roteiro que foi aplicado:

Repetimos o esquema acima até terminarmos a migração das 136 instâncias que executam o MongoDB.

 

Fase 2: Migração do Elasticache para Graviton

Posteriormente foi iniciada a migração dos clusters Elasticache, com um procedimento mais simples.

Foi utilizado o Modify Cluster para alterar a arquitetura para o modelo ARM e aplicar no cluster. Nenhum tipo de alteração nos clientes ou em nível de dados foi necessária.

 

Fase 3: Migração RDS Postgresql para Graviton

A migração das instâncias PostgreSQL seguiu a mesma linha do Elasticache, nenhuma alteração a nível de dados ou clients (aplicações) foi necessária.

 

Fase 4: Migração de clusters EKS de front-end / node JS para Graviton

Na sequência, fizemos a migração das aplicações de front-end que rodam em NodeJS 14.x e 16.x seguindo o roteiro abaixo:

  • Iniciamos a migração pela pipeline que realiza os builds de artefatos do front-end.
  • Esta automação foi construída utilizando Jenkins + Ansible em 3 passos:

1° passo: Criar jenkins-agents em cima de instâncias Graviton e configurar os node labels dos mesmos. Isso permite isolar os jobs de build em Graviton.

2° passo: Duplicar o step de build gerando um step igual, porém que executa isolado em instâncias Graviton, garantindo um artefato construído em Graviton ao final.

3° passo: Duplicar o step de construção da imagem docker. Novamente replicamos o step existente, porém empacotamos o artefato Graviton dentro de uma imagem docker.

  • A imagem docker que contém o artefato Graviton era identificada como Graviton no registry da AWS.
  • Antes da execução de imagens com o artefato gerado em Graviton, foi necessário criar novos node-groups EKS com instâncias Graviton. Esses node groups foram configurados com o taints e isso impedia aplicações X86 de executarem em Graviton. Garantimos que as aplicações em Graviton executassem somente em nodes Graviton, através da configuração em deployments do nodeAffinity que foi
  • Após a preparação do ambiente kubernetes, manifestos kubernetes e pipeline de CD foi possível executar a mesma aplicação dentro do mesmo cluster em X86 + Graviton.
  • Foi necessário trocar uma biblioteca nodeJS, que compilava em C para uma nativa em JS que serve para conexão com Redis, chamada node-redis.
  • O último passo foi remover toda a pipeline de construção X86, remover os deployments X86 e os nodes X86. Como resultado havia apenas a pipeline em Graviton, aplicações em Graviton e nodes em Graviton.

 

Esquema abaixo para ilustração:

 

 

Fase 5: Migração de clusters EKS back-end / Java para Graviton

Após a finalização da migração do front-end iniciamos a migração do back-end que consistia em aplicações Java executando em nodes EKS. O processo foi similar ao procedimento realizado para o front-end, porém nenhuma biblioteca java precisou ser trocada.
Abaixo roteiro para ilustrar:

Além das aplicações foi necessário migrar algumas aplicações internas do kubernetes para suas versões em Graviton:

  • ExternalDNS
  • Metric server.
  • Core-DNS.
  • Agents da NewRelic.
  • AWS Load Balancer Controller.
  • Prometheus
  • Dentre outras.

Com a virada destas aplicações dentro de cada cluster foi possível remover os node groups X86 mantendo apenas instâncias do tipo Graviton para os node groups EKS. Utilizamos instâncias c6g.4xlarge para os nodes de front-end e instâncias m6g.2xlarge para o back-end.

 

Resultado

O nosso principal objetivo com essa mudança foi conseguir reduzir custos. A meta inicial de 15% não foi só atingida como também superada. Toda essa transformação trouxe uma redução de aproximadamente 30% no custo por pedido na nossa plataforma de e-commerce.

O gráfico abaixo apresenta a redução de custo de aproximadamente 30% sobre os recursos computacionais na plataforma. A curva de redução acompanha a curva de adoção do Graviton.

Além da redução de custos, conseguimos executar a mudança para Graviton sem impacto de performance e sem downtime. Isto foi possível graças ao planejamento e execução de todas as etapas de forma cuidadosa, seguindo os procedimentos descritos anteriormente.

Já temos novos desafios baseados nos excelentes resultados que tivemos. Hoje 70% do e-commerce roda utilizando arquitetura Graviton. A próxima meta é atingir margens similares em outros canais e produtos digitais do Grupo Boticário e continuar otimizando e melhorando nossa infraestrutura.

Para saber mais sobre Graviton, acesse o link abaixo:

Graviton: https://thinkwithwp.com/pt/ec2/graviton/

 

Sobre os autores

Márcio Ribeiro é especialista cloud e amante de infraestrutura. Iniciou em 2008 com foco em infraestrutura tradicional e em 2015 migrou totalmente para o mundo cloud e práticas DevOps. Atualmente trabalha como gerente de infraestrutura no Grupo Boticário.

 

 

 

 

Thiago Couto é Arquiteto de Soluções na AWS e atua no segmento Enterprise auxiliando clientes de Retail e CPG em suas jornadas para nuvem. Possui mais de 10 anos de experiência atuando em arquiteturas que englobam AI/ML, integrações, IoT e correlatos.