Fundamental multirregional 4: prontidão operacional

Operar uma carga de trabalho multirregional é uma tarefa complexa que vem com desafios operacionais específicos de uma arquitetura multirregional. Isso inclui Conta da AWS gerenciamento, processos de implantação reformulados, criação de uma estratégia de observabilidade em várias regiões, criação e teste de processos de recuperação e, em seguida, gerenciamento do custo. Uma análise de prontidão operacional (ORR) pode ajudar as equipes a preparar uma carga de trabalho para a produção, seja ela sendo executada em uma única região ou em várias regiões.

4.a: gestão Conta da AWS

Para implantar uma carga de trabalho em todas as regiões Regiões da AWS, certifique-se de que haja paridade em todas as AWS service (Serviço da AWS) cotas de uma conta em todas as regiões. Primeiro, identifique tudo o Serviços da AWS que faz parte da arquitetura, analise o uso planejado nas regiões de espera e, em seguida, compare o uso planejado com o uso atual. Em alguns casos, se a região em espera não tiver sido usada antes, você poderá consultar as cotas de serviço padrão para entender o ponto de partida. Em seguida, em todos os serviços que serão usados, solicite um aumento de cota usando o console Service Quotas (é necessário fazer login) ou. APIs

Configure funções AWS Identity and Access Management (IAM) em cada região para dar aos operadores, ferramentas de automação e Serviços da AWS as permissões apropriadas aos recursos dentro da região em espera. Para obter isolamento regional para arquiteturas multirregionais, isole as funções por região. Certifique-se de que as permissões estejam em vigor antes de ativar uma região em espera.

4.b: Práticas de implantação

