Problemas de conexão persistentes

Regras de entrada:

Número da regra: preferencialmente inferior a qualquer regra de negação;

Type: Custom TCP Rule;

Protocolo: TCP

Port Range: 1024-65535

Fonte: 0.0.0.0/0 (ou crie regras individuais para as sub-redes do cluster) ElastiCache

Allow/Deny: Allow

Regras de saída:

Número da regra: preferencialmente inferior a qualquer regra de negação;

Type: Custom TCP Rule;

Protocolo: TCP

Port Range: 6379

Fonte: 0.0.0.0/0 (ou as sub-redes do cluster). ElastiCache Lembre-se de que o uso específico IPs pode criar problemas em caso de failover (ou escalonamento do cluster).

Allow/Deny: Allow

Regras de entrada:

Número da regra: preferencialmente inferior a qualquer regra de negação;

Type: Custom TCP Rule;

Protocolo: TCP

Port Range: 6379

Fonte: 0.0.0.0/0 (ou crie regras individuais para as sub-redes do cluster) ElastiCache

Allow/Deny: Allow

Regras de saída:

Número da regra: preferencialmente inferior a qualquer regra de negação;

Type: Custom TCP Rule;

Protocolo: TCP

Port Range: 1024-65535

Fonte: 0.0.0.0/0 (ou as sub-redes do cluster). ElastiCache Lembre-se de que o uso específico IPs pode criar problemas em caso de failover (ou escalonamento do cluster).

Allow/Deny: Allow

Uso da CPU: Valkey e Redis OSS são aplicativos multithread. No entanto, a execução de cada comando ocorre em um único thread (principal). Por esse motivo, ElastiCache fornece as métricas CPUUtilization EngineCPUUtilization e. EngineCPUUtilizationfornece a utilização da CPU dedicada ao processo Valkey ou Redis OSS e CPUUtilization o uso em todos os v. CPUs Os nós com mais de uma vCPU geralmente têm valores diferentes para CPUUtilization eEngineCPUUtilization, sendo o segundo geralmente mais alto. Um EngineCPUUtilization alto pode ser causado por um número elevado de solicitações ou operações complexas que levem uma quantidade significativa de tempo da CPU para ser concluída. Você pode identificar ambos com o seguinte:

Seu aplicativo não suporta o modo de ElastiCache cluster e ElastiCache tem o modo de cluster ativado;

Seu aplicativo não é compatível com TLS/SSL e ElastiCache tem a criptografia em trânsito ativada;

A aplicação suporta TLS/SSL, mas não possui os sinalizadores de configuração corretos ou autoridades de certificação confiáveis;

Número máximo de conexões: há limites rígidos para conexões simultâneas. Cada ElastiCache nó permite até 65.000 conexões simultâneas em todos os clientes. Esse limite pode ser monitorado por meio das CurrConnections métricas ativadas CloudWatch. No entanto, os clientes também têm seus limites para conexões de saída. No Linux, verifique o intervalo de portas efêmeras permitido com o comando:

# sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 60999

No exemplo anterior, 28231 conexões serão permitidas da mesma origem, para o mesmo IP de destino (ElastiCache nó) e porta. O comando a seguir mostra quantas conexões existem para um ElastiCache nó específico (IP 1.2.3.4):

ss --numeric --tcp state connected "dst 1.2.3.4 and dport == 6379" | grep -vE '^State' | wc -l

Se o número for muito alto, seu sistema pode ficar sobrecarregado tentando processar as solicitações de conexão. É aconselhável considerar a implementação de técnicas como grupo de conexões ou conexões persistentes para lidar melhor com as conexões. Sempre que possível, configure o grupo de conexões para limitar o número máximo de conexões a algumas centenas. Além disso, a lógica de recuo para lidar com tempo limite ou outras exceções de conexão seria aconselhável para evitar rotatividade de conexão em caso de problemas.

Limites de tráfego de rede: verifique as seguintes CloudWatch métricas do Redis OSS para identificar possíveis limites de rede atingidos no ElastiCache nó:

As métricas acima são a maneira ideal de confirmar que os nós atingem seus limites de rede. No entanto, os limites também são identificáveis por platôs em métricas de rede.

Se os platôs forem observados por períodos prolongados, eles provavelmente serão seguidos por atraso de replicação, aumento de bytes usados para cache, queda de memória livre, alto swap e uso da CPU. EC2 As instâncias da Amazon também têm limites de rede que podem ser rastreados por meio das métricas do driver ENA. Instâncias do Linux com suporte de rede aprimorado e drivers ENA 2.2.10 ou mais recentes podem revisar os contadores de limite com o comando:

# ethtool -S eth0 | grep "allowance_exceeded"

Redis OSS SlowLogs: a configuração ElastiCache padrão retém os últimos 128 comandos que levaram mais de 10 milissegundos para serem concluídos. O histórico de comandos lentos é mantido durante o tempo de execução do mecanismo e será perdido em caso de falha ou reinicialização. Se a lista atingir 128 entradas, eventos antigos serão removidos para abrir espaço para novas entradas. O tamanho da lista de eventos lentos e o tempo de execução considerado lento podem ser modificados através dos parâmetros slowlog-max-len e slowlog-log-slower-than em um grupo de parâmetros personalizado. A lista de logs lentos pode ser recuperada executando SLOWLOG GET 128 no mecanismo, 128 sendo os últimos 128 comandos lentos relatados. Cada entrada tem os seguintes campos:

