Share via

Requisitos do roteador de inferência e de conectividade do Azure Machine Learning

  • Artigo

O roteador de inferência do Azure Machine Learning é um componente crítico para inferência em tempo real com o cluster do Kubernetes. Neste artigo, você aprenderá:

  • O que é o roteador de inferência do Azure Machine Learning
  • Como funciona o dimensionamento automático
  • Como configurar e atender aos requisitos de desempenho da solicitação de inferência (número de solicitações por segundo e latência)
  • Requisitos de conectividade para o cluster de inferência do AKS

O que é o roteador de inferência do Azure Machine Learning

O roteador de inferência do Azure Machine Learning é o componente de front-end (azureml-fe) implantado no cluster do AKS ou no cluster do Kubernetes para Arc no momento da implantação da extensão do Azure Machine Learning. Ele tem as seguintes funções:

  • Rotear solicitações de inferência de entrada do balanceador de carga do cluster ou do controlador de entrada para pods de modelo correspondentes.
  • Balancear a carga de todas as solicitações de inferência recebidas com roteamento coordenado inteligente.
  • Gerenciar o dimensionamento automático dos pods de modelo.
  • Funcionalidades de failover e tolerância a falhas, garantindo que as solicitações de inferência sempre sejam atendidas no caso de aplicativos comerciais críticos.

As seguintes etapas mostram como as solicitações são processadas pelo front-end:

  1. O cliente envia a solicitação ao balanceador de carga.
  2. O balanceador de carga envia para um dos front-ends.
  3. O front-end localiza o roteador de serviço (a instância de front-end atuando como coordenadora) para o serviço.
  4. O roteador de serviço seleciona um back-end e o retorna para o front-end.
  5. O front-end encaminha a solicitação ao back-end.
  6. Depois que a solicitação é processada, o back-end envia uma resposta ao componente de front-end.
  7. O front-end propaga a resposta de volta ao cliente.
  8. O front-end informa ao roteador de serviço que o back-end concluiu o processamento e está disponível para outras solicitações.

O seguinte diagrama ilustra esse fluxo:

Diagram illustrating the flow of requests between components.

Como você pode ver no diagrama acima, por padrão, três instâncias do azureml-fe são criadas durante a implantação da extensão do Azure Machine Learning, uma instância funciona como uma função de coordenação e as outras instâncias atendem às solicitações de inferência de entrada. A instância de coordenação tem todas as informações sobre os pods de modelo e decide qual pod de modelo ficará responsável pela solicitação de entrada, enquanto as instâncias de serviço azureml-fe atuam para rotear a solicitação ao pod de modelo selecionado e propagar a resposta de volta ao usuário original.

Dimensionamento automático

O roteador de inferência do Azure Machine Learning gerencia o dimensionamento automático para todas as implantações de modelo no cluster do Kubernetes. Como todas as solicitações de inferência passam por ela, ela contém os dados necessários para dimensionar automaticamente os modelos implantados.

Importante

  • Não habilite o dimensionamento automático de pod horizontal do Kubernetes (HPA) para implantações de modelo. Isso faz os dois componentes de dimensionamento automático concorrerem entre si. O azureml-fe foi projetado para escalar automaticamente os modelos implantados pelo Azure Machine Learning, em que o HPA precisará estimar ou aproximar a utilização do modelo com base em uma métrica genérica, como o uso da CPU ou uma configuração de métrica personalizada.

  • O Azureml-fe não dimensiona o número de nós em um cluster do Serviço de Kubernetes do Azure, pois isso pode levar a um aumento de custos inesperado. Em vez disso, ele dimensiona o número de réplicas para o modelo dentro dos limites do cluster físico. Se você precisar dimensionar o número de nós dentro do cluster, poderá dimensionar manualmente o cluster ou configurar o dimensionamento automático do cluster do Serviço de Kubernetes do Azure.

O dimensionamento automático pode ser controlado pela propriedade scale_settings no YAML de implantação. O exemplo a seguir demonstra como habilitar o dimensionamento automático:

# deployment yaml
# other properties skipped
scale_setting:
  type: target_utilization
  min_instances: 3
  max_instances: 15
  target_utilization_percentage: 70
  polling_interval: 10
# other deployment properties continue

A decisão de escalar ou reduzir verticalmente é baseada em utilization of the current container replicas.

utilization_percentage = (The number of replicas that are busy processing a request + The number of requests queued in azureml-fe) / The total number of current replicas

Se esse número exceder target_utilization_percentage, mais réplicas serão criadas. Se for menor, as réplicas serão reduzidas. Por padrão, a utilização de destino é de 70%.

As decisões para adicionar réplicas são adiantadas e rápidas (cerca de 1 segundo). As decisões para remover réplicas são conservadoras (cerca de 1 minuto).

Por exemplo, se você quiser implantar um serviço de modelo e quiser saber quantas instâncias (pods/réplicas) devem ser configuradas por RPS (solicitação por segundo) e tempo de resposta de destino. Você pode calcular as réplicas necessárias usando o seguinte código:

from math import ceil
# target requests per second
targetRps = 20
# time to process the request (in seconds)
reqTime = 10
# Maximum requests per container
maxReqPerContainer = 1
# target_utilization. 70% in this example
targetUtilization = .7

