Por que minha instância do Amazon EC2 excede seus limites de rede quando minha utilização média é baixa?

Breve descrição

As métricas de desempenho de rede bw_in_allowance_exceeded, bw_out_allowance_exceeded ou pps_allowance_exceeded do Elastic Network Adaptor (ENA) podem aumentar mesmo quando sua utilização média é baixa. A causa mais comum desse problema são pequenos picos na demanda por recursos de rede, chamados de microexpansões. As microexpansões normalmente duram apenas segundos, milissegundos ou até microssegundos. As métricas do Amazon CloudWatch não são granulares o suficiente para refleti-los. Por exemplo, é possível usar as métricas de instância NetworkIn e NetworkOut no CloudWatch para calcular o throughput médio por segundo. No entanto, as taxas calculadas podem ser menores do que a largura de banda disponível da instância no tipo de instância devido às microexpansões.

Um aumento nas métricas bw_in_allowance_exceeded e bw_out_allowance_exceeded também ocorre em instâncias menores que têm uma largura de banda de "até", como "até 10 gigabits por segundo (Gbps)". As instâncias menores usam créditos de E/S de rede para ultrapassar sua largura de banda básica por um tempo limitado. Quando os créditos se esgotam, o tráfego se alinha à largura de banda básica e as métricas aumentam. Como a expansão de instâncias ocorre da melhor maneira possível, as métricas podem aumentar mesmo quando sua instância tem créditos de E/S disponíveis.

Um aumento na métrica pps_allowance_exceeded também ocorre quando padrões de tráfego não ideais causam perdas de pacotes em taxas de PPS mais baixas. Roteamento assimétrico, drivers desatualizados, pacotes pequenos, fragmentos e rastreamento de conexão afetam o desempenho do PPS em um workload.

Resolução

Cálculo médio

O CloudWatch coleta amostras das métricas do Amazon EC2 a cada 60 segundos para capturar o total de bytes ou pacotes que são transferidos em 1 minuto. O Amazon EC2 agrega as amostras e as publica no CloudWatch em períodos de 5 minutos. Cada estatística no período mostra um valor diferente.

Quando você usa o monitoramento detalhado, o CloudWatch publica as métricas NetworkIn e Networkout sem agregação em períodos de 1 minuto. Os valores de Soma, Mínimo, Média e Máximo são os mesmos, e o valor para SampleCount é 1. O CloudWatch sempre agrega e publica as métricas NetworkPacketsIn e NetworkPacketsOut em períodos de 5 minutos.

Use os métodos a seguir para calcular o throughput médio em bytes por segundo (Bps) ou PPS em um período:

• Para obter uma média simples no período especificado, divida a Soma por Período ou pela diferença de carimbo de data/hora entre os valores (DIFF_TIME).
• Para obter uma média no minuto com a maior atividade, divida o Máximo por 60 segundos.

Para converter Bps em Gbps, divida os resultados do cálculo por 1.000.000.000 bytes e multiplique-os por 8 bits.

Microexpansões nas métricas do CloudWatch

O exemplo a seguir mostra como uma microexpansão aparece no CloudWatch. A instância tem uma permissão de largura de banda de rede de 10 Gbps e usa monitoramento básico.

Em uma amostra de 60 segundos, uma transferência de dados de saída de aproximadamente 24 GB usa toda a largura de banda disponível. A transferência de dados aumenta o valor bw_out_allowance_exceeded e é concluída em aproximadamente 20 segundos com uma velocidade média de 9,6 Gbps. O Amazon EC2 não envia nenhum outro dado e a instância permanece inativa pelas 4 amostras restantes de 240 segundos.

O throughput médio em Gbps em um período de 5 minutos é muito menor do que durante a microexpansão:

Fórmula: AVERAGE_Gbps = SOMA(NetworkOut) / PERÍODO(NetworkOut) / 1.000.000.000 bytes * 8 bits

SOMA(NetworkOut) = (~24 GB * 1 amostra) + (~0 GB * 4 amostras) = ~24 GB

PERÍODO(NetworkOut) = 300 segundos (5 minutos)

AVERAGE_Gbps = ~24 / 300 / 1.000.000.000 * 8 = ~0,64 Gbps

