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.
Tópicos
EO 1: Como você entende e responde aos alertas e eventos acionados pelo seu cluster do ElastiCache?
EO 2: Quando e como você dimensiona seus clusters existentes do ElastiCache?
EO 3: Como você gerencia os recursos do seu cluster do ElastiCache e mantém o cluster atualizado?
EO 4: Como você gerencia as conexões de clientes aos seus clusters do ElastiCache?
EO 5: Como você implanta componentes do ElastiCache para uma workload?
EO 7: como solucionar problemas em eventos do mecanismo Valkey ou Redis OSS?
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.
-
[Obrigatório] O excesso de utilização da CPU e da rede nos nós primários deve ser resolvido descarregando e redirecionando as operações de leitura para os nós de réplica. Use nós de réplica para operações de leitura a fim de reduzir a utilização do nó primário. Isso pode ser configurado em sua biblioteca de cliente do Valkey ou Redis OSS conectando-se ao endpoint leitor do ElastiCache para modo cluster desabilitado ou usando o comando READONLY para modo cluster habilitado.
[Recursos]:
-
[Obrigatório] Monitore a utilização de recursos críticos do cluster, como CPU, memória e rede. A utilização desses recursos específicos do cluster precisa ser monitorada para informar sua decisão de ajustar a escala e do tipo de operação de ajuste. Com o modo de cluster do ElastiCache desabilitado, o nó primário e os nós de réplica podem escalar verticalmente. Os nós de réplica também podem escalar horizontalmente, de 0 a 5 nós. Com o modo de cluster habilitado, o mesmo se aplica a cada fragmento do cluster. Além disso, você pode aumentar ou reduzir o número de fragmentos.
[Recursos]:
-
[Ideal] O monitoramento da performance ao longo do tempo pode ajudar você a detectar mudanças na workload que passariam despercebidas se monitoradas em momentos específicos. Para detectar tendências de longo prazo, use as métricas do CloudWatch a fim de verificar intervalos de tempo mais longos. O aprendizado da observação de longos períodos de métricas do CloudWatch deve informar sua previsão sobre a utilização de recursos do cluster. Os pontos de dados e métricas do CloudWatch ficam disponíveis por até 455 dias.
[Recursos]:
-
[Ideal] Se seus recursos do ElastiCache forem criados com o CloudFormation, uma prática recomendada é realizar alterações usando modelos do CloudFormation para preservar a consistência operacional e evitar alterações de configuração não gerenciadas e desvios de pilha.
[Recursos]:
-
[Ideal] Automatize suas operações de ajuste de escala usando dados operacionais de cluster e defina limites no CloudWatch para configurar alarmes. Use o CloudWatch Events e o Simple Notification Service (SNS) para acionar funções do Lambda e executar uma API do ElastiCache a fim de ajustar a escala dos clusters automaticamente. Um exemplo seria adicionar um fragmento ao cluster quando a métrica
EngineCPUUtilizationatingir 80% por um longo período. Outra opção seria usarDatabaseMemoryUsedPercentagespara um limite baseado em memória.[Recursos]:
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.
-
[Ideal] Execute na versão mais recente do mecanismo disponível e aplique as atualizações de autoatendimento assim que estiverem disponíveis. O ElastiCache atualiza automaticamente sua infraestrutura subjacente durante a janela de manutenção especificada do cluster. No entanto, os nós em execução em seus clusters são atualizados por meio de atualizações de autoatendimento. Essas atualizações podem ser de dois tipos: patches de segurança ou pequenas atualizações de software. Compreenda a diferença entre os tipos de patches e quando eles são aplicados.
[Recursos]:
-
[Ideal] Organize seus recursos do ElastiCache usando etiquetas. Use etiquetas em grupos de replicação e não em nós individuais. Você pode configurar etiquetas para serem exibidas ao consultar recursos e usar etiquetas para realizar pesquisas e aplicar filtros. Você deve usar grupos de recursos para criar e manter facilmente coleções de recursos que compartilham conjuntos comuns de etiquetas.
[Recursos]:
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]:
-
Entrega de logs: Entrega de logs
-
Destinos de registro em log: Amazon CloudWatch Logs
-
Introdução ao Amazon CloudWatch Logs: O que é o Amazon CloudWatch Logs?
-
Introdução ao Amazon Kinesis Data Firehose: O que é o Amazon Kinesis Data Firehose?
-
-
[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