Pilar Excelência operacional da Lente do Well-Architected para o Amazon ElastiCache - Amazon ElastiCache

Pilar Excelência operacional da Lente do Well-Architected para o Amazon ElastiCache

O foco do pilar Excelência operacional está na execução e no monitoramento de sistemas para agregar valor empresarial e melhorar continuamente processos e procedimentos. Os principais tópicos incluem automatizar mudanças, responder a eventos e definir padrões para gerenciar operações diárias.

EO 1: Como você entende e responde aos alertas e eventos acionados pelo seu cluster do ElastiCache?

Introdução: ao operar clusters do ElastiCache, você tem a opção de receber notificações e alertas quando eventos específicos ocorrerem. Por padrão, o ElastiCache registra em log eventos relacionados aos seus recursos, como um failover, substituição de nó, operação de ajuste de escala, manutenção programada e muito mais. Cada evento inclui a data e hora, o nome e tipo da origem e uma descrição.

Benefício: ser capaz de entender e gerenciar os motivos subjacentes aos eventos que acionam os alertas gerados pelo seu cluster permite que você opere com mais eficiência e responda aos eventos de forma adequada.

  • [Obrigatório] Analise os eventos gerados pelo ElastiCache no console do ElastiCache (depois de selecionar sua região) ou usando o comando describe-events da Amazon Command Line Interface (AWS CLI) e a API do ElastiCache. Configure o ElastiCache para enviar notificações sobre eventos de cluster importantes usando o Amazon Simple Notification Service (Amazon SNS). Usar o Amazon SNS com seus clusters permite que você realize ações programáticas em eventos do ElastiCache.

    • Há duas grandes categorias de eventos: eventos atuais e programados. A lista de eventos atuais inclui: criação e exclusão de recursos, operações de ajuste de escala, failover, reinicialização de nó, criação de snapshot, modificação de parâmetros do cluster, renovação do certificado de CA, eventos de falha (falha no provisionamento do cluster [VPC ou ENI], falhas de ajuste de escala [ENI] e falhas de snapshot). A lista de eventos programados inclui: nó programado para substituição durante a janela de manutenção e substituição de nó reagendada.

    • Embora talvez você não precise reagir imediatamente a alguns desses eventos, é fundamental examinar primeiro todos os eventos de falha:

      • ElastiCache:AddCacheNodeFailed

      • ElastiCache:CacheClusterProvisioningFailed

      • ElastiCache:CacheClusterScalingFailed

      • ElastiCache:CacheNodesRebooted

      • ElastiCache:SnapshotFailed (somente Valkey ou Redis OSS)

    • [Recursos]:

  • [Ideal] Para automatizar as respostas a eventos, utilize os recursos dos produtos e serviços da AWS, como o SNS e as funções do Lambda. Siga as práticas recomendadas ao fazer alterações pequenas, frequentes e reversíveis, como código para evoluir suas operações ao longo do tempo. Você deve usar as métricas do Amazon CloudWatch para monitorar seus clusters.

    [Recursos]: monitorar endpoints de réplica de leitura do ElastiCache (modo cluster desabilitado) usando o AWS Lambda, Amazon Route 53 e Amazon SNS para um caso de uso do Lambda e SNS.

EO 2: Quando e como você dimensiona seus clusters existentes do ElastiCache?

Introdução: o dimensionamento correto do cluster do ElastiCache é um ato de equilíbrio que precisa ser avaliado sempre que houver alterações nos tipos de workload subjacentes. Seu objetivo é operar com o ambiente do tamanho certo para sua workload.

Benefício: a utilização excessiva de seus recursos pode resultar em latência elevada e diminuição geral da performance. Por outro lado, a subutilização pode resultar em provisionamento excessivo de recursos com uma otimização de custos não ideal. Ao dimensionar corretamente seus ambientes, você pode encontrar um equilíbrio entre eficiência de performance e otimização de custos. Para remediar o excesso ou a subutilização de recursos, o ElastiCache pode ter a escala ajustada em duas dimensões. Você pode ajustar a escala verticalmente ao aumentar ou diminuir a capacidade dos nós. Também pode ajustar a escala horizontalmente ao adicionar e remover nós.

EO 3: Como você gerencia os recursos do seu cluster do ElastiCache e mantém o cluster atualizado?

Introdução: ao operar em grande escala, é essencial que você seja capaz de localizar e identificar todos os seus recursos do ElastiCache. Ao lançar novos atributos da aplicação, você precisa criar simetria entre as versões do cluster em todos os tipos de ambiente do ElastiCache: desenvolvimento, teste e produção. Os atributos de recursos permitem que você separe ambientes para objetivos operacionais diferentes, como ao implantar novos atributos e ativar novos mecanismos de segurança.