Os recursos multirregionais podem complicar a implantação de uma carga de trabalho em várias regiões. Você precisa se certificar de implantar em uma região por vez. Por exemplo, se você usar uma abordagem ativa-passiva, deve implantar primeiro na região primária e depois na região de espera. AWS CloudFormationajuda você a implantar a infraestrutura em uma ou várias regiões e pode ser personalizada de acordo com suas necessidades. AWS CodePipelineajuda você a criar um pipeline integration/continuous delivery (CI/CD (contínuo), que tem ações entre regiões que permitem a implantação em regiões diferentes da região em que o pipeline está. Isso, combinado com estratégias robustas de implantação, como azul/verde, permite uma implantação de tempo de inatividade mínimo a zero.

No entanto, a implantação de recursos de monitoramento de estado pode se tornar mais complexa quando o estado do aplicativo ou dos dados não é externalizado para um armazenamento persistente. Nessas situações, adapte cuidadosamente o processo de implantação para atender às suas necessidades. Projete o pipeline e o processo de implantação para implantar em uma região por vez, em vez de implantar em várias regiões simultaneamente. Isso reduz a chance de falhas correlacionadas entre as regiões. Para saber mais sobre as técnicas que a Amazon usa para automatizar implantações de software, consulte o artigo da AWS Builders' Library Automatizando implantações seguras e sem intervenção.

4.c: Observabilidade

Ao projetar para Multirregião, considere como você monitorará a integridade de todos os componentes em cada região para obter uma visão holística da saúde regional. Isso pode incluir métricas de monitoramento para atraso na replicação, o que não é considerado para uma carga de trabalho de uma única região.

Ao criar uma arquitetura multirregional, considere observar também o desempenho da carga de trabalho nas regiões em espera. Isso inclui fazer exames de saúde e canários (testes sintéticos) funcionando na região de espera para fornecer uma visão externa da saúde da região primária. Além disso, você pode usar o Amazon CloudWatch Internet Monitor para entender o estado da rede externa e o desempenho de suas cargas de trabalho do ponto de vista do usuário final. A região primária deve ter a mesma observabilidade para monitorar a região em espera.

Os canários da região de espera devem monitorar as métricas de experiência do cliente para determinar a integridade geral da carga de trabalho. Isso é necessário porque, se houver um problema na região primária, a observabilidade na primária pode ser prejudicada e afetaria sua capacidade de avaliar a saúde da carga de trabalho.

Nesse caso, observar fora dessa região pode fornecer uma visão. Essas métricas devem ser agrupadas em painéis disponíveis em cada região e alarmes criados em cada região. Por ser um serviço regional, CloudWatché necessário ter alarmes nas duas regiões. Esses dados de monitoramento serão usados para fazer a chamada para o failover de uma região primária para uma de espera.

4.d: Processos e procedimentos

O melhor momento para responder à pergunta: “Quando devo falhar?” é muito antes de você precisar. Defina planos de recuperação que incluam pessoas, processos e tecnologia bem antes de um problema e teste-os regularmente. Decida sobre uma estrutura de decisão de recuperação. Se houver um processo de recuperação bem praticado e o tempo de recuperação for bem compreendido, você poderá optar por iniciar o processo de recuperação usando um failover que atenda à meta de RTO. Esse momento pode ocorrer imediatamente após a identificação de um problema com o aplicativo na região principal ou pode ser um evento posterior quando as opções de recuperação do aplicativo na região tiverem sido esgotadas.

A ação de failover em si deve ser 100% automatizada, mas a decisão de ativar o failover deve ser tomada por humanos, geralmente um pequeno número de indivíduos predeterminados na organização. Essas pessoas devem considerar a perda de dados e informações sobre o evento. Além disso, os critérios para um failover precisam ser claramente definidos e compreendidos globalmente dentro da organização. Para definir e concluir esses processos, você pode usar AWS Systems Manager runbooks, que permitem a end-to-end automação completa e garantem a consistência dos processos em execução durante o teste e o failover.

Esses runbooks devem estar disponíveis nas regiões primária e de espera para iniciar os processos de failover ou failback. Quando essa automação estiver em vigor, defina e siga uma cadência de testes regular. Isso garante que, quando houver um evento real, a resposta siga um processo bem definido e praticado no qual a organização tenha confiança. Também é importante considerar as tolerâncias estabelecidas para os processos de reconciliação de dados. Confirme se o processo proposto atende aos requisitos estabelecidos de RPO/RTO.

4.e: Teste

Ter uma abordagem de recuperação não testada é igual a não ter uma abordagem de recuperação. Um nível básico de teste seria executar um procedimento de recuperação para mudar a região operacional do seu aplicativo. Às vezes, isso é chamado de abordagem de rotação de aplicativos. Recomendamos que você crie a capacidade de mudar as regiões para sua postura operacional normal; no entanto, esse teste por si só não é suficiente.

O teste de resiliência também é fundamental para validar a abordagem de recuperação de um aplicativo. Isso envolve a injeção de cenários de falha específicos, a compreensão de como o aplicativo e o processo de recuperação reagem e, em seguida, a implementação de quaisquer mitigações necessárias caso o teste não ocorra conforme o planejado. Testar seu procedimento de recuperação na ausência de erros não lhe dirá como seu aplicativo se comporta como um todo quando ocorrem falhas. Você deve desenvolver um plano para testar sua recuperação em relação aos cenários de falha esperados. AWS Fault Injection Servicefornece uma lista crescente de cenários para você começar.

Isso é especialmente importante para aplicativos de alta disponibilidade, nos quais testes rigorosos são necessários para garantir que as metas de continuidade de negócios sejam atingidas. Testar proativamente os recursos de recuperação reduz o risco de falhas na produção, o que aumenta a confiança de que o aplicativo pode atingir o tempo de recuperação limitado desejado. Os testes regulares também criam experiência operacional, o que permite que a equipe se recupere de forma rápida e confiável das interrupções quando elas ocorrerem. Exercitar o elemento humano, ou processo, de sua abordagem de recuperação é tão importante quanto os aspectos técnicos.

4.f: Custo e complexidade

As implicações de custo de uma arquitetura multirregional são impulsionadas pelo maior uso da infraestrutura, pela sobrecarga operacional e pelo tempo de recursos. Conforme mencionado anteriormente, o custo da infraestrutura em uma região em espera é semelhante ao custo da infraestrutura em uma região primária durante o pré-provisionamento, portanto, dobra seu custo total. Provisione a capacidade de forma que seja suficiente para as operações diárias, mas ainda reserve capacidade de buffer suficiente para tolerar picos na demanda. Em seguida, configure os mesmos limites em cada região.

Além disso, se você estiver adotando uma arquitetura ativa-ativa, talvez seja necessário fazer alterações no nível do aplicativo para executar seu aplicativo com êxito em uma arquitetura multirregional. Essas mudanças podem ser demoradas e intensivas em recursos para projetar e operar. No mínimo, as organizações precisam gastar tempo entendendo as dependências técnicas e comerciais em cada região e projetando processos de failover e failback.

As equipes também devem realizar exercícios normais de failover e failback para se sentirem confortáveis com os runbooks que seriam usados durante um evento. Embora esses exercícios sejam cruciais para obter o resultado esperado de um investimento em várias regiões, eles representam um custo de oportunidade e consomem tempo e recursos de outras atividades.

4.g: Estratégia organizacional de failover multirregional

Regiões da AWS forneça limites de isolamento de falhas que evitem falhas correlacionadas e contenham o impacto das AWS service (Serviço da AWS) deficiências, quando elas ocorrem, em uma única região. Você pode usar esses limites de falha para criar aplicativos multirregionais que consistem em réplicas independentes e isoladas de falhas em cada região para limitar cenários de destino compartilhado. Isso permite que você crie aplicativos multirregionais e use uma variedade de abordagens — do backup e da restauração ao piloto leve e ao ativo-ativo — para implementar sua arquitetura multirregional. No entanto, os aplicativos normalmente não operam isoladamente, portanto, considere os componentes que você usará e suas dependências como parte de sua estratégia de failover. Geralmente, vários aplicativos trabalham juntos para oferecer suporte a uma história de usuário, que é um recurso específico oferecido a um usuário final, como publicar uma foto e uma legenda em um aplicativo de mídia social ou fazer o check-out em um site de comércio eletrônico. Por isso, você deve desenvolver uma estratégia organizacional de failover multirregional que forneça a coordenação e a consistência necessárias para que sua abordagem seja bem-sucedida.

Há quatro estratégias de alto nível que as organizações podem escolher para orientar uma abordagem multirregional. Elas estão listadas da abordagem mais granular à mais ampla:

• Failover em nível de componente

• Failover de aplicativo individual

• Failover do gráfico de dependências

• Failover de todo o portfólio de aplicativos

Cada estratégia tem vantagens e desvantagens e aborda diferentes desafios, incluindo flexibilidade na tomada de decisões de failover, capacidade de testar as combinações de failover, presença de comportamento modal e investimento organizacional em planejamento e implementação. Para se aprofundar em cada estratégia com mais detalhes, consulte a postagem do AWS blog Criação de uma estratégia organizacional de failover multirregional.

Orientação-chave

• Analise todas as AWS service (Serviço da AWS) cotas para garantir que elas estejam em paridade em todas as regiões nas quais a carga de trabalho será operada.

• O processo de implantação deve ter como alvo uma região por vez, em vez de envolver várias regiões simultaneamente.

• Métricas adicionais, como atraso na replicação, são específicas para cenários multirregionais e devem ser monitoradas.

• Estenda o monitoramento da carga de trabalho além da região principal. Monitore as métricas de experiência do cliente para cada região e meça esses dados de fora de cada região na qual uma carga de trabalho está sendo executada.

• Teste o failover e o failback regularmente. Implemente um único runbook para processos de failover e failback e use-o tanto para testes quanto para eventos ao vivo. Os runbooks para testes e eventos ao vivo não devem ser diferentes.

• Entenda as vantagens e desvantagens das estratégias de failover. Implemente um gráfico de dependências ou uma estratégia completa do portfólio de aplicativos.