O blog da AWS

Continuidade de negócios na AWS: Disponibilidade e resiliência

Por Horacio Ferro, Arquiteto de Soluções, AWS México

 

Trabalhando com nossos clientes na arquitectura de seus sistemas, geralmente temos requisitos de nível de serviço ou Acordo de Nível de Serviço (SLA), que definem diferentes atributos do sistema. Por exemplo, um SLA de disponibilidade de 99,99% indica que o sistema que estamos projetando não deve exceder 52,56 minutos indisponibilide em 365 dias. Ou, por exemplo, um SLA de durabilidade de 99,99% nos diz que por um giga-byte (GB) de informações não devemos superar a perda de informações em mais de 100 bytes.

Em termos de recuperação de desastres, temos duas métricas principais: Objetivo de Ponto de Recuperação ou Objetivo de Ponto de Recuperação (RPO, inglês), que nos diz quanto tempo ele pode existir em termos de perda de informações, por exemplo, um RPO de uma hora indica que, se o sistema falhou às 12:00pm, devemos ser capazes de contar com todas as alterações de informações geradas até 11:00 da manhã, ou seja, devemos ter mecanismos necessário para capturar tal mudança de informação e protegê-lo em uma localidade secundária. O Objetivo de Tempo de Recuperação (RTO, em inglês) indica quanto tempo o sistema pode estar indisponível, por exemplo, se o RTO for 1hr e o sistema falhar às 12:00, o sistema deve ter sua funcionalidade 100% restabelecida às 13:00.

Quando projetamos uma arquitetura de software, inicialmente nos concentramos em requisitos funcionais, ou seja, o que nosso sistema precisa resolver. Uma vez que temos essa arquitetura, é necessário garantir nossos atributos de qualidade, como níveis de serviço (SLAs). Usando nosso AWS Well Architected Framework, especificamente o pilar de confiabilidade, podemos robustecer nossa arquitetura para alcançar SLAs específicos.

Na AWS, nossa infraestrutura é distribuída geograficamente em regiões, essas regiões são isoladas umas das outras, tanto geograficamente quanto em software. Ou seja, se houver alguma catástrofe natural, as regiões são suficientemente afastadas e isoladas para não serem afectadas todas ao mesmo tempo, e os serviços são implantados de forma independente em cada uma dessas regiões.

Em uma região da AWS, temos diferentes zonas de disponibilidade, essas zonas de disponibilidade estão a uma distância que permita latências de 1 ms, têm sistemas redundantes e há uma distância entre elas para reduzir o risco de um evento natural que possa afetar mais de uma zona de disponibilidade. Saiba mais aqui e neste vídeo de Peter DeSantis há uma explicação adicional sobre a infraestrutura na AWS.

Veja alguns exemplos de níveis de disponibilidade alcançados usando várias zonas de disponibilidade e uma ou mais regiões:

  • Uma única região e uma ou mais zonas de disponibilidade:
    • 99% Aplicações úteis para o negócio, se não estiverem disponíveis apenas causam inconvenientes.
    • 99,9% Aplicações que podem tolerar a intermitência na sua recuperação.
    • 99,99% Aplicativos que devem ter alta disponibilidade e tolerância a falhas em qualquer um de seus componentes.
  • Várias regiões e várias zonas de disponibilidade:
    • 99,95% Aplicações com recuperação entre 5 e 30 minutos.
    • 99,999% Aplicações com recuperação em menos de 1 minuto.

Com base nas definições acima, como alcançamos esses objetivos robustecendo nossa arquitetura?

O primeiro passo é conhecer cada um dos componentes que compõem nossa arquitetura e seus SLAs independentes. A fim calcular o SLA de um sistema simplesmente multiplicar os SLAs diferentes uns com os outros. Exemplo:

 

 

Como podemos aumentar o SLA?

Para aumentar o SLA de um aplicativo, você precisa introduzir redundância e tolerância a falhas em todos os componentes da arquitetura, desde o cliente até a camada de persistência de dados. No exemplo a seguir, usaremos os seguintes serviços para conseguir isso:

  • Amazon Route 53 – Usando este serviço, obteremos um SLA 100% para resolução de nomes (DNS).
  • Amazon Application Load Balancer (ALB) – Esse serviço nos permite balancear solicitações e resiliência caso qualquer instância do EC2 falhe, reinicie ou desligue. Além disso, o uso de um grupo de Auto Scaling nos permite registrar/excluir dinamicamente instâncias do EC2 que são adicionadas ou paradas.
  • Amazon Elastic Cloud Compute (EC2) — Em instâncias do EC2, instalaremos os diferentes serviços, uma instância do EC2 nos forneceu um SLA de 90%, para obter 99,99% você precisa usar diferentes zonas de disponibilidade, oferecer suporte a grupos de auto escalabilidade (Auto Scaling Group) e um balanceador de cargas (ALB).
  • Amazon Relational Database Service (RDS) – A implantação de várias zonas de disponibilidade (Multi AZ) deve ser de 99,99% de SLA.

Nesta liga podemos encontrar os SLAs atualizados dos diferentes serviços – https://thinkwithwp.com/legal/service-level-agreements/

A arquitetura a seguir tem um SLA de 99,95% (99,99% 5 = 99,95001%) usando várias zonas de disponibilidade dentro de uma região da AWS, como podemos ver no diagrama abaixo.

 

 

Usando essa arquitetura em duas regiões, podemos obter o seguinte SLA:

Porcentagem de indisponibilidade de aplicativos em uma região 100% – 99,95% = 0,05% (até 4,38 horas por ano)

