Arquitectura de sistemas: Escalabilidad y Rendimiento en Communify

Please Networks como factoría digital tiene uno de sus puntos fuertes la creación de plataformas online de alta disponibilidad y escalabilidad.

Uno de los productos propios de Please Networks es Communify, un sistema de plugins que actúa sobre páginas web de terceros. Communify está en un proceso constante de mejora y desarrollo de nuevas funcionalidades. Los ingenieros de Please avanzan la plataforma pensando siempre en un sistema de alto rendimiento, capaz de responder a una gran cantidad de peticiones y de forma no predecible, al ser dependiente de otras páginas web. Un día especial como el resultado de las elecciones de Estados Unidos para los medios de comunicación, un día como el black friday para tiendas online o cualquier campaña de marketing pueden generar altos volúmenes de peticiones y el sistema debe seguir al máximo rendimiento.

 

LA ARQUITECTURA DE SISTEMAS DE COMMUNIFY

 

arquitectura_de_sistemas

 

Toda la infraestructura de Communify, como todos los proyectos de Please Networks, están en Amazon Web Services. En este caso se ha pensado en un sistema muy escalable, que permita separar los distintos puntos críticos y en cada caso tener la libertad de escalar el cuello de botella en un momento dado.

Communify cuenta con una infraestructura para dar servicio a una API y a un conjunto de archivos estáticos que contienen la aplicación JavaScript, estilos, imágenes… El acceso a la API o a estos assets se hace de forma distinta. En el primer lugar accedemos a una balanceador de carga (ELB) y en el segundo caso el acceso se hace mediante nuestro CDN (Cloud Front).

Para el caso de la API el balanceador de carga distribuye las peticiones a través de un conjunto de servidores (instancias EC2) utilizando el Auto Scaling de Amazon. Todos los servidores de esta capa son instancias T2 medium. Actualmente contamos con una instancia 24/7, una segunda que sólo se enciende en horario europeo y cuatro que se levantan en función de las necesidades de carga.

Las peticiones se distribuyen indistintamente a cada una de las máquinas, de modo que para un mismo usuario las llamadas secuenciales a la API no son respuestas por el mismo servidor, podemos darnos con el caso que el servidor que ha respondido la última petición para un usuario a la siguiente llamada ese servidor ya no exista.

A nivel de base de datos, cada cuenta de cliente de Communify cuenta con dos bases de datos distintas, una con la información del modelo y otra para las estadísticas. Cada una de estas base de datos están en servidores distintos, de modo que el rendimiento de una no afecta a la otra y permite un escalado según las necesidades.

La API es la encargada también de insertar los datos estadísticos. En este caso, dado al gran volumen de datos que genera la plataforma, no se insertan directamente, sino que entran en una cola (SQS) para que un servidor independiente las procese e inserte a la base de datos de estadísticas.

Todos los archivos que un usuario de Communify sube a la plataforma no se guardan en los servidores de la API, sino que se utiliza el servicio específico de Amazon (S3). Aquí cada una de las cuentas de Communify cuenta con su espacio. Para acceder a estos archivos, el usuario nunca lo hace directamente a S3, sino que lo hace a través del CDN. Esto es así ya que los tiempos de respuesta de S3 no son suficientes para el uso de Communify.

A partir del mismo CDN con el que se acceden a las imágenes que el usuario sube desde la plataforma también se accede a los archivos JavaScript, CSS y HTML que utiliza nuestra aplicación.

 

LAS MÉTRICAS DE LA API DE COMMUNIFY

El equipo de desarrollo de Please Networks siempre está analizando sus resultados para detectar rápidamente posibles errores, necesidades de escalabilidad, posibles necesidades de cambio… Para ello New Relic es el servicio usado para la monitorización de los servidores.

New Relic nos proporciona un conjunto de datos estadísticos acerca del uso de nuestra API, sus tiempos de respuesta, los volúmenes de peticiones, el análisis interno de uso de recursos para cada una de las llamadas, el rendimiento de la base de datos…

arquitectura_de_sistemas_3

En este post no haremos un análisis exhaustivo del rendimiento de las distintas peticiones, sino una visión general de su rendimiento. Hemos escogido un episodio de 6 horas con un comportamiento normal y sin necesidades especiales de carga.

La primera gráfica nos muestra los tiempos de respuesta, a nivel general, de la API de Communify. Vemos que los tiempos de proceso en el servidor son realmente bajos, 44.7 milisegundos de media. Podemos también analizar el tiempo dedicado a la ejecución de nuestro código en PHP y los tiempos de respuesta de la base de datos (MySQL).

arquitectura_de_sitemas_2  

Esta segunda gráfica nos muestra el número de peticiones por minuto que recibe nuestra API. Este dato se analiza mediante las rpm (request per minute), este valor analiza el número de peticiones realizadas en el espacio de tiempo de un minuto. Por ejemplo si tenemos 60 rpms sería que cada segundo se realiza una petición.

Este episodio no es demasiado grande en volumen de peticiones. Hemos tenido episodios con magnitudes de 3000 rpms en momentos con muchas campañas publicitarias activas. En este episodio vemos como hay el cambio de horario europeo, momento en el que se duplican las peticiones. Si comparamos con los tiempos mostrados antes vemos como se mantienen en la misma magnitud de tiempo en el servidor.

En este punto es curioso comparar ambas gráficas y ver como alrededor del 8 de noviembre a las 23:00 (horario estadounidense) el tiempo de proceso de PHP disminuye en unos 5 milisegundos. Esto es resultado de la ampliación con un segundo servidor al activar el horario europeo. También podemos ver como el tiempo de base de datos aumenta, hecho normal al duplicar las peticiones. En el caso de que el tiempo de base de datos aumentara en exceso, en el episodio se estabiliza al poco tiempo, podríamos escalar solo el servidor RDS con los datos del modelo para volver a los tiempos de respuesta deseados.

 

INTEGRACIÓN CONTINUA, ESTADÍSTICAS Y BIG DATA

 

Tan interesante es saber sobre la infraestructura de una plataforma como el conocimiento sobre sus automatizaciones. Communify cuenta con un sistema de integración continua que permite la actualización de la plataforma, servidores, bases de datos de una forma automática durante el proceso de puesta en producción.

Previo a este proceso, el servidor de integración continua ejecuta todos los tests de validación y prepara la release para actualizar el código en los servidores, la nueva release en el CDN, actualizar el SDK…

En futuros post explicaremos con más detalle nuestro sistema de integración continua y la estructura para servir en tiempo real las estadísticas de la plataforma. Si quieres saber más o te interesa contar con nuestra ayuda para el desarrollo y/o escalabilidad de tu arquitectura de sistemas, no dudes en contarnos tu caso.

Cómo generar más altas a tu programa de fidelización

Jordi Garreta | Captación de Leads

La digitalización del consumidor de hoy y los continuos cambios tecnológicos continúan generando nuevos retos a los retailers y a sus modelos de negocio, pero...

Omnicanalidad: Presente y futuro del Marketing Directo

Jordi Garreta | Omnicanal

En varias ocasiones hemos mencionado que los consumidores están sobrecargados con información y oportunidades, con miles de opciones a su alrededor para poder comprar los...


Latest Posts

Tags

Newsletter

Subscribe to our newsletter for good news, sent out every month.