REL10-BP01 Implantar a workload em vários locais - Framework Well-Architected da AWS
Orientação para implementaçãoRecursos

REL10-BP01 Implantar a workload em vários locais

Distribua os dados e os recursos da workload por várias zonas de disponibilidade ou, quando necessário, por Regiões da AWS. A diversidade dos locais pode variar conforme a necessidade.

Um dos princípios fundamentais do design de serviço na AWS é evitar pontos únicos de falha na infraestrutura física subjacente. Isso nos motiva a criar software e sistemas que usam várias zonas de disponibilidade e são resilientes à falha de uma única zona. De modo similar, os sistemas são criados para serem resilientes à falha de um único nó de computação, volume de armazenamento ou instância de banco de dados. Ao criar um sistema que dependa de componentes redundantes, é importante garantir que os componentes operem de modo independente e, no caso de Regiões da AWS, de modo autônomo. Os benefícios obtidos com cálculos teóricos de disponibilidade com componentes redundantes só serão válidos se isso for verdadeiro.

Zonas de disponibilidade (AZ)

As Regiões da AWS são compostas por várias zonas de disponibilidade projetadas para serem independentes umas das outras. Cada zona de disponibilidade é separada por uma distância física significativa em relação às outras zonas para evitar cenários de falha correlacionados devido a riscos ambientais, como incêndios, enchentes e tornados. Cada zona de disponibilidade tem uma infraestrutura independente: conexões dedicadas à rede elétrica, fontes de alimentação de reserva independentes, serviços mecânicos independentes e conectividade de rede independente dentro e além da zona de disponibilidade. Esse design limita as falhas em qualquer um desses sistemas apenas à AZ afetada. Apesar de serem separadas geograficamente, as zonas de disponibilidade estão localizadas na mesma área regional, o que permite redes de alto throughput e baixa latência. A Região da AWS inteira (em todas as zonas de disponibilidade, consistindo em vários data centers fisicamente independentes) pode ser tratada como um único destino lógico de implantação para sua workload, incluindo a capacidade de replicar dados de forma síncrona (por exemplo, entre bancos de dados). Assim, os clientes podem usar as zonas de disponibilidade em uma configuração ativa/ativa ou ativa/standby.

As zonas de disponibilidade são independentes e, portanto, a disponibilidade da workload aumenta quando ela é projetada para usar várias zonas. Alguns serviços da AWS (incluindo o plano de dados da instância do Amazon EC2) são implantados como serviços estritamente zonais, onde eles têm um destino compartilhado com a zona de disponibilidade como um todo. No entanto, as instâncias do Amazon EC2 nas outras AZs não serão afetadas e continuarão funcionando. Da mesma forma, se uma falha em uma zona de disponibilidade fizer com que um banco de dados Amazon Aurora falhe, uma instância do Aurora de réplica de leitura em uma AZ não afetada pode ser automaticamente promovida para primária. Serviços da AWS regionais, como o Amazon DynamoDB, por outro lado, usam internamente várias zonas de disponibilidade em uma configuração ativa/ativa para atingir as metas de design de disponibilidade desse serviço, sem a necessidade de configurar o posicionamento da AZ.

Diagrama que mostra uma arquitetura multicamada implantada em três zonas de disponibilidade. Observe que o Amazon S3 e o Amazon DynamoDB são sempre Multi-AZ automaticamente. O ELB também é implantado em todas as três zonas.

Figura 9: arquitetura multicamadas implantada em três Zonas de disponibilidade. Observe que o Amazon S3 e o Amazon DynamoDB são sempre Multi-AZ automaticamente. O ELB também é implantado em todas as três zonas.

Embora os planos de controle da AWS costumem permitir o gerenciamento de recursos dentro de toda a região (várias zonas de disponibilidade), determinados ambientes de gerenciamento (incluindo Amazon EC2 e Amazon EBS) podem filtrar os resultados para uma única zona de disponibilidade. Quando isso é feito, a solicitação é processada apenas na zona de disponibilidade especificada, o que reduz a exposição a interrupções em outras zonas de disponibilidade. Este exemplo da AWS CLI ilustra a obtenção de informações de instâncias do Amazon EC2 somente da zona de disponibilidade us-east-2c: 

 AWS ec2 describe-instances --filters Name=availability-zone,Values=us-east-2c

Zonas locais da AWS

As zonas locais da AWS atuam de forma semelhante às respectivas zonas de disponibilidade em suas respectivas regiões da Região da AWS, pois elas podem ser selecionadas como um local de posicionamento para recursos zonais da AWS, como sub-redes e instâncias do EC2. O que as torna especiais é que elas estão localizadas não na região da Região da AWS associada, mas perto de grandes centros populacionais, industriais e de TI onde não existe nenhuma região da Região da AWS atualmente. No entanto, elas ainda mantêm uma conexão segura e de alta largura de banda entre as Workloads locais na zona local e as executadas na Região da AWS. Você deve usar as zonas locais da AWS para implantar as workloads mais perto de seus usuários para requisitos de baixa latência.

Amazon Global Edge Network

A rede de presença global da Amazon consiste em pontos de presença em cidades em todo o mundo. O Amazon CloudFront usa essa rede para entregar conteúdo aos usuários finais com latência mais baixa. AWS O Global Accelerator permite criar endpoints de workload nesses pontos de presença para oferecer integração à rede global da AWS próxima aos usuários. O Amazon API Gateway habilita endpoints de API otimizados para a borda usando uma distribuição do CloudFront para facilitar o acesso do cliente por meio do ponto de presença mais próximo.