1) 1) (integer) 1 -----------> Sequential ID
   2) (integer) 1609010767 --> Timestamp (Unix epoch time)of the Event
   3) (integer) 4823378 -----> Time in microseconds to complete the command.
   4) 1) "keys" -------------> Command
      2) "*" ----------------> Arguments 
   5) "1.2.3.4:57004"-> Source

O evento acima aconteceu em 26 de dezembro, às 19:26:07 UTC, levou 4,8 segundos (4,823 ms) para ser concluído e foi causado pelo comando KEYS solicitado pelo cliente 1.2.3.4.

No Linux, o carimbo de data/hora pode ser convertido com a data do comando:

$ date --date='@1609010767'
Sat Dec 26 19:26:07 UTC 2020

Com Python:

>>> from datetime import datetime
>>> datetime.fromtimestamp(1609010767)
datetime.datetime(2020, 12, 26, 19, 26, 7)

Ou no Windows com PowerShell:

PS D:\Users\user> [datetimeoffset]::FromUnixTimeSeconds('1609010767')
DateTime      : 12/26/2020 7:26:07 PM
UtcDateTime  
                : 12/26/2020 7:26:07 PM
LocalDateTime : 12/26/2020 2:26:07 PM
Date          : 12/26/2020 12:00:00 AM
Day           : 26
DayOfWeek    
                : Saturday
DayOfYear     : 361
Hour          : 19
Millisecond   : 0
Minute        : 26
Month        
                : 12
Offset        : 00:00:00Ticks         : 637446075670000000
UtcTicks     
                : 637446075670000000
TimeOfDay     : 19:26:07
Year          : 2020

Muitos comandos lentos em um curto período de tempo (mesmo minuto ou menos) são motivo de preocupação. Revise a natureza dos comandos e como eles podem ser otimizados (consulte exemplos anteriores). Se comandos com complexidade de tempo O(1) são frequentemente relatados, verifique os outros fatores para o alto uso da CPU mencionado anteriormente.

Métricas de latência: ElastiCache para Redis, o OSS fornece CloudWatch métricas para monitorar a latência média de diferentes classes de comandos. O ponto de dados é calculado dividindo o número total de execuções de comandos na categoria pelo tempo total de execução no período. É importante entender que os resultados da métrica de latência são um agregado de vários comandos. Um único comando pode causar resultados inesperados, como tempos limite, sem impacto significativo nas métricas. Para tais casos, os eventos de log lento seriam uma fonte de informação mais precisa. A lista a seguir contém as métricas de latência disponíveis e os respectivos comandos que as afetam.

Comandos de runtime do Redis OSS:

Backup e replicação: ElastiCache para versões do Redis OSS anteriores à 2.8.22, use um processo bifurcado para criar backups e processar sincronizações completas com as réplicas. Esse método pode incorrer em sobrecarga de memória significativa para casos de uso intensivo de gravação.

A partir do ElastiCache Redis OSS 2.8.22, AWS introduziu um método de backup e replicação sem bifurcação. O novo método pode atrasar as gravações para evitar falhas. Ambos os métodos podem causar períodos de maior utilização da CPU, levar a tempos de resposta mais altos e, consequentemente, levar a estouro de limites de tempo do cliente durante a execução. Sempre verifique se as falhas do cliente acontecem durante a janela de backup ou a métrica SaveInProgress foi 1 no período. É aconselhável agendar a janela de backup para períodos de baixa utilização para minimizar a possibilidade de problemas com clientes ou falhas de backup.

Bugs na aplicação do cliente podem fazer com que as conexões sejam esquecidas e mantidas estabelecidas com um estado ocioso. Isso é chamado de "vazamento de conexão", e a conseqüência é um aumento constante no número de conexões estabelecidas observadas na métrica CurrConnections. Esse comportamento pode resultar em saturação no cliente ou no ElastiCache lado. Quando uma correção imediata não é possível do lado do cliente, alguns administradores definem um valor de “tempo limite” em seu grupo de ElastiCache parâmetros. O tempo limite é o tempo em segundos permitido para que as conexões ociosas persistam. Se o cliente não enviar nenhuma solicitação no período, o mecanismo encerrará a conexão assim que a conexão atingir o valor de tempo limite. Pequenos valores de tempo limite podem resultar em desconexões desnecessárias e os clientes precisarão lidar com eles corretamente e reconectar, causando atrasos.

A memória usada para armazenar chaves é compartilhada com buffers do cliente. Clientes lentos com grandes solicitações ou respostas podem exigir uma quantidade significativa de memória para lidar com seus buffers. O padrão ElastiCache para as configurações do Redis OSS não restringe o tamanho dos buffers de saída regulares do cliente. Se o limite maxmemory for atingido, o mecanismo tentará despejar itens para cumprir o uso do buffer. Em condições de memória extremamente baixa, ElastiCache para Redis, o OSS pode optar por desconectar clientes que consomem grandes buffers de saída do cliente para liberar memória e manter a integridade do cluster.

