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.

eShow Barcelona - WordPress Hiperescala

303 views

Published on

Cómo conseguir un WordPress completamente resistente a fallos y con capacidad de hiperescalar utilizando las herramientas Cloud de Amazon Web Services.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

eShow Barcelona - WordPress Hiperescala

  1. 1. WP Hiperescala //CloudMas/Efraim_Martinez/Cloud_Transformation_Director Page 1Monday, 27 March 2017
  2. 2. Page 2 @cloudmas @arspermeable #eShowBCN17 Monday, 27 March 2017
  3. 3. ¿Por qué un seminario sobre WP hiperescala?  Un CMS muy usado y útil para servicios de todos los tamaños  Una herramienta simple, facilita ver cómo encaja cada pieza y las ventajas que generan  El proceso se puede repetir para otras soluciones  Mapea una transformación a la nube tal y como CloudMas la plantea a sus clientes: Experimentar, mejorar, ampliar Monday, 27 March 2017 Page 3
  4. 4. Vayamos por partes…  El WordPress más simple en AWS…  … con algunas pequeñas mejoras en rendimiento y fiabilidad  Mejorar el rendimiento y prestaciones en Cloud  CloudFront como red de entrega de contenidos  ElastiCache para almacenamiento temporal de la base de datos  Mejorar la fiabilidad y escalabilidad en Cloud  Separar la capa de web y datos en WordPress  Escalado automático y resistencia a fallos de cada capa  De aquí en adelante…  Aspectos de la arquitectura que quedan pendientes Page 4Monday, 27 March 2017
  5. 5. ¿Qué es WordPress? (porque a lo mejor, alguien no sabe qué es wordpress) Page 5Monday, 27 March 2017
  6. 6. ¿Qué es wordpress?  La primera versión se lanza en 2003, como un motor de blogs de software libre (FOSS = Open Source)  2003: Se crea WordPress como un fork de B2 Cafelog  2003: Sistema de plugins, extiende funcionalidad  2005: Sistema de temas y págs estáticas, extiende visualización  2007: Nuevo UI para el backend, UX completamente rediseñada  2010: Nueva gestión de menús y tipos de posts personalizados  Actualmente es uno de los CMS más populares  27% de los sitios web del mundo usan WordPress  También es un ecosistema de desarrollo,  Cientos de miles de desarrolladores Page 6Monday, 27 March 2017
  7. 7. WP en Amazon Web Services Page 7Monday, 27 March 2017
  8. 8. La versión más simple de WP en AWS  Utilizamos EC2 para instalar una pila LAMP + WP  LAMP = Linux + Apache + MySQL + PHP  ¿Qué máquina utilizar?  Depende de la carga estimada (CPU/mem/disk/network)  Para una instancia independiente, T2 ó M3 puede ser suficiente  Si necesita escalar, hay que parar la máquina y cambiar el tipo  ¿Qué imagen utilizar? (AMI))  La imagen básica de Amazon Linux es suficiente  Hay imágenes en el Marketplace con todo lo necesario preinstalado  Se puede crear una AMI tras la instalación y configuración Page 8Monday, 27 March 2017
  9. 9. La versión más simple de WP en AWS Ventajas e inconvenientes  Ventajas  Control total sobre la arquitectura (versiones, configuración…)  Inconvenientes  Todos los elementos de la pila se instalan, configuran y mantienen manualmente (aunque parte se puede automatizar)  Menor escalabilidad, que además requiere interrupción de servicio Page 9Monday, 27 March 2017
  10. 10. La versión más simple de WP en AWS Esquema de la arquitectura Page 10Monday, 27 March 2017
  11. 11. Mejorando las prestaciones de WP en AWS Page 11Monday, 27 March 2017
  12. 12. Utilizando Amazon CloudFront (CDN) con WP  CloudFront es un servicio de CDN gestionado por Amazon  El usuario realiza la petición a CloudFront  CloudFront sirve el contenido desde una ubicación de límite (edge)  Si no dispone del contenido, lo recupera desde un origen, y lo almacena temporalmente siguiendo las políticas fijadas  Las siguientes consultas se sirven desde el “edge”  Con algunos servicios adicionales  Posibilidad de incluir servicios de WAF  Cachés intermedias de contenidos  Amazon Lambda at the edge Page 12Monday, 27 March 2017
  13. 13. Amazon CloudFront con Contenido Estático  Contenido estático WordPress: CSS, javascript y media  ¿Dónde almacenar los contenidos estáticos?  Servidor web  Bucket S3 de altísima fiabilidad (11-9 durabilidad, 5-9 acceso)  Integración de WordPress con S3  WordPress no se integra directamente con S3  La integración es sencilla, manual o con plugin (ej. W3 Total Cache)  Esta configuración libera carga de los servidores EC2 y convierte WordPress en completamente stateless Page 13Monday, 27 March 2017
  14. 14. Amazon CloudFront con Contenido Dinámico  Contenido dinámico WordPress: HTML generado por los scripts PHP del servidor WP  También se puede servir vía CloudFront  Aegurar se que CloudFront reenvía al servidor las cabeceras HTTP y las cookies necesarias para generar el contenido adecuado  En este caso, el origen de datos de CloudFront es la instancia EC2 en la que está alojada el servidor WordPress Page 14Monday, 27 March 2017
  15. 15. Caché de contenido de las bases de datos  Wordpress no cachea de forma nativa y por defecto el contenido de la base de datos  Sin embargo, mediante plugins, es sencillo integrar WordPress con Memcached, un sistema de cacheo en memoria  Amazon ElastiCache es un servicio de caché en memoria gestionado compatible con Memcached, de alta disponibilidad al poder utilizar varias zonas de disponibilidad  El mismo plugin W3 Total Cache puede realizar esta integración Page 15Monday, 27 March 2017
  16. 16. Esquema de una arquitectura WP Optimizado con CDN y caché Page 16Monday, 27 March 2017
  17. 17. Mejorando la fiabilidad y escalabilidad de WP con Amazon Web Services Page 17Monday, 27 March 2017
  18. 18. Dividir Wordpress en tiers: Web + Base de datos  Los tiers web y de base de datos tienen requerimientos muy diferentes que pueden optimizarse con familias AWS  C4 (optimizada para computación) es una mejor opción para web  R3 (optimizada para memoria) es mejor opción para bbdd  Con esta arquitectura, es sencillo introducir una base de datos gestionada de AWS  Amazon RDS MySQL  Amazon Aurora Page 18Monday, 27 March 2017
  19. 19. Escalando el Tier de Datos: Múltiples Zonas de Disponibilidad  Mejorar la disponibilidad: Amazon RDS MultiAZ  Copia réplica esclava que aumenta la fiabilidad del sistema  En caso de error, la copia esclava toma el servicio tras un failover  Cada copia deberá estar en una zona de disponibilidad diferente  Escalando el tier de datos  En caso de requerir más potencia en la base de datos se puede utilizar una instancia mayor o bien utilizar IOPS provisionados.  Mejorar el rendimiento: Amazon RDS con Read Replica  Mejora el acceso para lectura  En caso de problema, el failover a la copia de lectura es manual  WordPress no utiliza múltiples bases de datos por defecto, se requiere el uso de un plugin específico Page 19Monday, 27 March 2017
  20. 20. Escalabilidad y disponibilidad del tier de datos: Amazon Aurora  Amazon Aurora es un motor de base de datos compatible con MySQL y Posgress  Aúna el concepto de copia de lectura y escritura  Posibilidad de hasta 15 réplicas  Proporciona un end-point para escritura y otro para lectura únicos  A través de estos end-points se consigue escalabilidad y fiabilidad simultáneamente Page 20Monday, 27 March 2017
  21. 21. Escalabilidad y disponibilidad del tier Web: Grupos de autoescalado y balanceo de carga  La infraestructura de AWS es elástica  No es necesario provisionar para los picos de carga  Grupos de autoescalado  Pueden lanzarse o pararse nuevas instancias en función de la carga  Las instancias se lanzan en diferentes zonas de disponibilidad  Balanceador de carga (ELB)  Servicio gestionado de Amazon  Punto de entrada a un grupo de autoescalado  Detecta instancias que no pueden dar servicio y dejar de enviar peticiones a estas Page 21Monday, 27 March 2017
  22. 22. Aplicaciones stateless y WordPress  Para que los grupos de autoescalado y el balanceador de carga funcionen, la aplicación web tiene que ser stateless  No puede depender de información almacenada localmente para persistir sesiones HTTP  O bien almacena en el cliente (cookies)  O bien en algún tipo de almacenamiento persistente (BBDD)  Por suerte, WordPress es completamente stateless  (a menos que se utilice algún plugin que use sesiones nativas PHP)  Para UGC – multimedia (uploads), no  Se requiere sincronizar con almacenamiento compartido o almacenar en S3 (manualmente o con plugin) Page 22Monday, 27 March 2017
  23. 23. Esquema de una arquitectura WP con capas web+db separadas Page 23Monday, 27 March 2017
  24. 24. Y ahora, todo junto: WP Hiperescala Page 24Monday, 27 March 2017
  25. 25. Esquema de una arquitectura WP Hiperescala Page 25Monday, 27 March 2017
  26. 26. Lo que ha quedado pendiente Monday, 27 March 2017 Page 26Page 26
  27. 27. Cosas que han quedado fuera de alcance…  Métodos de backup y restore de las máquinas  Securización y bastionado de toda la plataforma  Wordpress  MySQL  Servidores  Redes  Consolidación y monitorización de logs de la plataforma  Entornos de pre-producción y staging Page 27Monday, 27 March 2017
  28. 28. Servicios AWS usados en esta arquitectura Page 28Page 28Monday, 27 March 2017
  29. 29. Servicios utilizados a lo largo de la construcción de una arquitectura para WP  Elastic Load Balancer (ELB)  AutoScaling Groups  Elastic Compute Cloud (EC2)  Elastic Block Storage (EBS)  Simple Storage Services (S3)  Amazon ElastiCache  Amazon RDS  Amazon Aurora  Amazon Route 53  Amazon Elastic IP  Amazon VPC (Virtual Private Cloud)  Security Groups  Network ACLs  Amazon CloudFront Page 29Monday, 27 March 2017
  30. 30. @cloudmas – Stand #48  Quiere migrar a Cloud un servicio IT  Su IT tradicional no sirve para sus nuevos proyectos de negocio  Quiere transformar su infraestructura IT para que sea más ágil, rápida y eficiente Acérquese y comparta su proyecto con uno de nuestros técnicos. Page 30Monday, 27 March 2017
  31. 31. Page 31Monday, 27 March 2017

×