HA versus tolerância a falhas: definições e diferenças

Alta disponibilidade (HA) e tolerância a falhas (FT) são dois objetivos distintos de confiabilidade que os arquitetos frequentemente confundem. Alta disponibilidade significa que um sistema apresenta um tempo de inatividade mínimo — ele pode tolerar falhas, mas talvez tenha breves interrupções durante a recuperação. Tolerância a falhas significa que um sistema continua operando sem qualquer interrupção mesmo quando componentes falham, pois dispõe de caminhos totalmente redundantes que assumem o controle instantaneamente.

A disponibilidade é medida como um percentual de tempo em funcionamento ao longo de um ano. 99,9% de disponibilidade (três noves) significa aproximadamente 8,7 horas de inatividade por ano, enquanto 99,99% (quatro noves) permite apenas 52,6 minutos. 99,999% (cinco noves) permite apenas 5,26 minutos. Cada nove adicional normalmente exige mais redundância, automação e custo. A prova SAA-C03 frequentemente pede que você identifique qual arquitetura atende a uma determinada meta de disponibilidade.

Uma arquitetura altamente disponível tolera a falha de um componente detectando automaticamente a falha e alternando para uma substituição íntegra em segundos ou minutos. Exemplos incluem RDS Multi-AZ (failover automático para uma instância em espera em uma AZ diferente), Auto Scaling Groups substituindo instâncias encerradas e Elastic Load Balancers desviando o tráfego de destinos não íntegros. Há uma breve interrupção, mas o sistema se recupera sem intervenção manual.

Uma arquitetura tolerante a falhas tem redundância ativa — vários componentes idênticos atendem às solicitações simultaneamente, de modo que, quando um falha, os demais absorvem a carga instantaneamente, sem tempo de inatividade. Exemplos incluem ELB ativo-ativo com várias instâncias EC2, DynamoDB Global Tables atendendo leituras e gravações simultaneamente em várias regiões e Aurora com várias réplicas de leitura. A tolerância a falhas exige mais recursos em execução o tempo todo.

A tolerância a falhas é significativamente mais cara que a alta disponibilidade porque exige capacidade redundante totalmente provisionada o tempo todo. Uma instância RDS Multi-AZ altamente disponível dobra o custo do banco de dados por manter uma instância em espera que só é ativada em caso de falha. Uma implantação Aurora ativo-ativo tolerante a falhas em várias regiões pode custar quatro vezes mais, mas elimina todo o tempo de inatividade durante falhas regionais. Os arquitetos devem equilibrar o custo da redundância com o custo comercial do tempo de inatividade.

O Recovery Time Objective (RTO) é o tempo máximo aceitável durante o qual um sistema pode ficar indisponível. As arquiteturas de alta disponibilidade têm como meta um RTO baixo — normalmente de minutos — por meio de failover automatizado. As arquiteturas tolerantes a falhas têm como meta um RTO próximo de zero. Ao projetar para HA, você deve escolher serviços e configurações que garantam a recuperação dentro do seu limite de RTO. Por exemplo, o RDS Multi-AZ fornece um RTO aproximado de 60 a 120 segundos, adequado para muitos requisitos de HA.

Um ponto único de falha (SPOF) é qualquer componente cuja falha faz todo o sistema falhar. Entre os SPOFs comuns estão uma única instância EC2 sem um ASG, um banco de dados RDS em uma única AZ, um único gateway NAT ou uma única zona de disponibilidade. Eliminar os SPOFs é o primeiro passo tanto para HA quanto para FT. A prova SAA-C03 testa com frequência sua capacidade de identificar e eliminar SPOFs em determinados diagramas de arquitetura.

Alcançar HA ou FT é muito mais simples para serviços sem estado (como servidores Web ou funções do Lambda), pois qualquer instância pode atender a qualquer solicitação. Serviços com estado (bancos de dados, caches e sistemas de arquivos) são mais difíceis — é preciso sincronizar o estado entre as réplicas, lidar com o atraso da replicação e garantir a consistência durante o failover. Serviços da AWS como EFS (sistema de arquivos compartilhado), ElastiCache com grupos de replicação e Aurora (armazenamento compartilhado) foram projetados para facilitar a HA de serviços com estado.

Entre os padrões comuns de HA na AWS estão: 1) Balanceamento de carga Multi-AZ — distribua instâncias EC2 entre AZs por trás de um ALB. 2) Réplicas de leitura — retire tráfego de leitura do primário e promova uma réplica em DR. 3) S3 para recursos sem estado — o S3 é inerentemente HA, com 11 noves de durabilidade. 4) Global Accelerator — IPs Anycast estáticos que encaminham o tráfego para endpoints íntegros entre regiões. Cada padrão troca custo por um nível específico de disponibilidade.

Os padrões tolerantes a falhas exigem redundância ativa em todos os componentes. Principais padrões de FT: o DynamoDB é inerentemente tolerante a falhas — replica os dados entre três AZs sem exigir failover. O S3 tem FT integrada. O Aurora Multi-Master (agora Aurora Serverless v2 com vários gravadores) permite gravações simultâneas em várias AZs. O Kinesis armazena dados em várias AZs por padrão. Escolher serviços gerenciados com FT integrada é o caminho mais econômico para arquiteturas sem tempo de inatividade.

Projetar para HA ou FT só é tão eficaz quanto seus testes. A AWS recomenda usar o AWS Fault Injection Simulator (FIS) para executar experimentos controlados que encerrem instâncias, limitem APIs ou injetem falhas de rede. Você deve verificar se o failover realmente é concluído dentro do seu RTO, se os dados não são perdidos além do seu RPO e se os alarmes são acionados corretamente. Dias de simulação regulares e exercícios de engenharia do caos revelam lacunas nas suas premissas de resiliência antes que os incidentes de produção o façam.

Teste sua compreensão dos conceitos do AWS Solutions Architect (SAA-C03) abordados nesta lição.

Nesta lição, você aprendeu que: a Alta Disponibilidade minimiza o tempo de inatividade por meio da recuperação automatizada (RTO de minutos), a Tolerância a Falhas elimina o tempo de inatividade por meio da redundância ativa (RTO zero) e o custo aumenta significativamente a cada nível de resiliência. Eliminar pontos únicos de falha é a base de ambas as abordagens. A seguir, exploraremos padrões Multi-AZ para serviços com estado.