Entendendo as métricas de desempenho de ADC
Introdução
Os serviços de entrega de aplicações são essenciais para o sucesso das aplicações. Seja para proporcionar escalabilidade, confiabilidade ou segurança, a maioria das aplicações depende de um ou mais desses serviços. Portanto, os controladores de entrega de aplicações (ADCs) ocupam um lugar fundamental na maioria das arquiteturas de aplicações, nuvem e data centers.
Para muitos ambientes, incluindo instalações de nuvem privada, o hardware de ADC dedicado ainda é a plataforma preferida para fornecer serviços de entrega de aplicações. Isso ocorre porque uma plataforma dedicada incorpora recursos controlados, estáveis e consistentes. Um appliance dedicado e desenvolvido especificamente para essa finalidade pode oferecer de forma consistente o desempenho e a confiabilidade exigidos até mesmo pelas cargas de trabalho de aplicações mais exigentes, pois não há variações no hipervisor, no software nem na plataforma computacional subjacente — além de contar com as vantagens de componentes de hardware especializados para transferir tarefas da CPU.
Mas o que “desempenho” realmente significa? Em geral, os fornecedores de ADC publicam quatro tipos principais de métricas para demonstrar o desempenho:
- Requisiçõ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 fichas técnicas abrangentes que apresentam essas e outras características da plataforma, incluindo tabelas de taxa de transferência, número de transações SSL ou conexões simultâneas. Interpretar esses números e sua relevância para a carga de trabalho de uma aplicação, bem como compreender os prováveis limites e gargalos de um sistema, é essencial para selecionar a plataforma correta. Aprender a interpretar as fichas técnicas dos fornecedores e compreender as métricas relevantes para suas aplicações pode ajudar você a escolher com mais sucesso as plataformas certas para sua empresa.
O que um ADC faz?
Um Controlador de Entrega de Aplicações é um componente de infraestrutura que atua como proxy de aplicações, fornecendo serviços de entrega de aplicações, como gerenciamento de tráfego, balanceamento de carga, descriptografia SSL, segurança da camada de aplicação e controle de acesso a aplicações. Dispositivos e serviços clientes se conectam ao ADC, que cria uma conexão separada com a aplicação (ou reutiliza uma conexão existente). Nesse intervalo lógico, o ADC insere serviços de entrega de aplicações.
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 precisa executar tarefas em várias camadas da pilha TCP e realizar diversas atividades para fornecer serviços de aplicação ao tráfego da aplicação. (Consulte a Figura 1.) Isso pode dificultar a interpretação das métricas de desempenho fornecidas pelos fabricantes de ADCs. Um pré-requisito fundamental para entender quais métricas são relevantes é identificar o tipo de carga de trabalho.

Existem muitos tipos de aplicações e, portanto, muitas cargas de trabalho de ADC diferentes. Embora a maioria das implantações em produção contenha uma combinação de cargas de trabalho, o impacto e as necessidades de cada uma influenciam quais componentes de um ADC serão mais utilizados. Mesmo dentro de cada componente, as necessidades das cargas de trabalho variam. Algumas podem ser mais sensíveis à latência, outras à variação de latência (jitter); algumas são sensíveis aos limites de taxa de transferência, enquanto outras dependem mais da disponibilidade.
Veja a seguir as cargas de trabalho mais comuns, juntamente com as principais métricas que lhes dão suporte:
- Atualmente, a carga de trabalho mais comum, usada por sites e muitos aplicativos móveis, consiste em aplicações Web HTTP transacionais, que frequentemente utilizam SSL e TLS. As métricas mais importantes para essa carga de trabalho são todas as métricas de SSL: RPS, TPS e taxa de transferência, além de RPS e CPS da camada 7.
- O DNS é outra carga de trabalho comum, usada em quase todas as comunicações pela Internet. O DNS é usado com frequência, com baixo volume de tráfego, e geralmente é 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.
- O uso da API REST está crescendo rapidamente, e ela é um meio comum de transporte de API para serviços. Por isso, a API REST é frequentemente usada na comunicação entre máquinas. Como a API REST é baseada em HTTP, as principais métricas são as mesmas do HTTP (todas as métricas de SSL): RPS, TPS e taxa de transferência, além de RPS e CPS da camada 7.
- O MQTT é um protocolo de mensagens emergente que tem muitas aplicações e está crescendo rapidamente na comunicação da Internet das Coisas (IoT). Assim como a API REST, o MQTT é usado principalmente em aplicações de comunicação máquina a máquina. As principais métricas do MQTT são CPS da camada 4 e taxa de transferência.
- O Diameter substitui o protocolo de autenticação RADIUS, opera na camada 4 e mantém as conexões TCP abertas por longos períodos. Suas principais métricas são o CPS da camada 4 e a robustez da tabela de conexões da camada 4.
- Protocolos de negociação financeira, como FIX, SAIL e OUCH, são sensíveis à latência tanto na camada 4 quanto na camada 7. Por isso, suas principais métricas são CPS na camada 4, além de RPS e CPS na camada 7.
- A tecnologia WebSockets é uma adição relativamente recente aos tipos de carga de trabalho, na qual o servidor pode iniciar a comunicação com o cliente por meio de uma conexão duradoura nas camadas 4 e 7. As principais métricas são CPS na camada 4, RPS e CPS na camada 7 e a robustez das tabelas de conexão das camadas 4 e 7.
- As cargas de trabalho de registro e alertas operam todas na camada 4, e algumas são baseadas na API REST, que opera na camada 7. Como resultado, uma métrica importante é o CPS da camada 4 e, para aquelas baseadas na API REST, o RPS e o CPS da camada 7.
As combinações de cargas de trabalho continuam evoluindo, e novas cargas de trabalho são introduzidas constantemente, cada uma com suas próprias métricas críticas de ADC, baseadas nas principais operações da carga de trabalho.

