IPUs melhoram a latência de rede em aplicações baseadas em microsserviços

O que são Microsserviços?

Microsserviços referem-se a uma abordagem moderna de desenvolvimento de software que envolve a quebra de uma grande aplicação em serviços menores, independentes e acoplados vagamente. Em vez de implementar aplicativos como sistemas de software monolíticos tradicionais, os provedores de serviços em nuvem, incluindo empresas conhecidas como Amazon, eBay, Netflix e Twitter, estão cada vez mais implementando suas aplicações como microsserviços em vez de projetos monolíticos tradicionais.

Alguns benefícios de microsserviços incluem:

• Escalabilidade: microsserviços permitem uma melhor escalabilidade, uma vez que os serviços individuais podem ser escalados independentemente uns dos outros. Isso significa que os desenvolvedores podem ampliar ou reduzir apenas os serviços que precisam, sem afetar o restante da aplicação.

• Flexibilidade: microsserviços facilitam as alterações em um sistema, pois os serviços individuais podem ser atualizados sem afetar toda a aplicação. Isso facilita a adoção de novas tecnologias, a experiência com diferentes linguagens de programação e o teste de novos recursos.

• Isolamento de falhas: cada microsserviço é um componente independente, se um serviço falhar, não afeta o restante da aplicação. Isso significa que os desenvolvedores podem identificar e corrigir problemas rapidamente sem afetar todo o sistema.

• Velocidade de desenvolvimento aprimorada: microsserviços permitem que equipes de desenvolvimento menores e mais focadas trabalhem de forma independente em serviços específicos. Isso acelera o processo de desenvolvimento e facilita o gerenciamento de sistemas grandes e complexos.

• Melhor tolerância a falhas: com microsserviços, é mais fácil construir sistemas tolerantes a falhas porque cada serviço pode ser projetado para lidar com erros de forma independente. Isso significa que todo o sistema é mais resiliente e menos propenso a falhar.

• Testes aprimorados: como cada microsserviço é independente, é mais fácil testar serviços individuais. Isso significa que os desenvolvedores podem testar serviços isoladamente, o que facilita a descoberta e correção de bugs.

Embora as arquiteturas de software baseadas em microsserviços ofereçam benefícios importantes, elas introduzem sobrecargas significativas de rede, de modo que parâmetros como a latência da rede tenham uma grande influência no desempenho geral da aplicação e no custo do data center. Ao aproveitar Intel FPGA unidades de processamento de infraestrutura (IPUs) executando software de plano de dados virtualizado da Napatech, os prestadores de serviços podem maximizar o desempenho de sua infraestrutura de rede, permitindo um nível de desempenho inatingível e, ao mesmo tempo, minimizar seu data center geral CAPEX e OPEX.

Desafios de rede para microsserviços

Em uma arquitetura de microsserviços, a latência da rede apresenta um desafio significativo à medida que serviços virtualizados implementados em contêineres ou máquinas virtuais (VMs) se comunicam uns com os outros através de uma rede virtualizada. Por exemplo, microsserviços se comunicam uns com os outros com frequência, o que pode resultar em uma grande quantidade de tráfego de rede. Esse aumento no tráfego de rede pode levar ao congestionamento da rede e ao aumento da latência, o que pode afetar negativamente o desempenho do sistema. Da mesma forma, em uma arquitetura de microsserviços, os serviços muitas vezes precisam chamar outros serviços para concluir uma tarefa e cada chamada de rede adiciona latência adicional ao sistema. Conforme o número de serviços e a complexidade do sistema aumentam, o número de atendimentos à rede também aumenta, o que pode levar a desafios significativos de latência. Por fim, diferentes microsserviços podem utilizar diferentes protocolos de rede para comunicação. Por exemplo, um serviço pode usar REST (REpresentational State Transfer) enquanto outro serviço pode usar gRPC (Chamada de procedimento remoto do Google). A tradução entre diferentes protocolos de rede pode adicionar latência adicional ao sistema.

