Por que tenho uma métrica “Network allowance exceeded” no meu cluster ElastiCache autogerenciado?

Breve descrição

Quando o workload da aplicação excede os recursos de rede do nó subjacente do ElastiCache, a modelagem do tráfego pode ocorrer. Para rastrear a modelagem do tráfego, use as seguintes métricas:

• NetworkBandwidthInAllowanceExceeded e NetworkBandwidthOutAllowanceExceeded
• NetworkPacketsPerSecondAllowanceExceeded
• NetworkConntrackAllowanceExceeded

Resolução

NetworkBandwidthInAllowanceExceeded e NetworkBandwidthOutAllowanceExceeded

As métricas NetworkBandwidthInAllowanceExceeded e NetworkBandwidthOutAllowanceExceeded rastreiam o número de pacotes de rede que o ElastiCache molda quando o throughput excede o limite agregado de largura de banda.

Ao analisar NetworkBandwidthInAllowanceExceeded e NetworkBandwidthOutAllowanceExceeded, você também deve analisar as métricas NetworkBytesIn e NetworkBytesOut no Amazon CloudWatch. Quando as métricas de uso de largura de banda do CloudWatch, NetworkBytesIn e NetworkBytesOut, estão abaixo dos limites no nível do nó, as métricas de desempenho de rede podem indicar que o ElastiCache excedeu um limite. Para obter mais informações, consulte Monitorar a largura de banda da instância.

Observação: pequenos surtos de tráfego podem causar a modelagem do tráfego, mesmo que sua largura de banda média esteja dentro de seus limites. Se houver picos ocasionais nessas métricas de limite de largura de banda sem efeitos no lado da aplicação, nenhuma ação adicional é necessária. Como o Valkey e o Redis OSS usam TCP, o TCP retransmite pacotes descartados.

Se essas métricas de limite de largura de banda forem consistentemente altas e sua aplicação detectar problemas de latência, revise os registros de data e hora dos problemas de latência. Se os carimbos de data/hora do erro corresponderem aos tempos dos picos da métrica, então aumente a escala verticalmente do seu cluster. Para obter mais informações, consulte Ajustar a escala de clusters autoprojetados.

Além disso, revise o tipo de nó de cache do cluster. Se o workload da aplicação aumentar constantemente o uso da rede além da largura de banda básica, você poderá obter uma modelagem de tráfego. Para obter mais informações, consulte Largura de banda disponível da instância.

Observação: para cada byte que o ElastiCache grava no nó primário, o ElastiCache replica as mesmas informações para todas as outras réplicas. Quando o cluster tenta processar o backlog de replicação, clusters com tipos de nós pequenos, várias réplicas e solicitações intensivas de gravação podem ter problemas. Esse backlog pode levar a altos valores de NetworkBandwidthOutAllowanceExceeded nos nós primários.

Para determinar o que causou um aumento nas métricas no lado da aplicação, procure comandos que operam em várias chaves. Isso inclui os seguintes exemplos:

• MGET
• MSET
• HGETALL

Se você trabalha com várias chaves grandes, como objetos JSON grandes ou valores de hash, poderá exceder os limites de largura de banda do seu tipo de nó. O ElastiCache então elimina o tráfego em excesso ou o adiciona a uma fila com base na carga atual.

NetworkPacketsPerSecondAllowanceExceeded

Se essa métrica for um valor diferente de 0, o uso da rede nos nós de cache subjacentes ultrapassou o limite de pacotes por segundo (PPS). Esse limite é específico para o tipo de nó que você usa. O ElastiCache descarta ou coloca em fila os pacotes em excesso que excedem o limite de nós.

Para aplicações que geram altas consultas por segundo (QPS) de pequenas solicitações, o nó pode ultrapassar os limites do PPS. Para determinar a taxa de execução de comandos, use as métricas do CloudWatch para cada tipo de dados de comando. Para obter mais informações, consulte Métricas para Valkey e Redis OSS.

Para resolver esse problema, é possível aumentar a escala verticalmente do cluster para um tipo de nó maior. Se as operações exigirem muita leitura, é possível adicionar mais réplicas de leitura ao cluster ou fragmento para distribuir a carga. Para clusters ativados no modo de cluster (CME), se as operações exigirem muita gravação, adicione mais fragmentos para aumentar a escala horizontalmente do cluster.

Observação: para clusters com modo de cluster desativado (CMD), você deve mover seu cluster para um nó maior para escalar as operações de gravação.

NetworkConntrackAllowanceExceeded

Se essa métrica for um valor diferente de 0, o ElastiCache excedeu o número máximo de conexões rastreadas em todos os grupos de segurança do nó. Depois de atingir o limite de conexão, as novas conexões falharão até que o ElastiCache feche as conexões existentes. Para obter mais informações, consulte Rastreamento de conexões de grupos de segurança do Amazon Elastic Compute Cloud (Amazon EC2).

Quando as cargas de trabalho criam um grande número de conexões de rede e você não as fecha adequadamente, as conexões permanecem abertas no lado do servidor. Essas conexões permanecem inativas e levam ao esgotamento do conntrack. Então, o ElastiCache não pode aceitar novas conexões até que o ElastiCache feche as conexões existentes.

Para resolver esse problema no ElastiCache, use o parâmetro timeout para revisar e modificar o tempo limite de conexão ociosa. Configure o parâmetro para que o servidor ElastiCache feche as conexões após um período de inatividade.

Para resolver esse problema no lado da aplicação, use as configurações do grupo de conexões para reutilizar as conexões existentes e reduzir a taxa de NewConnections. Para obter mais informações, consulte as Práticas recomendadas: Clientes Redis e Amazon ElastiCache para Redis.

Observação: tanto o parâmetro timeout no lado do servidor quanto as configurações de Grupo de conexões no lado do cliente gerenciam o estabelecimento da conexão e exigem testes de carga a partir da aplicação. Realize testes de carga na sua aplicação para determinar a configuração ideal tanto para o timeout quanto para as configurações do grupo de conexões.

Informações relacionadas

Monitorando o uso com o CloudWatch Metrics

Ajuste de escala do ElastiCache

Rede

Parâmetros do Redis OSS 2.6.13

As métricas de desempenho de rede em nível de instância do Amazon EC2 revelam novos insights