Métricas de desempenho e como interpretá-las
A taxa de transferência de qualquer dispositivo de rede depende 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 aos sinais elétricos que percorrem fios de cobre ou aos sinais ópticos que atravessam fibras ópticas. No entanto, além de simplesmente transmitir os dados por fios ou fibras, um ADC realiza diversas operações no tráfego de rede. A capacidade máxima de um ADC corresponde à soma das latências das operações em série, ou seja, das operações que não são executadas em paralelo. Felizmente, muitas operações são executadas em paralelo, mas o tempo necessário para realizá-las ainda limita a taxa de transferência total. Um dos objetivos dos projetistas de ADCs é minimizar essas latências para maximizar a taxa de transferência.
Avaliar o desempenho de um ADC específico e tentar adequá-lo a uma determinada implantação pode ser uma tarefa desafiadora. Os fornecedores de soluções de rede publicam métricas baseadas em testes destinados a maximizar uma métrica específica em detrimento de outras. O objetivo dessa abordagem é divulgar um valor útil que possa orientar a arquitetura e a tomada de decisões, mas os fornecedores sabem que nem todos os valores publicados serão válidos simultaneamente. Fazendo uma analogia com um automóvel: a Toyota anuncia que o modelo básico do Camry 2017 produz 178 cavalos de potência e alcança 33 milhas por galão na estrada; no entanto, não seria razoável esperar que o carro produzisse os 178 cavalos de potência máximos — com o acelerador pressionado até o fim a 6.000 RPM — e, ao mesmo tempo, alcançasse 33 milhas por galão. Da mesma forma, os fornecedores de soluções de rede apresentam métricas de desempenho individuais usando o melhor cenário possível para cada uma. Em geral, muitas das métricas de desempenho publicadas não podem ser reproduzidas simultaneamente.
Relações entre métricas e camadas OSI
Algumas das métricas publicadas podem ser aplicadas a diferentes níveis de processamento. Por exemplo, as solicitações por segundo podem representar valores de processamento da camada 2 (L2) ou da camada 7 (L7) do modelo OSI. Por outro lado, TPS geralmente se refere apenas à negociação de chaves SSL, enquanto as solicitações por segundo na camada 7 se referem às solicitações criptográficas subsequentes que utilizam uma sessão SSL estabelecida. Uma determinada carga de trabalho exigirá os diversos componentes de processamento do ADC de maneira diferente de outra carga. Outro ponto importante sobre as métricas de ADC publicadas é que cargas de trabalho distintas encontrarão limites de desempenho diferentes.