Tradicionalmente, um plano de dados virtualizado é implementado completamente em software e muitos de seus ciclos de computação são consumidos por meio da execução de um comutador virtual (vSwitch), que encaminha o tráfego de rede entre VMs. Como cada operação da vSwitch requer um número significativo de ciclos de CPU, esta arquitetura pode introduzir latência inaceitável no sistema e também pode impedir que o sistema alcance o desempenho geral ou a taxa de transferência necessária. Ao mesmo tempo, uma CPU que é fortemente utilizada executando o plano de dados virtual terá menos núcleos disponíveis para executar aplicações e serviços, aumentando o número de servidores necessários para suportar a carga de trabalho do data center e aumentando tanto CAPEX como OPEX. Consulte a Figura 1.

Aproveitando a arquitetura baseada em Intel® FPGA IPU

Uma arquitetura de nível de sistema mais eficiente e econômica aproveita um Intel FPGA IPU para descarregar o vSwitch da CPU do servidor, liberando a CPU do servidor para executar aplicativos e serviços.

A IPU, que substitui a placa de interface de rede (NIC) padrão no servidor de data center, implementa o vSwitch em hardware, usando um FPGA programável (Field Programmable Gate Array) para executar o plano de dados em conjunto com uma CPU de uso geral que executa o plano de controle. O vSwitch apresenta uma API (Application Programming Interface) padrão do setor para as VMs, garantindo que nenhuma mudança precise ser feita nas próprias VMs ao aproveitar essa arquitetura. Consulte a Figura 2.

A arquitetura baseada em IPU oferece três benefícios principais para um data center que executa aplicações baseadas em microsserviços:

• Latência ultrabaixa, o que minimiza o tráfego de atraso entre os microsserviços;

• Alto desempenho, o que maximiza a taxa de transferência geral do sistema e da aplicação;

• Utilização ideal da CPU do servidor sem núcleos de CPU de servidor consumidos pelo plano de dados vSwitch, o que minimiza o número total de servidores necessários para a carga de trabalho geral, minimizando também data centers CAPEX e OPEX.

Análise do MIT

Para quantificar os benefícios da descarga do vSwitch em cenários reais, o Instituto de Tecnologia de Massachusetts (MIT) analisou o desempenho de dois casos de uso baseados em microsserviços, comparando os resultados do uso de um vSwitch tradicional baseado em software com aqueles obtidos usando um Intel IPU executando software de plano de dados virtualizado da Napatech, um fornecedor líder de soluções SmartNIC e IPU. Esses dois casos de uso foram um aplicativo de subscrição de publicação "pub-sub" que usa a passagem de mensagens para transferências de dados em várias camadas e um aplicativo TCP de três níveis que compreende um servidor web, cache em memória e banco de dados de back-end. Os resultados dessa iniciativa de benchmarking estão documentados no artigo "Microservice Benchmarking on Intel IPUs running Napatech Software" publicado pelo MIT.

Análise de desempenho de aplicações do pub-sub

Uma aplicação pub-sub, abreviação em breve de "aplicativo de publicação de inscrição", é um padrão de mensagens comumente usado em sistemas distribuídos para facilitar a comunicação e coordenação entre diferentes componentes ou serviços. O padrão pub-sub permite uma comunicação assíncronos e dissociadas, onde os remetentes das mensagens, conhecidos como editores, não precisam conhecer os destinatários específicos, conhecidos como assinantes. As aplicações do pub-sub são aplicáveis a casos de uso como:

• Sistemas de reservas de assentos que criam uma planta baixa, atribuem lugares a ele e gerenciam os eventos de reserva de assentos ao vivo. À medida que os clientes compram ingressos, o pub-subsistema atualiza a planta baixa em todos os lugares em tempo real e mantém o sistema de cache distribuído em sincronia. Os clientes nunca acabam solicitando um assento apenas para descobrir que alguém havia comprado enquanto ainda estava na fase de navegação/compras.

