PRIVALIA (VEEPEE)

Privalia nació en Barcelona en 2006 de la  mano de Lucas Carné y José Manuel Villanueva. Su modelo de negocio estaba muy claro: ofrecer primeras marcas a precios exclusivos a sus clientes a través del comercio electrónico. En aquella época, pocas empresas habían dado el salto a la venta de moda textil por Internet, así que suponía tanto una oportuinidad como un riesgo. Su crecimiento exponencial y su estrategia les ha convertido en un referente del sector y les ha valido diversos galardones como el Website del Año (2012, 2013 y 2016) y la Mejor Webshop Mobile en los eCommAwards (2014) y el Premio CRC Oro a la Excelencia en Atención al cliente en la categoría Ecommerce, entre otros.

Desde 2016 Privalia pertenece al grupo francés Vente-Privée (ahora llamado Veepee), creadora y líder mundial del concepto de ventas flash. Actualmente, Veepee es un ecommerce multisectorial (que ofrece desde moda hasta tecnología) con más de 66 millones de usuarios registrados en todo el mundo y tiene presencia en 10 países.

El proyecto

En el año 2018 Privalia decidió poner en producción un servicio de marketplace para la web de España en el Cloud, en este caso utilizando los servicios ofrecidos por AWS. Para ello, confió una vez más en nuestro equipo de sistemas (Infrastructure), con el que lleva trabajando desde 2013.

El objetivo principal era el de optimizar las instancias que daban servicio a este nuevo website, pues para mitigar el impacto inicial de la puesta en producción se sobredimensionaron los diferentes microservicios que la componen. 

Para minimizar riesgos, el proyecto se desarrolló en distintas fases:

Estudio de la infraestructura:

El primer paso fue comprobar si todos los servicios que Privalia tenía desplegados en AWS estaban siendo utilizados o no. Es una comprobación que debe hacerse tanto en Cloud como On Premise y que permitirá reducir costes en la plataforma.

El control de los microservicios recae sobre el departamento de desarrollo, que es el conocedor de las dependencias de la aplicación. Realizamos un inventario de máquinas y bases de datos de todos los entornos, para que desarrollo validara los servicios que debíamos mantener o no.  

Con este conocimiento, pasamos a una segunda fase: analizar el uso de recursos de las EC2 (Elastic Compute Cloud) y RDS (Relational Database Service) para ajustar el tipo de instancia.

Análisis de la monitorización:

El equipo de infraestructura se sirvió de Cloudwatch, la herramienta de monitorización de AWS, para realizar una toma de datos básicos de las instancias como son CPU, IOPs de Disco y Red.

Para los servicios que tienen un uso intensivo de RAM, como podrían ser aplicaciones en Java, realizamos un análisis más concreto accediendo a las instancias. Todos estos datos los obtenemos accediendo a AWS vía AWS CLI (Command Line Interface) y volcando los datos en archivos CSV para su posterior tratamiento.

Con todos estos datos sabremos el consumo que tienen los microservicios y podremos ajustar el tipo de instancia.

Modificación de la infraestructura:

Una vez analizado el consumo real de los servicios y sabiendo los requerimientos o uso del servicio, modificamos las recetas de deployment de infraestructura. Concretamente, modificamos el número de instancias MIN / MAX / DESIRED de los autoescaling de AWS y el tipo de instancia de los Launch Configuration por uno mejor dimensionado.

Por último, lanzamos la pipeline de deploy para aplicar los cambios en la infraestructura.

Testeo y control:

Como el cambio que se ha realizado es únicamente de infraestructura y no de código, en los días posteriores al cambio, lanzamos de nuevo los scripts de análisis de CPU y monitoring que se habían lanzado en primer lugar. Esto nos permitió saber si el dimensionamiento que habíamos realizado sobre las máquinas era correcto o no.  

Tras la modificación de las intancias y la capacidad MIN/MAX/DESIRED, monitorizamos el comportamiento de los ASG (Auto Scaling Groups). Con estas métricas, vemos si con el mismo volumen de tráfico, ha sido necesario aumentar la capacidad de nodos de aplicación, la capacidad media y si en algún momento ha llegado al máximo establecido. Además, analizando esta información podremos ajustar de nuevo, si fuera necesario, los parámetros de instancia o capacidad del servicio.

Beneficios obtenidos

El principal beneficio obtenido tras el proyecto, tal como se ha comentado anteriormente, es la reducción de costes en las cuentas de AWS.

Los scripts realizados para obtener métricas de las máquinas nos ayudarán a realizar una tarea constante de mejora en la infraestructura. Después de cada deploy se puede analizar el rendimiento de las aplicaciones y reajustar los recursos de las máquinas que sean necesarios. De esta manera, nos aseguramos de pagar por unos recursos que no están siendo utilizados.

Descubre más sobre Privalia.