Cada camada de rede do modelo OSI tem várias métricas que são publicadas com mais frequência para essas camadas. Por exemplo, é comum ver métricas da camada 4 expressas em conexões por segundo, além de outras métricas de taxa de transferência dessa camada. As camadas 5 e 6 do modelo OSI não correspondem diretamente à pilha IP, mas serviços como SSL/TLS e compactação podem ser considerados como pertencentes a essas camadas. Conforme observado acima, os testes de cada uma dessas métricas costumam ser realizados com tráfego projetado para levar a métrica específica ao limite e não representam cargas de tráfego reais. Por exemplo, o valor máximo de TPS SSL será obtido em um teste com uma carga útil SSL de comprimento zero, de modo que nenhum tempo de processamento do ADC seja gasto na descriptografia de dados SSL. Embora isso seja razoável para determinar apenas o desempenho do hardware SSL, nenhuma aplicação em produção enviará cargas úteis de comprimento zero. Da mesma forma, a taxa de transferência da camada 2 será testada sem o SSL habilitado e sem processamento da camada 7, pois esses recursos reduzem o desempenho do ADC, embora muitas implantações em produção os utilizem. A maioria das métricas de ADC é testada isoladamente, mas a maioria dos ambientes de produção utiliza uma combinação de recursos do ADC, com cada métrica exigindo diferentes componentes ou combinações de componentes. Os componentes envolvidos podem incluir a CPU, a placa de interface de rede (NIC), circuitos integrados de aplicação específica (ASICs) e matrizes de portas programáveis em campo (FPGAs), entre outros. Quando um ADC não dispõe de determinado componente, a CPU é usada em seu lugar.

A métrica de pacotes indica quantos pacotes por segundo o ADC consegue processar, e os componentes mais exigidos por esse processamento variam de acordo com a camada. Por exemplo, o processamento de pacotes da camada 2 exige principalmente a placa de interface de rede (NIC), enquanto o processamento de pacotes da camada 4 exige principalmente o FPGA. A métrica de taxa de transferência em todas as camadas refere-se à 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 realizadas nessa camada específica. Por exemplo, a métrica de conexões da camada 4 mede quantas conexões TCP podem ser estabelecidas por segundo.
Métricas de processamento SSL
O processamento SSL é único, pois as sessões são estabelecidas e gerenciadas entre conexões. Uma conexão pode estabelecer uma sessão SSL (o que é chamado de transação), enquanto as conexões subsequentes podem reutilizar uma sessão SSL (o que é chamado de solicitação). Portanto, as métricas de transações e solicitações são apresentadas separadamente. As transações SSL levam muito mais tempo do que as solicitações SSL subsequentes, portanto, o fator limitante do desempenho de throughput costuma ser a métrica de transações. Depois que uma sessão SSL é estabelecida e uma solicitação subsequente é feita, a carga útil de dados precisa ser criptografada ou descriptografada. O ASIC criptográfico realiza a criptografia e a descriptografia; o desempenho é medido pela métrica de throughput.
Muitas vezes, é útil compactar a carga útil de dados. A compactação é realizada pelo ASIC de compactação, e sua métrica também é a taxa de transferência.
Processamento da camada de aplicação
Por fim, a camada 7 se diferencia porque, devido às opções complexas e variadas de gerenciamento de tráfego disponíveis, todo o processamento dessa camada é realizado pela 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 do pool e é executado pela CPU. A métrica de solicitações da camada 7 indica o número de solicitações por segundo que o ADC consegue processar nessa camada. Da mesma forma, a métrica de taxa de transferência da camada 7 indica a taxa de transferência total possível nessa camada.
Por fim, qualquer camada que precise preservar o estado da conexão exigirá que o ADC mantenha uma tabela de conexões. As tabelas de conexões são comuns em conexões TCP da camada 4, sessões SSL e sessões HTTP da camada 7. Protocolos com conexões de longa duração podem esgotar ou sobrecarregar a tabela de conexões de um ADC.
Cada métrica pode ajudar a determinar um aspecto específico do desempenho. Compreender as diferentes operações realizadas em cada camada, bem como quais componentes são afetados por essas operações, ajuda a avaliar as métricas de desempenho do ADC para uma implantação específica.
Hardware especializado e desempenho
Todos os aspectos da funcionalidade de um ADC podem ser fornecidos por uma CPU. Na verdade, muitos fornecedores de hardware de ADC oferecem uma versão exclusivamente em software. Isso é possível porque a CPU é o tipo de hardware mais flexível disponível, capaz de executar praticamente qualquer tarefa centrada em dados.
No entanto, confiar todos os aspectos da funcionalidade de um ADC a uma CPU tem suas limitações. Dos três principais tipos de hardware para processamento de tráfego de rede — CPU, ASIC e FPGA —, a CPU é o mais lento e, possivelmente, o mais caro, pois precisa 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 do que um ASIC na execução de uma tarefa, mas seus recursos se limitam ao que foi incorporado ao projeto do chip. Se uma aplicação precisar de recursos não disponíveis no ASIC, ela deverá usar uma CPU e executar as tarefas por software.
Se uma CPU é flexível e lenta, enquanto um ASIC é inflexível e rápido, há uma terceira tecnologia que fica no meio-termo: 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 por seus projetistas.