• Ferramentas educacionais que permitem que os alunos participem de uma sala de aula por meio de um aplicativo web, onde os clientes frequentemente encontram problemas como Wi-Fi não confiável ou redes celulares imprevisíveis. O pub-sub-sistema recupera sua conexão quando eles reusentem a rede e é capaz de lidar com mudanças rápidas no número de participantes on-line.

• Aplicações financeiras , como distribuição de dados de mercado, incluindo preços de ações, índices de mercado, dados comerciais e atualizações de catálogos de pedidos para assinantes em uma organização.

• Os sistemas de Internet das coisas (IoT), onde o pub-sub facilita a comunicação entre diversos dispositivos de IoT e permite uma disseminação eficiente de dados. Os sensores publicam dados, e os assinantes podem receber e processar os dados em tempo real.

Para esta análise, o MIT avaliou uma topologia de cadeia de cinco níveis desenvolvida com um modelo de comunicação sub-pub da Dapr, que é um tempo de execução portátil e orientado para eventos que permite aos desenvolvedores construir aplicações resilientes, sem estado e stateful que são executadas tanto na nuvem quanto na borda, enquanto suportam uma diversidade de linguagens e estruturas de desenvolvedores. Cada camada realiza computação intensiva de CPU por uma quantidade de tempo especificada pelo usuário, antes de transmitir sua saída para a camada downstream. Consulte a Figura 3.

Dentro do aplicativo pub-sub de cinco níveis, a colocação de serviços entre os dois servidores habilitados para OVS garante que os serviços dependentes estejam sendo executados em diferentes máquinas físicas, de modo que todo o tráfego entre camadas passe entre as IPUs, quando habilitado.

O MIT analisou o desempenho do sistema pub-sub com e sem a descarga baseada em IPU, medindo a latência das mensagens entre cargas variadas que são expressas como milhares de consultas por segundo (kQPS). Veja a Figura 4.

Quando a descarga é desabilitada e considerando a latência de cauda (ou seja, piorcaso), o aplicativo começa a saturar a 90kQPS, conforme indicado pelo ponto de inflexão no gráfico. Além desse nível de carga, o sistema não pode mais acompanhar as solicitações de forma eficiente, muito provavelmente devido a quedas de pacotes que resultam em retransmissões TCP. Quando a descarga é habilitada, no entanto, o sistema ainda acompanha as solicitações a uma carga de 140kQPS, a taxa máxima usada neste teste, indicando que a IPU permite um aumento de 50% na taxa de transferência, mantendo latência de cauda aceitável. Isso representa uma melhoria significativa na capacidade do sistema, resultando em uma economia de 30 a 40% no custo total do servidor e no consumo de energia.

Análise de desempenho de aplicativo TCP de três níveis

Uma aplicação TCP (Protocolo de Controle de Transmissão) de três níveis se refere a um projeto de arquitetura de software que divide um aplicativo em três camadas ou camadas lógicas, cada uma responsável por funções específicas. Essas camadas são geralmente chamadas de camada de apresentação, nível de aplicativo e nível de dados. O protocolo TCP é usado para comunicação entre estas camadas:

• Camada de apresentação: também conhecida como o nível de interface de usuário (IU), essa camada é responsável por apresentar as informações do aplicativo aos usuários e receber suas entradas. Ele lida com componentes da interface gráfica do usuário (GUI), como páginas da web, formulários ou interfaces de desktop. O nível de apresentação se comunica com o nível do aplicativo para recuperar ou atualizar dados conforme necessário.

• Nível de aplicativo: o nível de aplicação contém a lógica empresarial e a lógica de processamento do aplicativo. Ela lida com a funcionalidade principal e executa tarefas como validação de dados, aplicação de regras de negócios e operações específicas do aplicativo. Esse nível processa as solicitações a partir do nível de apresentação e se comunica com a camada de dados para recuperar ou armazenar dados.

