Diagrama de arquitetura de recuperação de desastres: RPO, RTO e quatro estratégias

Alta disponibilidade mantém um sistema funcionando quando um servidor ou uma zona de disponibilidade falha. Recuperação de desastres trata das falhas maiores: uma região inteira fora do ar, um banco de dados corrompido, uma conta apagada, um ransomware. O plano para esses casos precisa existir antes que eles aconteçam, e a arquitetura decide quantos dados você perde e quanto tempo fica fora do ar.

Este artigo define os dois números de que todo projeto de recuperação de desastres (DR) parte, percorre as quatro estratégias padrão com seus custos e desenha um warm standby em duas regiões.

RPO e RTO

• Objetivo de ponto de recuperação (RPO): quantos dados você pode se dar ao luxo de perder, medido em tempo. Um RPO de 5 minutos significa que perder os últimos 5 minutos de gravações é aceitável.
• Objetivo de tempo de recuperação (RTO): quanto tempo o serviço pode ficar fora do ar antes de voltar.

Os dois vêm do negócio, não da engenharia, e os dois custam dinheiro: cada passo rumo a zero perda de dados e zero indisponibilidade multiplica a infraestrutura e o trabalho de operação. Pergunte quanto custa uma hora fora do ar e quais dados não podem ser recriados, e escolha o projeto mais barato que atenda a esses números. Partes diferentes de um mesmo sistema costumam ter metas diferentes: o checkout pode precisar de minutos; o armazém de dados de relatórios, de um dia.

Quatro estratégias

O whitepaper da AWS sobre recuperação de desastres agrupa a DR em quatro estratégias, ordenadas por custo e velocidade de recuperação. As mesmas ideias valem em qualquer nuvem ou nos seus próprios data centers.

Backup and restore reconstrói tudo a partir dos backups e do código de infraestrutura. É suficiente para muitos sistemas internos, desde que a restauração tenha sido testada e a infraestrutura possa ser recriada a partir do código.

Pilot light mantém os dados vivos (bancos replicados, buckets replicados), mas deixa a computação desligada ou zerada. Recuperar significa iniciar os serviços e escalá-los.

Warm standby mantém rodando uma cópia pequena, mas funcional. Ela pode atender tráfego imediatamente com capacidade reduzida e escala durante o failover. Como está sempre rodando, também é fácil de testar.

Ativo/ativo atende os usuários a partir dos dois sites o tempo todo. O failover é quase só uma mudança de roteamento, mas gravações em duas regiões trazem tratamento de conflitos ou um design com um único escritor, e o custo é o de dois ambientes de produção.

Escolhendo para um sistema: um exemplo

Uma loja online que recebe 2.000 pedidos por hora pede para o checkout um RPO de 5 minutos e um RTO de 30 minutos. Backup and restore não atende o RPO: snapshots noturnos podem perder um dia de pedidos, e reconstruir a stack leva horas. Pilot light atende o RPO com a replicação do banco, mas iniciar e aquecer os serviços, os caches e o índice de busca em outra região costuma levar mais de 30 minutos na primeira vez que alguém tenta. Warm standby atende os dois: a réplica fica segundos atrás e os serviços reduzidos já estão rodando, então o failover é promoção, escala e uma troca de DNS. Ativo/ativo reduziria ainda mais o RTO, mas dobraria o custo e traria conflitos de gravação que a loja não precisa resolver. A resposta: warm standby para o checkout e backup and restore para o armazém de dados de relatórios.

Backups continuam necessários

A replicação também copia erros. Se alguém apaga uma tabela ou um ransomware criptografa os dados, a réplica acompanha em segundos. Mantenha backups point-in-time que a replicação não consiga alcançar:

• Snapshots e logs de transações guardados por dias ou semanas.
• Cópias numa conta separada, com credenciais diferentes, para que uma única conta comprometida não consiga apagar as duas.
• Backups imutáveis ou bloqueados, quando a sua plataforma oferecer.
• Testes de restauração regulares. Um backup que ninguém restaurou é uma esperança, não um backup.

A sequência de failover

Escreva os passos e mantenha-os curtos:

1. Decidir. Quem pode declarar um desastre e com base em qual sinal. Failover automático de uma região inteira é arriscado; muitos times automatizam a detecção e mantêm a decisão com uma pessoa.
2. Promover a réplica do banco na região de standby a primária.
3. Escalar a computação na região de standby até a capacidade total.
4. Mover o tráfego trocando os registros DNS de failover ou os pesos do balanceador global. Leve em conta os TTLs do DNS e os clientes que fazem cache.
5. Verificar com checagens sintéticas e depois anunciar.
6. Planejar a volta. Voltar para o site original é uma segunda migração e exige o mesmo cuidado.

O diagrama de arquitetura

Como ler:

• Em cima: os usuários chegam ao roteamento DNS com failover. Hoje ele envia todo o tráfego para a região primária; a aresta tracejada mostra para onde o tráfego vai depois do failover.
• Esquerda, a região primária: um balanceador de carga, seis instâncias da aplicação, armazenamento de objetos e o banco primário.
• Direita, a região de standby: a mesma forma em escala menor: duas instâncias da aplicação, uma réplica do banco alimentada por replicação assíncrona e objetos replicados. Arestas tracejadas marcam os caminhos que só levam tráfego depois do failover.
• Embaixo: snapshots diários vão para um cofre de backup em outra conta, a proteção contra corrupção e exclusão que a replicação não oferece.
• O bloco Markdown traz as metas que o projeto deve cumprir.

Testes

Planos de DR falham nos detalhes: um certificado expirado na região de standby, um endpoint fixo no código, um secret faltando, um TTL de DNS de um dia. A única saída é executar o failover. Agende simulações, comece por um único serviço e meça o RTO real em relação à meta. Um warm standby torna isso barato, e essa é uma das suas maiores vantagens sobre o pilot light.

O que colocar num diagrama de DR

• Os dois sites, com o que roda em cada um e em que escala.
• Os caminhos de replicação e seu modo, síncrono ou assíncrono, porque isso define o RPO.
• A chave de tráfego, e se ela é automática.
• Backups fora do raio de impacto, incluindo o limite da conta.
• As metas, escritas ao lado do projeto.

Para a parte de rede multirregião, veja o diagrama de arquitetura multirregião na AWS. O diagrama de replicação de banco de dados explica com mais detalhes o atraso de replicação e o failover, e o fluxograma de resposta a incidentes cobre como declarar e conduzir o incidente em si.

Monte no Archboard

1. Entre com Google ou GitHub e crie um diagrama.
2. Adicione duas molduras Região do pack Nuvem, uma para a primária e outra para a de standby.
3. Dentro de cada uma, adicione um Balanceador de carga na nuvem, um nó Instância de computação para a aplicação, um nó Armazenamento de objetos e um Banco de dados gerenciado. Coloque o número de instâncias nos rótulos.
4. Adicione uma Pessoa do pack Modelo C4 e um nó DNS do pack Rede acima das regiões, e outro nó Armazenamento de objetos abaixo para o cofre de backup.
5. Desenhe a replicação entre as regiões, deixe tracejados os caminhos usados só no failover e adicione um bloco Markdown do pack Básico com o RPO e o RTO.

O exemplo usa 14 nós de diagrama e fica dentro do plano Free.

Perguntas frequentes

Qual a diferença entre RPO e RTO? O RPO é quantos dados você pode perder, medido em tempo antes da falha. O RTO é quanto tempo leva para voltar a atender depois dela.

Alta disponibilidade é a mesma coisa que recuperação de desastres? Não. Alta disponibilidade lida com falhas de componentes e de zonas de forma automática e contínua. Recuperação de desastres lida com eventos maiores, como a queda de uma região ou a corrupção de dados, muitas vezes com um failover deliberado.

Ainda preciso de backups se replico para outra região? Sim. A replicação copia exclusões e corrupção quase na hora. Backups numa conta separada protegem contra isso.

Qual estratégia de recuperação de desastres devo escolher? A mais barata que atenda ao RPO e ao RTO de que o negócio precisa para aquele sistema. Warm standby é um meio-termo comum, porque é acessível e fácil de testar.

Com que frequência devo testar a recuperação de desastres? Com frequência suficiente para o runbook continuar verdadeiro: muitas vezes a cada trimestre nos sistemas críticos, e depois de qualquer mudança grande de arquitetura.

Comece grátis — um assento, sem cartão de crédito.