Um ADC bem projetado aproveitará ao máximo os recursos de cada tipo de hardware: delegando as tarefas comuns e simples aos componentes ASIC, executando tarefas mais complexas nos componentes FPGA e deixando as tarefas mais complexas e menos comuns a cargo da CPU. Grande parte da magia da engenharia de um ADC resulta da coordenação dos diferentes tipos de componentes para lidar com as diversas cargas de trabalho da maneira mais eficiente possível.
De longe, a tarefa mais frequente realizada em um ADC é o processamento de pacotes nas interfaces de rede. Uma NIC padrão, disponível no mercado, é otimizada para tráfego de entrada de alto volume (por exemplo, em um desktop ou outro dispositivo de usuário) ou para tráfego de saída de alto volume (por exemplo, em um servidor). Um ADC é único por exigir uma NIC otimizada para oferecer vazão máxima em ambas as direções. Nenhuma NIC disponível no mercado foi projetada para proporcionar vazão máxima nos dois sentidos. Como o processamento de pacotes em um ADC é frequente e relativamente simples, ele é bastante adequado para um ASIC. Em ambientes de ADC em cluster, um ASIC desagregador (DAG) atua como balanceador de carga de front-end, garantindo que as mesmas sessões de cliente e servidor sempre passem pelo mesmo nó do cluster. O uso de um DAG em um ambiente em cluster facilita o dimensionamento horizontal dos appliances ADC para atender às demandas de tráfego. Em um ADC devidamente projetado, todo o processamento e a comutação de pacotes da camada 2 podem ser realizados por 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 contra ataques distribuídos de negação de serviço (DDoS), incluindo cookies TCP SYN. O uso de um FPGA nesse nível permite o processamento e a proteção da camada 4, garantindo que o tráfego considerado para processamento adicional 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 outra aplicação para hardware dedicado. Muitas vezes, um ASIC especializado é usado para o processamento criptográfico, incluindo a negociação de chaves SSL, que exige grande capacidade computacional, em 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 das solicitações subsequentes também podem ser realizadas por hardware ASIC. Da mesma forma, a compactação e a descompactação com algoritmos comuns podem ser executadas por hardware ASIC. O uso de componentes ASIC dedicados permite o processamento rápido de criptografia e compactação.
Todo o processamento restante do tráfego de rede que não for realizado por ASICs e FPGAs deverá ser executado pela CPU. Embora seja mais lenta em comparação com ASICs e FPGAs, a CPU é o componente mais flexível do ADC. Ela também é responsável por tarefas não relacionadas ao processamento de rede, como a interface gráfica e outras funções de configuração, o tratamento de interrupções de E/S e até mesmo o processamento de solicitações de disco. Como as demandas sobre a CPU podem variar em termos de latência e ela é o último tipo de hardware a processar o tráfego de rede, os ADCs são projetados intencionalmente para direcionar o mínimo possível desse processamento à CPU, realizando a maior parte dele em ASICs e FPGAs mais rápidos.
Conclusão
Pode ser difícil traduzir as métricas publicadas pelos fornecedores em desempenho no mundo real. Embora seja complexo, 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 pode ajudar você a tomar a melhor decisão de compra para sua organização.
As fichas técnicas publicadas e outros recursos ajudam a facilitar a especificação da plataforma adequada, mas também é importante recorrer diretamente à experiência e ao conhecimento especializado do fornecedor sempre que possível. Os principais fornecedores terão amplo conhecimento especializado para associar cargas de trabalho a plataformas — conhecimento que deve estar prontamente disponível aos clientes.
Combinar um bom entendimento das características de tráfego das suas aplicações e dos recursos da plataforma com a experiência do seu fornecedor reduzirá o risco e os possíveis custos de subdimensionar ou superdimensionar a sua plataforma.
PUBLICADO EM 28 DE MARÇO DE 2017