concurrentRequests = targetRps * reqTime / targetUtilization

# Number of container replicas
replicas = ceil(concurrentRequests / maxReqPerContainer)

Desempenho do azureml-fe

O azureml-fe pode atingir 5 K solicitações por segundo (QPS) com boa latência, com uma sobrecarga não superior a 3 ms em média e 15 ms no percentil de 99%.

Observação

Se você tiver requisitos de RPS superiores a 10 mil, considere as seguintes opções:

  • Aumente as solicitações/limites de recursos para pods azureml-fe; por padrão, eles têm 2 vCPU e 1.2G de limite de memória.
  • Aumente o número de instâncias para azureml-fe. Por padrão, o Azure Machine Learning cria três ou uma instâncias do azureml-fe por cluster.
    • Essa contagem de instâncias depende da configuração de inferenceRouterHA da extensão do Azure Machine Learning.
    • Não é possível persistir a contagem de instâncias aumentada, pois ela será substituída pelo valor configurado depois que a extensão for atualizada.
  • Entre em contato com especialistas da Microsoft para obter ajuda.

Entenda os requisitos de conectividade para o cluster de inferência do AKS

O cluster AKS é implantado com um dos dois modelos seguintes de rede:

  • Rede Kubenet – os recursos de rede normalmente são criados e configurados à medida que o cluster AKS é implantado.
  • Rede da CNI (Interface de rede de contêiner) do Azure – o cluster AKS é conectado a um recurso e configurações de rede virtual existentes.

No caso da rede do Kubernetes, ela é criada e configurada corretamente para o serviço do Azure Machine Learning. Para a rede de CNI, você precisa entender os requisitos de conectividade e garantir a resolução de DNS e a conectividade de saída para inferência do AKS. Por exemplo, talvez sejam necessárias etapas adicionais se você estiver usando um firewall para bloquear o tráfego de rede.

O diagrama a seguir mostra os requisitos de conectividade para inferência do AKS. As setas pretas representam a comunicação real, e as setas azuis representam os nomes de domínio. Talvez seja necessário adicionar entradas para esses hosts ao firewall ou ao servidor DNS personalizado.

Diagram of the connectivity requirements for inferencing with Azure Kubernetes Services.

Para requisitos gerais de conectividade do AKS, confira Controlar o tráfego de saída para nós de cluster no Serviço de Kubernetes do Azure.

Para acessar os serviços do Azure Machine Learning com a proteção de um firewall, confira Configurar o tráfego de rede de entrada e de saída.

Requisitos gerais de resolução de DNS

A resolução de DNS na VNet existente está sob seu controle. Por exemplo, um firewall ou servidor DNS personalizado. Os hosts a seguir devem estar acessíveis:

Nome do host Usado por
<cluster>.hcp.<region>.azmk8s.io Servidor de API do AKS
mcr.microsoft.com MCR (Microsoft Container Registry)
<ACR name>.azurecr.io Seu ACR (Registro de Contêiner do Azure)
<account>.blob.core.windows.net Conta de Armazenamento do Azure (armazenamento de blob)
api.azureml.ms autenticação do Microsoft Entra
ingest-vienna<region>.kusto.windows.net Ponto de extremidade do Kusto para carregar a telemetria

Requisitos de conectividade em ordem cronológica: da criação do cluster à implantação do modelo

Logo após o azureml-fe ser implantado, ele tentará iniciar e esse projeto exigirá:

  • Resolver o DNS para o servidor de API do Serviço de Kubernetes do Azure
  • Consultar o servidor de API do Serviço de Kubernetes do Azure para descobrir outras instâncias próprias (é um serviço multipod)
  • Conectar-se a outras instâncias próprias

Quando o azureml-fe for iniciado, ele exigirá a seguinte conectividade para funcionar corretamente:

  • Conectar-se ao Armazenamento do Microsoft Azure para fazer download da configuração dinâmica
  • Resolva o DNS para o servidor de autenticação api.azureml.ms do Microsoft Entra e comunique-se com ele quando o serviço implantado usar a autenticação do Microsoft Entra.
  • Consultar o servidor de API do Serviço de Kubernetes do Azure para descobrir os modelos implantados
  • Comunicar-se com os PODs de modelo implantados

Na hora da implantação do modelo, para ela ser bem-sucedida, o nó de AKS deve poder:

  • Resolver o DNS para o ACR do cliente
  • Fazer download das imagens do ACR do cliente
  • Resolver o DNS para os blobs do Azure em que o modelo é armazenado
  • Fazer download dos modelos de blobs do Azure

Depois da implantação do modelo e da inicialização do serviço, o azureml-fe o descobrirá automaticamente usando a API do Serviço de Kubernetes do Azure e estará pronto para rotear a solicitação para ele. Ele deve poder se comunicar com os PODs de modelo.

Observação

Se o modelo implantado exigir conectividade (por exemplo, consultar o banco de dados externo ou outro serviço REST, baixar um blob etc.), a resolução do DNS e a comunicação de saída para esses serviços deverão ser habilitadas.

Próximas etapas