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

1. WP Hiperescala
//CloudMas/Efraim_Martinez/Cloud_Transformation_Director
Page 1Monday, 27 March 2017

2. Page 2
@cloudmas
@arspermeable
#eShowBCN17
Monday, 27 March 2017

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. 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. ¿Qué es WordPress?
(porque a lo mejor, alguien no sabe qué es wordpress)
Page 5Monday, 27 March 2017

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. WP en Amazon Web Services
Page 7Monday, 27 March 2017

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. 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. La versión más simple de WP en AWS
Esquema de la arquitectura
Page 10Monday, 27 March 2017

11. Mejorando las prestaciones de WP en AWS
Page 11Monday, 27 March 2017

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. 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. 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. 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. Esquema de una arquitectura WP
Optimizado con CDN y caché
Page 16Monday, 27 March 2017

17. Mejorando la fiabilidad y escalabilidad
de WP con Amazon Web Services
Page 17Monday, 27 March 2017

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. 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. 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. 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. 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. Esquema de una arquitectura WP
con capas web+db separadas
Page 23Monday, 27 March 2017

24. Y ahora, todo junto: WP Hiperescala
Page 24Monday, 27 March 2017

25. Esquema de una arquitectura WP Hiperescala
Page 25Monday, 27 March 2017

26. Lo que ha quedado
pendiente
Monday, 27 March 2017 Page 26Page 26

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. Servicios AWS
usados en esta
arquitectura
Page 28Page 28Monday, 27 March 2017

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. @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. Page 31Monday, 27 March 2017