Blog de Amazon Web Services (AWS)

Cómo el Grupo Boticário optimizó los costos mediante la adopción de Graviton

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

Grupo Boticário

Tiene 7 marcas propias y está presente en 16 países con tiendas, comercio electrónico, marketplace y miles de revendedores, además de la distribución exclusiva en Brasil de productos reconocidos internacionalmente.

Tiene su propio ecosistema de belleza, que va desde la manufactura hasta el punto de venta, desde la logística hasta el comercio minorista, desde el laboratorio hasta el core bussiness para asi poder entregar sus innovaciones en la palma de la mano de cada cliente.
La marca originaria : «O Boticário» fue elegida, por cuarto año consecutivo, la marca de cosméticos más querida por los brasileños* y el Grupo Boticário es la séptima empresa de belleza más sostenible del planeta**.
Nacida en Curitiba, Brasil hace 45 años, del sueño de su fundador Miguel Krigsner. Todo comenzó cuando abrió una farmacia de compuestos , donde descubrió que su vida estaría siempre impulsada por la alquimia de los cosméticos y las relaciones humanas.
Lo que comenzó como una farmacia pronto se convertiría en la marca O Boticário, que más tarde abrió espacio para otras 6 marcas, una Fundación y un Instituto.

Reto

El viaje del Grupo Boticário a la nube comenzó hace unos años, Sin embargo hasta el 2019 la adopción seguía siendo muy tímida y se limitaba al canal de comercio electrónico del Grupo. A partir de 2020, y con la ayuda de un estudio técnico-financiero, la Compañía decidió continuar con la estrategia de usar la nube. Esta decisión generó un gran crecimiento en el flujo y en consecuencia, una nueva perspectiva de los costos de la nube.
Actualmente, todavía hay muchos servicios que se ejecutan en el servicio EC2 dentro de la plataforma de comercio electrónico, como MongoDB, Elasticsearch y, por supuesto, los nodos de Kubernetes. Sin embargo, a principios de 2020, la plataforma de comercio electrónico representaba el 50% de la factura total de AWS. Dentro del comercio electrónico el 70-80% del costo estaba vinculado a EC2. Fue con esto en mente que O Boticario tomó la decisión de optimizar sus costos.

 

Reto

En 2021, O Boticariolanzó el desafío de reducir los costos de la nube de AWS en un 15% para el canal de comercio electrónico. Se asignaron varios frentes para lograr este objetivo, incluida la migración de servicios hacia RDS, Elasticache y, especialmente, EC2 a la arquitectura de procesadores ARM.

Dentro de las instancias de EC2 y los nodos de EKS, que se ejecutan en ec2, existían los siguientes servicios ejecutándose en procesadores con arquitectura de procesadores X86 :

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

Solución

Para lograr el objetivo de reducción de costos, O Boticariodeterminó el listado de las migraciones de recursos que se ejecutaban en procesadores Intel a Graviton. Esto se efectuó en las 5 fases que se describen a continuación:

  1. Migración de MongoDB en EC2 a Graviton.
  2. Migración de Elasticache a Graviton.
  3. Migración de RDS Postgresql a Graviton.
  4. Migración de clústeres de EKS de JS frontend/node a Graviton.
  5. Migración de clústeres EKS/Java de back-end a Graviton.

La migración se inició en los conjuntos de réplicas de MongoDB que se ejecutaban en EC2. En total, existían 136 instancias, de las cuales 29 conjuntos de réplicas ejecutaban MongoDB en el comercio electrónico. A continuación, describiremos los pasos de cada fase realizada para migrar todas las instancias sin tiempo de inactividad:

 

Fase 1: Migración de MongoDB en EC2 a Graviton

En la primera fase tuvimos 3 puntos principales:

  • Lanzamiento de una nueva instancia de EC2 Graviton.
  • El paquete MongoDB 4.4.7 en Graviton que se descargó del repositorio oficial de MongoDB.
  • Una vez instalada, se generó una AMI y, a partir de esa AMI, se inició la configuración de los nuevos conjuntos de réplicas siguiendo el siguiente script para cada uno de ellos
    • Se crearon 3 nuevas instancias de EC2 a partir de esta AMI.
    • La configuración del conjunto de réplicas que se va a migrar a Graviton se replicó en el nivel de configuración de la base de datos, como el nombre del conjunto de réplicas, las claves de comunicación, entre otros.
    • Las nuevas instancias de Graviton se integraron en el conjunto de réplicas existente en producción para replicar los datos.
    • Una vez replicados los datos en las 3 instancias nuevas, se procedió a la eliminación de cada instancia X86 del conjunto de réplicas. Para garantizar una extracción sin problemas, era importante asegurarse de que esta máquina no fuera la principal dentro del conjunto de réplicas. Sin embargo, si lo fuera, se llevó a cabo una etapa adicional. La máquina se removió de la configuración del conjunto de réplicas, para posteriormente apagarla y eliminarla.
    • Una vez eliminadas las 3 instancias X86, el nuevo conjunto de réplicas con Instancias Graviton se inicia apuntando al mismo DNS de conexión, sin requerir ajustes ni tiempo de inactividad en la aplicación.

A continuación se muestra la secuencia de comandos que se aplicó :

Repetimos el esquema anterior hasta que terminemos de migrar las 136 instancias que ejecutan MongoDB.

Fase 2: Migración de Elasticache a Graviton