É possível limitar o tamanho dos buffers do cliente com configurações personalizadas e os clientes que atingirem o limite serão desconectados. No entanto, os clientes devem ser capazes de lidar com desconexões inesperadas. Os parâmetros para lidar com o tamanho de buffers para clientes regulares são os seguintes:

Além dos buffers regulares do cliente, as opções a seguir controlam o buffer dos nós (ePub/Sub (Publish/Subscribe) clientes de réplica:

CPU:

Rede

On the network: Tcpdump and Wireshark (tshark na linha de comando) são ferramentas úteis para entender quanto tempo a solicitação levou para percorrer a rede, acionar o ElastiCache motor e obter uma devolução. O exemplo a seguir destaca uma única solicitação criada com o seguinte comando:

$ echo ping | nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com 6379
+PONG

Paralelamente ao comando acima, tcpdump estava em execução e retornou:

$ sudo tcpdump -i any -nn port 6379 -tt
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
1609428918.917869 IP 172.31.11.142.40966
    > 172.31.11.247.6379: Flags [S], seq 177032944, win 26883, options [mss 8961,sackOK,TS val 27819440 ecr 0,nop,wscale 7], length 0
1609428918.918071 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [S.], seq 53962565, ack 177032945, win
    28960, options [mss 1460,sackOK,TS val 3788576332 ecr 27819440,nop,wscale 7], length 0
1609428918.918091 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918122
    IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [P.], seq 1:6, ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 5: RESP "ping"
1609428918.918132 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [F.], seq 6, ack
    1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918240 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [.], ack 6, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918295
    IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [P.], seq 1:8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 7: RESP "PONG"
1609428918.918300 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 8, win
    211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
1609428918.918302 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [F.], seq 8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918307
    IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 9, win 211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

A partir da saída acima, podemos confirmar que o handshake de três vias do TCP foi concluído em 222 microssegundos (918091 - 917869) e o comando ping foi enviado e retornado em 173 microssegundos (918295 - 918122).

Demorou 438 microssegundos (918307 - 917869) da solicitação ao fechamento da conexão. Esses resultados confirmam que os tempos de resposta da rede e do mecanismo são bons e que a investigação pode concentrar-se em outros componentes.

No sistema operacional: Strace pode ajudar a identificar intervalos de tempo no nível do sistema operacional. A análise de aplicações reais seria muito mais extensa, e profilers ou depuradores especializados de aplicações são aconselhados. O exemplo a seguir mostra apenas se os componentes básicos do sistema operacional estão funcionando como esperado, caso contrário, investigações adicionais podem ser necessárias. Usando do mesmo comando PING do Redis OSS com strace, obtemos:

$ echo ping | strace -f -tttt -r -e trace=execve,socket,open,recvfrom,sendto nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com (http://example.xxxxxx.ng.0001.use1.cache.amazonaws.com/)
    6379
1609430221.697712 (+ 0.000000) execve("/usr/bin/nc", ["nc", "example.xxxxxx.ng.0001.use"..., "6379"], 0x7fffede7cc38 /* 22 vars */) = 0
1609430221.708955 (+ 0.011231) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709084
    (+ 0.000124) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709258 (+ 0.000173) open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709637 (+ 0.000378) open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709923
    (+ 0.000286) open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.711365 (+ 0.001443) open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
1609430221.713293 (+ 0.001928) socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
1609430221.717419
    (+ 0.004126) recvfrom(3, "\362|\201\200\0\1\0\2\0\0\0\0\rnotls20201224\6tihew"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 155
1609430221.717890 (+ 0.000469) recvfrom(3, "\204\207\201\200\0\1\0\1\0\0\0\0\rnotls20201224\6tihew"...,
    65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 139
1609430221.745659 (+ 0.027772) socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
1609430221.747548 (+ 0.001887) recvfrom(0, 0x7ffcf2f2ca50, 8192,
    0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK (Socket operation on non-socket)
1609430221.747858 (+ 0.000308) sendto(3, "ping\n", 5, 0, NULL, 0) = 5
1609430221.748048 (+ 0.000188) recvfrom(0, 0x7ffcf2f2ca50, 8192, 0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK
    (Socket operation on non-socket)
1609430221.748330 (+ 0.000282) recvfrom(3, "+PONG\r\n", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 7
+PONG
1609430221.748543 (+ 0.000213) recvfrom(3, "", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 0
1609430221.752110
    (+ 0.003569) +++ exited with 0 +++

No exemplo acima, o comando levou um pouco mais de 54 milissegundos para ser concluído (752110 - 697712 = 54398 microssegundos).

Um tempo significativo, aproximadamente 20 ms, foi levado para instanciar nc e fazer a resolução do nome (de 697712 a 717890), depois disso, 2ms foram necessários para criar o soquete de TCP (745659 a 747858), e 0,4 ms (747858 a 748330) para enviar e receber a resposta para a solicitação.