Benefício: separar os ambientes de desenvolvimento, teste e produção é uma prática operacional recomendada. Também é uma prática recomendada que seus clusters e nós em todos os ambientes tenham os patches de software mais recentes aplicados usando processos bem compreendidos e documentados. Aproveitar os atributos nativos do ElastiCache permite que sua equipe de engenharia se concentre em cumprir os objetivos de negócios e não na manutenção do ElastiCache.

EO 4: Como você gerencia as conexões de clientes aos seus clusters do ElastiCache?

Introdução: ao operar em grande escala, você precisa entender como seus clientes se conectam ao cluster do ElastiCache para gerenciar os aspectos operacionais da aplicação (como tempos de resposta).

Benefício: escolher o mecanismo de conexão mais adequado vai garantir que sua aplicação não se desconecte devido a erros de conectividade, como tempos limite.

  • [Obrigatório] Separe as operações de leitura e gravação e conecte-se aos nós de réplica para executar as operações de leitura. No entanto, esteja ciente de que, ao separar as gravações das leituras, você perderá a capacidade de ler uma chave logo depois de gravá-la devido à natureza assíncrona da replicação do Valkey e do Redis OSS. O comando WAIT pode ser usado para aumentar a segurança dos dados no mundo real e forçar as réplicas a reconhecer as gravações antes de responder aos clientes, com um custo geral de performance. O uso de nós de réplica para operações de leitura pode ser configurado em sua biblioteca de cliente do ElastiCache usando o endpoint de leitor do ElastiCache para o modo de cluster desabilitado. Para habilitar o modo de cluster, use o comando READONLY. Para muitas das bibliotecas de cliente do ElastiCache, o READONLY é implementado por padrão ou por meio de uma configuração.

    [Recursos]:

  • [Obrigatório] Use o agrupamento de conexões. Estabelecer uma conexão TCP tem um custo de tempo de CPU nos lados do cliente e do servidor, e o agrupamento permite que você reutilize a conexão TCP.

    Para reduzir a sobrecarga da conexão, use o agrupamento de conexões. Com um grupo de conexões, sua aplicação pode reutilizar e liberar conexões “à vontade”, sem o custo de estabelecer a conexão. Você pode implementar o agrupamento de conexões por meio de sua biblioteca de cliente do ElastiCache (se compatível), com um framework disponível para o ambiente da sua aplicação, ou criá-lo do zero.

  • [Ideal] Certifique-se de que o tempo limite do soquete do cliente esteja definido para pelo menos um segundo (em vez do padrão típico de “nenhum” em vários clientes).

    • Definir um valor de tempo limite muito baixo pode fazer com que o tempo limite seja atingido quando a carga do servidor estiver alta. Defini-lo muito alto pode fazer com que a aplicação demore muito para detectar problemas de conexão.

    • Controle o volume de novas conexões implementando o agrupamento de conexões em sua aplicação de cliente. Isso reduz a latência e a utilização da CPU necessárias para abrir e fechar conexões e realizar um handshake de TLS, caso o TLS esteja habilitado no cluster.

    [Recursos]: configurar o ElastiCache para aumentar a disponibilidade

  • [Bom] Usar pipelines (quando seus casos de uso permitirem) pode aumentar significativamente a performance.

    • Com pipelines, você reduz o tempo de ida e volta (RTT) entre os clientes da aplicação e o cluster, e novas solicitações podem ser processadas mesmo que o cliente ainda não tenha lido as respostas anteriores.

    • Com pipelines, você pode enviar vários comandos para o servidor sem esperar por respostas ou confirmações. A desvantagem dos pipelines é que, quando você finalmente obtém todas as respostas em lote, pode ter ocorrido um erro que só será detectado no final.

    • Implemente métodos para repetir as solicitações quando for retornado um erro que omite a solicitação incorreta.

    [Recursos]: Pipelines

EO 5: Como você implanta componentes do ElastiCache para uma workload?

Introdução: os ambientes do ElastiCache podem ser implantados manualmente por meio do Console da AWS ou programaticamente por meio de APIs, CLI, kits de ferramentas etc. As práticas recomendadas de Excelência operacional sugerem que as implantações sejam automatizadas por meio de código sempre que possível. Além disso, os clusters do ElastiCache podem ser isolados por workload ou combinados para fins de otimização de custos.

