Pilar Confiabilidade da Lente do Well-Architected para o Amazon ElastiCache
O pilar de confiabilidade se concentra nas workloads que executam as funções pretendidas e em como se recuperar rapidamente de falhas para atender às demandas. Os principais tópicos incluem projeto de sistema distribuído, planejamento de recuperação e adaptação às mudanças de requisitos.
Tópicos
CONF 1: Como você está oferecendo suporte a implantações de arquitetura de alta disponibilidade (HA)?
Introdução: compreender a arquitetura de alta disponibilidade do Amazon ElastiCache permitirá que você opere em um estado resiliente durante eventos de disponibilidade.
Benefício: arquitetar seus clusters do ElastiCache para que sejam resilientes a falhas garante maior disponibilidade para suas implantações do ElastiCache.
-
[Obrigatório] Determine o nível de confiabilidade necessário para seu cluster do ElastiCache. Workloads diferentes têm padrões de resiliência diferentes, desde workloads totalmente efêmeras até workloads essenciais à missão. Defina as necessidades de cada tipo de ambiente que você opera, como desenvolvimento, teste e produção.
Mecanismo de armazenamento em cache: ElastiCache para Memcached versus ElastiCache para Valkey e Redis OSS
-
O ElastiCache para Memcached não fornece nenhum mecanismo de replicação e é usado principalmente para workloads efêmeras.
-
O ElastiCache para Redis OSS oferece os atributos de HA discutidos abaixo.
-
-
[Ideal] Para workloads que exigem HA, use o ElastiCache no modo de cluster com no mínimo duas réplicas por fragmento, mesmo para workloads com requisitos de throughput baixa que exijam apenas um fragmento.
-
Com o modo de cluster habilitado, o multi-AZ é habilitado automaticamente.
O multi-AZ minimiza o tempo de inatividade realizando failovers automáticos do nó primário para as réplicas, em caso de manutenção planejada ou não planejada, além de mitigar falhas em AZ.
-
Para workloads fragmentadas, uma quantidade mínima de três fragmentos fornece uma recuperação mais rápida durante eventos de failover, pois o protocolo de cluster do Valkey ou Redis OSS exige que a maioria dos nós primários esteja disponível para ter quórum.
-
Configure duas ou mais réplicas em toda a disponibilidade.
Ter duas réplicas proporciona maior escalabilidade de leitura e também disponibilidade de leitura em cenários em que uma réplica passa por manutenção.
-
Use tipos de nó baseados em Graviton2 (nós padrão na maioria das regiões).
O ElastiCache apresenta desempenho otimizado nesses nós. Como resultado, você obtém melhor performance de replicação e sincronização, resultando em maior disponibilidade geral.
-
Monitore e ajuste o tamanho certo para lidar com picos de tráfego previstos: sob carga pesada, o mecanismo pode deixar de responder, o que afeta a disponibilidade.
BytesUsedForCacheeDatabaseMemoryUsagePercentagesão bons indicadores do uso da memória, enquantoReplicationLagé um indicador da integridade de replicação com base na taxa de gravação. Você pode usar essas métricas para acionar o ajuste de escala do cluster. -
Garanta a resiliência do lado do cliente testando com a API de failover antes de um evento de failover na produção
.
[Recursos]:
-
CONF 2: Como você está cumprindo seus objetivos de ponto de recuperação (RPOs) com o ElastiCache?
Introdução: entenda o RPO da workload para embasar as decisões sobre estratégias de backup e recuperação do ElastiCache.
Benefício: ter uma estratégia de RPO em vigor pode melhorar a continuidade dos negócios nos cenários de recuperação de desastres. Projetar políticas de backup e restauração pode ajudar você a atingir seus objetivos de ponto de recuperação (RPO) para seus dados do ElastiCache. O ElastiCache oferece recursos de snapshot que são armazenados no Amazon S3, com uma política de retenção configurável. Esses instantâneos são gerados durante uma janela de backup definida e gerenciados automaticamente pelo serviço. Se sua workload exigir granularidade de backup adicional, você tem a opção de criar até 20 backups manuais por dia. Os backups criados manualmente não têm uma política de retenção de serviços e podem ser mantidos indefinidamente.
-
[Obrigatório] Entenda e documente o RPO de suas implantações do ElastiCache.
-
Lembre-se de que o Memcached não oferece nenhum processo de backup.
-
Analise a capacidade dos atributos de backup e restauração do ElastiCache.
-
-
[Ideal] Implemente um processo bem comunicado para fazer backup do cluster.
-
Inicie backups manuais conforme necessário.
-
Analise as políticas de retenção para backups automáticos.
-
Observe que os backups manuais serão mantidos indefinidamente.
-
Agende seus backups automáticos durante períodos de baixo uso.
-
Execute operações de backup em réplicas de leitura para garantir a minimização do impacto na performance do cluster.
-
-
[Bom] Aproveite o atributo de backup agendado do ElastiCache para fazer backup regular de seus dados durante uma janela definida.
-
Teste periodicamente as restaurações de seus backups.
-
-
[Recursos]:
CONF 3: Como você oferece suporte aos requisitos de recuperação de desastres (DR)?
Introdução: a recuperação de desastres é um aspecto importante do planejamento de qualquer workload. O ElastiCache oferece várias opções para implementar a recuperação de desastres com base nos requisitos de resiliência da workload. Com o Amazon ElastiCache Global Datastore, você pode gravar em seu cluster em uma região e disponibilizar os dados para leitura em outros dois clusters de réplica entre regiões, viabilizando leituras de baixa latência e recuperação de desastres em várias regiões.
Benefício: compreender e se planejar para uma variedade de cenários de desastre pode garantir a continuidade dos negócios. As estratégias de DR devem equilibrar custo, impacto na performance e potencial de perda de dados.
-
[Obrigatório] Desenvolva e documente estratégias de DR para todos os seus componentes do ElastiCache com base nos requisitos da workload. O ElastiCache é único porque alguns casos de uso são totalmente efêmeros e não exigem nenhuma estratégia de DR, enquanto outros estão na extremidade oposta do espectro e exigem uma estratégia de DR extremamente robusta. Todas as opções devem ser ponderadas em relação à otimização de custos: maior resiliência requer mais recursos de infraestrutura.
Entenda as opções de DR disponíveis em nível regional e multirregional.
-
As implantações multi-AZ são recomendadas para evitar falhas de AZ. Realize a implantação com o modo de cluster habilitado em arquiteturas multi-AZ, com um mínimo de 3 AZs disponíveis.
-
O Global Datastore é recomendado para se proteger contra falhas regionais.
-
-
[Ideal] Habilite o Global Datastore para workloads que exigem resiliência por região.
-
Tenha um plano para realizar failover para a região secundária em caso de degradação da primária.
-
Teste o processo de failover multirregional antes de um failover na produção.
-
Monitore a métrica
ReplicationLagpara entender o impacto potencial da perda de dados durante eventos de failover.
-
-
[Recursos]:
CONF 4: Como se planejar efetivamente para os failovers?
Introdução: habilitar o multi-AZ com failovers automáticos é uma prática recomendada do ElastiCache. Em certos casos, o ElastiCache para Valkey e Redis OSS substitui os nós primários como parte das operações de serviço. Exemplos incluem eventos de manutenção planejada e o caso improvável de falha em um nó ou problema em zona de disponibilidade. Os failovers bem-sucedidos dependem da configuração do ElastiCache e da sua biblioteca de cliente.
Benefício: seguir as práticas recomendadas para failovers do ElastiCache em conjunto com sua biblioteca de cliente específica do ElastiCache ajuda a minimizar o tempo de inatividade potencial durante eventos de failover.
-
[Obrigatório] Com o modo de cluster desabilitado, use tempos limite para que seus clientes detectem se precisam se desconectar do nó primário antigo e se reconectar ao novo nó primário, usando o endereço IP do endpoint primário atualizado. Com o modo de cluster habilitado, a biblioteca de cliente é responsável por detectar alterações na topologia subjacente do cluster. Isso é feito com mais frequência por meio de configurações na biblioteca de cliente do ElastiCache, que também permitem definir a frequência e o método de atualização. Cada biblioteca de cliente oferece configurações próprias e mais detalhes estão disponíveis na documentação correspondente.
[Recursos]:
-
Minimizar o tempo de inatividade no ElastiCache para Valkey e Redis OSS usando o Multi-AZ
-
Analise as práticas recomendadas da sua biblioteca de cliente do ElastiCache.
-
-
[Obrigatório] Os failovers bem-sucedidos dependem de um ambiente de replicação saudável entre o nó primário e os nós de réplica. Analise e compreenda a natureza assíncrona da replicação do Valkey e Redis OSS, bem como as métricas do CloudWatch disponíveis para relatar o atraso na replicação entre o nó primário e os nós de réplica. Para casos de uso que exigem maior segurança de dados, use o comando WAIT para forçar as réplicas a reconhecerem as gravações antes de responder aos clientes conectados.
[Recursos]:
-
[Ideal] Valide regularmente a capacidade de resposta da aplicação durante o failover usando a API Test Failover do ElastiCache.
[Recursos]:
CONF 5: Seus componentes do ElastiCache foram projetados para escalar?
Introdução: quando você entende os recursos de ajuste de escala e as topologias de implantação disponíveis, seus componentes do ElastiCache podem se ajustar ao longo do tempo para atender às mudanças nos requisitos da workload. O ElastiCache oferece ajuste de escala em quatro direções: aumento/redução na horizontal e na vertical.
Benefício: seguir as práticas recomendadas para implantações do ElastiCache oferece a maior flexibilidade para ajuste de escala, além de atender ao princípio do Well Architected de ajuste horizontal da escala para minimizar o impacto das falhas.
-
[Obrigatório] Entenda a diferença entre topologias com modo de cluster habilitado e desabilitado. Em quase todos os casos, é recomendável realizar a implantação com o modo de cluster habilitado, pois isso aumenta a escalabilidade ao longo do tempo. Os componentes com modo de cluster desabilitado têm capacidade limitada de escalar horizontalmente com a adição de réplicas de leitura.
-
[Obrigatório] Entenda quando e como escalar.
-
Para mais READIOPS: adicione réplicas.
-
Para mais WRITEOPS: adicione fragmentos (aumentar a escala horizontalmente).
-
Para mais E/S de rede: use instâncias otimizadas para rede (aumentar a escala verticalmente).
-
-
[Ideal] Implante seus componentes do ElastiCache com o modo de cluster habilitado, com uma tendência para mais nós menores, em vez de menos nós maiores. Isso limita o raio de alcance de uma falha de nó.
-
[Ideal] Inclua réplicas em seus clusters para melhorar a capacidade de resposta durante eventos de ajuste de escala.
-
[Bom] Com o modo de cluster desabilitado, utilize as réplicas de leitura para aumentar a capacidade geral de leitura. O ElastiCache oferece suporte a até 5 réplicas de leitura com o modo de cluster desabilitado, além de ajuste vertical da escala.
-
[Recursos]:
