Autor
Este artículo es la segunda parte de una serie en la que recorremos el proceso de registrar modelos utilizando Mlflow, servirlos como un punto final de la API y, finalmente, escalarlos según las necesidades de nuestra aplicación. Le animamos a leer nuestro artículo anterior en el que mostramos cómo desplegar una instancia de seguimiento en k8s y comprobar los prerrequisitos prácticos (secretos, variables de entorno...) ya que aquí seguiremos basándonos en ellos.
A continuación, mostramos cómo servir un modelo de aprendizaje automático que ya está registrado en Mlflow y exponerlo como un punto final de la API en k8s.
Parte 2- ¿Cómo servir un modelo como API en Kubernetes?
Introducción
Es obvio que el seguimiento y la optimización del rendimiento de los modelos es una parte importante de la creación de modelos de ML. Una vez hecho esto, el siguiente reto es integrarlos en una aplicación o un producto para utilizar sus predicciones. Esto es lo que llamamos servicio o inferencia de modelos. Existen diferentes marcos de trabajo y técnicas que nos permiten hacerlo. Sin embargo, aquí nos centraremos en Mlflow y mostraremos lo eficiente y sencillo que puede llegar a ser.
Construir y desplegar la imagen de servicio
Los diferentes archivos de configuración utilizados aquí forman parte del repositorio práctico Básicamente, necesitamos
1. Prepare la imagen docker del servidor Mlflow y envíela al registro de contenedores en GCP.
cd mlflow-serving-ejemplodocker build --tag $/mlflow_serving:v1
--archivo docker_mlflow_serving .docker push $/mlflow_serving:v1
2. Prepare el archivo de despliegue de Kubernetes
modificando la sección del contenedor y mapeándola al imagen docker previamente empujado a GCR, la trayectoria del modelo y el puerto servidor.
| apiVersion: apps/v1 | |
| amable: Despliegue | |
| metadata: | |
| nombre: mlflow-serving | |
| etiquetas: | |
| app: serve-ML-model-mlflow | |
| spec: | |
| réplicas: 1 | |
| selector: | |
| matchLabels: | |
| app: mlflow-serving | |
| plantilla: | |
| metadata: | |
| etiquetas: | |
| app: mlflow-serving | |
| spec: | |
| contenedores: | |
| – nombre: mlflow-serving | |
| imagen: GCR_REPO/mlflow_serving:v1 1TP45Cambie aquí | |
| env: | |
| – nombre: MODELO_URI | |
| valor: “gs://../artifacts/../../artifacts/..“ 1TP45Cambie aquí | |
| – nombre: PUERTO DE SERVICIO | |
| valor: “8082“ | |
| – nombre: GOOGLE_APPLICATION_CREDENTIALS | |
| valor: “/etc/secrets/keyfile.json“ | |
| volumeMounts: | |
| – nombre: gcsfs-creds | |
| mountPath: “/etc/secrets“ | |
| readOnly: verdadero | |
| recursos: | |
| solicita: | |
| cpu: “1000m“ | |
| volúmenes: | |
| – nombre: gcsfs-creds | |
| secreto: | |
| secretName: gcsfs-creds | |
| artículos: | |
| – llave: keyfile.json | |
| ruta: keyfile.json |
3. Ejecute los comandos de despliegue
kubectl create -f deployments/mlflow-serving/mlflow_serving.yaml
4. Exponga el despliegue para el acceso externo
Con el siguiente comando, se creará un nuevo recurso para redirigir el tráfico externo a nuestra API.
kubectl expose deployment mlflow-serving --port 8082 --type="LoadBalancer"
5. Compruebe el despliegue y consulte el punto final
Si el despliegue tiene éxito, mlflow-serving debería estar UP y un pod debería estar disponible. Puede comprobarlo escribiendo kubectl get pods
El paso final es comprobar la dirección IP externa que se asignó al equilibrador de carga que redirige el tráfico a nuestro contenedor API utilizando kubectl obtener servicios y pruebe la respuesta a algunas consultas.
Un código de ejemplo para realizar esas consultas podría encontrarse en lo siguiente cuaderno en el que cargamos unas cuantas filas de data, seleccionamos características, las convertimos a formato JSON y las enviamos en una solicitud posterior a la API.
Ahora, combinando los pasos realizados en nuestros artículos anterior y actual, nuestra arquitectura final tendría el siguiente aspecto:
Conclusión
En este artículo, mostramos que podemos desplegar fácilmente modelos de aprendizaje automático como un punto final de API utilizando el módulo de servicio Mlflow.
Como podrá observar, en nuestro despliegue actual sólo se ha creado un pod para servir el modelo. Aunque esto funciona bien para aplicaciones pequeñas en las que no esperamos múltiples consultas paralelas, podría mostrar rápidamente sus límites en otras, ya que un solo pod tiene recursos limitados. Además, de esta forma la aplicación no podrá utilizar la potencia de cálculo de más de un nodo. En el siguiente y último artículo de esta serie, abordaremos la cuestión de la escalabilidad. En primer lugar, destacaremos los cuellos de botella e intentaremos resolverlos para conseguir una aplicación escalable que aproveche la potencia de nuestro clúster Kubernetes.