Más tarde, se inició la migración de los clústeres de Elasticache, con un procedimiento más sencillo.
Modify Cluster se utilizó para cambiar la arquitectura al modelo ARM y aplicarla al clúster. No se requirió ningún cambio a nivel de datos ni de cliente.

 

Fase 3: Migración de RDS Postgresql a Graviton

La migración de las instancias de PostgreSQL siguió la misma línea que Elasticache, no se necesitaron cambios en el nivel de datos ni en los clientes (aplicaciones).

 

Fase 4: Migración de clústeres de EKS de front-end/Node JS a Graviton

A continuación, se migraron las aplicaciones front-end que se ejecutan en NodeJS 14.x y 16.x siguiendo la siguiente hoja de ruta:

  • Comenzamos la migración a través del pipeline que realiza las compilaciones de artefactos front-end.
  • Esta automatización se creó con Jenkins+Ansible en 3 pasos:

Paso 1: Crear jenkins-agents sobre las instancias de Graviton y configurar sus etiquetas de nodo. Esto le permite aislar los trabajos de compilación en Graviton.
Paso 2: Duplicar el paso de compilación generando un paso igual, pero uno que se ejecute de forma aislada en las instancias de Graviton, garantizando un artefacto construido en Graviton.
Paso 3: Duplicar el paso de creación de imágenes de Docker. Una vez más, replicamos el paso existente, pero empaquetamos el artefacto Graviton dentro de una imagen acoplable.

  • La imagen de Docker que contiene el artefacto Graviton se identificó como Graviton en el Image Registry de AWS.
  • Antes de ejecutar imágenes con el artefacto generado en Graviton, era necesario crear nuevos grupos de nodos EKS con instancias de Graviton. Estos grupos de nodos se configuraron con taints y esto evitó que las aplicaciones X86 se ejecutaran en Graviton. De esta forma, nos aseguramos de que las aplicaciones de Graviton se ejecutaran solo en los nodos de Graviton, a través de la configuración en las implementaciones de NodeAffinity que se configuró.
  • Tras preparar el entorno de Kubernetes, los manifiestos de Kubernetes y la canalización de CD, fue posible ejecutar la misma aplicación dentro del mismo clúster en X86+ Graviton.
  • Era necesario cambiar una biblioteca NodeJS, que se compilaba en C a una biblioteca JS nativa que sirviera para conectarse con Redis, llamada node-redis.
  • El último paso fue eliminar toda la canalización de compilación de X86, eliminar las implementaciones de X86 y los nodos de X86. Como resultado, solo había la tubería de Graviton, las aplicaciones de Graviton y los nodos de Graviton.

Diagrama a continuación para ilustración:

Fase 5: Migración de clústeres Java y backend de EKS a Graviton

Una vez completada la migración del front-end, comenzamos a migrar el backend, que consistía en aplicaciones Java que se ejecutaban en nodos de EKS. El proceso fue similar al procedimiento realizado para el front-end, pero no fue necesario intercambiar ninguna biblioteca de Java.

A continuación se muestra un guion ilustrativo:

Además de las aplicaciones, era necesario migrar algunas aplicaciones internas de Kubernetes a sus versiones de Graviton:

  • DNS externo.
  • Servidor de métricas.
  • Core-DNS.
  • Agentes de New Relic.
  • Controlador de balanceador de carga de AWS.
  • Prometheus.

Con el cambio de estas aplicaciones dentro de cada clúster, fue posible eliminar los grupos de nodos X86, manteniendo solo las instancias de tipo Graviton para los grupos de nodos de EKS. Usamos instancias c6g.4xlarge para los nodos front-end y instancias m6g.2xlarge para el backend.

 

Resultado

Nuestro principal objetivo con este cambio era reducir los costos. El objetivo inicial del 15% no solo se alcanzó sino que también se superó. Toda esta transformación supuso una reducción de aproximadamente un 30% en el costo por pedido en nuestra plataforma de comercio electrónico.
El siguiente gráfico muestra la reducción de costos de aproximadamente un 30% en comparación con los recursos computacionales de la plataforma. La curva de reducción sigue la curva de adopción de Graviton.

Además de la reducción de costos, pudimos llevar a cabo el traslado a Graviton sin afectar el rendimiento y sin tiempo de inactividad. Esto fue posible gracias a la cuidadosa planificación y ejecución de todas las etapas,siguiendo los procedimientos descritos anteriormente.
Ahora, existen nuevos desafíos basados en los excelentes resultados que obtuvimos. Hoy, el 70% del comercio electrónico se ejecuta con la arquitectura Graviton. El siguiente objetivo es lograr márgenes similares en otros canales y productos digitales del Grupo Boticário y seguir optimizando y mejorando nuestra infraestructura.
Para obtener más información sobre Graviton, acceda al siguiente enlace:

Gravitón: https://thinkwithwp.com/pt/ec2/graviton/
Este artículo fue traducido del Blog de AWS en Portugués


Sobre os autores

Márcio Ribeiro es un especialista en la nube y un amante de la infraestructura. Comenzó en 2008 con un enfoque en la infraestructura tradicional y en 2015 migró por completo al mundo de la nube y a las prácticas de DevOps. Actualmente trabaja como gerente de infraestructura en Grupo Boticário.

Thiago Couto es arquitecto de soluciones en AWS y trabaja en el segmento empresarial para ayudar a los clientes minoristas y de bienes de consumo envasados en sus viajes a la nube. Tiene más de 10 años de experiencia trabajando en arquitecturas que abarcan AI/ML, integraciones, IoT y correlaciones.