Resiliência e disponibilidade são aspectos críticos de cada aplicativo SaaS. Ao construir seus serviços SaaS Serverless na infraestrutura da AWS, você implanta automaticamente em várias zonas de disponibilidade dentro de uma única região, o que fornece maior resiliência e mecanismos automatizados de failover de disponibilidade. Como engenheiros e arquitetos, é fundamental entender esses conceitos e como configurar nossos serviços corretamente.
Nesta postagem, você aprenderá sobre zonas de disponibilidade (AZs), o que são, por que são essenciais e minhas dicas para configurar recursos em várias AZs dentro de uma única região.
Índice
Definições e propriedades das zonas de disponibilidade
Quando criamos recursos em uma região, os criamos em uma ou mais zonas de disponibilidade.
As AZs (zonas de disponibilidade) trabalham juntas nos bastidores para manter nosso serviço funcionando, compartilhando o tráfego, replicando os dados nos bancos de dados e assumindo o tráfego umas das outras em caso de interrupção da AZ.
Às vezes, os detalhes ficam ocultos para nós, mas, às vezes, definimos explicitamente a quantidade de AZs que queremos usar — VPCs, Aurora e Fargate vêm à mente.
Vamos definir o que é uma zona de disponibilidade. De acordo com a documentação da AWS :
Os recursos da AWS são hospedados em vários locais no mundo todo. Esses locais são compostos de Regiões da AWS, Zonas de Disponibilidade e Zonas Locais. Cada Região da AWS é uma área geográfica separada. Cada Região da AWS tem vários locais isolados conhecidos como Zonas de Disponibilidade.
Como você sabe, "tudo falha o tempo todo", como Werner Vogles sempre diz, então o conceito de AZs é essencial para garantir que nosso serviço funcione mesmo se uma AZ tiver problemas, mas as outras AZs estiverem online.
As AZs fornecem maior disponibilidade, tolerância a falhas e escalabilidade do que um único data center. Em vez de ter um único ponto de falha, agora você tem várias zonas para confiar caso uma das AZs tenha problemas.
*Há também o conceito de serviços multirregionais, que aumenta a disponibilidade do serviço um nível acima, mas não vou abordá-lo aqui.
Propriedades da Zona de Disponibilidade
As AZs têm características especiais de acordo com a documentação da AWS :
Cada região tem um número diferente de AZs, mas todas têm pelo menos 3.
Todas as AZs em uma região são interconectadas por meio de fibra metropolitana de alta largura de banda, baixa latência e totalmente redundante.
O tráfego entre AZs é criptografado e suporta replicação síncrona.
O particionamento de aplicativos entre AZs melhora a proteção contra problemas como quedas de energia e desastres naturais.
As AZs são fisicamente separadas por uma distância significativa, normalmente dentro de 100 km (60 milhas) uma da outra.
Seu serviço pode não utilizar TODAS as AZs.
Quando uma AZ tem problemas em uma região, a AWS sabe como utilizar as outras AZs para manter seu serviço e seus recursos funcionando. O tráfego mudará "automaticamente" para outras AZs saudáveis e seus recursos. Além disso, assim que a AZ com defeito retornar online, ela replicará os dados que perdeu.
Tudo isso é gerenciado para nós pela AWS. Isso é bem incrível, se você me perguntar.
Por que entender AZs é importante
Desenvolvedores sem servidor geralmente não pensam em AZs, pois essas informações são manipuladas pela AWS nos bastidores. Ao usar serviços sem servidor como Lambda e DynamoDB, as AZs são selecionadas para você, e você não precisa gerenciá-las ou mantê-las. Para mais informações, consulte a documentação da AWS .
No entanto, ao usar VPCs ou serviços não totalmente sem servidor (você precisa definir seus VPCs e eles não são dimensionados para zero), como Aurora, OpenSearch ou Fargate, as AZs entram em jogo, e é importante entender seu impacto.
As AZs podem aumentar o SLA e o SLI gerais , pois você é mais resiliente a uma única falha de AZ. Elas aumentam a resiliência a falhas e a disponibilidade e têm o potencial de melhorar o desempenho, pois a AWS equilibra automaticamente o tráfego e o acesso entre as AZs.
Vamos pegar o Aurora, por exemplo, e analisar algumas das vantagens que a implantação em várias AZs traz:
O Aurora armazena cópias dos dados em um cluster de BD em várias Zonas de Disponibilidade em uma única Região da AWS. Quando os dados são gravados na instância de BD primária, o Aurora replica os dados de forma síncrona em Zonas de Disponibilidade para seis nós de armazenamento associados ao seu volume de cluster - Documentação da AWS
Além de proteger seus bancos de dados contra falhas quando uma AZ tem problemas, ele também permite que a AWS conduza failovers em caso de falhas planejadas. manutenção .
AZs e o caso peculiar dos IDs
As zonas de disponibilidade têm IDs e nomes físicos :
A AWS mapeia as Zonas de Disponibilidade físicas aleatoriamente para os nomes das Zonas de Disponibilidade de cada conta da AWS. Essa abordagem ajuda a distribuir recursos entre as Zonas de Disponibilidade em uma Região da AWS, em vez de os recursos provavelmente serem concentrados na Zona de Disponibilidade "a" para cada Região. Como resultado, a Zona de Disponibilidade us-east-1a para sua conta da AWS pode não representar o mesmo local físico que us-east-1a para uma conta diferente da AWS.
Quando consideramos uma escala maior do que uma única conta da AWS, como uma organização da AWS com vários serviços implantados em várias contas, o problema se torna ainda mais significativo.
Se dois serviços em duas contas diferentes naquela organização fossem implantados em AZs específicas por seus nomes: 'us-east-1a' e 'us-east-1b', a AWS mapearia para diferentes AZs físicas (sobre as quais você não tem controle) nas contas da sua organização. Embora você pense que está implantando seus recursos nas mesmas AZs físicas, isso provavelmente não é verdade!
Para controlar em qual AZ específica você implanta, você precisa saber o mapeamento correto entre nome e ID físico .
Abordaremos uma solução alternativa com um exemplo de código do AWS CDK mais adiante neste post.
Quando uma AZ ou região pode ficar inativa?
Uma AZ pode ficar inativa devido a falhas de hardware, desastres naturais, falta de energia ou outros desastres.
Uma região fica inativa quando TODAS as suas AZs sofrem falhas e são marcadas como "inativas". Esse desastre afeta todos os clientes da AWS implantados nessa região. Veja o histórico de caso da AWS , que remonta a 13 anos. Essas coisas acontecem!
Vamos revisar alguns casos de uso de falhas de serviço, desde os mais simples até os mais extremos.
O caso de uso simples é que seu serviço fique inativo quando todas as AZs que ele utiliza estiverem inativas.
No entanto, as coisas podem ficar mais complicadas. Vamos supor que você não implemente em todas as AZs naquela região. A região tem 3 AZs, e você usa apenas 2 das 3 AZs: AZs A e B. Se as zonas de disponibilidade A e B estiverem inativas, você ainda experimentará uma falha regional em seu aplicativo, mesmo que a região ainda tenha uma AZ funcionando.
Mas pode ficar ainda mais complicado. Vamos supor que seu serviço SaaS dependa de outro serviço SaaS em tempo de execução. Ambos os serviços são implantados em contas AWS diferentes.
Suponha que seu serviço seja implantado nas AZ 1 e 2, e o serviço B, do qual você depende criticamente, seja implantado nas AZ 1 e 3. Caso as regiões 1 e 3 estejam inativas, enquanto você ainda tem sua AZ 2 disponível, você está essencialmente inativo, pois sua dependência crítica, o serviço B, está inativo.
É por isso que entender as AZs e garantir que a organização SaaS use a mesma metodologia e as mesmas AZs garantem a disponibilidade.
Como tudo em software, é tudo sobre prós, contras e restrições. Implantar em todas as AZs é a resposta mais simples, mas vai custar muito caro.
Vamos discutir minhas recomendações para a seleção de AZ.
Recomendações para seleção de zona de disponibilidade
Como regra geral:
Duas são melhores do que uma. Implante em um mínimo de duas AZs. Para consistência em toda a organização, veja o exemplo de código abaixo para saber como isso pode ser alcançado. Certifique-se de que todas as organizações usem as mesmas AZs (1 e 2, por exemplo). Veja a seção 'Seleção de AZ via IaC' abaixo para ver como fazer isso via IaC.
Serviços SaaS críticos que estejam dispostos a pagar mais por SLI e desempenho aprimorados durante mau funcionamento parcial da AZ são incentivados a implantar em três ou mais AZs.
Antes de adicionar uma AZ, é crucial calcular o custo tanto da TRANSFERÊNCIA DE DADOS quanto da infraestrutura extra. Esta etapa garante que a implantação permaneça econômica e alinhada ao orçamento da organização.
Para serviços SaaS críticos que são implantados em regiões com mais de 3 AZs, avalie o custo para determinar se as AZs adicionadas valem a pena. Como referência, essas regiões falharam antes, então até mesmo uma região com 6 AZs pode ser feita.
Seleção AZ via IaC
É impossível definir IDs físicos de AZ como 'use-1az1' (para a região us-east-1) diretamente no código AWS CloudFormation/CDK. Em vez disso, você precisa fornecer os nomes de AZ; como sabemos, eles são mapeados de forma diferente em cada conta para IDs diferentes. Precisamos determinar qual nome de AZ é mapeado para AZ1, AZ2, etc.
Você pode fazer isso no código CDK usando o AWS SDK (boto3 para Python) para encontrar o mapeamento específico da conta entre o nome e o ID da AZ.
Considere este exemplo de código Python que cria uma VPC que é SEMPRE implantada em AZ1 e AZ2:
A mágica acontece nas linhas 48-57. Nós iteramos sobre o mapeamento e procuramos os nomes AZ que correspondem ao ID que queremos implementar. Simples e eficaz!
Dicas de seleção AZ para VPC
Ao configurar uma Virtual Private Cloud (VPC), você tem mais controle e deve selecionar explicitamente quais AZs usar. Normalmente, implantar seus recursos (como instâncias EC2 ou Elastic Load Balancers) é uma prática recomendada em várias AZs regionais.
Use várias sub-redes dentro da VPC, cada uma residindo em uma AZ diferente. Isso permite que você distribua seus recursos entre AZs e mantenha redundância em caso de falha de uma AZ.
Como observação lateral, se você tiver Lambdas dentro da sua VPC, eles serão implantados de acordo com a definição da VPC; caso contrário, cabe ao serviço Lambda configurar e escolher as AZs.
Dicas de seleção AZ para Aurora
Um cluster Aurora DB é tolerante a falhas por design. O volume do cluster abrange várias Zonas de Disponibilidade (AZs) em uma única Região da AWS, e cada AZ contém uma cópia dos dados do volume do cluster. Essa funcionalidade significa que seu cluster de DB pode tolerar uma falha de uma AZ sem nenhuma perda de dados e apenas uma breve interrupção do serviço.
Recomendamos que você distribua a instância primária e as instâncias do leitor no seu cluster de banco de dados em várias zonas de disponibilidade para melhorar a disponibilidade do seu cluster de banco de dados. - Documentação da AWS
Compreendendo o custo da zona de disponibilidade
Implantar e criar recursos em várias AZs aumenta o custo. Você paga pelos recursos implantados (réplicas Aurora, EC2s, ALBs, gateway Nat, etc.) e, em alguns casos, pelo tráfego entre as AZs.
Vamos revisar o seguinte cenário: implantamos uma máquina EC2 e um cluster Aurora RDS MySQL em uma VPC com 2 AZs.
Neste caso, pagaremos o dobro do valor pelos recursos do EC2, Aurora DB, VPCs e outras partes da rede (ENIs, etc.)
Quanto à transferência de dados, você não paga pela replicação de dados AZ entre as instâncias do RDS nem pelos dados enviados dentro da mesma região (entre EC2 e RDS).
No entanto, você pagará por qualquer custo de rede entre EC2s e por quaisquer dados que estejam entre EC2 e RDS de uma AZ diferente (caso o RDS esteja inativo na primeira AZ).
Como você pode ver, caso você tenha 1 AZ e adicione outro, você pagará mais que o dobro devido à implantação de rede e infraestrutura.
Esse custo será reduzido à medida que você adicionar mais AZs, pois o custo relativo da implantação da infraestrutura representa uma porcentagem menor do custo geral.
Quanto ao custo da transferência de dados em si, o custo difere entre as regiões, mas na maior parte,
a transferência de dados cross-AZ dentro da região custa $ 0,01/GB, e se as atualizações forem de ida e volta, você paga duas vezes, $ 0,02/GB. Leia mais aqui .
O custo difere entre as regiões, então certifique-se de verificar antes de adicionar uma AZ na sua região.
Resumo
Nesta publicação, abordamos a importância da resiliência e disponibilidade em aplicativos SaaS criados na AWS usando Availability Zones (AZs). Definimos o que são AZs e por que elas são importantes e escrevemos código IaC concreto para configurar recursos em várias AZs.
Obrigado Maxim Drobachevsky e Meitar Karas pela ajuda e avaliação!