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á. # Implantação elástica Implantação elástica Há muitos cenários em que a implantação de um único servidor pode não ser suficiente para seu site. Nessas situações, você precisa de uma arquitetura escalável com vários servidores. **Topics** + [ # Arquitetura de referência ](reference-architecture.md) + [ # Dimensionando a camada da web ](scaling-the-web-tier.md) + [ # Nível de web sem estado ](stateless-web-tier.md) # Arquitetura de referência Arquitetura de referência A [arquitetura de AWS referência Hosting WordPress on](https://github.com/awslabs/aws-refarch-wordpress), disponível em, GitHub descreve as melhores práticas para implantação WordPress AWS e inclui um conjunto de AWS CloudFormation modelos para que você comece a trabalhar rapidamente. A arquitetura a seguir é baseada nessa arquitetura de referência. O restante desta seção analisará os motivos por trás das escolhas arquitetônicas. A base AMI no GitHub foi alterada de Amazon Linux1 para Amazon Linux2 em julho de 2021. No entanto, os modelos de implantação no S3 ainda não foram alterados. É recomendável usar modelos em GitHub se houver um problema para implantar a arquitetura de referência com modelos no S3. ![\[Arquitetura de referência para hospedagem WordPress em AWS\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/best-practices-wordpress/images/image4.png) *Arquitetura de referência para hospedagem WordPress em AWS* **Componentes da arquitetura** A arquitetura de referência ilustra uma implementação completa de melhores práticas para um WordPress site emAWS. + Tudo começa com o cache de borda na **Amazon CloudFront** (1) para armazenar o conteúdo em cache perto dos usuários finais para uma **** entrega mais rápida. + CloudFront extrai conteúdo estático de um **bucket do S3** (2) e conteúdo dinâmico de um **Application Load** Balancer (4) na frente das instâncias da web. + As instâncias da web são executadas em um **grupo Auto Scaling de EC2** **instâncias** **da Amazon** (6). + Um ** ElastiCache **cluster (7) armazena em cache os dados consultados com frequência para **** acelerar as respostas. Uma SQL instância **do Amazon Aurora** My (8) hospeda o WordPress banco de dados. + As WordPress EC2 instâncias acessam WordPress dados compartilhados em um sistema de EFS arquivos **da Amazon** por meio de um **EFSMount Target** (9) em cada zona de disponibilidade. + Um **Internet Gateway** (3) permite a comunicação entre seus recursos VPC e a Internet. + **NATOs gateways** (5) em cada zona de disponibilidade permitem que EC2 instâncias em sub-redes privadas (aplicativo e dados) acessem a Internet. ****Na **Amazon**, VPC existem dois tipos de sub-redes: pública (sub-rede pública) e privada (**sub-rede** do **aplicativo e sub-rede** de dados).**** Os recursos implantados nas sub-redes públicas receberão um endereço IP público e ficarão visíveis publicamente na Internet. O **Application Load Balancer** (4) e um host Bastion para administração são implantados aqui. Os recursos implantados nas sub-redes privadas recebem somente um endereço IP privado e, portanto, não são visíveis publicamente na Internet, melhorando a segurança desses recursos. As **instâncias do servidor WordPress ** **web** (6), as **instâncias ElastiCache do cluster** (7), as **instâncias do Aurora My SQL Database** (8) e o **EFSMount Targets** (9) são todas implantadas em sub-redes privadas. O restante desta seção aborda cada uma dessas considerações com mais detalhes. # Dimensionando a camada da web Dimensionando a camada da web Para transformar sua arquitetura de servidor único em uma arquitetura escalável de vários servidores, você deve usar cinco componentes principais: + EC2Instâncias da Amazon + Imagens de máquina da Amazon (AMIs) + Balanceadores de cargas + Escalabilidade automática + Verificações de integridade AWSfornece uma ampla variedade de tipos de EC2 instância para que você possa escolher a melhor configuração de servidor em termos de desempenho e custo. De um modo geral, o tipo de instância otimizada para computação (por exemplo, C4) pode ser uma boa opção para um WordPress servidor web. Você pode implantar suas instâncias em várias zonas de disponibilidade em uma AWS região para aumentar a confiabilidade da arquitetura geral. Como você tem controle total da sua EC2 instância, você pode fazer login com acesso root para instalar e configurar todos os componentes de software necessários para executar um WordPress site. Depois de terminar, você pode salvar essa configuração como umaAMI, que poderá ser usada para executar novas instâncias com todas as personalizações que você fez. Para distribuir as solicitações do usuário final para vários nós do servidor web, você precisa de uma solução de balanceamento de carga. AWSfornece essa capacidade por meio do [Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/), um serviço altamente disponível que distribui tráfego para várias instâncias. EC2 Como seu site está veiculando conteúdo para seus usuários por meio de HTTP ouHTTPS, recomendamos que você use o Application Load Balancer, um balanceador de carga da camada de aplicativo com roteamento de conteúdo e a capacidade de executar vários WordPress sites em domínios diferentes, se necessário. O Elastic Load Balancing suporta a distribuição de solicitações em várias zonas de disponibilidade em uma AWS região. Você também pode configurar uma verificação de integridade para que o Application Load Balancer pare automaticamente de enviar tráfego para instâncias individuais que falharam (por exemplo, devido a um problema de hardware ou de software). AWSrecomenda usar a página de login do WordPress administrador (`/wp-login.php`) para a verificação de integridade, pois essa página confirma que o servidor da Web está em execução e que o servidor da Web está configurado para servir PHP os arquivos corretamente. Você pode optar por criar uma página de verificação de integridade personalizada que verifique outros recursos dependentes, como recursos de banco de dados e cache. *Para obter mais informações, consulte [Verificações de saúde para seus grupos-alvo](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html) no *Application Load Balancer Guide*.* A elasticidade é uma característica fundamental da AWS nuvem. Você pode lançar mais capacidade computacional (por exemplo, servidores web) quando precisar e executar menos quando não precisar. [O Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) é um AWS serviço que ajuda você a automatizar esse provisionamento para aumentar ou diminuir a EC2 capacidade da Amazon de acordo com as condições definidas por você, sem a necessidade de intervenção manual. Você pode configurar o Amazon EC2 Auto Scaling para que o número de EC2 instâncias que você está usando aumente perfeitamente durante os picos de demanda para manter o desempenho e diminua automaticamente quando o tráfego diminuir, a fim de minimizar os custos. O Elastic Load Balancing também oferece suporte à adição e remoção dinâmicas de EC2 hosts da Amazon da rotação de balanceamento de carga. O próprio Elastic Load Balancing também aumenta e diminui dinamicamente a capacidade de balanceamento de carga para se ajustar às demandas de tráfego sem intervenção manual. # Nível de web sem estado 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 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 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.