Benefício: escolher o mecanismo de implantação mais adequado para seus ambientes do ElastiCache pode melhorar a excelência operacional ao longo do tempo. É recomendável realizar operações como código sempre que possível para minimizar a quantidade de erros humanos e aumentar a repetibilidade, a flexibilidade e o tempo de resposta aos eventos.

Ao entender os requisitos de isolamento da workload, você pode optar por ter ambientes dedicados do ElastiCache por workload ou combinar várias workloads em clusters únicos, ou combinações dessas estratégias. Compreender as vantagens e desvantagens pode ajudar a encontrar um equilíbrio entre Excelência operacional e Otimização de custos.

  • [Obrigatório] Entenda as opções de implantação disponíveis para o ElastiCache e automatize esses procedimentos sempre que possível. Os possíveis caminhos de automação incluem CloudFormation, AWS CLI/SDK e APIs.

    [Recursos]:

  • [Obrigatório] Para todas as workloads, determine o nível de isolamento do cluster necessário.

    • [Ideal] Isolamento alto: mapeamento 1:1 entre workload e cluster. Permite o melhor controle sobre o acesso, o dimensionamento, a escalabilidade e o gerenciamento dos recursos do ElastiCache por workload.

    • [Melhor] Isolamento médio: M:1 isolado por finalidade, mas talvez compartilhado entre várias workloads (por exemplo, um cluster dedicado a armazenar workloads em cache e outro dedicado a mensagens).

    • [Bom] Isolamento baixo: M:1 multiuso, totalmente compartilhado. Recomendado para workloads em que o acesso compartilhado é aceitável.

EO 6: Como você planeja e mitiga falhas?

Introdução: a Excelência operacional inclui a antecipação de falhas por meio da realização de exercícios regulares “pré-mortem” a fim de identificar possíveis fontes de falha para que elas possam ser removidas ou mitigadas. O ElastiCache oferece uma API de failover que permite simular eventos de falha de nós, para fins de teste.

Benefício: ao testar cenários de falha com antecedência, você pode aprender como eles afetam sua workload. Isso permite testar com segurança os procedimentos de resposta e sua eficácia, além de familiarizar sua equipe com sua execução.

[Obrigatório] Realize regularmente testes de failover em contas de dev/teste. TestFailover

EO 7: como solucionar problemas em eventos do mecanismo Valkey ou Redis OSS?

Introdução: a Excelência operacional exige a capacidade de investigar as informações do serviço e do mecanismo para analisar a integridade e o status dos clusters. O ElastiCache pode emitir logs do mecanismo Valkey ou Redis OSS para o Amazon CloudWatch e o Amazon Kinesis Data Firehose.

Benefício: habilitar os logs do mecanismo Valkey ou Redis OSS nos clusters do ElastiCache fornece informações sobre eventos que afetam a integridade e desempenho dos clusters. Os logs do mecanismo Valkey ou Redis OSS fornecem dados diretamente do mecanismo que não estão disponíveis por meio do mecanismo de eventos do ElastiCache. Por meio da observação cuidadosa dos eventos do ElastiCache (consulte a pergunta EO 1 anterior) e dos logs do mecanismo, é possível determinar a ordem dos eventos ao solucionar problemas, tanto da perspectiva do serviço ElastiCache quanto da perspectiva do mecanismo.

  • [Obrigatório] Certifique-se de que a funcionalidade de registro em log do mecanismo Redis OSS esteja habilitada. Ela está disponível no ElastiCache para Redis OSS versão 6.2 e posteriores. Isso pode ser feito durante a criação do cluster ou modificando o cluster depois da criação.

    • Determine se o Amazon CloudWatch Logs ou o Amazon Kinesis Data Firehose são o destino apropriado para os logs do mecanismo Redis OSS.

    • Selecione um log de destino apropriado no CloudWatch ou no Kinesis Data Firehose para manter os logs. Se você tiver vários clusters, considere usar um log de destino diferente para cada cluster, pois isso ajudará a isolar os dados ao solucionar problemas.

    [Recursos]:

  • [Ideal] Se estiver usando o Amazon CloudWatch Logs, considere usar o Amazon CloudWatch Logs Insights para consultar o log do mecanismo Valkey ou Redis OSS a fim de obter informações importantes.

    Como exemplo, crie uma consulta ao grupo de logs do CloudWatch que contém os logs do mecanismo Valkey ou Redis OSS que retornarão eventos com um LogLevel de “WARNING”, como:

    fields @timestamp, LogLevel, Message | sort @timestamp desc | filter LogLevel = "WARNING"

    [Recursos]: Analisar dados de logs com o CloudWatch Logs Insights