As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Nível de web sem estado
Para tirar proveito de vários servidores web em uma configuração de escalabilidade automática, sua camada da web deve ser sem estado. Um aplicativo sem estado é aquele que não precisa conhecer interações anteriores e não armazena informações da sessão. No caso de WordPress, isso significa que todos os usuários finais recebem a mesma resposta, independentemente de qual servidor web processou sua solicitação. Um aplicativo sem estado pode ser escalado horizontalmente, pois qualquer solicitação pode ser atendida por qualquer um dos recursos computacionais disponíveis (ou seja, instâncias do servidor web). Quando essa capacidade não é mais necessária, qualquer recurso individual pode ser encerrado com segurança (após o esgotamento das tarefas em execução). Esses recursos não precisam estar cientes da presença de seus colegas — tudo o que é necessário é uma forma de distribuir a carga de trabalho para eles.
Quando se trata de armazenamento de dados da sessão do usuário, o WordPress núcleo é completamente sem estado porque depende de cookies armazenados no navegador da web do cliente. O armazenamento de sessões não é uma preocupação, a menos que você tenha instalado algum código personalizado (por exemplo, um WordPress plug-in) que, em vez disso, dependa de PHP sessões nativas.
No entanto, WordPress foi originalmente projetado para ser executado em um único servidor. Como resultado, ele armazena alguns dados no sistema de arquivos local do servidor. Quando executado WordPress em uma configuração de vários servidores, isso cria um problema porque há inconsistência entre os servidores da Web. Por exemplo, se um usuário fizer upload de uma nova imagem, ela será armazenada somente em um dos servidores.
Isso demonstra por que precisamos melhorar a configuração de WordPress execução padrão para mover dados importantes para o armazenamento compartilhado. A arquitetura de melhores práticas tem um banco de dados como uma camada separada fora do servidor web e faz uso do armazenamento compartilhado para armazenar uploads, temas e plug-ins do usuário.
# Armazenamento compartilhado (Amazon S3 e Amazon) EFS
Por padrão, WordPress armazena os carregamentos do usuário no sistema de arquivos local e, portanto, não é apátrida. Portanto, precisamos mover a WordPress instalação e todas as personalizações do usuário (como configuração, plug-ins, temas e uploads gerados pelo usuário) para uma plataforma de dados compartilhada para ajudar a reduzir a carga nos servidores da Web e tornar a camada da Web sem estado.
[O Amazon Elastic File System](https://aws.amazon.com/efs/details/) (AmazonEFS) fornece sistemas de arquivos de rede escaláveis para uso com EC2 instâncias. Os sistemas de EFS arquivos da Amazon são distribuídos em um número irrestrito de servidores de armazenamento, permitindo que os sistemas de arquivos cresçam de forma elástica e permitindo acesso paralelo massivo a partir de instâncias. EC2 O design distribuído da Amazon EFS evita os gargalos e restrições inerentes aos servidores de arquivos tradicionais.
Ao mover todo o diretório de WordPress instalação para um sistema de EFS arquivos e montá-lo em cada uma de suas EC2 instâncias quando elas são inicializadas, seu WordPress site e todos os seus dados são armazenados automaticamente em um sistema de arquivos distribuído que não depende de nenhuma EC2 instância, tornando sua camada da web completamente sem estado. A vantagem dessa arquitetura é que você não precisa instalar plug-ins e temas em cada nova inicialização de instância e pode acelerar significativamente a instalação e a recuperação de WordPress instâncias. Também é mais fácil implantar alterações em plug-ins e temas WordPress, conforme descrito na seção [Considerações de implantação](appendix-a-cloudfront-configuration.md) deste documento.
Para garantir o desempenho ideal do seu site ao ser executado a partir de um sistema de EFS arquivos, verifique as configurações recomendadas para a Amazon EFS e OPcache na [arquitetura de AWS referência para WordPress](https://github.com/awslabs/aws-refarch-wordpress#opcache).
Você também tem a opção de descarregar todos os ativos estáticos, como imagens e JavaScript arquivosCSS, em um bucket do S3 com armazenamento em CloudFront cache na frente. O mecanismo para fazer isso em uma arquitetura de vários servidores é exatamente o mesmo de uma arquitetura de servidor único, conforme discutido na seção [Conteúdo estático](accelerating-content-delivery.md) deste whitepaper. Os benefícios são os mesmos da arquitetura de servidor único — você pode transferir o trabalho associado ao serviço de seus ativos estáticos para o Amazon S3 e CloudFront, assim, permitir que seus servidores web se concentrem apenas em gerar conteúdo dinâmico e atendam a mais solicitações de usuários por servidor web.
# Nível de dados (Amazon Aurora e Amazon) ElastiCache
Com a WordPress instalação armazenada em um sistema de arquivos de rede distribuído, escalável e compartilhado e os ativos estáticos sendo servidos pelo Amazon S3, você pode focar sua atenção no componente de estado restante: o banco de dados. Assim como no nível de armazenamento, o banco de dados não deve depender de um único servidor, portanto, não pode ser hospedado em um dos servidores web. Em vez disso, hospede o WordPress banco de dados no Amazon Aurora.
[O Amazon Aurora](https://aws.amazon.com/rds/aurora) é um banco de dados relacional SQL compatível com o My SQL e o Postgre, criado para a nuvem, que combina o desempenho e a disponibilidade de bancos de dados comerciais avançados com a simplicidade e a economia de bancos de dados de código aberto. O Aurora My SQL aumenta o SQL desempenho e a disponibilidade do My integrando totalmente o mecanismo de banco de dados a um sistema de armazenamento distribuído específico, com o respaldo de. SSD Ele é tolerante a falhas e se recupera automaticamente, replica seis cópias de seus dados em três zonas de disponibilidade, foi projetado para oferecer mais de 99,99% de disponibilidade e faz backup contínuo de seus dados no Amazon S3. O Amazon Aurora foi projetado para detectar falhas no banco de dados e reiniciá-lo automaticamente sem necessidade de recuperação de pane nem de recriar o cache do banco de dados.
O Amazon Aurora fornece vários [tipos de instâncias](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html) para se adequar a diferentes perfis de aplicativos, incluindo instâncias com capacidade de intermitência e otimizadas para memória. Para melhorar o desempenho do seu banco de dados, você pode selecionar um tipo de instância grande para fornecer mais CPU recursos de memória.
O Amazon Aurora processa o failover automaticamente entre a instância primária e as [réplicas do Aurora para que seus aplicativos possam retomar as](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Replication.html) operações de banco de dados o mais rápido possível e sem intervenção administrativa manual. O failover normalmente leva menos de 30 segundos.
Depois de criar pelo menos uma réplica do Aurora, conecte-se à sua instância primária usando o endpoint do cluster para permitir que seu aplicativo faça o failover automático caso a instância primária falhe. Você pode criar até quinze réplicas de leitura de baixa latência em três zonas de disponibilidade.
À medida que seu banco de dados é dimensionado, o cache do banco de dados também precisará ser escalado. Conforme discutido anteriormente na seção [Cache de banco](database-caching.md) de dados, ElastiCache tem recursos para escalar o cache em vários nós em um ElastiCache cluster e em várias zonas de disponibilidade em uma região para melhorar a disponibilidade. Ao escalar seu ElastiCache cluster, certifique-se de configurar seu plug-in de cache para se conectar usando o endpoint de configuração para que ele WordPress possa usar novos nós de cluster à medida que são adicionados e parar de usar nós de cluster antigos à medida que são removidos. Você também deve configurar seus servidores web para usar o [ElastiCacheCluster Client PHP](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/Appendix.PHPAutoDiscoverySetup.html) e atualizá-lo AMI para armazenar essa alteração.