Compreendendo as métricas de desempenho do ADC

Os serviços de entrega de aplicativos são essenciais para o sucesso dos aplicativos. Independentemente de esses serviços adicionarem escalabilidade, confiabilidade ou segurança, a maioria dos aplicativos depende de um ou mais. Os controladores de entrega de aplicativos (ADCs), portanto, ocupam um lugar crítico na maioria dos projetos de aplicativos, nuvem e data center.

Para muitos ambientes, incluindo instalações de nuvem privada, o hardware ADC dedicado ainda é a plataforma preferida para fornecer serviços de entrega de aplicativos. Isso ocorre porque uma plataforma dedicada incorpora recursos controlados, estáveis e consistentes. Um dispositivo dedicado e desenvolvido especificamente pode fornecer consistentemente o desempenho e a confiabilidade que até mesmo a carga de trabalho de aplicativo mais exigente exige, porque não há variação no hipervisor, software ou plataforma de computação subjacente, além de ter as vantagens de componentes de hardware especializados para descarregar tarefas da CPU.

Mas o que "desempenho" realmente significa? Em geral, os fornecedores de ADC publicam quatro tipos principais de métricas para demonstrar desempenho:

• Solicitações por segundo (RPS)
• Conexões por segundo (CPS)
• Transações por segundo (TPS)
• Taxa de transferência (geralmente medida em gigabits por segundo, Gbps)

Os fabricantes fornecem folhas de dados abrangentes listando essas e outras características da plataforma, incluindo tabelas de rendimento, números de transações SSL ou conexões simultâneas. Interpretar esses números e sua relevância para a carga de trabalho de um aplicativo, além de entender os prováveis limites e gargalos de um sistema, são essenciais para selecionar a plataforma correta. Aprender a interpretar planilhas de dados de fornecedores e entender as métricas relevantes para seus aplicativos pode ajudar você a ter mais sucesso na seleção das plataformas certas para seu negócio.

Um Application Delivery Controller é um componente de infraestrutura que atua como um proxy de aplicativo, fornecendo serviços de entrega de aplicativos, como gerenciamento de tráfego, balanceamento de carga, descriptografia SSL, segurança da camada de aplicativo e controle de acesso para aplicativos. Dispositivos e serviços clientes se conectam ao ADC, e o ADC cria uma conexão separada (ou reutiliza uma existente) com o aplicativo. Nessa lacuna lógica, o ADC insere os serviços de entrega de aplicativos.

Para entender a carga de trabalho de um ADC, é útil analisar uma conexão TCP e uma solicitação da camada de aplicação. O ADC deve executar tarefas em várias camadas da pilha TCP e realizar uma série de atividades para fornecer serviços de aplicativo ao tráfego de aplicativo. (Veja Figura 1.) Isso pode dificultar a interpretação das métricas de desempenho dos fornecedores de ADC. Um pré-requisito fundamental para entender quais métricas são relevantes é identificar o tipo de carga de trabalho.

Existem muitos tipos de aplicativos e, portanto, muitas cargas de trabalho de ADC diferentes. Embora a maioria das implantações de produção contenha uma mistura de cargas de trabalho, o impacto e as necessidades de cada carga de trabalho influenciam quais componentes de um ADC serão mais utilizados. Mesmo dentro dos componentes, as necessidades de carga de trabalho variam. Algumas cargas de trabalho podem ser mais sensíveis à latência, outras mais sensíveis à instabilidade; algumas cargas de trabalho são sensíveis aos limites de rendimento, enquanto algumas cargas de trabalho são mais dependentes da disponibilidade.

Aqui estão as cargas de trabalho mais comuns, juntamente com as principais métricas que as suportam:

• Atualmente, a carga de trabalho mais comum, usada por sites e muitos aplicativos móveis, são aplicativos web HTTP transacionais, geralmente usando SSL e TLS. As métricas mais importantes para essa carga de trabalho são todas as métricas SSL: RPS, TPS e taxa de transferência, bem como RPS e CPS da camada 7.
• DNS é outra carga de trabalho comum usada em quase todas as trocas de dados da Internet. O DNS é usado com frequência, com volume de tráfego baixo e comumente implantado usando UDP em vez de TCP. Como resultado, as métricas mais importantes são a taxa de transferência das camadas 3 e 4.
• A API REST está crescendo rapidamente em uso e se refere a um transporte de API comum para serviços. Como resultado, a API REST é frequentemente usada na comunicação máquina a máquina. Como a API REST é baseada em HTTP, as principais métricas são as mesmas do HTTP (todas as métricas SSL): RPS, TPS e taxa de transferência, bem como RPS e CPS da camada 7.
• MQTT é um protocolo de mensagens emergente que tem muitos usos e está crescendo rapidamente na comunicação da Internet das Coisas (IoT). Assim como a API REST, o MQTT é encontrado principalmente em aplicativos máquina a máquina. As principais métricas para MQTT são CPS da camada 4 e taxa de transferência.
• O Diameter é um substituto para o protocolo de autenticação RADIUS que opera na camada 4 e mantém as conexões TCP abertas por longos períodos de tempo. Suas principais métricas são o CPS da camada 4 e a robustez da tabela de conexão da camada 4.
• Protocolos de negociação financeira como FIX, SAIL e OUCH são sensíveis à latência tanto no nível da camada 4 quanto da camada 7. Isso faz com que suas principais métricas sejam a camada 4 CPS, além da camada 7 RPS e CPS.
• A tecnologia WebSockets é uma adição relativamente recente aos tipos de carga de trabalho, por meio da qual o servidor pode iniciar a comunicação com o cliente por meio de uma conexão duradoura de camada 4 e camada 7. As principais métricas são CPS da camada 4, RPS e CPS da camada 7 e a robustez das tabelas de conexão das camadas 4 e 7.
• Todas as cargas de trabalho de registro e alerta operam na camada 4 e algumas são baseadas na API REST, que opera na camada 7. Como resultado, uma métrica fundamental é o CPS da camada 4 e, para aqueles baseados na API REST, o RPS e o CPS da camada 7.

As combinações de cargas de trabalho continuam a evoluir e novas cargas de trabalho são constantemente introduzidas, cada uma com suas próprias métricas críticas de ADC com base nas operações primárias da carga de trabalho.

A taxa de transferência de qualquer dispositivo de rede é uma função da latência — o atraso introduzido pelo processamento do tráfego de rede. No mínimo, a velocidade da luz impõe uma latência mínima para sinais elétricos que viajam por fios de cobre ou sinais ópticos que viajam por fibra óptica. Além de apenas mover os dados por fio ou fibra, um ADC executa diversas operações no tráfego de rede. As capacidades máximas de um ADC são a soma das latências de operações seriais, ou seja, operações não executadas em paralelo. Felizmente, muitas operações são executadas em paralelo, mas o tempo necessário para executá-las continua sendo uma restrição ao rendimento total. Um dos objetivos dos projetistas de ADC é minimizar essas latências para maximizar o rendimento.

Avaliar o desempenho de um ADC específico e tentar compará-lo a uma implantação específica pode ser assustador. Os fornecedores de rede publicam métricas com base em testes destinados a maximizar uma métrica específica em detrimento de outras. O motivo dessa abordagem é publicar um número utilizável que possa orientar a arquitetura e as decisões, mas os fornecedores entendem que nem todos os números publicados serão verdadeiros simultaneamente. Usando uma analogia com um carro: A Toyota anuncia que seu modelo básico Camry 2017 produz 178 cavalos de potência e atinge 33 milhas por galão na estrada, mas não seria razoável esperar que o carro produzisse a potência total de 178 cavalos — pisando fundo no acelerador a 6.000 RPM — e, ao mesmo tempo, fornecesse 33 milhas por galão. De forma semelhante, os fornecedores de rede mostram métricas de desempenho individuais usando o melhor cenário para cada uma. Como regra, muitas das métricas de desempenho publicadas não podem ser reproduzidas simultaneamente.

Algumas das métricas publicadas podem ser aplicadas a diferentes níveis de processamento. Por exemplo, solicitações por segundo podem representar valores para processamento da camada OSI 2 (L2) ou da camada OSI 7 (L7). Por outro lado, o TPS geralmente se refere apenas à negociação de chaves SSL, enquanto solicitações da camada 7 por segundo se referem a solicitações criptográficas subsequentes usando uma sessão SSL estabelecida. Uma carga de trabalho específica exercitará os vários componentes de processamento do ADC de forma diferente de outra carga de trabalho. Outra conclusão importante sobre as métricas publicadas do ADC é que diferentes cargas de trabalho encontrarão diferentes limites de desempenho.