• Data Tier: o nível de dados, também conhecido como a camada de acesso de dados ou o nível do banco de dados, é responsável pelo gerenciamento do armazenamento e recuperação de dados. Lida com interações com os sistemas de banco de dados, como consultas e atualização de dados. O nível de dados recebe solicitações do nível de aplicativo e retorna os dados solicitados ou realiza as modificações de dados necessárias.

Em um aplicativo TCP de três níveis, a comunicação entre essas camadas é facilitada usando o protocolo TCP. O TCP garante a entrega confiável e ordenada de dados entre as camadas, fornecendo um mecanismo de comunicação orientado para conexão e baseado em fluxo. Ao separar a aplicação nesses três níveis, a arquitetura TCP de três níveis permite modularidade, escalabilidade e manutenção mais fácil da aplicação. Cada camada pode ser desenvolvida e dimensionada de forma independente, facilitando a flexibilidade e a reutilização dos componentes.

Para esta análise, o MIT avaliou uma aplicação de três níveis com o NGINX como o servidor web de front-end, Memcached como a camada de cache na memória e MongoDB como o banco de dados de back-end com armazenamento persistente. Os clientes interagem com a NGINX, que verifica se um par de valor-chave é colocado em cache em Memcached e, em caso afirmativo, retorna o valor ao cliente. Se não, NGINX faz interface com MongoDB para obter a saída e cache adicionalmente em Memcached. Consulte a Figura 5.

O MIT analisou o desempenho do aplicativo TCP de três níveis com e sem a descarga baseada em IPU, medindo a latência das mensagens em diferentes cargas, que, como no exemplo anterior, são expressas como milhares de consultas por segundo (kQPS). Consulte a Figura 6.

Quando a descarga é desabilitada e considerando a latência de cauda (ou seja, o pior caso), o aplicativo começa a saturar a aproximadamente 17kQPS, conforme indicado pelo ponto de inflexão no gráfico. Além desse nível de carga, o sistema não pode mais acompanhar as solicitações de forma eficiente, muito provavelmente devido a quedas de pacotes que resultam em retransmissões TCP. Quando a descarga é habilitada, no entanto, a saturação não começa até que uma carga de 26kQPS indique que a IPU permite um aumento de 53% na taxa de transferência, mantendo latência de cauda aceitável. Tal como o exemplo anterior, isso representa uma melhoria significativa na capacidade do sistema, resultando em uma economia de 30 a 40% no custo total do servidor e no consumo de energia.

Configuração do sistema

A configuração do sistema usada pelo MIT para benchmarking de microsserviços foi a seguinte:

• Dois servidores inspur de soquete duplo, cada um com um processador Intel® Xeon® Gold 6338 com cache de 48 MB, executando a 2,0 GHz com velocidade turbo de 3,2 GHz. Cada servidor foi configurado com memória de 512 GB, uma unidade de inicialização de 480 GB, módulos de armazenamento duploS P6410 NVMe de 1,6 TB e um NIC 10G controlador Ethernet Intel® XL710.

• Além do NIC padrão, cada servidor foi configurado com um adaptador Intel IPU C5000X com duas portas SFP28 de 10/25 G e uma interface de host PCIe 3.0, com base em um Intel® Stratix® FPGA e Intel® Xeon® Sistema em Chip (SoC) D. Consulte a Figura 7.

• Cada IPU estava executando o software de virtualização de link 4.3.3 da Napatech, oferecendo um plano de dados virtualizado descarregado e acelerado, incluindo funções como Open vSwitch (OVS), suporte de VirtIO, migração ao vivo, espelhamento de VM-para-VM, encapsulamento/descapsulação VLAN/VxLAN, Q-in-Q, balanceamento de carga RSS, agregação de link e Qualidade de Serviço (QoS).