Mergulho aprofundado no Serviço de Agente Foundry e sua rede

Quando executa o Microsoft Foundry Agent Service com uma rede virtual própria (VNet), é responsável por dimensionar a sub-rede delegada, planear a alocação de IP e compreender como o tráfego do agente flui pela plataforma. Este artigo explica a arquitetura de rede por trás dos agentes alojados e de prompt, o modelo de alocação de IP e os sinais que indicam problemas de capacidade. Destina-se a arquitetos de cloud e redes que já escolheram trazer o seu próprio VNet para o Foundry Agent Service. Para configurar a rede, consulte Configurar rede privada para o Foundry Agent Service.

Se usar um agente de programação como o GitHub Copilot para planear o seu VNet, sub-net e modelo de capacidade, a Microsoft Foundry Skill pode ajudá-lo a raciocinar na arquitetura e aplicar as orientações de rede do Foundry no seu próprio ambiente.

Visão geral da arquitetura de rede

O diagrama seguinte mostra as duas zonas envolvidas em qualquer pedido de Serviço de Agente Foundry: a rede da plataforma Foundry, gerida pela Microsoft, à esquerda, e a VNet do seu cliente à direita.

A rede da plataforma aloja o endpoint Foundry, a camada host Micro VM que executa agentes alojados, o Tools Service e a camada host Data Proxy. O seu VNet de cliente contém uma sub-rede delegada (onde as Micro VMs e o Data Proxy consomem IPs) e uma sub-rede privada de endpoint que se liga ao seu armazenamento, bases de dados e Key Vault.

Dois fluxos de pedido percorrem esta arquitetura:

• Agente alojado: Cliente para endpoint Foundry para Micro VM (/invoke) para Tools Service para Data Proxy para recursos do cliente através de endpoints privados.
• Prompt agent: Cliente para o endpoint Foundry, para o serviço de ferramentas, para o proxy de dados, e para os recursos do cliente através dos endpoints privados. Não há Micro VM neste caminho.

Conceitos-chave

Como flui o tráfego

Cada pedido de Serviço de Agente Foundry entra no endpoint Foundry e sai para os seus recursos de cliente através de endpoints privados. O tipo de agente determina o que acontece durante o processo.

Entrada para o endpoint da Foundry

Os clientes enviam pedidos HTTPS para o seu endpoint Foundry (por exemplo, <your-resource>.services.ai.azure.com). O gateway API da plataforma autentica o pedido e encaminha-o com base no tipo de agente alvo.

Caminho do agente hospedado

Para um agente alojado, a plataforma encaminha o pedido para uma Micro VM na sua sub-rede delegada através do /invoke protocolo. A Micro VM tem duas interfaces de rede:

Apesar de a Micro VM ter a sua própria NIC, qualquer invocação de ferramenta é encaminhada através do proxy de dados.

Caminho do agente de prompt

Para um prompt agent, o agente corre em computação gerida pela Microsoft. O endpoint do Foundry encaminha o pedido diretamente para o Serviço de Ferramentas, que aciona o proxy de dados dedicado. Os IPs são atribuídos ao nível do projeto, por isso todos os agentes de prompt dentro de um projeto partilham a mesma infraestrutura de proxy de dados.

Saída para os recursos do cliente

O tráfego de saída do proxy de dados chega às suas contas de armazenamento, bases de dados e Key Vault através de endpoints privados na sua sub-rede privada. Configurar as zonas de DNS Privado correspondentes (por exemplo, privatelink.blob.core.windows.net, privatelink.database.windows.net e privatelink.vaultcore.azure.net) para que a resolução dos nomes fique dentro da VNet.

Dimensionamento das subredes e alocação de IP

A configuração da sub-rede aplica-se ao nível da conta da Foundry. Todos os projetos na conta partilham a mesma configuração de sub-rede, e os agentes alojados e de prompt partilham a mesma sub-rede delegada. O tamanho recomendado tem de abranger o uso combinado de IP por parte dos agentes em todos os projetos, atualizações de plataforma e eventos de escalabilidade.

Tamanho recomendado da sub-rede

Use uma faixa CIDR /24 para cargas de trabalho em produção. Uma sub-rede /27 pode funcionar para implantações mais pequenas, mas deixa muito pouco margem de manobra. Atualizações de plataformas, implementações e eventos de escalabilidade precisam de IPs adicionais temporários, e uma pequena sub-rede pode ficar esgotada durante estas operações.

Intervalos IP suportados

A sua sub-rede deve usar apenas os intervalos privados de IPv4 RFC 1918 :

• 10.0.0.0/8
• 172.16.0.0/12 (cobre 172.16.x.x até 172.31.x.x)
• 192.168.0.0/16

Os intervalos públicos de IP e os intervalos CGNAT (por exemplo, 100.64.0.0/10) não são suportados e causam falhas no encaminhamento.

Como as IPs são consumidas

Os IPs são reservados numa proporção de aproximadamente 1 IP por 10 pods . Cada projeto Foundry recebe um proxy de dados que começa com 1 pod (1 réplica) e se expande conforme o tráfego aumenta.

A capacidade do projeto é dinâmica porque um volume maior de tráfego por projeto consome mais IPs.

Tamanho da sub-rede e sessões concorrentes

O número de sessões simultâneas de agentes disponíveis por subscrição varia consoante a região. Por defeito, as sessões simultâneas e os IPs utilizáveis das sub-redes têm uma correspondência de 1:1, até ao limite da sua região.

Com o mapeamento predefinido 1:1, utilize uma sub-rede /26 ou superior para suportar 50 sessões simultâneas.

