Arquiteturas resilientes

Folha de revisão · 6 temas · AWS Solutions Architect Associate

Feita para a véspera. Imprimir esta página tira o menu e as abas.

Alta disponibilidade e tolerância a falhas

É a base do domínio de 26%, e onde nasce a resposta padrão da prova: se o enunciado fala em falha, a alternativa certa quase sempre distribui em mais de uma zona de disponibilidade. Sem saber o que é zona, região e serviço de escopo regional, você não distingue a alternativa que resolve da que só parece resolver.

Como cai: A aplicação precisa continuar disponível se um data center inteiro falhar. O que muda na arquitetura?

Erros comuns

Tratar região e zona de disponibilidade como sinônimos. Região é a área geográfica; zona é um ou mais data centers isolados dentro dela. Multi-AZ protege contra falha de data center; multirregião protege contra falha da região inteira.
Achar que multirregião é sempre melhor. Custa mais, adiciona latência de replicação e complexidade. A prova pune resposta acima do requisito: se o enunciado fala em falha de AZ, a resposta multirregião está errada.
Confundir alta disponibilidade com tolerância a falhas. Alta disponibilidade aceita uma interrupção curta durante o failover; tolerância a falhas não perde nada, e custa bem mais.
Esquecer que uma instância EC2 vive em uma única zona. Ela não migra sozinha: o que dá disponibilidade é ter várias, em zonas diferentes, atrás de um balanceador.
Achar que S3, DynamoDB e Lambda precisam de configuração para serem resilientes na região. Eles já replicam entre zonas por desenho; o que exige decisão é a proteção entre regiões.
Ignorar o modelo de responsabilidade compartilhada. A AWS entrega zonas isoladas; usar mais de uma é trabalho do arquiteto, não acontece por padrão.

Vocabulário

região: — Área geográfica com várias zonas de disponibilidade, como sa-east-1 (São Paulo). Você escolhe a região por latência, custo, serviços disponíveis e exigência legal de onde o dado mora.
zona de disponibilidade: — Um ou mais data centers dentro de uma região, com energia, refrigeração e rede independentes. Separados o bastante para um desastre local não atingir dois; próximos o bastante para replicação síncrona.

Balanceamento de carga e Auto Scaling

Aparece em metade dos cenários do Domínio 2 e reaparece nos de desempenho e custo. A prova cobra três decisões: qual balanceador (a pista está no protocolo e no tipo de roteamento), o que a verificação de integridade faz de fato, e a diferença entre repor capacidade e aumentar capacidade — que é o par Auto Scaling e política de escala.

Como cai: A aplicação precisa suportar picos imprevisíveis e sobreviver à falha de uma instância, com o MENOR custo. O que você desenha?

Erros comuns

Escolher NLB para roteamento por caminho ou por cabeçalho. NLB é camada 4: enxerga IP e porta, não URL. Roteamento por conteúdo é ALB.
Escolher ALB quando o enunciado pede IP estático, latência ultrabaixa ou milhões de conexões por segundo. Isso é NLB, que ainda suporta protocolos além de HTTP.
Achar que o balanceador dá alta disponibilidade sozinho. Ele distribui entre alvos saudáveis; se todos estão na mesma zona, a zona continua sendo o ponto único de falha.
Confundir verificação de integridade do balanceador com a do Auto Scaling. A do balanceador tira o alvo da rotação; para o Auto Scaling substituir a instância, o grupo precisa usar o tipo de verificação ELB, não só EC2.
Usar escala por agendamento para carga imprevisível, ou escala reativa para pico conhecido. Agendamento é para padrão previsível; rastreamento de alvo é para carga variável.
Ignorar o período de estabilização (cooldown) e o aquecimento. Sem eles, o grupo escala em cascata reagindo a métricas de instâncias que ainda nem subiram.

Vocabulário