Mesmo quando você calcula o throughput médio com base na amostra mais alta, a quantidade ainda não reflete o throughput durante a microexpansão:

Fórmula: AVERAGE_Gbps = MÁXIMO(NetworkOut) / 60 segundos / 1.000.000.000 bytes / 8 bits

MÁXIMO(NetworkOut) = ~24 GB

AVERAGE_Gbps = ~24 GB / 60 / 1.000.000.000 * 8 = ~3,2 Gbps

Quando dados de alta resolução estão disponíveis, é possível obter médias mais precisas. Quando você coleta métricas de uso da rede do sistema operacional (SO) em intervalos de 1 segundo, o throughput médio atinge brevemente aproximadamente 9,6 Gbps.

Monitore microexpansões

É possível usar o agente do CloudWatch no Linux e no Windows para publicar métricas de rede no nível do sistema operacional no CloudWatch em intervalos de até 1 segundo. O agente também pode publicar métricas de desempenho da rede ENA.

Observação: métricas de alta resolução têm preços mais altos.

Também é possível usar as ferramentas do sistema operacional para monitorar as estatísticas da rede em intervalos de até 1 segundo. Em instâncias do Windows, use o Monitor de desempenho. Em Linux, use sar, nload, iftop, iptraf-ng ou netqtop.

Para identificar claramente as microexpansões, realize uma captura de pacotes do sistema operacional e use o Wireshark para traçar um grafo de E/S em intervalos de 1 milissegundo. Para obter mais informações, consulte Download Wireshark (Baixar o Wireshark) e 8.8. The "I/O Graphs" window (8.8. A janela "Grafos de E/S") no site do Wireshark.

Esse método tem as seguintes limitações:

• As permissões de rede são aproximadamente proporcionais em um nível de microssegundo. Por exemplo, um tipo de instância com desempenho de largura de banda de 10 Gbps pode enviar e receber cerca de 10 megabits (Mb) em 1 milissegundo.
• As capturas de pacote causam carga extra no sistema e podem reduzir o throughput geral e as taxas de PPS.
• As capturas de pacote podem não incluir todos os pacotes devido às perdas de pacotes causadas por um buffer cheio.
• As marcações de data e hora não refletem com precisão quando uma rede enviou pacotes ou quando o ENA os recebeu.
• Os grafos de E/S podem mostrar menor atividade no tráfego de entrada porque o Amazon EC2 molda o tráfego que excede sua cota antes de chegar à instância.

Filas e perdas de pacotes

Quando a rede coloca um pacote na fila, a latência resultante é medida em milissegundos. As conexões TCP podem escalar seu throughput e exceder as cotas de um tipo de instância do EC2. Como resultado, algumas filas de pacotes são esperadas mesmo quando você usa bottleneck bandwidth and round trip (BBR) ou outros algoritmos de controle de congestionamento que usam latência como sinal. Quando uma rede perde um pacote, o TCP retransmite automaticamente os segmentos perdidos. Tanto as filas quanto as perdas de pacotes podem resultar em maior latência e menor throughput. No entanto, não é possível ver as ações de recuperação. Normalmente, os únicos erros que é possível ver são quando sua aplicação usa tempos limite baixos ou quando a rede perde pacotes suficientes para que a conexão seja encerrada à força.

As métricas de desempenho da rede ENA não diferenciam entre pacotes em fila e pacotes perdidos. Para medir a latência TCP no nível da conexão no Linux, use os comandos ss ou tcprtt. Para medir as retransmissões de TCP, use os comandos ss ou tcpretrans em estatísticas em nível de conexão e nstat em estatísticas de todo o sistema. Para baixar as ferramentas tcprtt e tcpretrans que fazem parte da BPF Compiler Collection (BCC), consulte bcc no site do GitHub. Também é possível usar capturas de pacotes para medir a latência e as retransmissões.

Observação: os pacotes que a rede perdeu devido às cotas excedidas de instância não aparecem nos contadores de perda de ip ou ifconfig.

Evite microexpansões

Primeiro, compare as métricas de desempenho da rede ENA com os indicadores-chave de desempenho (KPIs) da sua aplicação para descobrir o efeito das filas ou perdas de pacotes.