Regiões da AWS

As Regiões da AWS foram projetadas para serem autônomas. Portanto, para usar uma abordagem em várias regiões, você pode implantar cópias dedicadas de serviços em cada uma delas.

Uma abordagem multirregiões é comum para que as estratégias de recuperação de desastres atendam aos objetivos de recuperação quando ocorrem eventos pontuais de grande escala. Consulte Plano de recuperação de desastres (DR) para obter mais informações sobre essas estratégias. Aqui, no entanto, focamos a disponibilidade, que busca oferecer um objetivo médio de tempo de atividade ao longo do tempo. Para objetivos de alta disponibilidade, uma arquitetura multirregiões geralmente será projetada para ser ativa/ativa, em que cada cópia do serviço (em suas respectivas regiões) está ativa (atendendo às solicitações).

Recomendação

Os objetivos de confiabilidade para a maioria das workloads pode ser cumprido usando-se uma estratégia Multi-AZ em uma única Região da AWS. Considere arquiteturas multirregiões somente quando as workloads tiverem requisitos extremos de disponibilidade ou outras metas de negócios que exijam uma arquitetura multirregiões.

A AWS fornece a você os recursos para operar serviços em várias regiões. Por exemplo, a AWS fornece replicação contínua e assíncrona de dados usando a replicação do Amazon Simple Storage Service (Amazon S3), réplicas de leitura do Amazon RDS (incluindo réplicas de leitura do Aurora) e tabelas globais do Amazon DynamoDB. Com a replicação contínua, as versões dos seus dados tornam-se disponíveis para uso quase imediato em cada uma das regiões ativas.

Com o AWS CloudFormation, é possível definir sua infraestrutura e implantá-la de forma consistente nas Contas da AWS e nas Regiões da AWS. O AWS CloudFormation StackSets amplia a funcionalidade das pilhas, permitindo que você crie, atualize ou exclua pilhas do AWS CloudFormation em várias contas e regiões com uma única operação. Para implantações de instâncias do Amazon EC2, uma imagem de máquina da Amazon (AMI) é usada para fornecer informações como configuração de hardware e software instalado. Você pode implementar um pipeline do Amazon EC2 Image Builder que cria as AMIs de que você precisa e as copia para suas regiões ativas. Isso garante que essas AMIs de ouro tenham tudo o que você precisa para implantar e escalar sua workload em cada nova região.

Para rotear o tráfego, tanto o Amazon Route 53 quanto o AWS Global Accelerator permitem a definição de políticas que determinam quais usuários vão para qual endpoint regional ativo. Com o Global Accelerator, você define uma discagem de tráfego para controlar a porcentagem de tráfego que é direcionada para cada endpoint da aplicação. O Route 53 oferece suporte a essa abordagem percentual e também várias outras políticas disponíveis, incluindo políticas baseadas em geoproximidade e latência. O Global Accelerator aproveita automaticamente a extensa rede de servidores de borda da AWS para integrar o tráfego ao backbone da rede da AWS o mais rápido possível, resultando em menores latências de solicitação.

Todas essas capacidades operam de forma a preservar a autonomia de cada região. Há muito poucas exceções a essa abordagem, incluindo nossos serviços que fornecem entrega de borda global (como o Amazon CloudFront e o Amazon Route 53), junto com o ambiente de gerenciamento para o serviço do AWS Identity and Access Management (IAM). A grande maioria dos serviços opera inteiramente dentro de uma única região.

Datacenter on-premises

Para workloads executadas em um datacenter on-premises, arquitete uma experiência híbrida quando possível. O AWS Direct Connect fornece uma conexão de rede dedicada entre seu ambiente on-premises e a AWS, permitindo que você trabalhe em ambos.

Outra opção é executar a infraestrutura e os serviços da AWS on premises usando o AWS Outposts. O AWS Outposts é um serviço totalmente gerenciado que estende a infraestrutura da AWS, os serviços da AWS, as APIs e as ferramentas para o seu datacenter. A mesma infraestrutura de hardware usada na Nuvem AWS é instalada no seu datacenter. Os AWS Outposts são então conectados à Região da AWS mais próxima. Em seguida, você pode usar o AWS Outposts para oferecer suporte a workloads com baixa latência ou requisitos de processamento de dados locais.

Nível de risco exposto se esta prática recomendada não for estabelecida: Alto

Orientação para implementação

  • Use várias zonas de disponibilidade e Regiões da AWS. Distribua os dados e os recursos da workload por várias zonas de disponibilidade ou, quando necessário, por Regiões da AWS. A diversidade dos locais pode variar conforme a necessidade.

  • Se a workload precisar ser implantada em várias regiões, escolha uma estratégia multirregiões. A maioria das necessidades de confiabilidade pode ser atendida em uma única Região da AWS por meio de uma estratégia de várias zonas de disponibilidade. Use uma estratégia multirregiões quando necessário para atender às suas demandas de negócios.

  • Avalie o AWS Outposts para sua workload. Se a workload exigir baixa latência do datacenter on-premises ou tiver requisitos de processamento de dados locais. Então execute a infraestrutura e os serviços da AWS on-premises usando o AWS Outposts.

  • Determine se as zonas locais da AWS ajudam você a fornecer serviços aos usuários Se você tiver requisitos de baixa latência, veja se as zonas locais da AWS estão próximas dos seus usuários. Se estiverem, use-as para implantar as workloads mais perto desses usuários.

Recursos

Documentos relacionados:

Vídeos relacionados: