Uma abordagem multidimensional proativa para evitar falhas operacionais, Parte 2: Camada de Infraestrutura

Figura 1. Probabilidade e impacto de eventos de falha

Conforme demonstrado na Figura 1, a resiliência da infraestrutura é uma combinação de alta disponibilidade (HA) e recuperação de desastres (DR). Alta disponibilidade envolve aumentar a disponibilidade do sistema implementando redundância entre os componentes e removendo pontos de falha.

Algumas decisões feitas na camada de aplicação, como por exemplo utilizar um padrão stateless, simplificam a implementação de HA na camada de infraestrutura, permitindo que ela seja dimensionada usando grupos de Auto Scaling e distribuindo aplicação redundantes em várias AZs.

Padrão 2: Entendendo e controlando falhas de infraestrutura

Para construir uma infraestrutura resiliente é necessário entender quais falhas de infraestrutura estão sob controle e quais não estão, conforme demonstrado na Figura 2.

Com base nesse conhecimento, podemos automatizar a detecção de falhas, controlá-las, e empregar padrões pró-ativos, como estabilidade estática, para mitigar qualquer necessidade de redimensionar a infraestrutura durante períodos críticos, provisionando adequadamente os componentes mínimos necessários para operação.

Algumas das decisões de infraestrutura que estão sob nosso controle e que podem aumentar a resiliência de infraestrutura incluem:

• Os serviços da AWS possuem um plano de controle(control plane) e um plano de dados(data plane), projetados para diminuir impactos significativos nos serviços. Os data planes geralmente têm objetivos de disponibilidade mais altas do que os control planes, e geralmente são menos complexos. Ao implementar planos de resiliência, devemos diminuir a dependência em operações que são executadas pelo control plane. Por exemplo, o serviço Amazon Route 53 (Route 53) tem um data plane projetado para um SLA de 100% de disponibilidade. Um bom mecanismo de resiliência deve depender do data plane, e não do plano de controle, conforme explicado em Criação de mecanismos de recuperação de desastres usando o Amazon Route 53.
• Compreender a arquitetura de rede e as rotas implementadas em uma nuvem privada virtual (VPC) são essenciais ao testar o tráfego de aplicações. Compreender o fluxo de tráfego ajuda a projetar aplicações mais eficientes, além de analisar como uma falha de componente pode afetar o tráfego de uma forma geral. Para aumentar a resiliência da rede, é importante implementar uma estratégia adequada para o controle de subnets e endereçamento IP, evitando problemas de roteamento em caso de falha ou ativação de DR. Utilize ferramentas de gerenciamento de endereço IP para gerenciar subnets, roteamento, e endereçamento IP.
• Ao projetar VPCs e AZs, procure entender os limites de cada serviço, implante tabelas e componentes de roteamento independentes em cada AZ, aumentando assim a disponibilidade da rede. Por exemplo, ao utilizar o NAT Gateway da AWS ao invés de instâncias que efetuem serviço de NAT, obtém-se maior disponibilidade, conforme exemplificado na comparação disponibilizada na documentação de VPC.

Padrão 3: Considerando as diferentes formas de aumentar a disponibilidade na camada de infraestrutura

Conforme já detalhado, resiliência de infraestrutura = HA + DR.

Diferentes formas pelas quais a disponibilidade de aplicações pode ser aprimorada, incluem:

• Construindo com redundância: Redundância é a duplicação de componentes de aplicação para aumentar a disponibilidade geral de um sistema distribuído. Após seguir as melhores práticas recomendadas na camada de aplicação, podemos criar mecanismos de recuperação automática na camada de infraestrutura.

Podemos aproveitar os recursos de Auto Scaling, e utilizar as métricas e alarmes do Amazon CloudWatch para automatizar a configuração de instancias em múltiplas AZs. Isso pode proteger aplicações contra eventuais falhas de AZ conforme mostrado na Figura 3.

Figura 3. Redundância aumenta disponibilidade

• Dimensionamento automático de infraestrutura: ao ocorrer falhas em uma AZ, o Auto Scaling mantém o número de componentes necessários para manter os tempos de resposta das aplicações nos níveis desejados. Desta forma, a alta disponibilidade e os custos serão mantidos. O dimensionamento automático deve utilizar métricas para aumentar ou diminuir o número de recursos necessários de forma adequada, conforme mostrado na Figura 4.

Figura 4. Como o escalonamento automático melhora a disponibilidade

• Implemente padrões de conectividade de rede resilientes: ao criar sistemas distribuídos altamente resilientes, o acesso de rede à infraestrutura da AWS também precisa ser altamente resiliente. Ao implantar aplicações híbridas, a capacidade necessária para que elas se comuniquem com os aplicativos nativos da nuvem é uma consideração importante. O AWS Direct Connectou VPNs são opções que devem ser consideradas para tal comunicação.