Percentual de indisponibilidade de aplicativos em duas regiões combinadas 0,05% * 0,05% = 0,000025% (Até 7.884 segundos por ano)

SLA total usando ambas as regiões = 100% – 0,000025% = 99,999975%

 

 

NOTA: Se usarmos essa arquitetura em várias regiões, você precisará alternar o serviço do Amazon RDS para outro serviço que funcione em várias regiões como ativo/ativo, como o banco de dados global do Amazon Aurora e neste caso tenha em conta a latência de replicação para o cálculo do SLA e o seu efeito sobre o RPO/RTO da sua aplicação.

 

Como posso reduzir a complexidade na arquitetura, tempo de gerenciamento e custos?

A implantação da arquitetura anterior em duas regiões aumenta significativamente a complexidade, o esforço administrativo e os custos. Em seguida, vamos projetar uma arquitetura semelhante usando duas ou mais regiões, mas com serviços sem servidor (Serverless), com os quais vamos reduzir os custos inserindo um esquema de carga para uso sem infraestrutura ociosa, reduzir a complexidade da arquitetura e esforço administrativo por ser serviços gerenciados.

  • Amazon Route 53 – Usando este serviço, obteremos um SLA 100% para resolução de nomes (DNS).
  • Amazon CloudFront – Esse serviço nos permite ter um cache próximo aos nossos clientes, tem um SLA de 99,9%, usando o Origin Fail Over , podemos registrar duas fontes diferentes para combinar SLAs e ter melhor disponibilidade.
  • Amazon Simple Storage Service (S3) – Usando este serviço, podemos hospedar um site estático, esse serviço tem um SLA de 99,9%. Ao ativar a replicação ou outra região, podemos aumentar esse SLA.
  • Amazon API Gateway – Com esse serviço, podemos hospedar APIs REST e conectá-las a outros serviços, o API Gateway nos fornece um SLA de 99,95%.
  • AWS Lambda — Neste serviço, podemos hospedar nossos micros serviços obtendo um SLA de 99,95%.
  • Amazon RDS – Este serviço nos fornece um SLA de 99,99%.

Calculando o SLA combinado de serviços 99,9% * 99,9% * 99,95% * 99,95% * 99,99% = 99,69% obtemos um SLA 0,24% abaixo do SLA da arquitetura tradicional, mas em troca obtemos uma arquitetura mais simples, menos componentes para gerenciar e reduzir o custo por não ter infraestrutura ociosa. Se adicionarmos outra região da AWS a essa arquitetura, alcançaremos 99,999% de SLA.

 

 

O que posso implementar se meus requisitos de serviço não forem tão rigorosos?

Há cenários em que o custo de ter uma infraestrutura duplicada não é justificável, ou seja, não ter o sistema por alguns minutos ou mesmo horas, pode não afetar a continuidade dos negócios. Nesses casos, existem alternativas que podemos usar como um plano de recuperação de desastres, no qual o RPO (Recovery Point Objective) e o RTO (Recovery Time Objective) serão a base para selecionar o método mais adequado.

  • Backups e recuperação Esse é o método mais simples e econômico para criar um plano de recuperação de desastres, é gerar backups, executar um plano de recuperação e executar testes diários desse plano. Para que esse tipo de plano de recuperação de desastres seja viável, nossos RPOs e RTOs não podem ser muito baixos, leve em conta que, ao implementar esse plano, toda a infraestrutura deve ser restaurada e pode levar várias horas ou mesmo dias dependendo da complexidade do sistema.
  • Luz Piloto. A ideia após este tipo de recuperação de desastres é uma analogia de um piloto de aquecedor a gás, tendo o mínimo necessário para iniciar o ambiente. Este esquema de recuperação de desastres tem uma pequena parte da infra-estrutura ativa, mantendo uma sincronização de dados mutáveis (bancos de dados, arquivos compartilhados, etc.). Essa infraestrutura deve permitir que o restante da infraestrutura seja implantado automaticamente para reduzir os tempos de RPO e RTO, ao contrário da estratégia de backup e restauração, aqui falamos em uma escala de minutos a horas.
  • Espera quente. Ao contrário da chama piloto, a espera quente contém uma réplica exata da infraestrutura, mas em pequena escala, ou seja, temos todos os componentes do aplicativo original, mas com recursos reduzidos. Neste caso, o site alternativo levará menos tempo para estar 100% disponível, pois só requer escalonamento para demanda no momento do incidente, reduzindo ainda mais o RPO e o RTO, neste caso estaríamos em uma escala de segundos a minutos.

Conclusão:

Para obter 99,999% de SLA ou disponibilidade, é sempre necessário considerar um ambiente multirregião.

Uma região da AWS pode fornecer até 99,99% de disponibilidade para alguns serviços.

O uso do serviços Serverless reduz consideravelmente a complexidade da implantação e da manutenção, eliminando o gerenciamento de componentes individuais e automatizando tarefas como auto escalonamento e tolerância a falhas.

Próximos passos:

Exercite o uso da ferramenta Well Architected Framework para identificar o nível atual de SLA em relação ao nível desejado e fazer os ajustes necessários.

 

Este artigo foi traduzido do Blog da AWS em Espanhol

 

Sobre el autor

Horacio Ferro é Arquiteto de Soluções na  AWS México.

 

 

 

 

Revisores técnicos:

Raul Frias é Arquiteto de Soluções.

 

 

 

 

Carlos Castro Arquiteto de Soluções Principal Outposts.

 

 

 

 

Felipe De Bene é Arquiteto de Soluções n