Para suportar mais sessões concorrentes com a mesma subrede, crie um pedido de suporte do Azure. No pedido, especifique a subscrição, a região e o número esperado de sessões simultâneas. Com base nos seus requisitos e capacidade regional, o suporte pode aumentar o mapeamento para 10 sessões concorrentes por IP utilizável (1:10).

Capacidade do Projeto

Uma instância Foundry suporta aproximadamente 250 projetos com baixo tráfego. Com tráfego intenso, quando os agentes escalam para várias réplicas, o limite efetivo pode descer para apenas ~25 projetos. Quando os IPs são esgotados, a provisão de novos projetos falha.

Comportamento durante a manutenção da plataforma

As atualizações de plataforma fazem funcionar infraestruturas antigas e novas em paralelo, o que aumenta temporariamente o consumo de propriedade intelectual. Uma sub-rede /24 fornece buffer suficiente para lidar com estes picos temporários juntamente com as tuas cargas de trabalho normais. As atualizações de infraestrutura são totalmente geridas pela Microsoft, incluindo o seu timing.

Comportamento de rede dos agentes alojados

Os agentes alojados correm no Azure Container Apps e dão-lhe controlo sobre a configuração do CPU e da memória. Implementa-os através do seu próprio Azure Container Registry.

Revisões e utilização da propriedade intelectual

Quando implementas uma atualização (nova imagem, configuração ou código), a plataforma cria uma nova revisão. Durante o lançamento, as revisões antigas e novas correm em paralelo à medida que o tráfego se desloca para a nova versão, e ambas consomem IPs da sua sub-rede.

Limites de revisão por agente alojado:

• 100 revisões ativas por agente.
• 1.000 revisões totais por nome de agente. As revisões inativas mais antigas são automaticamente eliminadas quando o limite ativo é atingido.
• Aproximadamente 200 agentes hospedados por instância do Foundry.

O limite de 200 agentes hospedados é separado do limite de ~250 projetos, que se aplica a toda a instância, abarcando todos os tipos de agentes.

Conectividade de saída

Cada agente alojado corre numa Micro VM ligada à sua sub-rede delegada com uma interface de rede dedicada e usa o seu próprio IP para comunicação de saída. As chamadas de ferramenta são sempre encaminhadas através do proxy de dados de tenant único. Para implementações de agentes de código-fonte, a etapa de provisionamento também requer acesso de saída a endpoints específicos. Consulte Requisitos de firewall para redes virtuais privadas.

Desempenho e escalabilidade

Escalar agentes alojados não introduz latência nem degradação de desempenho. O único cenário em que o desempenho é afetado é quando o esgotamento do IP impede a plataforma de escalar, o que é evitável com o tamanho adequado das sub-redes. Os agentes alojados suportam configurações personalizadas de CPU e memória. Seleciona entre os pares disponíveis de CPU e memória quando cria uma versão agente.

Comportamento de rede dos agentes de prompt

Os agentes de prompt também correm no Azure Container Apps, mas a computação e a escalabilidade são totalmente geridas pela Microsoft. Não se configura CPU ou memória.

Revisões e utilização da propriedade intelectual

Ao contrário dos agentes hospedados, as revisões dos agentes de prompt não consomem IPs. O proxy de dados funciona em modo de revisão única, pelo que revisões inativas não têm impacto na disponibilidade de IP.

Conectividade de saída

Os agentes de comando utilizam o proxy de dados de inquilino único para toda a conectividade de saída. Os IPs são atribuídos ao nível do projeto, por isso todos os agentes de prompt dentro de um projeto partilham a mesma infraestrutura de proxy de dados.

Limites e desempenho

Não há um limite rígido para o número de prompt agents que podes implementar por instância do Foundry. Como a computação e a escalabilidade são totalmente geridas, não existem problemas esperados de latência ou desempenho ligados ao número de agentes de prompt implementados.

Sobreposição de peering VNet e IP

Intervalos de IP sobrepostos causam falhas de encaminhamento, pelo que todos os VNets peered devem usar intervalos de IP únicos e não sobrepostos. Esta regra aplica-se também a configurações de peering bidirecional. Apenas são suportados intervalos privados IPv4 RFC 1918. Endereços CGNAT (por exemplo, 100.x.x.x) não são suportados.

Se não conseguires evitar sobreposição de IP, usa rede virtual gerida em vez de trazer o teu próprio VNet. O VNet gerido automatiza a configuração da rede e elimina preocupações com sobreposição de IP.

Monitorizar a utilização do IP e detetar exaustão

O portal do Azure atualmente não expõe a utilização de IP para sub-redes delegadas, por isso não podes monitorizá-la diretamente. Os principais indicadores de esgotamento de IP são erros HTTP 5xx provenientes do proxy de dados e, para agentes alojados, falhas na criação de sessão (erros 4xx). Quando os IPs se esgotam, o dimensionamento do proxy de dados e o aprovisionamento de novos projetos falham, e os agentes hospedados não conseguem alocar uma micro VM para novas sessões. Monitorizar a saúde dos proxies de dados e o sucesso na criação de sessões de agentes alojados como indicadores principais de problemas de capacidade.

Considere implementar uma nova instância Foundry com uma sub-rede nova quando observar:

• O proxy de dados devolve erros 5xx.
• A criação de sessão do agente hospedado falha com erros 4xx.
• Falhas no provisionamento de novos projetos.

Referência rápida

Conteúdo relacionado

• Configurar rede privada para o Foundry Agent Service
• Agentes alojados no serviço Foundry Agent
• Rede virtual gerenciada
• Configurar ligação privada