PRIVALIA (VEEPEE)

Privalia va néixer a Barcelona en 2006 de la  mà de Lucas Carné i José Manuel Villanueva. El seu model de negoci era molt clar: oferir primeres marques a preus exclusius als seus clients a través del comerç electrònic. En aquella època, poques empreses havien fet el salt a la venda de moda tèxtil per Internet, així que suposava tant una oportunitat com un risc. El seu creixement exponencial i la seva estratègia els ha convertit en un referent del sector i els ha valgut diversos guardons com el Website de l’Any (2012, 2013 i 2016), la Millor Webshop Mobile en els eCommAwards (2014) i el Premi CRC Or a l’Excel·lència en Atenció al client en la categoria Ecommerce, entre altres.

Des de 2016 Privalia pertany al grup francès Vente-Privée (ara Veepee), creadora i líder mundial del concepte de vendes flaix. Actualment, Veepee és un ecommerce multisectorial (que ofereix des de moda fins a tecnologia) amb més de 66 milions d’usuaris registrats a tot el món i té presència en 10 països.

El projecte

L’any 2018 Privalia va decidir posar en producció un servei de marketplace per a la web d’Espanya en el Cloud, en aquest cas utilitzant els serveis oferts per AWS. Per a això, va confiar una vegada més en el nostre equip de sistemes (Infrastructure), amb el qual porta treballant des de 2013.

L’objectiu principal era el d’optimitzar les instàncies que donaven servei a aquest nou website, perquè per a mitigar l’impacte inicial de la posada en producció es van sobredimensionar els diferents microserveis que la componen.

Per a minimitzar riscos, el projecte es va desenvolupar en diferents fases:

Estudi de la infraestructura:

El primer pas va ser comprovar si tots els serveis que Privalia tenia desplegats en AWS estaven sent utilitzats o no. És una comprovació que ha de fer-se tant en Cloud com On Premise i que permetrà reduir costos en la plataforma.

El control dels microserveis recau sobre el departament de desenvolupament, que és el coneixedor de les dependències de l’aplicació. Vam realitzar un inventari de màquines i bases de dades de tots els entorns, perquè desenvolupament validés els serveis que havíem de mantenir o no.  

Amb aquest coneixement, passem a una segona fase: analitzar l’ús de recursos de les EC2 (Elastic Compute Cloud) i RDS (Relational Database Service) per a ajustar el tipus d’instància.

Anàlisi de la monitorització:

L’equip d’infraestructura es va servir de Cloudwatch, l’eina de monitoratge de AWS, per a realitzar una presa de dades bàsiques de les instàncies com són CPU, IOPs de Disc i Xarxa.

Per als serveis que tenen un ús intensiu de RAM, com podrien ser aplicacions a Java, realitzem una anàlisi més concreta accedint a les instàncies. Totes aquestes dades els obtenim accedint a AWS via AWS CLI (Command Line Interface) i bolcant les dades en arxius CSV per al seu posterior tractament.

Amb totes aquestes dades sabrem el consum que tenen els microserveis i podrem ajustar el tipus d’instància.

Modificació de la infraestructura:

Una vegada analitzat el consum real dels serveis i sabent els requeriments o ús del servei, modifiquem les receptes de deployment d’infraestructura. Concretament, modifiquem el nombre d’instàncies MIN / MAX / DESIRED dels autoescaling de AWS i el tipus d’instància dels Launch Configuration per un més ben dimensionat.

Finalment, llancem la pipeline de deploy per a aplicar els canvis en la infraestructura.

Test i control:

Com el canvi que s’ha realitzat és únicament d’infraestructura i no de codi, en els dies posteriors al canvi, llancem de nou els scripts d’anàlisis de CPU i monitoring que s’havien llançat en primer lloc. Això ens va permetre saber si el dimensionament que havíem realitzat sobre les màquines era correcte o no.

Després de la modificació de les intancias i la capacitat MIN/MAX/DESIRED, monitorem el comportament dels ASG (Acte Scaling Groups). Amb aquestes mètriques, veiem si amb el mateix volum de trànsit, ha estat necessari augmentar la capacitat de nodes d’aplicació, la capacitat mitjana i si en algun moment ha arribat al màxim establert. A més, analitzant aquesta informació podrem ajustar de nou, si fos necessari, els paràmetres d’instància o capacitat del servei.

Beneficis obtinguts

El principal benefici obtingut després del projecte, tal com s’ha comentat anteriorment, és la reducció de costos en els comptes de AWS.

Els scripts realitzats per a obtenir mètriques de les màquines ens ajudaran a fer una tasca constant de millora en la infraestructura. Després de cada deploy es pot analitzar el rendiment de les aplicacions i reajustar els recursos de les màquines que siguin necessaris. D’aquesta manera, ens assegurem de pagar per uns recursos que no estan sent utilitzats.

Descobreix més sobre Privalia.