Cada camada de rede OSI tem diversas métricas mais comumente publicadas para essas camadas. Por exemplo, é comum ver métricas da camada 4 citadas em conexões por segundo e outras métricas para taxa de transferência da camada 4. As camadas OSI 5 e 6 não são mapeadas prontamente para a pilha IP, mas serviços como SSL/TLS e compactação podem ser considerados camadas 5 e 6. Conforme observado acima, os testes para cada uma dessas métricas geralmente são realizados com tráfego projetado para estressar aquela métrica específica e não representam cargas de tráfego do mundo real. Por exemplo, o TPS SSL máximo resultará de um teste com uma carga SSL de comprimento zero, de modo que nenhum tempo de processamento do ADC seja gasto na descriptografia de dados SSL. Embora seja razoável determinar apenas o desempenho do hardware SSL, nenhum aplicativo de produção enviará cargas úteis de comprimento zero. Da mesma forma, o rendimento da camada 2 será testado sem SSL habilitado e sem processamento da camada 7, pois isso deixará o ADC lento, embora muitas implantações de produção usem esses recursos. A maioria das métricas do ADC são testadas isoladamente, mas a maioria dos ambientes de produção usa uma combinação de recursos do ADC, com cada métrica enfatizando diferentes componentes ou combinações de componentes. Os componentes envolvidos podem incluir a CPU, a placa de interface de rede (NIC), circuitos integrados específicos de aplicação (ASICs) e matrizes de portas programáveis em campo (FPGAs), entre outros. Quando um ADC não possui um componente específico, a CPU é usada em seu lugar.

A métrica de pacotes indica quantos pacotes por segundo o ADC pode processar, e os componentes mais estressados por esse processamento variam de acordo com a camada. Por exemplo, o processamento de pacotes da camada 2 sobrecarrega principalmente a placa de interface de rede (NIC), enquanto o processamento de pacotes da camada 4 sobrecarrega principalmente o FPGA. A métrica de taxa de transferência em todas as camadas se refere à taxa de transferência total disponível em gigabits por segundo, enquanto a métrica de conexões mede quantas conexões por segundo podem ser feitas naquela camada específica. Por exemplo, a métrica de conexão da camada 4 mede quantas conexões TCP podem ser estabelecidas por segundo.

O processamento SSL é único porque as sessões são estabelecidas e gerenciadas entre conexões. Uma conexão pode estabelecer uma sessão SSL (chamada de transação), enquanto conexões subsequentes podem reutilizar uma sessão SSL (chamada de solicitação). Portanto, as métricas de transação e solicitação são listadas separadamente. De longe, as transações SSL demoram mais que as solicitações SSL subsequentes, então o número limitante no desempenho da taxa de transferência geralmente é a métrica de transações. Depois que uma sessão SSL é estabelecida e uma solicitação subsequente é feita, a carga de dados deve ser criptografada ou descriptografada. O ASIC criptográfico lida com criptografia e descriptografia; o desempenho é medido na métrica de rendimento.

Muitas vezes é útil compactar a carga de dados. A compressão é realizada pelo ASIC de compressão e sua métrica também é a taxa de transferência.

Por fim, a camada 7 é única porque, dadas as opções complexas e variadas de gerenciamento de tráfego disponíveis, todo o processamento da camada 7 é realizado via CPU. A persistência de cookies é um recurso comum da camada 7 que vincula cada sessão de usuário a um servidor específico no pool e é executada pela CPU. A métrica de solicitações da camada 7 se refere ao número de solicitações da camada 7 por segundo que o ADC pode executar. Da mesma forma, a métrica de rendimento da camada 7 se refere ao rendimento total possível na camada 7.

Por fim, qualquer camada que precise preservar o estado da conexão exigirá que o ADC mantenha uma tabela de conexão. Tabelas de conexão são comuns para conexões TCP de camada 4, sessões SSL e sessões HTTP de camada 7. Protocolos com conexões de longa duração podem esgotar ou estressar uma tabela de conexões ADC.

Cada métrica pode ajudar a determinar um aspecto específico do desempenho. Entender as diferentes operações realizadas em cada camada, juntamente com quais componentes são afetados por essas operações, auxilia na avaliação das métricas de desempenho do ADC para uma implantação específica.

Cada aspecto da funcionalidade do ADC pode ser fornecido por uma CPU. Na verdade, muitos fornecedores de hardware ADC oferecem uma versão somente de software. Isso é possível porque uma CPU é o tipo de hardware mais flexível disponível, capaz de executar quase qualquer tarefa centrada em dados.

No entanto, confiar todos os aspectos da funcionalidade do ADC a uma CPU tem seus limites. Dos três principais tipos de hardware para processamento de tráfego de rede — CPU, ASIC e FPGA — a CPU é a mais lenta e sem dúvida a mais cara, necessitando do suporte de memória e controladores de memória. Os outros dois tipos de hardware para processamento de tráfego de rede são o ASIC e o FPGA. Um ASIC é projetado para executar uma tarefa específica, daí o nome. Nenhum outro tipo de hardware é mais rápido que um ASIC para executar uma tarefa, mas suas capacidades são limitadas ao que está projetado no chip. Se um aplicativo precisar de recursos não disponíveis no ASIC, ele deverá usar uma CPU e executar as tarefas no software.