verificação de integridade: — Teste periódico que o balanceador faz em cada alvo. Ao falhar o limiar configurado, o alvo sai da rotação e deixa de receber tráfego.
grupo de Auto Scaling: — Conjunto de instâncias criado a partir de um modelo de lançamento, com capacidade mínima, desejada e máxima, distribuído pelas sub-redes informadas.

Bancos resilientes: Multi-AZ, réplicas de leitura e tabelas globais

Multi-AZ e réplica de leitura resolvem problemas diferentes e a prova oferece um como distrator do outro em quase todo cenário de banco. Quem sabe que a espera do Multi-AZ não aceita leitura, e que a réplica pode estar atrasada, elimina metade das alternativas antes de pensar no resto.

Como cai: O banco precisa sobreviver à falha de uma zona e aguentar relatórios pesados sem afetar as transações. O que você configura?

Erros comuns

Achar que a instância de espera do Multi-AZ atende leitura. Ela não recebe tráfego nenhum; existe para assumir no failover. Quem quer distribuir leitura precisa de réplica de leitura.
Usar réplica de leitura como mecanismo de alta disponibilidade. A replicação é assíncrona e a promoção é manual: há atraso possível e não há failover automático.
Esquecer que o failover do Multi-AZ troca o registro DNS do endpoint. A aplicação precisa reconectar; conexão presa em cache de DNS é o sintoma clássico.
Confundir Aurora réplica com Aurora Global Database. Réplicas ficam na mesma região e podem ser alvo de failover; Global Database replica para outra região, com atraso típico abaixo de um segundo.
Achar que tabela global do DynamoDB precisa de configuração de failover. Ela é ativa em todas as regiões escolhidas: escreve-se e lê-se em qualquer uma, com resolução do último escritor em caso de conflito.
Tratar backup automático como alta disponibilidade. Backup restaura depois, com tempo parado; disponibilidade é continuar.

Vocabulário

Aurora: — Banco compatível com MySQL e PostgreSQL em que o armazenamento é uma camada compartilhada, com seis cópias em três zonas, separada das instâncias de computação.
tabela global: — Replicação ativa em várias regiões: escreve-se e lê-se em qualquer uma delas, com resolução de conflito pelo último escritor.

Route 53: políticas de roteamento e failover

É a peça que liga duas regiões numa arquitetura, e a prova sempre dá a pista na palavra: 'usuário mais próximo' não é a mesma coisa que 'menor latência', e 'dividir o tráfego para testar' não é a mesma coisa que 'usar o outro se este cair'. Cada uma dessas frases aponta para uma política diferente.

Como cai: A aplicação roda em duas regiões e deve mandar o usuário para a mais rápida, caindo para a outra se ela falhar. O que configurar?

Erros comuns

Confundir roteamento por latência com geolocalização. Latência escolhe a região que responde mais rápido para aquele usuário; geolocalização escolhe pelo país ou continente de origem, mesmo que outra fosse mais rápida.
Confundir geolocalização com geoproximidade. Geolocalização é regra por local de origem; geoproximidade calcula distância até os recursos e permite deslocar tráfego com um viés (bias).
Achar que failover funciona sem verificação de integridade. Sem ela, o Route 53 não sabe que o primário caiu e continua respondendo o mesmo endereço.
Esquecer o TTL. Enquanto o registro antigo estiver em cache do resolvedor, o cliente continua indo ao destino que caiu; TTL alto atrasa qualquer failover de DNS.
Usar registro CNAME na raiz do domínio. A raiz não aceita CNAME; para apontar a raiz a um recurso da AWS, usa-se o registro de alias.
Tratar roteamento multivalor como balanceador. Ele devolve até oito endereços saudáveis e o cliente escolhe; não distribui carga nem verifica capacidade.

Vocabulário

verificação de integridade do Route 53: — Teste periódico, feito de vários pontos do mundo, contra um endereço, um alarme do CloudWatch ou outras verificações combinadas. Registros associados a uma verificação que falha deixam de ser devolvidos.
registro de alias: — Registro exclusivo do Route 53 que aponta para um recurso da AWS (ELB, CloudFront, site em S3, API Gateway) pelo nome do serviço, funciona na raiz da zona e não é cobrado por consulta.

