Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Infraestructura técnica de Uvinum

Evolución, estado actual, alta disponibilidad y próximos pasos / puntos de mejora.

Más información sobre la infraestructura actual y la migración que llevamos a cabo en https://uvinum.engineering/historia-de-una-migraci%C3%B3n-26078521811c#.jownvrolr

  • Login to see the comments

Infraestructura técnica de Uvinum

  1. 1. Infraestructura técnica de Uvinum Evolución, estado actual, alta disponibilidad y próximos pasos @obokaman
  2. 2. É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 …
  3. 3. É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 …
  4. 4. 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)
  5. 5. Infraestructura pre 2013
  6. 6. 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).
  7. 7. 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 PushGithub Marketplace Estáticosymultimedia
  8. 8. 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.
  9. 9. 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.
  10. 10. MySQL 1 Cloud Storage CDN Infraestructura actual Clientes Oficinas Frontal 1 Frontal 2Backend 1 MySQL 2 Sphinx 1 Sphinx 2 Balanceador CI server Offer crawlers … PushGithub Backend Marketplace Estáticos y multimedia Backend 2 Balanceador en reserva Frontal 3 Frontal 4
  11. 11. 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.
  12. 12. Escalado vertical VS horizontal
  13. 13. 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
  14. 14. 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.
  15. 15. 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…

×