Se uma CPU é flexível e lenta, e um ASIC é inflexível e rápido, uma terceira tecnologia opera no meio: o FPGA. Um FPGA é mais lento que um ASIC, mas muito mais rápido que uma CPU, e pode ser programado para executar tarefas não previstas pelos projetistas do FPGA.

Um ADC bem projetado usará os recursos de cada tipo de hardware em sua extensão máxima: relegando as tarefas comuns e simples aos componentes ASIC, executando tarefas mais complexas em componentes FPGA e lidando com as tarefas mais complexas e menos comuns na CPU. Grande parte da magia da engenharia em um ADC é o resultado da coordenação dos diferentes tipos de componentes para lidar com as diversas cargas de trabalho de forma mais eficiente.

A tarefa mais frequente, de longe, realizada em um ADC é o processamento de pacotes nas interfaces de rede. Uma NIC padrão e pronta para uso é ajustada para tráfego de entrada de alto volume (por exemplo, em um desktop ou outro dispositivo de usuário) ou ajustada para tráfego de saída de alto volume (por exemplo, em um servidor). Um ADC é único porque requer uma NIC ajustada para rendimento máximo em ambas as direções. Nenhuma NIC pronta para uso foi projetada para rendimento máximo em ambas as direções. Como o processamento de pacotes ADC é frequente e é uma tarefa relativamente simples, ele é bem adequado para um ASIC. Em ambientes ADC em cluster, um ASIC desagregador (DAG) atua como um balanceador de carga front-end, garantindo que as mesmas sessões de cliente e servidor sempre fluam pelo mesmo nó de cluster. O uso de um DAG em um ambiente em cluster facilita o dimensionamento horizontal de dispositivos ADC para atender às demandas de tráfego. Em um ADC projetado corretamente, todo o processamento e comutação de pacotes da camada 2 podem ser realizados em hardware ASIC especializado.

As tarefas de processamento das camadas 3 e 4 são mais complexas, o que as torna adequadas para um FPGA. Um FPGA pode fornecer recursos de roteamento, bem como proteções de firewall e negação de serviço distribuída (DDoS), incluindo cookies TCP SYN. O uso de um FPGA neste nível permite o processamento e as proteções da camada 4, garantindo que o tráfego considerado para processamento posterior tenha sido devidamente montado e filtrado.

O processamento de criptografia e compactação, como SSL ou TLS, e os novos recursos introduzidos pelo HTTP/2, são outro uso para hardware dedicado. Frequentemente, um ASIC especializado será usado para processamento criptográfico, incluindo a negociação de chaves SSL computacionalmente intensiva de cifras modernas, como a criptografia Diffie-Hellman de curva elíptica (ECDHE). Após a negociação da chave SSL, a criptografia e a descriptografia em massa de solicitações subsequentes também podem ser manipuladas pelo hardware ASIC. Da mesma forma, a compressão e a descompressão usando algoritmos comuns podem ser realizadas por hardware ASIC. O uso de componentes ASIC dedicados permite o processamento rápido de criptografia e compactação.

Qualquer processamento restante do tráfego de rede não manipulado por ASICs e FPGAs deve ser processado pela CPU. Embora lenta em relação a ASICs e FPGAs, a CPU é o componente mais flexível no ADC. A CPU também é encarregada de tarefas não relacionadas ao processamento de rede, como a GUI e outras tarefas de configuração, manipulação de interrupções de E/S ou até mesmo processamento de solicitações de disco. Como as demandas sobre a CPU podem variar com a latência e a CPU é o último tipo de hardware a processar o tráfego de rede, os ADCs são projetados intencionalmente para direcionar o mínimo de processamento de tráfego possível para a CPU, processando o máximo possível em ASICs e FPGAs mais rápidos.

Pode ser difícil traduzir as métricas publicadas pelos fornecedores em desempenho no mundo real. Entender a interação entre os diferentes tipos de cargas de trabalho, os recursos que elas consomem e os recursos de uma plataforma de hardware, embora complexa, pode ajudar você a tomar a melhor decisão de compra para sua organização.

Folhas de dados publicadas e outros recursos ajudam a facilitar a especificação da plataforma correta, mas também é importante confiar diretamente na experiência e no conhecimento do fornecedor sempre que possível. Os principais fornecedores terão profunda experiência em combinar cargas de trabalho com plataformas, uma experiência que deve estar prontamente disponível para os clientes.

Combinar um bom entendimento das características do tráfego do seu aplicativo e dos recursos da plataforma com a experiência do seu fornecedor reduzirá o risco e as despesas potenciais de provisionamento insuficiente ou excessivo da sua plataforma.