Platform For AI:Chamar services por uma conexão direta VPC

Casos de uso

• Requisitos de alto desempenho: Para services com alto tráfego e grande volume de consultas por segundo (QPS), como reconhecimento de imagem ou fala, a conexão direta melhora significativamente o desempenho de acesso.

• Aplicações sensíveis à latência: Em services que exigem tempos de resposta rápidos, como recomendação online e controle de risco financeiro, a conexão direta reduz efetivamente a latência.

Como funciona

A conexão direta VPC baseia-se em dois mecanismos:

• Conectividade de rede: Após configure uma VPC para um service, o PAI-EAS cria e anexa uma interface de rede elástica auxiliar gratuita para cada instância de service na VPC e no vSwitch especificados. Isso estabelece um caminho de rede direto entre a VPC e as instâncias de service do PAI-EAS. Consequentemente, os clientes dentro da VPC acessam as instâncias de service do PAI-EAS diretamente, sem passar por um gateway, evitando o encaminhamento de rede de camada 4 do slb e de camada 7.

• Descoberta de service: O PAI-EAS oferece um mecanismo de descoberta de service que permite aos clientes obter uma lista em tempo real de pares IP:PORT de todas as instâncias de service. Os clientes usam essa lista para implementar balanceamento de carga e failover.

Acesso entre regiões e faturamento

P: Qual a diferença entre o acesso interno VPC entre regiões e o acesso pela rede pública?

A principal diferença depende do seu tipo de gateway:

• Gateway compartilhado: Basta estabelecer conectividade de rede entre as duas VPCs (por exemplo, usando CEN ou VPC peering). Nenhuma configuração adicional de gateway do PAI-EAS é necessária.

• Gateway dedicado: Além de estabelecer a conectividade da VPC, execute etapas adicionais de configuração relacionadas ao CEN no PAI-EAS. Para mais informações, consulte Cross-VPC access to a dedicated gateway using CEN.

P: O acesso interno VPC entre regiões gera custos de tráfego? Por que ainda é recomendado?

Sim, o tráfego de rede interna entre regiões incorre em taxas. Apesar disso, o acesso interno pela VPC é recomendado para ambientes de produção pelos seguintes motivos:

• Segurança: O tráfego não passa pela internet pública, eliminando riscos de exposição externa.

• Desempenho: Menor latência e conexões mais estáveis em comparação ao acesso pela rede pública.

• Eficiência de custos: Os custos de tráfego de rede interna entre regiões geralmente são menores que os custos de tráfego de saída pela rede pública.

Configuração de endpoint estável para services com múltiplas réplicas

Quando seu service escala para múltiplas réplicas, os IPs das instâncias de backend podem mudar. Utilize as abordagens a seguir para manter um endereço de conexão estável.

Princípio subjacente: O PAI-EAS usa o slb (Server Load Balancer) para expor um Service Endpoint unificado para cada service. Independentemente de quantas réplicas de backend estejam em execução, os clientes precisam se conectar apenas a este único endereço — não é necessário rastrear alterações individuais de IP das instâncias.

• Opção 1 (Recomendada): Use o domínio público com uma lista de permissões de IP de backend. Configure o backend para permitir tráfego apenas do intervalo de IPs da sua VPC par. Isso fornece um endereço de domínio estável sem configuração adicional de dns.

• Opção 2: Configure o Alibaba Cloud PrivateZone na sua VPC par para resolver um domínio personalizado para o endereço IP privado do PAI-EAS. Observe que, se o endereço IP mudar, atualize o registro dns ou integre um mecanismo de descoberta de service para manter a resolução atualizada.

Chamar outros services EAS a partir de um contêiner EAS

Se o seu service EAS precisar chamar outro service EAS de dentro do seu contêiner, observe o seguinte:

• Erros 401 ou falhas de conexão: Geralmente ocorrem quando uma aplicação em contêiner chama outro service EAS usando um endpoint público. As causas comuns são restrições de rede no ambiente do contêiner ou configuração incorreta de token.

• Abordagem recomendada: Use o endereço interno da VPC para chamadas entre services. Isso garante conectividade e melhora a segurança.

• Alternativa: Se for obrigatório usar um endpoint público, configure um gateway dedicado. Note que isso envolve custos adicionais de ALB.

• Requisito de autenticação: Independentemente do tipo de endereço utilizado, cada requisição deve incluir um token de Authorization válido no cabeçalho da requisição.

Lógica principal

Ao usar uma conexão direta VPC, o cliente ignora o gateway e se conecta diretamente às instâncias de service. Isso significa que o cliente é responsável por lidar com a descoberta de service, balanceamento de carga e nova tentativa após falha. Os sdks oficiais do PAI-EAS encapsulam essa lógica para você:

• Descoberta de service: O sdk inicia uma thread em segundo plano durante a inicialização para chamar periodicamente a API de descoberta de service do PAI-EAS. Ele recupera e armazena em cache uma lista de pares IP:PORT e pesos das instâncias de backend. Se a chamada à API falhar, o sdk continua usando a última lista em cache para garantir a disponibilidade.

• Balanceamento de carga: Para cada requisição, o sdk selecione uma instância alvo do cache local usando um algoritmo de round-robin ponderado. Os pesos são determinados pelos pesos das instâncias retornados pela API de descoberta de service.

