3½ noves (99,95%) com um tempo de recuperação entre 5 e 30 minutos

Essa meta de disponibilidade para aplicativos exige um tempo de inatividade extremamente curto e perda de dados muito pequena durante tempos específicos. Aplicativos com essa meta de disponibilidade incluem aqueles nas áreas de: bancos, investimento, serviços de emergência e captura de dados. Esses aplicativos têm pontos de recuperação e tempos de recuperação muito curtos.

Podemos melhorar ainda mais o tempo de recuperação usando uma abordagem de Standby passivo abordagem de duas regiões da AWS. Implantaremos toda a carga de trabalho em ambas as regiões, com o nosso site passivo reduzido e todos os dados mantidos eventualmente consistentes. Ambas as implantações terão um comportamento estaticamente estável em suas respectivas regiões. Os aplicativos devem ser criados usando os padrões de resiliência do sistema distribuído. Precisaremos criar um componente leve de roteamento que monitore a integridade da carga de trabalho e que possa ser configurado para rotear o tráfego para a região passiva, se necessário.

Monitorar recursos

Haverá alertas em cada substituição de um servidor da web, quando o banco de dados realizar o failover ou quando a Região realizar o failover. Também monitoraremos o conteúdo estático no Amazon S3 para disponibilidade e alerta se ele ficar indisponível. O registro será agregado para facilitar o gerenciamento e ajudar na análise de causa raiz em cada Região.

O componente de roteamento monitora a integridade do aplicativo e todas as dependências rígidas regionais que temos.

Adaptar-se às mudanças de demanda

Igual ao cenário de quatro noves.

Implementar alterações

A entrega de novo software ocorre conforme um cronograma fixo a cada duas a quatro semanas. As atualizações de software serão automatizadas usando padrões de implantação canário ou azul/verde.

Existem runbooks para quando ocorre o failover da Região, para problemas comuns do cliente que ocorrem durante esses eventos e para relatórios comuns.

Teremos manuais para problemas de banco de dados comuns, incidentes relacionados à segurança, implantações com falha, problemas inesperados do cliente no failover da Região e estabelecimento da causa raiz dos problemas. Depois da identificação da causa raiz, a correção do erro será identificada por uma combinação das equipes de operações e desenvolvimento e implantada quando a correção for desenvolvida.

Também atuaremos com o AWS Support para Gerenciamento de eventos de infraestrutura.

Fazer o backup de dados

Como no cenário de quatro noves, usamos os backups automáticos do RDS e o versionamento do S3. Os dados são replicados de forma automática e assíncrona do cluster do Aurora RDS na região ativa para réplicas de leitura entre regiões na região passiva. A replicação entre regiões do S3 é usada para mover dados de forma automática e assíncrona da região ativa para a passiva.

Arquitetar para resiliência

Igual ao cenário de quatro noves, e também o failover regional é possível. Isso é gerenciado manualmente. Durante o failover, rotearemos solicitações a um site estático usando failover de DNS até a recuperação na segunda Região.

Testar a resiliência

Igual ao cenário de quatro noves, e ainda validaremos a arquitetura por meio de dias de jogos usando runbooks. A correção de RCA também tem prioridade sobre versões de recursos para implementação e implantação imediatas.

Planejar para a recuperação de desastres (DR)

O failover regional é gerenciado manualmente. Todos os dados são replicados de forma assíncrona. A infraestrutura no standby passivo é expandida. Isso pode ser automatizado usando um fluxo de trabalho executado no AWS Step Functions. O AWS Systems Manager (SSM) também pode ajudar com essa automação, pois você pode criar documentos do SSM que atualizam grupos de Auto Scaling e redimensionam instâncias.

Meta de design de disponibilidade

Presumimos que pelo menos algumas falhas exigirão uma decisão manual de executar a recuperação, porém, com uma boa automação neste cenário, presumimos que apenas dois eventos por ano exigirão essa decisão. Levamos 20 minutos para decidir executar a recuperação e presumimos que a recuperação estará concluída dentro de 10 minutos. Isso implica cerca de 30 minutos para a recuperação de uma falha. Presumindo duas falhas por ano, nosso tempo de impacto estimado para o ano é de 60 minutos.

Isso significa que o limite superior de disponibilidade é de 99,95%. A disponibilidade geral dependerá também da taxa real de falha, da duração da falha e da rapidez com que cada falha se recupera realmente. Para essa arquitetura, presumimos que o aplicativo está online continuamente por meio de atualizações. Com base nisso, nossa meta de design de disponibilidade é 99,95%.

Resumo

Tópico	Implementação
Monitorar recursos	Verificações de integridade em todas as camadas, incluindo integridade de DNS no nível de região da AWS, e em KPIs; em alertas enviados quando os alarmes configurados são acionados; enviando alertas sobre todas as falhas. As reuniões operacionais são rigorosas para detectar tendências e gerenciar conforme as metas de design.
Adaptar-se às mudanças de demanda	ELB para nível de aplicativo de escalabilidade automática e web; armazenamento de escalabilidade automática e réplicas de leitura em várias zonas nas regiões ativas e passivas do Aurora. Dados e infraestrutura sincronizados entre regiões da AWS para estabilidade estática.
Implementar alterações	Implantação automatizada por meio de canário ou azul/verde e reversão automatizada quando os KPIs ou os alertas indicam problemas não detectados na aplicação, as implantações são feitas em uma zona de isolamento e em uma região da AWS de cada vez.
Fazer o backup de dados	Backups automatizados em cada região da AWS por meio do RDS para atender ao RPO e restauração automatizada praticada regularmente em um dia de jogo. Os dados do Aurora RDS e do S3 são replicados de forma automática e assíncrona da região ativa para a passiva.
Arquitetar para resiliência	Escalabilidade automática para fornecer nível de aplicativo e web com autorrecuperação; RDS é Multi-AZ; failover regional é gerenciado manualmente com local estático apresentado durante o failover.
Testar a resiliência	O teste de falha de zona de isolamento e componente está no pipeline e é praticado com a equipe operacional regularmente em um dia de jogo; existe um manual para diagnosticar problemas desconhecidos e existe um processo de Análise de causa raiz com caminhos de comunicação para qual era o problema e como ele foi corrigido ou prevenido. A correção de RCA tem prioridade sobre versões de recursos para implementação e implantação imediatas.
Planejar para a recuperação de desastres (DR)	Standby passivo implantado em outra região. A infraestrutura é expandida usando fluxos de trabalho executados com o uso de documentos do AWS Step Functions ou do AWSSystems Manager. Backups criptografados via RDS. Réplicas de leitura entre regiões entre duas regiões da AWS. Replicação entre regiões de ativos estáticos no Amazon S3. A restauração é para a região da AWS ativa no momento, praticada em um dia de jogo e coordenada com a AWS.