Hoy vamos a hablar sobre las recomendaciones de AWS para implementar WordPress en tu cloud. AWS nos ofrece una multitud de soluciones según el entorno que necesitemos implementar. En la mayoría de los casos, querremos implementar este conocido CMS aprovechando las soluciones ofrecidas por AWS en términos de escalabilidad y flexibilidad, y una de las muchas recomendaciones es usar Elastic File System (EFS) como sistema de almacenamiento. Refiriéndonos a este punto, hay una conferencia ofrecida en AWS Reinvent of 2017 por uno de los arquitectos de soluciones de AWS en la que hacen un pequeño laboratorio que implementa WordPress en un entorno escalable con alta disponibilidad.
AWS re:Invent 2017: Learn to Build a Cloud-Scale WordPress Site That Can Keep Up wit (STG324)
Después de ver lo que nos dice AWS, tenemos claro que el esquema para implementar un entorno «ideal» con WordPress en la nube debería ser algo así.
Ahora que hemos entendido esto, pasemos a la práctica real. Tenemos que migrar un cliente de un proveedor que es cloud a AWS. Este cliente tiene un entorno simple, pero bastante voluminoso, ya que la migración implica mover más de 50 wordpress al mismo servidor y pasar de un entorno completamente monolítico a un entorno escalable, flexible y elástico para resolver problemas de rendimiento e intentar ofrecer un mejor servicio a sus clientes, así como la facilidad de poder hacer crecer la plataforma fácilmente si es necesario.
En una primera fase, decidimos hacer una primera migración en 5 sitios web. A partir de este momento comienzan los problemas.
Por nuestra parte, definimos una arquitectura basada en un sistema de autoescalado con el cual, estas instancias serán las que ejecuten el código web contenido en un volumen EFS compartido con las zonas de disponibilidad donde se encuentran nuestras instancias.
Una vez implementado, realizamos algunas pruebas de rendimiento y … mala señal, el tiempo hasta el primer byte es de más de 35 segundos. Ok, podría ser nuestra culpa, así que vamos a usar Cloudfront como caché y CDN para optimizar los tiempos de carga … Implementamos distribuciones de Cloudfront y obtuvimos una mejora «brutal» del rendimiento, ahora el tiempo para el primer byte es en promedio 30 segundos. Decepcionante. Aquí podemos ver una tabla con el supuesto rendimiento de EFS:
| File System Size (GiB) | Baseline Aggregate Throughput (MiB/s) | Burst Aggregate Throughput (MiB/s) | Maximum Burst Duration (Min/Day) | % of Time File System Can Burst (Per Day) |
|---|---|---|---|---|
| 10 | 0.5 | 100 | 7.2 | 0.5% |
| 256 | 12.5 | 100 | 180 | 12.5% |
| 512 | 25.0 | 100 | 360 | 25.0% |
| 1024 | 50.0 | 100 | 720 | 50.0% |
| 1536 | 75.0 | 150 | 720 | 50.0% |
| 2048 | 100.0 | 200 | 720 | 50.0% |
| 3072 | 150.0 | 300 | 720 | 50.0% |
| 4096 | 200.0 | 400 | 720 | 50.0% |
Después de esto, decidimos habilitar OPCache, así que recuerde, tenemos WordPress ejecutándose en varias instancias de un grupo de escalado automático con OPCache y almacenamiento en caché de Cloudfront y con el código en un volumen compartido EFS. Ahora el tiempo para el primer byte es de aproximadamente 20 segundos cuando se solicita el archivo y no está en la caché.
En este punto, creemos que el problema es que EFS puede necesitar aprovisionamiento, lo cual hicimos y no mejoramos nada … Estábamos en una encrucijada, ya que habíamos seguido todas las recomendaciones de Amazon y no habíamos mejorado la plataforma del cliente, pero en cambio había empeorado. Analizamos la situación a fondo y llevamos a cabo un número infinito de pruebas para llegar a la conclusión de que EFS no es eficiente cuando se trabaja con miles de archivos pequeños, porque la velocidad de acceso o lectura de estos archivos es muy pequeña.
Finalmente, decidimos prescindir de EFS y configurar nuestro propio servidor NFS en EC2 utilizándolo de la misma manera que usamos EFS. Allí se almacenó el código del wordpress y este se sirve a las instancias de autoescalado que es quien las ejecuta. Sorprendentemente con este cambio, el tiempo hasta el primer byte se ha convertido en menos de 1 segundo.
En conclusión, y como opinión personal, EFS podría ser útil en algunos contextos, en nuestro caso particular no nos ha ofrecido el rendimiento que necesitábamos y tuvimos que prescindir de él. Con esto, aprovechamos para comentar que desde Geko analizamos las necesidades de nuestros clientes desde todos los puntos de vista posibles para ofrecer las mejores soluciones y las que mejor se adaptan a sus necesidades.
Si tiene alguna sugerencia o desea contactarnos, puede hacerlo a través del correo electrónico info@geko.cloud
Estaremos encantados de saber de ti. Y no olvides, ¡Feel the Geko Way! 🙂