Escolha a disponibilidade entre zonas e regiões

Comece pela operação do usuário

Alta disponibilidade (HA) busca manter um serviço utilizável apesar de falhas de componentes. Defina o que significa ser utilizável antes de escolher a arquitetura. Uma página de reservas que carrega enquanto todas as requisições de reserva falham não representa um serviço de reservas disponível.

Defina um objetivo de nível de serviço (SLO) para a operação importante. Defina quais requisições entram na medição, o que significa sucesso e o período de medição. O SLA de um serviço de nuvem descreve o compromisso daquele provedor. Não comprova a disponibilidade medida da sua aplicação.

Como ilustração, uma disponibilidade de 99,9% baseada em tempo permite 43,2 minutos de indisponibilidade em um mês de 30 dias. Um SLO baseado em requisições tem outro denominador. Nenhuma das medidas informa quanto dado você pode perder nem garante uma duração máxima para cada interrupção.

Entenda os limites de falha

Uma Zona de Disponibilidade (AZ) da AWS é um local de infraestrutura isolado dentro de uma Região. Uma Região contém várias AZs. Um projeto multi-region distribui componentes da carga de trabalho entre Regiões. Outros provedores têm seus próprios limites e comportamentos de serviço; inspecione o serviço escolhido.

Essas são possibilidades de projeto, não garantias de disponibilidade. Um rótulo não prova que todos os componentes necessários usam o limite pretendido.

Rastreie o caminho completo da requisição

Considere um serviço fictício de reservas. Réplicas web funcionam em duas AZs. Ambas usam um banco de dados e um gateway de saída na AZ A. O gateway é necessário para chamar o provedor de pagamentos.

Se a AZ A falhar, a réplica web na AZ B pode continuar saudável enquanto as reservas falham. A equipe deve avaliar o banco de dados, o caminho de rede, o provedor de identidade, a dependência de pagamentos e o roteamento. Inspecione o modo real do banco gerenciado: replicação, failover e comportamento de leitura variam conforme o produto e a configuração.

Verifique também a capacidade. Os recursos sobreviventes devem suportar a carga necessária. Um projeto que depende da criação de capacidade durante um incidente depende de cotas, recursos disponíveis e operações do plano de controle.

Execute um exercício controlado com limites definidos, condições de parada e um responsável. Verifique uma reserva completa, incluindo a reconciliação do pagamento. Registre requisições que falharam e o tempo até recuperar a operação útil.

Decida se outra Região resolve o problema

A operação multi-region acrescenta transferência de dados, recursos duplicados, coordenação de deployment e trabalho operacional. Ativo/passivo mantém um ambiente pronto para receber tráfego. Ativo/ativo atende tráfego em mais de um ambiente. A prontidão exigida e o comportamento dos dados são diferentes.

Para o serviço de reservas, escritas concorrentes introduzem uma pergunta: duas Regiões podem vender o mesmo assento? Defina quem tem autoridade sobre uma reserva e o comportamento durante uma interrupção da replicação. “Replicar o banco de dados” não é uma resposta completa.

Verifique locais permitidos para os dados, chaves de criptografia, certificados, DNS, segredos e serviços externos. Uma indisponibilidade do serviço de identidade compartilhado ou um release defeituoso pode afetar várias Regiões. Mais locais não eliminam todas as causas comuns.

Conecte disponibilidade e recuperação

HA trata falhas especificadas durante a operação. Recuperação de desastres restaura um serviço utilizável e seus dados após um evento disruptivo. Um serviço multi-region ainda precisa de um plano de recuperação para exclusão ou corrupção de dados.

Documente os cenários de falha escolhidos e aqueles que o negócio aceita. Mantenha testes e definições de infraestrutura alinhados conforme a aplicação mudar. Continue com RTO, RPO e recuperação de desastres.