Princípio fundamental da multirregião 1: Compreender os requisitos - AWS Orientação prescritiva

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Princípio fundamental da multirregião 1: Compreender os requisitos

Conforme mencionado anteriormente, a alta disponibilidade e a continuidade das operações são motivos comuns para buscar arquiteturas multirregionais. As métricas de disponibilidade medem a porcentagem de tempo em que uma carga de trabalho está disponível para uso em um período definido, enquanto as métricas de continuidade das operações medem o tempo de recuperação de eventos de grande escala e, normalmente, de maior duração.

Medir a disponibilidade é um processo quase contínuo. As medições específicas podem variar, mas normalmente se aglutinam em torno de uma métrica de disponibilidade alvo, geralmente chamada de nove (como disponibilidade de 99,99%). Com metas de disponibilidade, um tamanho único não serve para todos. Você deve estabelecer metas de disponibilidade no nível da carga de trabalho e separar os componentes não críticos dos componentes críticos, em vez de aplicar uma única meta em todas as cargas de trabalho.

Para a continuidade das operações, as seguintes point-in-time medidas são normalmente usadas:

  • Objetivo de tempo de recuperação (RTO) — RTO é o atraso máximo aceitável entre a interrupção do serviço e a restauração do serviço. Esse valor determina uma duração aceitável pela qual o serviço está comprometido.

  • Objetivo de ponto de recuperação (RPO) — RPO é o tempo máximo aceitável desde o último ponto de recuperação de dados. Isso determina o que é considerado uma perda de dados aceitável entre o ponto de recuperação mais recente e a interrupção do serviço.

Assim como definir metas de disponibilidade, o RTO e o RPO também devem ser definidos no nível da carga de trabalho. Uma continuidade mais agressiva das operações ou a alta disponibilidade exigem maior investimento. Dito isso, nem todo aplicativo pode exigir ou exigir o mesmo nível de resiliência. Alinhar os proprietários de negócios e de TI para avaliar a importância dos aplicativos com base no impacto nos negócios e, em seguida, classificá-los adequadamente pode ajudar a fornecer um ponto de partida. As tabelas a seguir fornecem exemplos de hierarquização.

Esta tabela mostra um exemplo de escalonamento de resiliência para contratos de nível de serviço (). SLAs

Nível de resiliência Disponibilidade do SLA Tempo de inatividade aceitável/ano

Platina

99,99%

52.60 minutos

Ouro

99,90%

8.7 horas

Prata

99,5%

1,83 dias

A tabela a seguir mostra um exemplo de escalonamento de resiliência para RTO e RPO.

Nível de resiliência RTO máximo RPO máximo Critérios Custo

Platina

15 minutos

5 minutos

Cargas de trabalho de missão crítica

$$$

Ouro

15 minutos — 6 horas

2 horas

Cargas de trabalho importantes, mas não essenciais

$$

Prata

6 horas — alguns dias

24 horas

Cargas de trabalho não críticas

$

Ao projetar cargas de trabalho para resiliência, considere a relação entre alta disponibilidade e continuidade das operações. Por exemplo, se uma carga de trabalho exigir disponibilidade de 99,99%, não mais do que 53 minutos de inatividade por ano são toleráveis. Pode levar pelo menos 5 minutos para detectar uma falha e outros 10 minutos para que um operador se envolva, tome decisões sobre as etapas de recuperação e execute essas etapas. Não é incomum levar de 30 a 45 minutos para se recuperar de um único problema. Nesse caso, é vantajoso ter uma estratégia multirregional para fornecer uma instância isolada que elimine o impacto correlacionado. Isso permite operações contínuas por meio de falhas dentro de um tempo limitado, enquanto você faz a triagem da deficiência inicial de forma independente. É aqui que é necessário definir o tempo de recuperação limitado apropriado e garantir o alinhamento.

Uma abordagem multirregional pode ser apropriada para cargas de trabalho de missão crítica que têm necessidades extremas de disponibilidade (por exemplo, disponibilidade de 99,99 por cento ou mais) ou requisitos rigorosos de continuidade de operações que só podem ser atendidos com o failover em outra região. No entanto, esses requisitos geralmente são aplicáveis somente a um pequeno subconjunto do portfólio de carga de trabalho de uma empresa que tem um tempo de recuperação limitado medido em minutos ou horas. A menos que um aplicativo precise de um tempo de recuperação de minutos ou algumas horas, talvez seja melhor esperar que uma interrupção regional do aplicativo seja corrigida na região afetada. Essa abordagem geralmente está alinhada com cargas de trabalho de nível inferior.

Antes de implementar uma arquitetura multirregional, os tomadores de decisão de negócios e as equipes técnicas devem estar alinhados sobre as implicações de custo, incluindo fatores de custo operacional e de infraestrutura. Uma arquitetura típica de várias regiões pode ter um custo duas vezes maior do que uma abordagem de região única. Embora existam vários padrões multirregionais para a continuidade dos negócios, como operar com espera quente, espera quente ou luz piloto, o padrão com o menor risco de atingir os objetivos de recuperação envolverá a execução de espera dinâmica e dobrará o custo de sua carga de trabalho.

Orientação-chave

  • As metas de disponibilidade e continuidade das operações, como RTO e RPO, devem ser estabelecidas por carga de trabalho e alinhadas com os negócios e as partes interessadas de TI.

  • A maioria das metas de disponibilidade e continuidade das operações pode ser alcançada em uma única região. Para metas que não podem ser alcançadas em uma única região, considere a opção Multirregião com uma visão clara das compensações entre custo, complexidade e benefícios.