Autor
Este artigo é a segunda parte de uma série na qual percorremos o processo de registro de modelos usando o Mlflow, servindo-os como um endpoint de API e, por fim, dimensionando-os de acordo com as necessidades do nosso aplicativo. Recomendamos que os senhores leiam nosso artigo anterior, no qual mostramos como implantar uma instância de rastreamento no k8s e verificar os pré-requisitos práticos (segredos, variáveis de ambiente...), pois continuaremos a nos basear neles aqui.
A seguir, mostramos como servir um modelo de aprendizado de máquina que já está registrado no Mlflow e expô-lo como um endpoint de API no k8s.
Parte 2 - Como servir um modelo como uma API no Kubernetes?
Introdução
É óbvio que rastrear e otimizar o desempenho dos modelos é uma parte importante da criação de modelos de ML. Uma vez feito isso, o próximo desafio é integrá-los a um aplicativo ou produto para usar suas previsões. Isso é o que chamamos de inferência ou serviço de modelos. Existem diferentes estruturas e técnicas que nos permitem fazer isso. No entanto, aqui vamos nos concentrar no Mlflow e mostraremos como ele pode ser eficiente e direto.
Criar e implementar a imagem de serviço
Os diferentes arquivos de configuração usados aqui fazem parte do repositório prático Basicamente, precisamos:
1. Prepare a imagem do docker de serviço do Mlflow e envie-a para o registro de contêineres no GCP.
cd mlflow-serving-exampledocker build --tag $/mlflow_serving:v1
--file docker_mlflow_serving .docker push $/mlflow_serving:v1
2. Prepare o arquivo de implantação do Kubernetes
modificando a seção do contêiner e mapeando-a para o imagem do docker anteriormente enviados para o GCR, o caminho do modelo e a porta de serviço.
| Versão da API: aplicativos/v1 | |
| tipo: Implantação | |
| metadata: | |
| nome: mlflow-serving | |
| rótulos: | |
| aplicativo: servir-ML-model-mlflow | |
| especificação: | |
| réplicas: 1 | |
| seletor: | |
| matchLabels: | |
| aplicativo: mlflow-serving | |
| modelo: | |
| metadata: | |
| rótulos: | |
| aplicativo: mlflow-serving | |
| especificação: | |
| contêineres: | |
| - nome: mlflow-serving | |
| imagem: GCR_REPO/mlflow_serving:v1 #roque aqui | |
| env: | |
| - nome: MODEL_URI | |
| valor: “gs://../artifacts/../../artifacts/..“ #roque aqui | |
| - nome: SERVING_PORT | |
| valor: “8082“ | |
| - nome: GOOGLE_APPLICATION_CREDENTIALS | |
| valor: “/etc/secrets/keyfile.json“ | |
| volumeMounts: | |
| - nome: gcsfs-creds | |
| mountPath: “/etc/secrets“ | |
| readOnly: verdadeiro | |
| recursos: | |
| solicitações: | |
| cpu: “1000m“ | |
| volumes: | |
| - nome: gcsfs-creds | |
| segredo: | |
| secretName: gcsfs-creds | |
| itens: | |
| - chave: keyfile.json | |
| caminho: keyfile.json |
3. Executar comandos de implantação
kubectl create -f deployments/mlflow-serving/mlflow_serving.yaml
4. Expor a implementação para acesso externo
Com o comando a seguir, um novo recurso será criado para redirecionar o tráfego externo para nossa API.
kubectl expose deployment mlflow-serving --port 8082 --type="LoadBalancer"
5. Verificar a implementação e consultar o ponto de extremidade
Se a implantação for bem-sucedida, o mlflow-serving deverá ser UP e um pod deverá estar disponível. O senhor pode verificar isso digitando kubectl get pods
A etapa final é verificar o endereço IP externo que foi atribuído ao balanceador de carga que redireciona o tráfego para nosso contêiner de API usando kubectl get services e testar a resposta a algumas consultas.
Um exemplo de código para realizar essas consultas pode ser encontrado no seguinte notebook no qual carregamos algumas linhas do data, selecionamos recursos, convertemos em formato JSON e os enviamos em uma solicitação de postagem para a API.
Agora, combinando as etapas realizadas em nossos artigos anterior e atual, nossa arquitetura final seria a seguinte:
Conclusão
Neste artigo, mostramos que podemos implementar facilmente modelos de aprendizado de máquina como um endpoint de API usando o módulo de serviço Mlflow.
Como o senhor pode notar, em nossa implantação atual, apenas um pod foi criado para atender ao modelo. Embora isso funcione bem para aplicativos pequenos em que não esperamos várias consultas paralelas, pode rapidamente mostrar seus limites em outros, pois um único pod tem recursos limitados. Além disso, dessa forma, o aplicativo não poderá usar a capacidade de computação de mais de um nó. No próximo e último artigo desta série, abordaremos a questão da escalabilidade. Primeiro, destacaremos os gargalos e tentaremos resolvê-los para obter um aplicativo dimensionável que aproveite o poder do nosso cluster do Kubernetes.
