Implementación, promoción y reversión de un modelo con Acciones de GitHub

Con el modelo registrado y la promoción de producción protegidos por un entorno de GitHub, está listo para servir predicciones sin exponer a todos los usuarios a una versión no probada.

Creación de un punto de conexión y una implementación

Un punto de conexión en línea administrado proporciona una dirección HTTPS estable que una aplicación cliente, como el sistema de programación de Proseware, llama a para obtener una predicción. El propio punto de conexión no ejecuta el modelo. Una o varias implementaciones, cada una de las cuales empareja una versión de modelo registrada específica con una configuración de proceso y, para los modelos de MLflow, un entorno generado automáticamente y un script de puntuación, realizan el servicio real. Mantener estable la URL del punto de conexión mientras reemplaza los despliegues por detrás significa que el sistema de planificación nunca necesita cambiar, incluso cuando el modelo de no presentación se reentrena y se vuelve a desplegar.

Promover una nueva versión de forma segura

Un punto de conexión puede hospedar más de una implementación a la vez y controlar el porcentaje de tráfico entrante que recibe cada implementación. Esta configuración le permite implementar una nueva versión del modelo de la misma manera que implementaría cualquier cambio de software de producción: implementar la nueva versión junto con la actual en 0% tráfico, confirmar que se comporta como se esperaba y, a continuación, desplazar gradualmente el tráfico hacia él, un enfoque que normalmente se denomina implementación azul-verde. Si la nueva versión rinde peor, rediriges el tráfico al despliegue anterior en lugar de desactivar el punto de conexión.

Haz pruebas antes de redirigir el tráfico

Antes de que una nueva implementación reciba cualquier tráfico activo, envíe solicitudes directamente a esa implementación y compare sus respuestas con respecto a lo que espera. Solo después de que la nueva implementación supere estas comprobaciones, aumente su asignación de tráfico. Dado que una implementación puede tardar unos minutos en llegar a un estado listo, una prueba automatizada debe esperar a que la implementación finalice el aprovisionamiento antes de enviar solicitudes.

Automatización de la canalización con Acciones de GitHub

Repetir manualmente el registro, la implementación y las pruebas para cada modelo reentrenado no es escalable, por lo que el equipo de Proseware automatiza la canalización con Acciones de GitHub y la CLI de Azure Machine Learning (v2). La forma recomendada actual de autenticar un flujo de trabajo en Azure es credenciales federadas de OpenID Connect (OIDC), lo que permite Acciones de GitHub solicitar un token de acceso de corta duración en lugar de almacenar un secreto de cliente como secreto de repositorio. Configura una credencial federada en una aplicación de Microsoft Entra, limitada a tu repositorio y rama, y luego haz referencia a ella en el flujo de trabajo con la acción azure/login:

permissions:
  id-token: write
  contents: read

env:
  RESOURCE_GROUP: ${{ vars.AZURE_RESOURCE_GROUP }}
  WORKSPACE_NAME: ${{ vars.AZURE_WORKSPACE_NAME }}
  ENDPOINT_NAME: ${{ vars.AZURE_ENDPOINT_NAME }}

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Sign in to Azure
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
      - name: Register and deploy the model
        run: |
          az extension add -n ml -y
          az ml model create \
            --file model.yml \
            --resource-group $RESOURCE_GROUP \
            --workspace-name $WORKSPACE_NAME
          az ml online-deployment create \
            --name green \
            --endpoint-name $ENDPOINT_NAME \
            --file green-deployment.yml \
            --resource-group $RESOURCE_GROUP \
            --workspace-name $WORKSPACE_NAME
      - name: Test the new deployment
        run: |
          az ml online-endpoint invoke \
            --name $ENDPOINT_NAME \
            --deployment-name green \
            --request-file sample-request.json \
            --resource-group $RESOURCE_GROUP \
            --workspace-name $WORKSPACE_NAME
      - name: Send limited traffic to the new deployment
        run: |
          az ml online-endpoint update \
            --name $ENDPOINT_NAME \
            --traffic "blue=90 green=10" \
            --resource-group $RESOURCE_GROUP \
            --workspace-name $WORKSPACE_NAME

El bloque permissions del flujo de trabajo concede al trabajo el id-token que necesita para solicitar un token de Azure. El azure/login paso intercambia ese token para una sesión de CLI de Azure autenticada. Una vez que una prueba directa se realiza correctamente, el flujo de trabajo envía 10% de tráfico a la nueva green implementación. Siga promocionándolo solo después de que su comportamiento en producción cumpla los criterios de aceptación.

Revertir al modelo anterior

Mantenga la implementación anterior blue disponible hasta que el nuevo modelo complete su período de observación. Si aparecen errores o predicciones inaceptables tras la promoción, redirija todo el tráfico de vuelta a blue:

az ml online-endpoint update \
  --name $ENDPOINT_NAME \
  --traffic "blue=100 green=0" \
  --resource-group $RESOURCE_GROUP \
  --workspace-name $WORKSPACE_NAME

Cambiar el tráfico conserva la dirección URL del punto de conexión y proporciona una recuperación más rápida que eliminar y volver a crear el punto de conexión. Una vez que el tráfico haya vuelto al modelo anterior, investiga el despliegue green sin exponer a los usuarios a este. Elimine la implementación anterior solo después de que el nuevo modelo cumpla sus criterios de aceptación para el período de observación necesario.