• Nova tentativa após falha: Se uma requisição falhar devido a erro de rede, tempo limite de conexão ou resposta 5xx, o sdk tenta novamente a requisição em uma instância diferente do cache local. Em uma implantação com múltiplas instâncias, isso evita que uma única instância defeituosa cause falhas nas requisições.

Se você planeja crie um cliente personalizado sem usar um sdk, implemente capacidades equivalentes. Para mais informações, consulte Build a custom client.

Exemplos

package main

import (
        "fmt"
        "github.com/pai-eas/eas-golang-sdk/eas"
)

func main() {
    // Use the endpoint in the format {Uid}.vpc.{RegionId}.pai-eas.aliyuncs.com. Replace {Uid} with your account ID and specify the service region and name. For example, the region ID for China (Shanghai) is cn-shanghai.
    client := eas.NewPredictClient("123**********.vpc.cn-shanghai.pai-eas.aliyuncs.com", "scorecard_pmml_example")
    // Replace with your service token. You can find the token under Invocation Information on the service details page.
    client.SetToken("YWFlMDYyZDNmNTc3M2I3MzMwYmY0MmYwM2Y2MTYxMTY4NzBkNzdj****")
    client.SetEndpointType(eas.EndpointTypeDirect)
    client.Init()
    req := "[{\"fea1\": 1, \"fea2\": 2}]"
    for i := 0; i < 100; i++ {
        resp, err := client.StringPredict(req)
        if err != nil {
            fmt.Printf("failed to predict: %v\n", err.Error())
        } else {
            fmt.Printf("%v\n", resp)
        }
    }
}

API de descoberta de service

O PAI-EAS fornece uma API HTTP para descoberta de service dentro da VPC configurada. A API retorna uma lista de endereços IP, portas e pesos de todas as instâncias de backend de um service.

• URL: http://<Your Alibaba Cloud Account ID>.vpc.<RegionID>.pai-eas.aliyuncs.com/exported/apis/eas.alibaba-inc.k8s.io/v1/upstreams/<Service Name>

• Autenticação: Nenhum token é necessário. A API é acessível apenas de dentro da VPC configurada para o service.

• Intervalo de polling: Esta é uma API de canal lateral e deve ser chamada periodicamente por uma tarefa em segundo plano, por exemplo, a cada 5 ou 10 segundos. Não chame esta API para cada requisição de inferência. Fazer isso degrada severamente o desempenho.

Exemplo:

O exemplo a seguir mostra como consultar um service chamado mnist_saved_model_example implantado em China (Hangzhou) com duas instâncias.

$curl http://123**********.vpc.cn-hangzhou.pai-eas.aliyuncs.com/exported/apis/eas.alibaba-inc.k8s.io/v1/upstreams/mnist_saved_model_example

Substitua 123********** pelo ID da sua conta.

A resposta a seguir mostra uma lista de endereços de service de backend:

{
  "correlative": [
    "mnist_saved_model_example"
  ],
  "endpoints": {
    "items": [
      {
        "app": "mnist-saved-model-example",
        "ip": "172.16.XX.XX",
        "port": 50000,
        "weight": 100
      },
      {
        "app": "mnist-saved-model-example",
        "ip": "172.16.XX.XX",
        "port": 50000,
        "weight": 100
      }
    ]
  }
}

Solução de problemas: Falhas de acesso ao domínio VPC

Sintoma: O domínio VPC está inacessível, mas o service pode ser acessado via endereço IP direto retornado pela API de descoberta de service.

Causa comum: Sintaxe incorreta do comando curl — por exemplo, a URL não está entre aspas, o que faz com que o shell interprete mal caracteres especiais como & ou ? na URL.

Solução: Coloque a URL entre aspas duplas e execute uma requisição de teste mínima via endereço IP ou domínio VPC para verifique a conectividade:

# Test using the VPC domain (URL must be enclosed in double quotes)
curl "http://123**********.vpc.cn-hangzhou.pai-eas.aliyuncs.com/api/predict/your-service-name" \
  -H "Authorization: your-token"

# Test using a direct IP address (replace with an IP from the service discovery API response)
curl "http://172.16.XX.XX:50000/api/predict/your-service-name" \
  -H "Authorization: your-token"

Requisitos de implementação

Ao crie um cliente personalizado, você deve lidar com a descoberta de service, balanceamento de carga e novas tentativas após falha. Para uma implementação de referência completa, consulte o código-source do Python sdk. A seguir estão os principais requisitos de implementação:

1. Armazene a lista de instâncias em cache localmente e atualize-a periodicamente: Inicie uma thread em segundo plano para chamar periodicamente a API de descoberta de service, por exemplo, a cada 5 ou 10 segundos. Substitua a lista de instâncias em cache local pela lista retornada.

   Importante

   A API de descoberta de service é um service de canal lateral. Não a chame para cada requisição de inferência. Se a chamada à API falhar ou retornar uma lista vazia, continue usando a lista em cache local. Não limpe o cache. Deixar de fazer isso tornará seu service indisponível.

2. Balanceie as requisições: Para cada requisição de inferência, selecione uma instância do cache local. Recomendamos o uso de um algoritmo round-robin ponderado, mas você também pode usar um algoritmo personalizado com base na sua lógica de negócios.

3. Tente novamente requisições com falha: Se uma requisição falhar devido a erro de conexão, tempo limite ou resposta 5xx, tente novamente a requisição em uma instância diferente do cache local. Isso requer pelo menos duas instâncias disponíveis.