Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (9)
Similar a PHP Conference Argentina 2014
Similar a PHP Conference Argentina 2014 (20)
Último
Último (20)
PHP Conference Argentina 2014
- 1. Infraestructura para un proyecto de gran porte Noviembre 2014
- 2. Andrés Montañez @andres_montanez Rodrigo Mendez @menrod Alejandro Glejberman @aglejberman @aciliainternet
- 3. Introducción ■ Sobre el proyecto ■ Infraestructura de servidores ■ Software y servicios utilizados ■ Desafíos ■ Conclusiones
- 4. El Proyecto
- 5. Punto de Partida ■ Migración a una nueva plataforma ■ Tráfico heredado ■ En caso de error… no rollback ■ Contenido Editorial ■ Manejador de contenido ■ Sitios web ■ Multi país/región
- 6. Situación inicial ■ ¿Que debemos soportar inicialmente? ■ Aplicaciones “legacy”: LAMP ■ Una nueva aplicación en Symfony 2 ■ Otras aplicaciones web y mobile en el futuro ■ ¿Con que recursos empezamos? ■ Balanceador CISCO ACE ■ Ocho servidores
- 7. Los Fierros
- 8. Balanceo de tráfico ■ Opciones ■ Round Robin en DNS ■ Heart Beat ■ Load Balancer ■ Cisco ACE ■ Único punto de acceso a las aplicaciones ■ ¡Es hardware dedicado! ■ Deriva todo el tráfico a los servidores Varnish ■ Permite escalar horizontalmente el cache
- 9. Receta clásica: LAMP ■ Tenemos dos servidores de Frontend ■ ¡Hagamos todo LAMP! ■ Pero... ■ Aplicaciones incompatibles (módulos, versiones) ■ Necesitamos redundancia ■ ¿Cómo solucionamos? ■ ¡Virtualizamos todo!
- 10. Frontends Virtualizados ■ ¿Qué logramos virtualizando? ■ Aislamos las diferentes aplicaciones ■ Logramos redundancia ■ Distribución de recursos y tráfico ■ Servicio de virtualización: KVM ■ Ventaja: funciona… ■ Desventaja: …pero no tan bien
- 11. Backends ■ Bases de Datos ■ MySQL ■ MongoDB ■ Gestión de Contenidos ■ Feeds de uso externo ■ Apps ■ Integradores ■ Scripts de mantenimiento
- 12. Media ■ Varios TeraBytes de assets ■ Web Server ■ Nginx ■ Optimizado para statics ■ PHP-FPM (imágenes “on the fly”) ■ Montado en Backends y Frontends ■ Origen de los CDNs
- 14. Desafíos
- 15. Entornos de Trabajo Pero en local me funciona… ■ Ambientes de staging ■ Entornos por aplicación ■ Entornos por issue ■ Control de Versiones
- 16. Deployment ¿Cómo subimos a producción? ■ Magallanes ■ Peticiones de Deployment ■ Deploy Master ■ ¡Los viernes no se hace deploy!
- 17. Performance y Cache ¿Cómo mejoramos la performance? ■ Varnish ■ Memcached ■ Sesiones de PHP ■ Fragment Cache
- 18. SSL ¿Cómo usamos HTTPs con una sola IP? ■ Varnish no soporta HTTPs ■ Son varios certificados SSL ■ Solución… Pound
- 19. Búsquedas ¿Aparece algo si busco “собака сплетник”? ■ Más de 30 idiomas ■ Incluyendo Chino, Ruso, Griego, Turco… ■ Solucionamos con… Sphinx
- 20. DELETE FROM … Oops! Backups ■ Control de Versiones en Git ■ Respaldo y Réplicas de Bases de Datos ■ Respaldo de Assets ■ Respaldo de código no versionado
- 21. Monitoreo ¿Te levanta el sitio? ■ Testing Unitario y Funcional ■ Integración Continua ■ Monitoreo permanente ■ Guardia 24x7
- 22. Moraleja
- 23. Situación Actual ✓ Servidores: 13 ✓ Máquinas virtuales: 24 ✓ Aplicaciones: 7 y sumando ✓ Sitios: +120 ✓ Feeds: +10 ✓ Visitas únicas: +7 millones por mes ✓ Líneas de PHP: ~500.000 made in Acilia
- 24. ¿Qué nos ha dejado la experiencia? “Una infraestructura a medida para cada aplicación” – La virtualización rinde “¡En PHP 5.4 tenemos traits!” – Beneficios de estar actualizados “Desarrollar para el problema y no para el proyecto” – Acilia Components
- 26. Enlaces Acilia Internet @aciliaInternet Andrés Montañez @andres_montanez Rodrigo Mendez @menrod Alejandro Glejberman @aglejberman Varnish Pound Sphinx OSSEC rdiff-backup Magallanes
Notas del editor
- Vamos a contar nuestra experiencia de haber llevado adelante un proyecto de gran porte utilizando PHP en combinación con otras tecnologías. Nosotros somos: Andrés: Más de una década desarrollando en PHP. Creador de la herramienta de deployment Magallanes. Jugador de rol (a la Dungeons & Dragons). Cinéfilo. Uruguayo que no toma mate. Rodrigo: Puede trabajar con cualquier Linux siempre y cuando use KDE, Programador Macho, vi es su entorno de desarrollo. Uruguayo que solo toma mate. Alejandro: 10 años con php y con symfony desde la versión 1.0, futbolista frustrado devenido en ingenerio en computación. Acilia: Es una empresa de software, ubicada en Madrid y Montevideo. Realizamos proyectos de Internet, web y móvil. Trabajamos con una amplia gama de tecnologías, pero nos apoyamos mucho en PHP / Symfony.
- Vamos a presentar la definición de la arquitectura de servidores, la definición de la infraestructura y el hardware utilizado, sin ahondar en detalle. Mostraremos la combinación de software elegido para las distintas soluciones que implementamos. Es una forma de implementar, no la única. Nos encargamos de todo el ecosistema. Desde el desarrollo hasta el mantenimiento, pasando por servidores y monitoreo.
- Migración de una arquitectura previa, tanto en software como en hardware (vencimiento de licencias???) Una refactorización dónde se ve todo igual DNS TTL Tráfico heredado: la aplicación ya contaba con bastante tráfico, había que mantenerlo No había margen para “crecer de a poco” Contenido editorial: noticias, artículos, competiciones, usuarios
- Servidores: Dos servidores de Varnish (cache) Dos servidores de Frontend (vms / apps) Dos servidores de Backend (cms) Un servidor de Media (assets) Un servidor de Staging Nota 1: Porque 8? tuvimos la posibilidad de elegir la cantidad de servidores, el cliente estaba de acuerdo. Nota 2: Explicar la terminología y en que servicios consiste cada uno Nota 3: Porque no 2 de media? Por akamai. Nota 4: Servicios grandes: Front y Back, por la redundancia se requieren 2 de cada uno, asi que 4 minimo. Se necesitaba una capa de cache, por lo cual si queriamos cumplir con la redundancia ibamos a necesitar 2 más, ahi van 6. Esto toma el 75% de los servidores iniciales: 8. Un numero considerable para una aplicación que recién comenzaba.
- Servidores Varnish son la primer línea de defensa de las aplicaciones (conexión entre Balanceador y Varnish) Explicar que es el balanceador, en terminos fisicos (hardware). Que otras opciones hay? Round robin en DNS, pero da problemas si uno de los puntos de acceso se cae. HeartBeat, en el proveedor actual no podemos mover las IPs publicas. Explicar los falsos positivos. Problemas de colocation, etc. Ventajas? Facilita la administración de los dominios Desventajas? Tener un único punto de acceso es útil de forma administrativa, pero problemático cuando falla, por ejemplo por algún switch en mal estado (son problemas atípicos).
- Incompatibilidad: Las aplicaciones legacy y la nueva en Symfony2 no son compatibles en el mismo entorno. Cada aplicacion requiere de distinta configuración en apache, distintas versiones de PHP Cada aplicacion necesita modulos especiales Configuraciones de Varnish distintas para cada app Hay que cumplir todos estos requisitos, solo con dos servidores y sin perder la redundancia. Nota 1: Más adelante veremos la toma de decisión sobre como determinamos que servicios/software utilizar.
- Virtualizamos los servidores de frontend Aislamos aplicaciones, configuraciones independientes y tuneadas Cada aplicación puede tener asignada la cantidad de recursos que necesite en cada momento. Cada aplicacion puede tener la configuracion especifica que se requiera. VMWare Qué problemas tiene kvm? Debido al poco tiempo de pruebas, decidimos utilizar KVM. Hoy, tres años más tarde, estamos comenzando un proceso evaluativo y progresivo de mover estas VMs a una solución co-gestionada en VMWare.
- En los backends tenemos todos los gestores de contenido, los CMS. El código está hecho en Zend Framework (requerimiento del cliente) y se ejecuta en una arquitectura LAMP clássica. También tenemos las bases de datos, todas MySQL, aunque para algunos proyectos también tenemos MongoDB. Las bases no tienen redundancia pero si están replicadas –topología master-slave– que podemos usar en caso de que ocurra algún problema. Los Feeds son una parte importante de la plataforma pero que pasa desapercibida. Son usados por terceras partes, aplicaciones móviles, integradores de contenidos, etc. Desde los backends también ejecutamos scripts de mantenimiento, se realizan procesos de reducción de datos, integración con servicios externos, procesado de videos, etc.
- Contamos con muchos assets, varios TeraBytes de imágenes que deben ser gestionados, y para eso contamos con un servidor dedicado. Utilizamos Nginx para el servicio web por su alta eficiencia para entregar contenido estático, como es el caso. Además contamos con una instancia de PHP para recortar imágenes a demanda, tamaños que no estén previstos en el CMS pero que quizá lo requieran otras aplicaciones externas. El “storage” de media se encuentra montado en cada Backend via NFS, así desde el CMS se puede subir assets al servidor sin mayor inconveniente. Por el contrario, cuando necesitamos subir imagenes desde los frontends, por ejemplo avatares o imagenes de concursos, desde la aplicacion hacemos un “upload” interno, que es recibido por un PHP que valida el payload. Esto lo hacemos para no tener el servidor montado en cada frontend, las principales razones son: seguridad y practicidad. En varios casos, por delante de este servidor hay un servicio de CDN transparente, para optimizar los tiempos de descarga desde los usuarios. Este servidor se accede desde un punto de entrada distinto al balanceador.
- El balanceador de carga en primera línea, que envía todo el tráfico a los varnish. En los backends tenemos las correspondientes bases de datos, CMSs y motores de búsqueda, además de ser desde donde se realizan tareas de mantenimiento. Un servidor de Media donde están los assets “grandes”. Este servidor se accede por fuera del balanceador de carga, en algunos casos por via de CDN. Esto probó ser útil para no saturar el tráfico del balanceador de carga (anécdota The Walking Dead). *** Sistema Operativo Ubuntu Web Server Apache para manejadores de contenido Nginx (PHP-FPM) para frontends PHP lo más actualizado posible Base de datos MySQL MongoDB
- Tenemos un servidor dedicado a entornos de pruebas y demostraciones, donde el cliente puede entrar y validar el desarrollo, revisarlo, cambiarlo, y finalmente aprobarlo antes de subirlo a producción. Esto es un punto vital y clave. A su vez, muchas veces necesitamos un ambiente extra, ya sea por un desarrollo en paralelo (en otra rama) o excluyente con otro. En estos casos resolvemos de forma muy simple, creamos un entorno nuevo (macros de Apache). Ahora bien, toda esta colaboración y trabajo en equipo descentralizado lo podemos hacer gracias a que trabajamos bajo control de versiones, en nuestro caso usamos Git via GitHub.
- Anécdota que se pisaron los deploys!! En el entorno web los cambios son algo de todos los días, y cuando somos varios trabajando es facil perder el control de lo que está en producción. Para tener orden es que realizamos peticiones de deployment. Indicando que aplicación queremos publicar y el motivo del mismo. A su vez, las tandas de deployment se realizan una vez al día de lunes a jueves. ¿Por qué no los viernes? Simple, porque el sábado y domingo no hay soporte por si el cliente quiere cambiar algo deployado el viernes. Para repartir las responsabilidades del deployment es que tenemos el rol del Deploy Master, es un miembro del equipo que se responsabiliza de los deployments durante toda la semana, este rol rota entre todo el equipo. Estas aplicaciones requieren tareas especiales en el deployment más allá de copiar el código. Hay que crear enlaces simbólicos, limpiar y generar caches, habilitar configuraciones, etc. Para esto, usamos la herramienta Magallanes que nos permite realizar estas tareas y crear propias, sin salirnos de PHP.
- La performance es uno de los puntos clave y con que más cuidado debemos tener A nivel de código de PHP y de framework son varios los puntos a mejorar de performance, pero no los únicos El cache es nuestra primera defensa. Varnish permite cachear de forma independiente assets (media, js, css, etc), HTML, o incluso fragmentos de HTML. No solo cacheamos la “web”. Sino también todo lo que usa la aplicacion. Como ser configuraciones, traducciones, resolución de redirecciones, fragmentos de HTML. Casi todo está en memcache. Así como Varnish cachea la parte de “afuera” de la web; hemos desarrollado un componente llamado FragmentCache que nos permite cachear renders (subrequests) de Symfony. Esto ha probado ser muy útil, particularmente en sitios con muchos modulos. Experiencia de Usuario
- El cliente requiere que en algunos sitios haya protección via SSL Tenemos sola una IP de acceso, por lo cual presenta un problema para definir los certificados A su vez Varnish no implementa SSL Utilizamos en los mismos servidores de Varnish el servicio Pound, que actúa como un proxy reverso… Al cual le podemos definir todos los certificados SSL y cuando llega un request HTTPs intenta desencriptarlo probando con todos los certificados hasta dar con el correcto… Y saber hacia donde redirigir el request. Es una solución que funciona, a expensa de recursos ya que debe probar varios certificados antes de dar con el correcto.
- En todos los sitios la búsqueda es una funcionalidad imprescindible Debemos hacerla eficiente, ya que se buscan varios modelos de datos (artículos, videos, biografías) Contemplar que tenemos más de 30 idiomas en lenguas muy extrañas, o al menos dispares entre sí Con Sphinx pudimos abarcar todas los requerimientos, sin perder performance. Nos permite buscar sobre diversos tipos de datos y aplicar reglas de orden Se integra muy bien con PHP
- Tener una política de backups es muy importante. ¡No hace falta justificar por qué! El código de los proyectos lo versionamos en Git, via GitHub. Eso ya es un respaldo en sí mismo. Las bases de datos están replicadas y además se realizan dumps de las bases de producción a cada hora. También se realizan dumps diarios y mensuales de todas las bases de datos de la infraestructura (incluyendo las de producción). Los assets (imágenes) se respaldan en un servidor aparte. Existe código no versionado, de aplicaciones del cliente no gestionadas por nosotros, que se respaldan de forma diaria con rdiff-backup. Hemos verificado satisfactoriamente el recuperar información desde todos estos backups.
- El mejor problema es aquél que pudimos prevenir. Por ello hacemos aplicamos testing unitario y funcional Además realizamos integración continua que verifica que las funcionalidades más críticas no se rompan En cada push se lanzan tests y en caso de que alguno falle nos llega una notificación Esto es sumamente útil en los Feeds, que no son fáciles de verificar Pero si lo anterior falla, tenemos un monitoreo permanente en la plataforma. Utilizamos Pingdom, Nagios, OSSEC y scripts propios que nos alertan de si un servicio está dando problemas Además contamos con Cacti para tener el histórico del rendimiento de los servidores Por último, le ofrecemos al cliente un servicio de Guardia 24x7, por si ocurre un problema grave. Pero “grave” con G mayúscula.
- De aquella infraestructura de 8 servidores, algunas aplicaciones legacy y una aplicación symfony en desarrollo… Es que llegamos hoy a 13 servidores físicos con más de 24 máquinas virtuales… Que hostean 7 aplicaciones symfony2, no contamos las legacy Que se reparten en más de 120 sitios y más de 10 feeds para aplicaciones móviles e integradores Servimos en promedio más de 7 millones de visitas únicas por mes Que ejecutan alrededor de 500.000 líneas de código PHP escritas en Acilia Las perspectivas son de crecimiento y de desafíos aún más interesantes
- La virtualización nos ha rendido muy bien Actualmente estamos pasando a VMWare para simplificar la gestión y crecer en ese aspecto. Lo primero y más importante que nos ha dejado la experiencia… Es una enorme satisfacción, de realización, superación y objetivos y metas logradas Mantener todo actualizado ha resultado una buena práctica a mediano plazo Desde servidores y servicios, hasta las versiones de PHP y Symfony. ¡Incluyendo a nosotros mismos! Además, estamos desarrollando en componentes, para reutilizar en nuestros proyectos. De esta forma logramos desarrollar más rápido y mejor. El concepto de base es pensar en una solución para el problema abstracto y no para el problema del proyecto.