Pilar de confiabilidade da ElastiCache lente Amazon Well-Architected - Amazon ElastiCache
REL1: Como você está dando suporte às implantações de arquitetura de alta disponibilidade (HA)?REL2: Como você está cumprindo seus objetivos de ponto de recuperação (RPOs)ElastiCache?REL3: Como você dá suporte aos requisitos de recuperação de desastres (DR)? REL4: Como você planeja eficazmente os failovers?REL5: Seus ElastiCache componentes foram projetados para serem escalados?

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á.

Pilar de confiabilidade da ElastiCache lente Amazon Well-Architected

O pilar de confiabilidade se concentra nas cargas de trabalho que executam as funções pretendidas e em como se recuperar rapidamente de falhas no atendimento às demandas. Os principais tópicos incluem projeto de sistema distribuído, planejamento de recuperação e adaptação às mudanças nos requisitos.

REL1: Como você está dando suporte às implantações de arquitetura de alta disponibilidade (HA)?

Introdução em nível de pergunta: Compreender a arquitetura de alta disponibilidade da Amazon ElastiCache permitirá que você opere em um estado resiliente durante eventos de disponibilidade.

Benefício em nível de pergunta: arquitetar seus ElastiCache clusters para serem resilientes a falhas garante maior disponibilidade para suas implantações. ElastiCache

  • [Obrigatório] Determine o nível de confiabilidade que você precisa para seu ElastiCache cluster. 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 (Memcached) vs ElastiCache (Redis) OSS

    1. ElastiCache (Memcached) não fornece nenhum mecanismo de replicação e é usado principalmente para cargas de trabalho efêmeras.

    2. ElastiCache (RedisOSS) oferece recursos de HA discutidos abaixo

  • [Melhor] Para cargas de trabalho que exigem HA, use ElastiCache (RedisOSS) no modo de cluster com no mínimo duas réplicas por fragmento, mesmo para cargas de trabalho com requisitos de taxa de transferência pequenos que exigem apenas um fragmento.

    1. 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.

    2. Para cargas de trabalho fragmentadas, um mínimo de três fragmentos fornece uma recuperação mais rápida durante eventos de failover, pois o Valkey ou o Redis OSS Cluster Protocol exige que a maioria dos nós primários esteja disponível para atingir o quorum.

    3. 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.

    4. Use tipos de nó baseados em Graviton2 (nós padrão na maioria das regiões).

      ElastiCache (RedisOSS) adicionou desempenho otimizado nesses nós. Como resultado, você obtém melhor performance de replicação e sincronização, resultando em maior disponibilidade geral.

    5. Monitore e dimensione corretamente para lidar com os picos de tráfego previstos: sob carga pesada, o mecanismo ElastiCache (RedisOSS) pode deixar de responder, o que afeta a disponibilidade. BytesUsedForCachee DatabaseMemoryUsagePercentage são bons indicadores do uso da memória, enquanto ReplicationLag são um indicador da integridade da replicação com base na taxa de gravação. Você pode usar essas métricas para acionar o ajuste de escala do cluster.

    6. Garanta a resiliência do lado do cliente testando com o Failover API antes de um evento de failover de produção.

    [Recursos]:

REL2: Como você está cumprindo seus objetivos de ponto de recuperação (RPOs)ElastiCache?

Introdução em nível de pergunta: entenda a carga de trabalho para RPO embasar as decisões sobre estratégias de ElastiCache backup e recuperação.

Benefício em nível de pergunta: ter uma RPO estratégia implementada pode melhorar a continuidade dos negócios no caso de cenários de recuperação de desastres. Projetar suas políticas de backup e restauração pode ajudá-lo a atingir seus objetivos de ponto de recuperação (RPO) para seus ElastiCache dados. ElastiCache (RedisOSS) oferece recursos de snapshot que são armazenados no Amazon S3, junto 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] Compreenda e RPO documente suas ElastiCache implantações.

    • Lembre-se de que o Memcached não oferece nenhum processo de backup.

    • Analise os recursos dos recursos de ElastiCache Backup e Restauração.

  • [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 recurso de backup agendado ElastiCache para fazer backup regular de seus dados durante uma janela definida.

    • Teste periodicamente as restaurações de seus backups.

  • [Recursos]:

REL3: Como você dá suporte aos requisitos de recuperação de desastres (DR)?

Introdução em nível de pergunta: a recuperação de desastres é um aspecto importante de qualquer planejamento de carga de trabalho. ElastiCache (RedisOSS) oferece várias opções para implementar a recuperação de desastres com base nos requisitos de resiliência da carga de trabalho. Com o Amazon ElastiCache Global Datastore, você pode gravar em seu cluster ElastiCache (RedisOSS) em uma região e ter os dados disponíveis para serem lidos em outros dois clusters de réplicas entre regiões, permitindo leituras de baixa latência e recuperação de desastres em todas as 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 ElastiCache componentes com base nos requisitos da carga de trabalho. 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. Certifique-se de implantar com o modo de cluster ativado em arquiteturas Multi-AZ, com um mínimo de 3 disponíveis. AZs

    • 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 ReplicationLag para entender o impacto potencial da perda de dados durante eventos de failover.

  • [Recursos]:

REL4: Como você planeja eficazmente os failovers?

Introdução em nível de pergunta: habilitar o Multi-AZ com failovers automáticos é uma prática recomendada. ElastiCache Em certos casos, o ElastiCache (RedisOSS) 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 tanto da configuração da biblioteca cliente ElastiCache quanto da sua biblioteca cliente.

Benefício em nível de pergunta: seguir as melhores práticas para ElastiCache failovers em conjunto com sua biblioteca cliente específica ElastiCache (RedisOSS) ajuda a minimizar o possível tempo de inatividade 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 cliente ElastiCache (RedisOSS), que também permitem que você defina 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]:

  • [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 do Redis, bem como as CloudWatch métricas disponíveis para relatar o atraso de OSS replicação entre os nós primário e de réplica. Para casos de uso que exigem maior segurança de dados, use o WAIT comando para forçar as réplicas a reconhecer as gravações antes de responder aos clientes conectados.

    [Recursos]:

  • [Melhor] Valide regularmente a capacidade de resposta do seu aplicativo durante o failover usando o ElastiCache Test Failover. API

    [Recursos]:

REL5: Seus ElastiCache componentes foram projetados para serem escalados?

Introdução em nível de pergunta: ao compreender os recursos de escalabilidade e as topologias de implantação disponíveis, seus ElastiCache componentes podem se ajustar com o tempo para atender às mudanças nos requisitos de carga de trabalho. ElastiCacheoferece escala de 4 vias: entrada/saída (horizontal) e cima/baixo (vertical).

Benefício em nível de pergunta: seguir as melhores práticas para ElastiCache implantações fornece a maior flexibilidade de escalabilidade, além de atender ao princípio da Well Architected de escalar horizontalmente 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 informaçõesREADIOPS: adicione réplicas

    • Para saber maisWRITEOPS: adicione fragmentos (escale)

    • Para mais E/S de rede: use instâncias otimizadas para rede (aumentar a escala verticalmente).

  • [Melhor] Implante seus ElastiCache componentes com o modo de cluster ativado, 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] Para o modo de cluster desativado, utilize as réplicas de leitura para aumentar a capacidade geral de leitura. ElastiCache tem suporte para até 5 réplicas de leitura no modo de cluster desativado, bem como escalabilidade vertical.

  • [Recursos]: