Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Nivel de web sin estado
Para aprovechar los múltiples servidores web en una configuración de escalado automático, su nivel web debe ser sin estado. Una aplicación sin estado es aquella que no necesita conocer las interacciones anteriores y no almacena información de sesión. En este caso WordPress, esto significa que todos los usuarios finales reciben la misma respuesta, independientemente del servidor web que haya procesado su solicitud. Una aplicación sin estado puede escalarse horizontalmente, ya que cualquier solicitud puede ser atendida por cualquiera de los recursos informáticos disponibles (es decir, instancias de servidores web). Cuando esa capacidad ya no sea necesaria, se puede cerrar cualquier recurso individual de forma segura (una vez agotadas las tareas en ejecución). No es necesario que esos recursos sean conscientes de la presencia de sus homólogos; lo único que se necesita es una forma de distribuirles la carga de trabajo.
En lo que respecta al almacenamiento de los datos de las sesiones de los usuarios, el WordPress núcleo carece completamente de estado porque depende de las cookies que se almacenan en el navegador web del cliente. El almacenamiento de las sesiones no es un problema, a menos que hayas instalado un código personalizado (por ejemplo, un WordPress complemento) que, en cambio, se base en PHP sesiones nativas.
Sin embargo, WordPress se diseñó originalmente para ejecutarse en un único servidor. Como resultado, almacena algunos datos en el sistema de archivos local del servidor. Cuando se ejecuta WordPress en una configuración de varios servidores, esto crea un problema porque hay incoherencia entre los servidores web. Por ejemplo, si un usuario carga una imagen nueva, solo se almacena en uno de los servidores.
Esto demuestra por qué necesitamos mejorar la configuración de WordPress ejecución predeterminada para mover los datos importantes al almacenamiento compartido. La arquitectura de mejores prácticas tiene una base de datos como capa independiente fuera del servidor web y utiliza el almacenamiento compartido para almacenar las subidas por los usuarios, los temas y los complementos.
# Almacenamiento compartido (Amazon S3 y AmazonEFS)
De forma predeterminada, WordPress almacena las cargas de los usuarios en el sistema de archivos local y, por lo tanto, no es apátrida. Por lo tanto, debemos trasladar la WordPress instalación y todas las personalizaciones de los usuarios (como la configuración, los complementos, los temas y las subidas generadas por los usuarios) a una plataforma de datos compartida para reducir la carga en los servidores web y hacer que el nivel web no tenga estado.
[Amazon Elastic File System](https://aws.amazon.com/efs/details/) (AmazonEFS) proporciona sistemas de archivos de red escalables para su uso con EC2 instancias. Los sistemas de EFS archivos de Amazon se distribuyen en un número ilimitado de servidores de almacenamiento, lo que permite que los sistemas de archivos crezcan de forma elástica y permite el acceso masivo en paralelo desde las instancias. EC2 El diseño distribuido de Amazon EFS evita los cuellos de botella y las limitaciones inherentes a los servidores de archivos tradicionales.
Al mover todo el directorio de WordPress instalación a un sistema de EFS archivos y montarlo en cada una de las EC2 instancias al arrancar, el WordPress sitio y todos sus datos se almacenan automáticamente en un sistema de archivos distribuido que no depende de ninguna EC2 instancia, lo que hace que su capa web quede completamente sin estado. La ventaja de esta arquitectura es que no es necesario instalar complementos ni temas cada vez que se lanza una nueva instancia, y permite acelerar considerablemente la instalación y la recuperación de las WordPress instancias. También es más fácil implementar los cambios en los complementos y los temas WordPress, tal y como se describe en la sección [Consideraciones de implementación](appendix-a-cloudfront-configuration.md) de este documento.
Para garantizar un rendimiento óptimo de su sitio web cuando se ejecuta desde un sistema de EFS archivos, compruebe los ajustes de configuración recomendados para Amazon EFS y OPcache en la [arquitectura de AWS referencia](https://github.com/awslabs/aws-refarch-wordpress#opcache) de WordPress.
También tienes la opción de descargar todos los activos estáticos, como las imágenes y los JavaScript archivosCSS, a un bucket de S3 con el almacenamiento en CloudFront caché por delante. El mecanismo para hacerlo en una arquitectura de varios servidores es exactamente el mismo que en una arquitectura de un solo servidor, tal como se explica en la sección [Contenido estático](accelerating-content-delivery.md) de este documento técnico. Los beneficios son los mismos que en la arquitectura de un solo servidor: puede delegar el trabajo asociado con el servicio de sus activos estáticos a Amazon S3 y CloudFront, por lo tanto, permitir que sus servidores web se centren únicamente en generar contenido dinámico y atender más solicitudes de usuario por servidor web.
# Nivel de datos (Amazon Aurora y Amazon ElastiCache)
Con la WordPress instalación almacenada en un sistema de archivos de red distribuido, escalable y compartido y los activos estáticos servidos desde Amazon S3, puede centrar su atención en el componente con estado restante: la base de datos. Al igual que ocurre con el nivel de almacenamiento, la base de datos no debe depender de un único servidor, por lo que no puede alojarse en uno de los servidores web. En su lugar, aloje la WordPress base de datos en Amazon Aurora.
[Amazon Aurora](https://aws.amazon.com/rds/aurora) es una base de datos relacional compatible con My SQL y Postgre, SQL compatible con My Postgre, diseñada para la nube, compatible con My My Postgre y Postgre, compatible con My Postgre y Postgre, diseñada para la nube. Aurora My SQL aumenta el SQL rendimiento y la disponibilidad de My gracias a la estrecha integración del motor de base de datos con un sistema de almacenamiento distribuido diseñado específicamente para My My, respaldado por. SSD Es tolerante a errores y se recupera automáticamente, replica seis copias de los datos en tres zonas de disponibilidad, está diseñado para ofrecer una disponibilidad superior al 99,99% y realiza copias de seguridad continuas de los datos en Amazon S3. Amazon Aurora está diseñado para detectar automáticamente los bloqueos de las bases de datos y se reinicia sin necesidad de realizar recuperaciones tras bloqueos ni de recompilar la caché de la base de datos.
Amazon Aurora ofrece varios [tipos de instancias](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html) que se adaptan a diferentes perfiles de aplicaciones, incluidas las instancias optimizadas para memoria y las que se pueden reproducir en ráfagas. Para mejorar el rendimiento de la base de datos, puede seleccionar un tipo de instancia grande para proporcionar más CPU recursos de memoria.
Amazon Aurora administra automáticamente la conmutación por error entre la instancia principal y las [réplicas de Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Replication.html) para que sus aplicaciones puedan reanudar las operaciones de la base de datos lo antes posible sin intervención administrativa manual. La conmutación por error suele tardar menos de 30 segundos.
Después de crear al menos una réplica de Aurora, conéctese a la instancia principal mediante el punto de enlace del clúster para permitir que la aplicación realice automáticamente la conmutación por error en caso de que la instancia principal falle. Puede crear hasta 15 réplicas de lectura de baja latencia en tres zonas de disponibilidad.
A medida que la base de datos se amplíe, la caché de la base de datos también necesitará ampliarse. Como se explicó anteriormente en la sección [Almacenamiento en caché de bases](database-caching.md) de datos, ElastiCache cuenta con funciones para escalar la memoria caché entre varios nodos de un ElastiCache clúster y entre varias zonas de disponibilidad de una región para mejorar la disponibilidad. A medida que amplíe el ElastiCache clúster, asegúrese de configurar el complemento de almacenamiento en caché para que se conecte mediante el punto final de configuración, de modo que WordPress pueda utilizar los nuevos nodos del clúster a medida que se vayan añadiendo y dejar de utilizar los nodos de clúster antiguos a medida que se eliminen. También debes configurar tus servidores web para que usen el [cliente de ElastiCache clúster PHP y actualizarlos AMI para](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/Appendix.PHPAutoDiscoverySetup.html) almacenar este cambio.