Testar cenários de failover e fallback ajuda a validar se as conexões de rede operam conforme o esperado, com as rotas fazendo failover para atender aos objetivos de RTO. À medida que o número de pontos de conexão entre o datacenter e as VPCs da AWS aumenta, uma configuração de hub and spoke fornecida pelo Direct Connect gateway e transit gateways simplificam a topologia, testes e o failover da rede. Para obter mais informações, verifique as Recomendações de resiliência do AWS Direct Connect.

• Sempre que possível, use o backbone de rede da AWS para aumentar a segurança, a resiliência e reduzir custos. O AWS PrivateLink fornece acesso seguro aos serviços da AWS, expondo funcionalidades e APIs de aplicação para outras unidades de negócios ou contas de parceiros também hospedadas na AWS.
• Os dispositivos de segurança precisam ser configurados com alta disponibilidade, para que, caso uma AZ não esteja disponível, os controles de segurança possam ser realizados pelos dispositivos redundantes nas outras AZs.
• Pense com antecedência sobre a resolução de DNS: o DNS é um componente crítico de infraestrutura. Uma resolução de DNS híbrida deve ser projetada com cuidado, utilizando os dispositivos de resolução de nomes do Route 53 HA, ao invés de dispositivos independentes de proxy.

Implemente uma boa estratégia para compartilhar regras de resolução de DNS entre contas da AWS e VPCs utilizando o Resource Access Manager. Os testes de failover de rede são uma parte importante dos Planos de Recuperação de Desastres e Continuidade de Negócios. Para saber mais, acesse Configurar resolução de DNS integrada para redes híbridas no Amazon Route 53 

• Utilize serviços gerenciados: o mesmo conceito de redundância em componentes de aplicações que afetam a disponibilidade se aplica aos componentes de infraestrutura da AWS. Serviços da AWS, como AWS Lambda, Amazon Simple Queue Service, Elastic Load Balancing (ELB), e Amazon Simple Storage Service, utilizam múltiplas AZs para sua própria resiliência.

Além disso, os ELBs utilizam verificações de acessibilidade constantes garantindo que solicitações de usuários sejam roteadas para outro componente, caso um dos componentes falhe. Isso melhora a disponibilidade total do sistema distribuído, pois cada camada colabora para a disponibilidade total do sistema. A Figura 5 detalha as vantagens de alguns serviços gerenciados da AWS.

Figura 5. Os serviços gerenciados da AWS ajudam na construção de infraestruturas resilientes (clique na imagem para ampliar)

Padrão 4: Utilize os requisitos de RTO e RPO para determinar a estratégia de failover correta para sua aplicação

Documente os requisitos de RTO e RPO antecipadamente, para determinar estratégias seguras de failover (Figura 6). As estratégias de recuperação de desastres na AWS variam de baixo custo e complexidade (como backup & restore) a estratégias mais complexas, quando são necessários valores mais baixos de RTO e RPO.

No pilot light e warm standby, apenas a região primária recebe tráfego. Na pilot light, apenas componentes críticos de infraestrutura são carregados na região de backup. A automação é utilizada para verificar falhas na região primária, usando verificações de acessibilidade e outras métricas.

Quando as verificações de acessibilidade falharem, use uma combinação de grupos de Auto-Scaling, e automação de infraestrutura-como-código (IaC) para a implantação rápida de outros componentes necessários.

Observação: essa estratégia depende da disponibilidade do control plane na região secundária para implantação dos recursos; tenha em mente que se não houver computação previamente provisionada na região secundária, nada poderá ser provisionado em caso de desastre. Considere cuidadosamente os requisitos de negócio e as características da nível de serviço da aplicação, antes de decidir sobre uma estratégia de failover. Para entender todos os fatores e complexidades envolvidos em cada uma dessas estratégias de recuperação de desastres, consulte as opções de recuperação de desastres na nuvem

Figura 6. Relação entre RTO, RPO, custo, perda de dados e duração da interrupção do serviço

Conclusão

Na Parte 2 desta série, descrevemos que a resiliência de infraestrutura é uma combinação de HA e DR. É importante considerar a probabilidade e o impacto de diferentes eventos de falha em relação aos requisitos de disponibilidade. Criando padrões de resiliência na camada de aplicação Parte 1, juntamente com a documentação antecipada dos requisitos de RTO/RPO, bem como a resiliência operacional e de processo de uma organização, ajudam a escolher os serviços gerenciados que melhor atendem as necessidades, e a implementar estratégias de failover mais apropriadas.

É importante diferenciar as características de carga normal e anormal para aplicações, para implementar automação, alertas e notificações de alarmes. Isso nos permite dimensionar automaticamente nossa infraestrutura para carga normal esperada, além de implementar ações corretivas e automação para erradicar problemas em caso de anomalias. Use IaC para fazer um failover rápido e teste seus processos de failover frequentemente.

Na Parte 3 desta série, discutimos a resiliência operacional!