Desacoplamento: SQS, SNS e EventBridge

Desacoplar é a resposta estrutural do Domínio 2: componentes que falham juntos viram componentes que falham sozinhos. A prova testa a escolha entre os três serviços com pistas precisas — 'processar depois' é fila, 'avisar vários' é tópico, 'rotear por conteúdo do evento' é EventBridge — e cobra o que acontece com a mensagem quando o consumidor falha.

Como cai: Picos de pedidos derrubam o serviço de processamento e pedidos se perdem. Como redesenhar para não perder nada?

Erros comuns

Achar que fila padrão do SQS garante ordem. Ela é de melhor esforço e pode entregar a mesma mensagem mais de uma vez; ordem estrita e exatamente uma entrega são da fila FIFO.
Esquecer que o consumidor precisa apagar a mensagem. Sem a exclusão, ela reaparece quando o tempo de visibilidade expira — que é justamente o que protege contra consumidor que morreu no meio.
Usar SNS quando o requisito é absorver pico. Tópico entrega e esquece; se o assinante estiver fora, a mensagem se perde. Absorver carga e reter é fila.
Usar SQS quando o requisito é avisar vários sistemas. Uma mensagem na fila é consumida por um consumidor; para vários destinos, é tópico, ou tópico com uma fila por destino.
Tratar EventBridge como fila. Ele roteia eventos por regra para destinos; não guarda para consumo posterior nem tem tempo de visibilidade.
Não configurar fila de mensagens mortas. Sem ela, uma mensagem que sempre falha fica reprocessando para sempre e trava a fila.

Vocabulário

SQS: — Fila gerenciada. O produtor publica, a mensagem fica retida, o consumidor lê, processa e apaga. Absorve picos e isola ritmos.
SNS: — Tópico de publicação e assinatura. Uma mensagem chega a todos os assinantes: filas, funções, endpoints HTTP, e-mail, SMS.

Estratégias de recuperação de desastres: RTO, RPO e as quatro opções

É onde o Domínio 2 fecha, e a questão é sempre a mesma em roupas diferentes: o enunciado dá um RTO e um RPO e pergunta a estratégia mais barata que os atende. Quem sabe a ordem das quatro e o que cada uma mantém ligada responde em segundos; quem não sabe escolhe pela que parece mais robusta e erra por excesso.

Como cai: O negócio aceita 4 horas parado e no máximo 15 minutos de dados perdidos. Qual estratégia de DR atende com o MENOR custo?

Erros comuns

Trocar RTO por RPO. RTO é tempo até voltar (olha para a frente); RPO é o ponto no passado a que você volta, ou seja, quanto dado se perde (olha para trás).
Escolher a estratégia mais robusta quando o enunciado pede a mais barata que atende. A prova pune resposta acima do requisito: se 4 horas de RTO bastam, multissítio está errado.
Achar que luz-piloto mantém a aplicação ligada. Ela mantém só o núcleo, tipicamente o dado replicado; os servidores estão desligados ou nem existem, e sobem na hora do desastre.
Confundir espera morna com multissítio. Espera morna mantém uma versão reduzida rodando de verdade, que é escalada no desastre; multissítio atende tráfego nas duas regiões o tempo todo.
Esquecer que a região secundária precisa de mais que dados: AMIs, modelos de lançamento, configuração, limites de serviço e a zona de DNS também precisam existir lá.
Confiar num plano de DR nunca testado. A prova cobra teste periódico, e o custo real de um RTO baixo inclui o ensaio.

Vocabulário

RTO: — Recovery Time Objective: o tempo máximo aceitável entre o desastre e o serviço de volta. Olha para a frente.
RPO: — Recovery Point Objective: o ponto no passado a que se volta — na prática, quanto trabalho se perde. Olha para trás.