Teste de carga para atendimento de endpoints

Este artigo orienta você pelo processo essencial de teste de carga dos pontos de extremidade do Serviço de Modelo de IA do Mosaic para garantir que eles possam lidar com workloads de produção com eficiência. Ele também fornece exemplos práticos, analogias do mundo real e instruções passo a passo usando a estrutura de teste de carga Locust, para demonstrar como medir métricas-chave de desempenho, como solicitações por segundo e limites de simultaneidade. Dessa forma, você pode dimensionar corretamente seus endpoints e implantar modelos de forma confiante para atender às suas necessidades de negócios.

O que é um teste de carga?

Um teste de carga é um teste que simula o uso no mundo real do Serviço de Modelo de IA do Mosaic que atende aos pontos de extremidade, garantindo que eles atendam aos seus requisitos de produção, como latência ou solicitações por segundo. Um teste de carga mede o desempenho do ponto de extremidade em diferentes níveis de tráfego, ajudando você a dimensionar o ponto de extremidade corretamente para não causar atrasos.

Imagine isso: São 8:00 da manhã em um dia da semana, e um café popular no coração da cidade está apenas abrindo. O aroma de café fresco enche o ar. O barista está preparado, as máquinas se aqueceram, e a fila de clientes carentes de cafeína já está se formando.

No começo, as coisas funcionam bem. Alguns clientes se aproximam, fazem seus pedidos, e o barista começa a preparar suas bebidas. Algumas bebidas levam 30 segundos, outras levam um minuto , dependendo da complexidade. O barista faz malabarismos com vários pedidos com eficiência prática.

Mas em breve, mais pessoas chegarão. Cinco clientes se transformam em dez, depois vinte. Cada um está fazendo um pedido, esperando sua bebida, e talvez conversando um pouco no balcão. O barista está agora sob pressão. Mesmo com um segundo barista entrando, o sistema começa a se esticar – a linha cresce, os pedidos se acumulam e os clientes começam a esperar mais tempo.

Agora imagine que você está tentando medir quantas bebidas o café pode servir por minuto antes que os clientes comecem a sair frustrados. Isso é teste de carga.

Nesta analogia:

• Cada cliente é um cliente que está enviando uma solicitação.
• Os baristas representam o servidor que processa inferências de modelo uma a uma ou em paralelo.
• O tempo para fazer um pedido e servir a bebida é o tempo de implementação do modelo .
• Atrasos na conversa, pagamento ou localização do pedido são sua sobrecarga de rede.
• Mais clientes que chegam ao mesmo tempo é concorrência de clientes.
• Adicionar mais baristas ou mais computadores é como aumentar a simultaneidade do servidor.

Como em qualquer bom café, há um limite para o quanto os funcionários podem lidar ao mesmo tempo. Se você não planeja com antecedência , digamos, trazendo mais baristas durante o horário de pico - as pessoas saem infelizes. O mesmo vale para seus sistemas sob carga. O teste de carga ajuda a identificar onde estão os gargalos, quanto tráfego seu sistema pode lidar e quais alterações você precisa fazer para um serviço mais suave.

Antes de executar um teste de carga no endpoint, você precisa:

• Entenda os componentes e conceitos relacionados ao teste de carga.
• Decida e defina seus requisitos de produção.
• Encontre um payload representativo para a estrutura de teste de carga a ser usada ao avaliar seu ponto de extremidade.

Conceitos e definições de teste de carga

A tabela a seguir define os conceitos relacionados ao teste de carga:

Requisitos de latência

Com base nos requisitos de negócios e clientes, defina o desempenho ideal do seu sistema. Em um modelo que atende ao ponto de extremidade, a latência inclui o tempo de viagem de ida e volta que um cliente experimenta ao enviar dados para inferência. Isso inclui latência de rede, bem como tempo de inferência. É importante garantir que seus requisitos sejam realistas. Por exemplo, se o seu modelo levar 15ms para realizar inferência quando carregado na memória, você precisará permitir tempo adicional para latência de rede quando servido em um ponto de extremidade de serviço de modelo.

Como rps, latência e simultaneidade se relacionam?

Uma empresa tem alguns critérios definidos para o sucesso de seu sistema. Para sistemas de ML, os critérios de negócios geralmente são resultados de alta qualidade, baixa latência e alta taxa de transferência. A qualidade dos resultados está especificamente relacionada ao próprio modelo, enquanto a latência e a taxa de transferência de ponta a ponta são características do sistema de serviço. A latência de ponta a ponta consiste no tempo de execução do modelo e na sobrecarga de rede. A taxa de transferência (ou solicitações ou consultas por segundo) está inversamente relacionada à latência e diretamente relacionada à simultaneidade.

• Quanto mais simultaneidade, maior a taxa de transferência.
• Quanto maior a latência, menor a taxa de transferência.

Em geral, há uma proporção ideal de simultaneidade do lado do cliente para simultaneidade do lado do servidor para qualquer aplicativo específico. Por exemplo, "quantos hambúrgueres um cozinheiro de linha consegue preparar simultaneamente". Como pode haver muitas etapas compartilhadas no processo de cozimento, o chef de linha pode ser capaz de cozinhar mais idealmente quatro hambúrgueres ao mesmo tempo em vez de cozinhar apenas um de cada vez. Há um limite para essa paralelização, em algum momento o ato de realizar muitos atos paralelos adiciona muita latência, como se o chef precisasse adicionar queijo a 1000 hambúrgueres.

Uma das metas centrais de um teste de carga é determinar a taxa ideal para seu aplicativo. A taxa ideal maximiza RPS, atende aos seus requisitos de latência e evita a fila. Essa proporção pode ser usada para dimensionar com precisão seu ponto de extremidade para atender às cargas mais exigentes.

Se o ponto de extremidade não conseguir processar solicitações com rapidez suficiente, uma linha começará a ser formada. Isso é chamado de fila. A formação de uma fila normalmente resulta em latência de ponta a ponta muito mais longa, pois agora há tempo adicional que cada solicitação gasta aguardando antes de ser processada. Se as solicitações continuarem a chegar mais rápido do que as solicitações podem ser processadas, a fila aumentará, o que aumentará ainda mais a latência. Por esse motivo, é importante entender o tipo de demanda de pico que o seu endpoint pode enfrentar e assegurar que ele esteja corretamente dimensionado com um teste de estresse.

Exemplos de cenário de teste de carga

No teste de carga, bem como em sistemas do mundo real, a relação entre simultaneidade do cliente, simultaneidade do servidor e latência é dinâmica e interdependente. Vamos ver essa relação com um exemplo simples:

Cenário 1: Configuração simples

Nessa configuração, um único cliente envia solicitações sequencialmente – ele aguarda uma resposta antes de emitir a próxima solicitação. Como o tempo total por solicitação é a soma da execução do modelo e latência de sobrecarga (40 ms + 10 ms), a latência de ponta a ponta medida é de 50 ms.

• Número de clientes: 1
• Concorrência provisionada: 1
• Latência de sobrecarga: 10 ms
• Tempo de execução do modelo 40 ms

Como resultado, o cliente conclui uma solicitação a cada 50 ms, o que equivale a 20 solicitações por segundo ou consultas por segundo.

Cenário 2: aumentar a simultaneidade provisionada

Nesse caso, você tem o dobro da simultaneidade provisionada e um único cliente fazendo solicitações sequencialmente. Isso significa que a latência total ainda é de 50 ms (40ms + 10ms) e o sistema está vendo apenas 20 solicitações por segundo (QPS).

• Número de clientes: 1
• Simultaneidade provisionada: 1 -> 2
• Latência de sobrecarga: 10 ms
• Tempo de execução do modelo 40 ms

Cenário 3: Adicionar outro cliente ao sistema.

Agora você tem dois clientes fazendo solicitações a um ponto de extremidade com duas simultaneidades provisionadas. Nesse caso, a solicitação de cada cliente pode ser processada simultaneamente e de forma independente pelo endpoint (supondo perfeito balanceamento de carga). Portanto, enquanto a latência total ainda é de 50 ms (40ms + 10ms), o sistema observa 40 solicitações por segundo, já que cada cliente envia 20 qps.

• Número de clientes: 1 a> 2
• Concorrência provisionada: 2
• Latência de sobrecarga: 10 ms
• Tempo de execução do modelo 40 ms

Aumentar a simultaneidade provisionada e o número de clientes que fazem solicitações aumenta o QPS (consultas por segundo) total observado em seu sistema, sem penalizar a latência.

Cenário 4: Vamos reduzir a concorrência provisionada

Neste último cenário, o número de clientes é maior do que a simultaneidade provisionada. Essa configuração apresenta outra variável, a enfileiramento, no sistema e seu efeito no QPS e na latência.

• Número de clientes: 2
• Concorrência provisionada: 2 -> 1
• Latência de sobrecarga: 10 ms
• Tempo de execução do modelo: 40 ms

Aqui, você tem dois clientes fazendo solicitações simultaneamente. O ponto de extremidade, entretanto, só pode processar uma única solicitação por vez. Isso força a segunda solicitação a aguardar antes que a primeira solicitação seja processada. A espera ou, mais corretamente, o enfileiramento da segunda solicitação pode afetar negativamente a latência do sistema. Supondo que o servidor permita a fila (habilitada por padrão no Serviço de Modelo do Databricks), o segundo cliente verá uma latência de 90 ms: 10 ms (sobrecarga de rede) + 40 ms (tempo de espera de enfileiramento) + 40 ms (tempo de execução do modelo). Isso é significativamente pior do que os 50 ms vistos antes.