Se os KPIs estiverem abaixo do limite exigido ou você receber erros no log de aplicação, realize as seguintes ações para reduzir as filas e perdas de pacotes:

• Aumente a escala verticalmente: Aumente o tamanho da instância para uma instância que tenha uma permissão de rede maior. Os tipos de instância com um "n", como C7gn, têm maiores permissões de rede.
• Aumente a escala horizontalmente: Distribua o tráfego em várias instâncias para reduzir o tráfego e a contenção em instâncias individuais.

Em operações baseadas em Linux, também é possível implementar as seguintes estratégias para evitar microexpansões. É uma prática recomendada testar as estratégias em um ambiente de teste para verificar se elas reduzem a modelagem do tráfego sem efeitos negativos no workload.

Observação: as estratégias a seguir são apenas para tráfego de saída.

SO_MAX_PACING_RATE

Use a opção de soquete SO_MAX_PACING_RATE para especificar uma taxa de ritmo máxima em Bps para uma conexão. Em seguida, o kernel Linux introduz atrasos entre os pacotes do soquete para que o throughput não exceda a cota especificada por você.

Para usar esse método, você deve implementar as seguintes alterações:

• Alterações no código da aplicação.
• Suporte do kernel. Para obter mais informações, consulte net: introduce SO_MAX_PACING_RATE no site do GitHub.
• Disciplina de enfileiramento de fila justa (FQ) ou suporte do kernel ao ritmo na camada TCP (somente para TCP).

Para obter mais informações, consulte getsockopt(2) - Linux manual page (getsockopt(2) - página de manual do Linux) e tc-fq(8) - Linux manual page (tc-fq(8) - página de manual do Linux) no site do man7. Além disso, consulte tcp: internal implementation for pacing (tcp: implementação interna pro ritmo) no site do GitHub.

qdiscs

O Linux usa a configuração padrão de uma disciplina de enfileiramento pfifo_fast (qdisc) em cada fila ENA para agendar pacotes. Use o fq qdisc para reduzir as intermitências de tráfego causadas pelo fluxo individual e regular seu throughput. Ou use fq_codel e cake para fornecer recursos de gerenciamento ativo de filas (AQM) que reduzem o congestionamento da rede e melhoram a latência. Para obter mais informações, consulte tc(8) - Linux manual page (tc(8) - página de manual do Linux) no site do man7.

Para TCP, ative a Notificação explícita de congestionamento (ECN) em clientes e servidores. Em seguida, combine o ECN com um qdisc que possa realizar a marcação ECN de Congestion Experienced (CE). As marcas CE fazem com que o sistema operacional reduza o throughput de uma conexão para reduzir a latência e as perdas de pacotes causadas por uma cota de instância excedida. Para usar essa solução, você deve configurar o qdisc com um limite de CE baixo com base no tempo médio de ida e volta (RTT) de suas conexões. É uma prática recomendada usar essa solução somente quando o RTT médio entre as conexões não varia muito. Por exemplo, sua instância gerencia o tráfego somente em uma Zona de disponibilidade.

Devido a problemas de desempenho, não é uma prática recomendada configurar a modelagem agregada da largura de banda no nível da instância.

Filas de transmissão curtas (Tx)

Use filas Tx curtas para reduzir a modelagem do PPS. Os limites da fila de bytes (BQL) limitam dinamicamente o número de bytes em trânsito nas filas Tx. Para ativar o BQL, adicione ena.enable_bql=1 à linha de comandos do kernel no GRUB.

Observação: você deve ter o driver do ENA versão 2.6.1g ou superior para usar essa solução. O BQL já está ativado em drivers ENA com versões de kernel Linux que terminam com K.

Para obter mais informações, consulte bql: Byte Queue Limits (bql: Limites de fila em bytes) no site LWN.net.

Ao usar o ENA Express, você deve desativar o BQL para maximizar a largura de banda.

Também é possível usar o ethtool para reduzir o comprimento da fila Tx do padrão de 1.024 pacotes. Para obter mais informações, consulte a ethtool(8) - Linux manual page (ethtool(8) - página de manual do Linux) no site do man7.

Informações relacionadas

Largura de banda de rede de instâncias do Amazon EC2