Déployer, promouvoir et restaurer un modèle avec GitHub Actions

Avec le modèle inscrit et la promotion de production protégés par un environnement GitHub, vous êtes prêt à servir des prédictions sans exposer chaque utilisateur à une version non testée.

Créer un point de terminaison et un déploiement

Un point de terminaison en ligne managé fournit une adresse HTTPS stable qu’une application cliente, comme le système de planification de Proseware, appelle pour obtenir une prédiction. Le point de terminaison lui-même n’exécute pas le modèle. Un ou plusieurs déploiements, chacun associant une version spécifique d’un modèle enregistré à une configuration de calcul et, pour les modèles MLflow, à un environnement généré automatiquement et à un script de scoring, assurent concrètement le service. Le fait de maintenir l’URL du point de terminaison stable pendant que vous remplacez les déploiements sous-jacents signifie que le système de planification n’a pas besoin d’être modifié, même lorsque le modèle de prédiction des absences est réentraîné et redéployé.

Promouvoir une nouvelle version en toute sécurité

Un point de terminaison peut héberger plusieurs déploiements à la fois et contrôler le pourcentage de trafic entrant reçu par chaque déploiement. Cette configuration vous permet de déployer une nouvelle version de modèle de la même façon que vous déployiez n’importe quelle modification logicielle de production : déployez la nouvelle version en même temps que celle actuelle à 0% trafic, confirmez qu’elle se comporte comme prévu, puis déplacez progressivement le trafic vers celui-ci, une approche communément appelée déploiement bleu-vert. Si la nouvelle version offre de moins bonnes performances, vous redirigez le trafic vers le déploiement précédent au lieu de mettre le point de terminaison hors service.

Tester avant de déplacer le trafic

Avant qu’un nouveau déploiement reçoive tout trafic en direct, vous envoyez des demandes directement à ce déploiement et comparez ses réponses à ce que vous attendez. Une fois que le nouveau déploiement passe ces vérifications, vous augmentez son allocation de trafic. Étant donné qu’un déploiement peut prendre quelques minutes pour atteindre un état prêt, un test automatisé doit attendre que le déploiement termine l’approvisionnement avant d’envoyer des demandes.

Automatiser le pipeline avec GitHub Actions

Répéter manuellement l'enregistrement, le déploiement et les tests pour chaque modèle réentraîné n'est pas viable à grande échelle ; l'équipe de Proseware automatise donc le pipeline avec GitHub Actions et l'interface de ligne de commande Azure Machine Learning (v2). La méthode recommandée actuelle pour authentifier un flux de travail à Azure est les informations d’identification fédérées OpenID Connect (OIDC), ce qui permet GitHub Actions demander un jeton d’accès à courte durée au lieu de stocker un secret client en tant que secret de référentiel. Vous configurez des informations d’identification fédérées sur une application Microsoft Entra, délimitée à votre référentiel et à votre branche, puis vous la référencez dans le flux de travail avec l’action 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

Le bloc permissions du flux de travail accorde à la tâche les id-token dont elle a besoin pour demander un jeton à Azure. L’étape azure/login échange ce jeton pour une session de Azure CLI authentifiée. Une fois qu’un test en direct a réussi, le flux de travail envoie 10 % du trafic vers le nouveau déploiement green. Promouvez-le davantage uniquement après que son comportement de production répond à vos critères d’acceptation.

Revenir au modèle précédent

Conservez le déploiement précédent blue disponible jusqu’à ce que le nouveau modèle termine sa période d’observation. Si des erreurs ou des prédictions inacceptables apparaissent après la promotion, routez tout le trafic vers blue:

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

La modification du trafic conserve l’URL du point de terminaison et offre une récupération plus rapide que la suppression et la recréation du point de terminaison. Une fois le trafic revenu au modèle précédent, examinez le déploiement green sans y exposer les utilisateurs. Supprimez le déploiement précédent uniquement après que le nouveau modèle respecte ses critères d’acceptation pour la période d’observation requise.