Validar e melhorar o RTO e o RPO usando o AWS Resilience Hub

Para saber mais sobre como estabelecer RTO e RPO para uma aplicação, consulte “Estabelecendo metas de RTO e RPO para aplicativos em nuvem“.

O AWS Resilience Hub é um novo serviço lançado em Novembro de 2021. Esse serviço foi desenvolvido para ajudar a definir, validar e rastrear a resiliência de suas aplicações na nuvem da AWS.

Você pode definir políticas de resiliência para cada aplicação. Essas políticas incluem metas de RTO e RPO para interrupções na camada de aplicação, infraestrutura, zona de disponibilidade (AZ) e região. Cada avaliação do Resilience Hub utiliza as melhores práticas definidas no framework do AWS Well-Architected. Ele analisa os componentes de uma aplicação, como computação, armazenamento, banco de dados, e rede, e documenta onde há falta de resiliência.

Neste blog, abordamos como o Resilience Hub pode ajudá-lo a validar o RTO e o RPO para cada componente de aplicação, considerando quatro tipos de interrupções, que por sua vez, pode ajudá-lo a melhorar a resiliência das suas aplicações:

• RTO e RPO da aplicação,
• RTO e RPO da infraestrutura da AWS,
• Interrupção da zona de disponibilidade (AZ), e
• Interrupção em uma região específica da AWS.

RTO e RPO da Aplicação

As interrupções em aplicações ocorrem quando a pilha de infraestrutura (hardware) está íntegra, mas a pilha da aplicação (software) não. Essa interrupção pode ser causada por alterações de configuração, implantações de código incorreto, falhas de integração etc. A determinação do RTO e do RPO para pilhas de aplicações depende da importância da aplicação, bem como dos requisitos de conformidade. Por exemplo, uma aplicação de missão crítica pode ter um RTO e RPO de 5 minutos

Exemplo: uma aplicação comercial crítica está hospedada em um bucket do Amazon Simple Storage Service (Amazon S3) e foi configurada sem replicação e/ou controle de versões entre regiões. A Figura 1 mostra que o RTO e o RPO da aplicação são irrecuperáveis com base em uma meta de 5 minutos de RTO e RPO

Figura 1. Avaliação do Resilience Hub do bucket do Amazon S3 em relação ao RTO da aplicação

 

Depois de executar uma avaliação, o Resilience Hub fornece recomendações para ativar o controle de versão no bucket do Amazon S3, conforme mostrado na Figura 2.

Figura 2. Recomendação de resiliência para o Amazon S3

 

Depois de ativar o controle de versão, você pode atingir o RTO estimado de 5m e o RPO de 0s. O controle de versão permite que você preserve, recupere e restaure qualquer versão de qualquer objeto armazenado em um bucket, melhorando a resiliência da sua aplicação.

O Resilience Hub também fornece o custo associado à implementação das recomendações. Nesse caso, não há custo para ativar o controle de versão no bucket do Amazon S3. O preço normal do S3 se aplica a cada versão de um objeto. Você pode armazenar qualquer número de versões do mesmo objeto, então talvez queira implementar alguma lógica de expiração e exclusão se planeja usar o controle de versão.

O Resilience Hub pode fornecer uma ou mais recomendações para atender aos requisitos como custo, alta disponibilidade e menos alterações. Conforme mostrado na Figura 2, adicionar o controle de versão para o bucket do S3 satisfaz tanto a otimização da alta disponibilidade quanto a melhor arquitetura possível com o mínimo de alterações.

RTO e RPO da infraestrutura AWS

A interrupção da infraestrutura AWS ocorre quando os componentes subjacentes da infraestrutura (componentes de hardware) falham. Considere um cenário em que ocorreu uma interrupção parcial devido à falha de um componente.

Por exemplo, um dos componentes da sua aplicação de missão crítica é um Amazon Elastic Container Service (ECS) implementado em uma instância do Elastic Compute Cloud (EC2), e sua meta de RTO e RPO para infraestrutura é de 1 segundo. A Figura 3 mostra que você não consegue atingir sua meta de RTO de infraestrutura em 1 segundo

Figura 3. Avaliação do Resilience Hub para a aplicação no ECS em relação à infraestrutura

 

A Figura 4 mostra a recomendação do Resilience Hub de adicionar grupos de AWS Auto Scaling e provedores de capacidade do Amazon ECS em várias AZs.

Figura 4. Recomendação do Resilience Hub para cluster ECS — adicionar grupos de escalonamento automático e provedores de capacidade em várias AZs.

 

O AWS Auto Scaling monitora suas aplicações e ajusta automaticamente a capacidade para manter um desempenho estável e previsível com o menor custo possível. Os provedores de capacidade do Amazon ECS são usados para gerenciar a infraestrutura que as tarefas usam em seus clusters. Ele pode usar grupos do AWS Auto Scaling para gerenciar automaticamente as instâncias do Amazon EC2 registradas em seus clusters. Ao aplicar a recomendação do Resilience Hub, você alcançará um RTO e RPO estimados de quase zero segundos e o custo estimado da alteração é de $16,98/mês.

Interrupções na Zona de Disponibilidade (AZ) da AWS

A infraestrutura global da AWS é construída em torno das regiões e zonas de disponibilidade da AWS para alcançar a alta disponibilidade (HA). As regiões da AWS oferecem várias zonas de disponibilidade fisicamente separadas e isoladas, conectadas a redes de baixa latência, alta velocidade, e altamente redundantes.
Por exemplo, você configurou um NAT gateway público em uma única AZ para permitir que instâncias em uma sub-rede privada enviem tráfego de saída para a Internet. Você implantou instâncias do Amazon Elastic Compute Cloud (Amazon EC2) em várias zonas de disponibilidade.

Figura 5. Avaliação do Resilience Hub para o NAT gateway em uma única AZ

 

A Figura 5 mostra as interrupções na AZ como irrecuperáveis e não atendem às metas de RTO. Os NAT gateways são serviços totalmente gerenciados, não há hardware para gerenciar, portanto, são resilientes (0s de RTO) em caso de falhas de infraestrutura. No entanto, a implantação de apenas um NAT gateway em uma única AZ deixa a arquitetura vulnerável. Se a AZ do NAT gateway ficar inativa, os recursos implantados em outras AZs perderão o acesso à Internet.

Figura 6. Recomendação do Resilience Hub para criar uma arquitetura de NAT gateway independente da AZ.

 

A Figura 6 mostra a recomendação do Resilience Hub de implantar NAT gateways em cada AZ onde os recursos correspondentes do EC2 estão localizados.

Seguindo a recomendação do Resilience Hub, você pode obter o menor RTO e RPO possíveis de 0 segundos no caso de uma interrupção da AZ e criar uma arquitetura independente de AZs com custo de $32,94 por mês.

A implantação do NAT Gateway em várias AZs pode atingir o menor RTO/RPO para interrupção da AZ, o menor custo com alterações mínimas, portanto, a recomendação é a mesma para todas as três opções.

Interrupções em uma região da AWS

Uma região da AWS consiste em várias AZs isoladas e fisicamente separadas dentro de uma área geográfica. Esse design alcança a maior tolerância e estabilidade possíveis a falhas. Para um evento de desastre que inclua o risco de interrupção de vários data centers ou uma interrupção do serviço regional, é uma boa prática considerar uma estratégia de recuperação de desastres multirregionais para mitigar desastres naturais e técnicos que podem afetar uma região inteira na AWS. Se uma ou mais regiões ou serviços regionais usados por sua carga de trabalho usa não estiverem disponíveis, esse tipo de interrupção poderá ser resolvido com a mudança para uma região secundária. Pode ser necessário definir um RTO e um RPO regionais se você tiver uma aplicação dependente de várias regiões.

Por exemplo, você tem um Amazon RDS Single-AZ para MySQL como parte de uma aplicação global de missão crítica e configurou RTO de 30 minutos e RPO de 15 minutos para todos os quatro tipos de interrupção. Cada instância do RDS é executada em uma instância do Amazon EC2 apoiada por um volume Amazon Elastic Block Store (Amazon EBS) para armazenamento. O RDS tira snapshots diários do banco de dados, que são armazenados de forma durável no Amazon S3 nos bastidores. Ele também copia regularmente os registros de transações para o S3, com intervalos de até 5 minutos, fornecendo uma recuperação pontual quando necessário.

Se uma instância de EC2 sofrer uma falha, o RDS tentará automaticamente iniciar uma nova instância na mesma AZ, anexar o volume do EBS e se recuperar. Nesse cenário, o RTO pode variar de minutos a horas. A duração depende do tamanho do banco de dados e da abordagem de falha e recuperação. O RPO é zero no caso de falha da instância recuperável porque o volume do EBS foi recuperado. Se houver uma interrupção na AZ, você poderá criar uma nova instância em uma AZ diferente usando recuperação pontual. O Single-AZ não oferece proteção contra interrupções regionais. A Figura 7 mostra que você não consegue atingir o RTO regional de 30 min e o RPO de 15 minutos.

Figura 7. Avaliação do Resilience Hub para o Amazon RDS

Figura 8. Recomendação do Resilience Hub para alcançar RTO e RPO em nível regional

 

Conforme mostrado na Figura 8, o Resilience Hub fornece três recomendações de optimização a fim de lidar com interrupções na AZ, de forma econômica e com mudanças mínimas.

Recomendação 1 “Otimizar para RTO/RPO da AZ”: as alterações recomendadas nessa opção ajudarão você a obter o menor RTO e RPO possíveis no caso de uma interrupção da AZ. Para um RDS Single-AZ, o Resilience Hub recomenda mudar o banco de dados para Aurora e adicionar duas réplicas de leitura na mesma região para obter RTO e RPO direcionados para falhas na AZ. Também recomenda adicionar uma réplica de leitura em diferentes regiões para obter resiliência para interrupções regionais. O custo estimado dessas mudanças, conforme mostrado na Figura 8, é de $66,85 por mês.

As réplicas de leitura do Amazon Aurora compartilham o mesmo volume de dados da instância original do banco de dados. O Aurora lida com interrupção de AZ automatizando totalmente o failover sem perda de dados. O Aurora cria um cluster de banco de dados altamente disponível com replicação síncrona em várias AZs. Essa é considerada a melhor opção para bancos de dados de produção em que o backup de dados é um fator crítico.

Recomendação 2 “Otimizar o custo”: essas alterações otimizarão sua aplicação para atingir o menor custo atendendo ao RTO e ao RPO desejados. A recomendação aqui é manter um Amazon RDS Single-AZ e criar a réplica de leitura na região primária com uma réplica de leitura adicional em uma região secundária/diferente. O custo estimado dessas mudanças é de $54,38 por mês. Você pode promover uma réplica de leitura em uma instância autônoma como uma solução de recuperação de desastres se a instância de banco de dados primária falhar ou ficar indisponível durante a interrupção da região.

Recomendação 3 “Otimizar para mudanças mínimas”: essas mudanças permitem atingir o RTO e o RPO desejados, com mudanças de implementação mínimas. O Resilience Hub recomenda criar um banco primário Multi-AZ e uma réplica de leitura Multi-AZ em duas regiões diferentes. O custo estimado das alterações é de $81,56 por mês. Quando você provisiona uma instância de banco de dados Multi-AZ, o Amazon RDS cria automaticamente uma instância de banco de dados primária e replica os dados de forma síncrona em uma instância de espera em uma AZ diferente. Em caso de falha na infraestrutura, o Amazon RDS executa um failover automático na instância de banco de dados secundária. Como o endereço de acesso ao banco de dados permanece o mesmo após um failover, sua aplicação pode retomar a comunicação com o banco sem a necessidade de intervenção manual.

Embora todas as três recomendações ajudem você a atingir um RTO e RPO de aplicação específicos de 30 minutos, os custos e esforços estimados podem variar.

Conclusão

Para criar uma carga de trabalho resiliente, você precisa implementar as melhores práticas corretamente. Neste post, mostramos como melhorar a resiliência de sua aplicação e alcançar RTO e RPO considerando interrupções na camada de aplicação, infraestrutura, AZ e regiões, utilizando as recomendações fornecidas pelo Resilience Hub. Para conhecer mais e experimentar o serviço, visite a página do AWS Resilience Hub.