Infraestructura técnica de UvinumEvolución, estado actual, alta disponibilidad y próximos pasos

@obokaman

Érase una vez, en 2009…

Un único servidor (para atraerlos a todos y atarlos en las tinieblas…)

Todos los servicios en una misma máquina. (Pocos inicialmente. LAMP. Period.)

Todos los servicios instalados y configurados manualmente

Deploy “manual” mediante GIT

…

Érase una vez, en 2009…

Un único servidor (para atraerlos a todos y atarlos en las tinieblas…)

Todos los servicios en una misma máquina. (Pocos inicialmente. LAMP. Period.)

Todos los servicios instalados y configurados manualmente

Deploy “manual” mediante GIT

…

Los primeros años de Uvinum

Durante los primeros años trabajamos en desarrollo con una combinación de máquinas virtuales gestionadas manualmente con VirtualBox + Verdot (Mac Mini) & Pinot (DELL)

Crecimiento exponencial de tráfico (requests) y, sobretodo, de volumen de datos a tratar.

Añadimos algún servidor adicional, y repartimos (que no replicamos) servicios > Carga más repartida, pero seguimos teniendo puntos únicos de fallo.

Introducimos algunos servicios que nos “facilitan la vida”: Beanstalk para gestionar los repositorios y los deploys (actual Deploybot), S3 almacenamiento de archivos estáticos, Sendgrid para el envío de emails transaccionales…

Monitorizamos errores manualmente (a través del parsing de logs), y el sistema a nivel de servidores (ServerDensity). No disponemos de monitorización a nivel de aplicación.

Algunos experimentos con “Real Cloud” de Dinahosting (Juniper)

Infraestructura pre 2013

Mejoras introducidas

Mejor entorno de desarrollo: Adoptamos Vagrant como herramienta para gestionar nuestras máquinas virtuales de desarrollo. Nuevos flujos de trabajo en lo que se refiere al control de versiones: git-flow

Reparto y externalización de responsabilidades: separación gestión de versiones (Github) y automatización del deploy (Gigas VPS + Deploybot), assets y estáticos para la mejora de la velocidad y tiempos de respuesta (MaxCDN / Cloudfront), ejecución microservicio crawlings / Marawler en DigitalOcean, introducción de colas (Beanstalkd) para la gestión de tareas secuenciales, gestión centralizada de sesiones (Redis), replicación de lectura de MySQL

Mejoras en el control de errores y la monitorización del sistema: pasamos de monitorizar únicamente los servidores a nivel rendimiento, CPU, RAM, disco, MySQL… a monitorizar en detalle el comportamiento de la aplicación (New Relic), incluyendo tests end-to-end con Synthetics. Sumamos múltiples servicios de monitorización desde el pto. de vista de cliente final: Montastic + Alerts NR + PingDom + Monitis. Integramos servicio de alertas por SMS con Pagerduty (alertas de pagos).

App Server

Data Server

Cloud Storage

CDN

CI server

Offer crawlers

…

App server: - Dell PowerEdge R420 - 2x2xE5-2440(sixcore) 2,40 Ghz - 64GB RAM

Data server: - Dell PowerEdge R420 - 2x2xE5-2440(sixcore) 2,40 Ghz - 64GB RAM

CI server: - VPS con Centos 6 + Plesk 11 - 4 cores AMD - 4GB RAM

Offer crawlers (2,n…): - Instancias Cloud con Centos6 - 2 cores AMD - 2GB RAM

Infraestructura 2013-2016

ClientesOficinas

Backend

Push Github

Marketplace

Estáticos y multimedia

Problemas detectados

Múltiples responsabilidades por máquina: aún y con cierta “especialización” en cada servidor, al encontrarse ambas máquinas ofreciendo múltiples servicios (servidor web, php, mysql, memcache, sphinx…) algunos de los cuales compiten por el mismo tipo de recursos, en ocasiones es complicado optimizar la configuración y óptimo funcionamiento de cada uno de ello. También se dificulta la depuración de errores en busca de cuellos de botella por cuestiones de rendimiento.

