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

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.

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.

• 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:

• 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ó :

Fase 2: Migración de Elasticache a Graviton

• 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.

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:

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.