Serviços zonais

A Independência da Zona de Disponibilidade (AZI) permite AWS oferecer serviços zonais, como Amazon EC2 e Amazon EBS. Um serviço zonal é aquele que fornece a capacidade de especificar em qual zona de disponibilidade os recursos são implantados. Esses serviços operam de forma independente em cada zona de disponibilidade dentro de uma região e, o mais importante, também falham de forma independente em cada zona de disponibilidade. Isso significa que os componentes de um serviço em uma zona de disponibilidade não dependem de componentes em outras zonas de disponibilidade. Podemos fazer isso porque um serviço zonal tem planos de dados zonais. Em alguns casos, como no EC2, o serviço também inclui planos de controle zonal para operações alinhadas por zona, como iniciar uma instância do EC2. Para esses serviços, AWS também fornece um endpoint de plano de controle regional para facilitar a interação com o serviço. O plano de controle regional também fornece funcionalidade com escopo regional, além de servir como uma camada de agregação e roteamento sobre os planos de controle zonais. Isso é mostrado na figura a seguir.

Um serviço zonal com planos de controle e planos de dados isolados por zona

As zonas de disponibilidade oferecem aos clientes a capacidade de operar cargas de trabalho de produção mais altamente disponíveis, tolerantes a falhas e escaláveis do que seria possível em um único data center. Quando uma carga de trabalho usa várias zonas de disponibilidade, os clientes ficam melhor isolados e protegidos de problemas que afetam a infraestrutura física de uma única zona de disponibilidade. Isso ajuda os clientes a criar serviços redundantes em todas as zonas de disponibilidade e, se arquitetados corretamente, permanecerem operacionais mesmo se uma zona de disponibilidade apresentar falhas. Os clientes podem aproveitar o AZI para criar cargas de trabalho altamente disponíveis e resilientes. A implementação do AZI em sua arquitetura ajuda você a se recuperar rapidamente de uma falha isolada na zona de disponibilidade porque seus recursos em uma zona de disponibilidade minimizam ou eliminam a interação com recursos em outras zonas de disponibilidade. Isso ajuda a remover dependências entre zonas de disponibilidade, o que simplifica a evacuação da zona de disponibilidade. Consulte Padrões avançados de resiliência Multi-AZ para obter mais detalhes sobre a criação de mecanismos de evacuação da zona de disponibilidade. Além disso, você pode aproveitar ainda mais as zonas de disponibilidade seguindo algumas das mesmas práticas recomendadas AWS usadas em seus próprios serviços, como implantar apenas alterações em uma única zona de disponibilidade por vez ou remover uma zona de disponibilidade do serviço se uma alteração nessa zona de disponibilidade der errado.

A estabilidade estática também é um conceito importante para arquiteturas de zonas de multidisponibilidade. Um dos modos de falha que você deve planejar com arquiteturas de zona de disponibilidade múltipla é a perda de uma zona de disponibilidade, o que pode resultar na perda da capacidade de uma zona de disponibilidade. Se você não pré-provisionou capacidade suficiente para lidar com a perda de uma zona de disponibilidade, isso pode fazer com que sua capacidade restante seja sobrecarregada pela carga atual. Além disso, você precisará depender dos planos de controle dos serviços zonais usados para substituir essa capacidade perdida, que pode ser menos confiável do que um projeto estaticamente estável. Nesse caso, pré-provisionar capacidade extra suficiente pode ajudá-lo a ficar estaticamente estável à perda de um domínio de falha, como uma zona de disponibilidade, ao ser capaz de continuar as operações normais sem a necessidade de alterações dinâmicas.

Você pode optar por usar um grupo de auto scaling de instâncias do EC2 implantadas em várias zonas de disponibilidade para aumentar e reduzir dinamicamente a escala, com base nas necessidades de sua carga de trabalho. O escalonamento automático funciona bem para mudanças graduais no uso que ocorrem de minutos a dezenas de minutos. No entanto, lançar novas instâncias do EC2 leva tempo, especialmente se suas instâncias exigirem inicialização (como instalação de agentes, binários de aplicativos ou arquivos de configuração). Durante esse tempo, sua capacidade restante pode ser sobrecarregada pela carga atual. Além disso, a implantação de novas instâncias por meio do auto scaling depende do plano de controle do EC2. Isso apresenta uma desvantagem: para ser estaticamente estável à perda de uma única zona de disponibilidade, você precisa pré-provisionar instâncias EC2 suficientes nas outras zonas de disponibilidade para lidar com a carga que foi transferida da zona de disponibilidade prejudicada, em vez de depender do escalonamento automático para provisionar novas instâncias. No entanto, o pré-provisionamento de capacidade extra pode gerar custos adicionais.

Por exemplo, durante a operação normal, vamos supor que sua carga de trabalho exija seis instâncias para atender ao tráfego de clientes em três zonas de disponibilidade. Para ser estaticamente estável contra uma única falha na zona de disponibilidade, você implantaria três instâncias em cada zona de disponibilidade, totalizando nove. Se uma única zona de disponibilidade de instâncias falhasse, você ainda teria seis e seria capaz de continuar atendendo ao tráfego de seus clientes sem a necessidade de provisionar e configurar novas instâncias durante a falha. Obter estabilidade estática para sua capacidade do EC2 tem um custo adicional, pois, nesse caso, você está executando 50% de instâncias adicionais. Nem todos os serviços em que você pode pré-provisionar recursos terão custos adicionais, como o pré-provisionamento de um bucket S3 ou de um usuário. Você precisará ponderar todas as desvantagens da implementação da estabilidade estática em relação ao risco de exceder o tempo de recuperação desejado para sua carga de trabalho.

AWS Locais Zones and Outposts aproximam o plano de dados de AWS serviços selecionados dos usuários finais. Os planos de controle desses serviços residem na região principal. Sua instância Local Zone ou Outposts terá dependências de plano de controle para serviços zonais como EC2 e EBS na Zona de Disponibilidade em que você criou sua Zona Local ou sub-rede Outposts. Eles também terão dependências de planos de controle regionais para serviços regionais, como o Elastic Load Balancing (ELB), grupos de segurança e o plano de controle Kubernetes gerenciado pelo Amazon Elastic Kubernetes Service (Amazon EKS) (se você usar o EKS). Para obter informações adicionais específicas sobre Outposts, consulte a documentação e as perguntas frequentes sobre suporte e manutenção. Implemente estabilidade estática ao usar Locais Zones ou Outposts para ajudar a melhorar a resiliência para controlar deficiências do plano ou interrupções na conectividade da rede com a região principal.