Puntos únicos de error: algunos de los servicios se encuentran replicados en ambos servidores, pero no están balanceados, de forma que un problema de disponibilidad en alguno de ellos provocaría una pérdida temporal de servicio, obligando a una actuación manual para la reposición del mismo, apuntando de uno a otro servidor, teniendo que promover la réplica a master en el caso de MySQL, o llevando a cabo cambios de DNS en el caso de los servidores web.

Pruebas fallidas

Durante este tiempo hicimos un primer intento de migración a un servicio de hosting “gestionado”

Máquinas virtualizadas. Debian. Infraestructura administrada 100% por una empresa externa

Carencias importantes en cuanto a la optimización de la configuración de los servicios. No pudimos cumplir ninguno de los 3 KPI principales que nos marcamos: tiempo de generación medio de página, tiempo medio de respuesta a cliente, tiempos de respuesta registrados en Google Webmaster Tools.

MySQL 1

Cloud Storage CDN

Infraestructura actual

ClientesOficinas

Frontal 1 Frontal 2Backend 1

MySQL 2 Sphinx 1 Sphinx 2

Balanceador

CI server

Offer crawlers

…

Push Github

Backend

Marketplace

Estáticos y multimedia

Backend 2

Balanceador en reserva

Frontal 3 Frontal 4

Mejoras introducidas

Réplica y balanceo de todos los servicios: Disponemos de 2 nodos físicos que replican todos los servicios: servidores web, bases de datos, motores de búsqueda, etc. Se balancea la carga de los servicios. Se eliminan las operaciones manuales a realizar en caso de fallo de algunos servicios (balanceadores, servidores web, motores de búsqueda…) y se minimizan para los servicios más críticos (MySQL, promoción slave > master)

Virtualización + automatización de operaciones de instalación y mantenimiento: La nueva plataforma trabaja con máquinas virtuales (VMWare sobre VSphere) sobre los dos nodos físicos que hemos contratado. Esto nos ofrece una flexibilidad que antes era impensable y mejora la portabilidad de los servicios (posibildad de snapshots, por ejemplo). La automatización de la instalación y mantenimiento de los servidores mediante Ansible nos permite mantener más fácilmente la consistencia entre el entorno de desarrollo y el de producción.

Posibilidad de continuar escalando horizontalmente la plataforma: Con la nueva configuración es posible añadir nuevos nodos físicos a la infraestructura y replicar la distribución de servicios de los existentes, incrementando de esta forma la capacidad de la plataforma sin que esto suponga un incremento en la complejidad de la misma o mayor trabajo de mantenimiento.

Escalado vertical VS horizontal

Escalado horizontal

Consistencia: Todos los nodos deben ver la misma información.

Disponibilidad: Garantizar que cada petición a un nodo reciba información sobre si ha sido resuelta satisfactoriamente.

Tolerancia al particionado: El sistema puede seguir funcionando aunque uno de los nodos falle

Nuevos retos

Optimización de los recursos en un entorno virtual: Se introducen algunas particularidades relacionadas con la virtualización en cuanto a la optimización de los recursos que no son obvias ni aplicables en el caso de servidores físicos. P.e.: mejor rendimiento con máquinas virtuales más pequeñas, de un sólo procesador. Overhead por la gestión dinámica de la capacidad de proceso en VM +1 CPU.

Optimización del uso de la red: Las máquinas virtuales pueden conectar con otras VM que pueden estar en el mismo nodo físico o no. Hemos preparado la configuración para tener esto en cuenta y que crimen las conexiones entre los servicios disponibles en el mismo nodo, si están disponibles. De esta forma favorecemos las conexiones de red “virtuales” VS las “físicas”, evitando tráfico innecesario entre ambos nodos.

Next steps

Infraestructura inmutable: “Server configuration is a one-off event when a server is first provisioned. After that the configuration is never updated — the only thing that changes on the server is application data. When the configuration needs to change, the server is discarded and replaced with another freshly built one.” Podríamos conseguirlo con algunos pequeños cambios en el proceso de puesta en marcha de nuevos nodos.

Automatización total frente a fallos del sistema: Promoción de los slave a master, puesta en marcha y reemplazo automático de VMs problemáticas, provisional de IPs dentro del rango correspondiente a cada servicio…