Distribuire, promuovere ed effettuare il rollback di un modello con GitHub Actions

Con il modello registrato e l'innalzamento di livello di produzione protetto da un ambiente GitHub, è possibile gestire le stime senza esporre ogni utente a una versione non testata.

Creare un endpoint e una distribuzione

Un endpoint online gestito fornisce un indirizzo HTTPS stabile che un'applicazione client, ad esempio il sistema di pianificazione di Proseware, chiama per ottenere una stima. L'endpoint stesso non esegue il modello. Una o più distribuzioni, ognuna associa una versione del modello registrata specifica a una configurazione di calcolo e, per i modelli MLflow, un ambiente generato automaticamente e uno script di assegnazione dei punteggi, esegue la gestione effettiva. Mantenere stabile l'URL dell'endpoint mentre si sostituiscono le distribuzioni al di sotto di esso significa che il sistema di pianificazione non deve mai cambiare, anche quando il modello no-show viene nuovamente sottoposto a training e ridistribuito.

Alzare di livello una nuova versione in modo sicuro

Un endpoint può ospitare più distribuzioni alla volta e controllare la percentuale di traffico in ingresso ricevuta da ogni distribuzione. Questa configurazione consente di implementare una nuova versione del modello allo stesso modo in cui si implementa qualsiasi modifica software di produzione: distribuire la nuova versione insieme a quella corrente a 0% traffico, verificare che si comporti come previsto, quindi spostare gradualmente il traffico verso di esso, un approccio comunemente denominato distribuzione blu-verde. Se la nuova versione ha prestazioni inferiori, reindirizzi il traffico alla distribuzione precedente invece di mettere fuori servizio l'endpoint.

Testare prima di spostare il traffico

Prima che una nuova distribuzione riceva qualsiasi traffico live, si inviano richieste direttamente a tale distribuzione e si confrontano le relative risposte rispetto a quanto previsto. Solo dopo che la nuova distribuzione ha superato questi controlli aumenti l'allocazione del traffico. Poiché una distribuzione può richiedere alcuni minuti per raggiungere uno stato pronto, un test automatizzato deve attendere il completamento del provisioning della distribuzione prima che invii le richieste.

Automatizzare la pipeline con GitHub Actions

Ripetere manualmente la registrazione, la distribuzione e i test per ogni modello riaddestrato non è scalabile, quindi il team di Proseware automatizza la pipeline con GitHub Actions e la CLI di Azure Machine Learning (v2). Il modo consigliato corrente per autenticare un flusso di lavoro per Azure è OpenID Connect (OIDC) credenziali federate, che consentono di GitHub Actions richiedere un token di accesso di breve durata anziché archiviare un segreto client come segreto del repository. Si configura una credenziale federata in un'applicazione Microsoft Entra, limitata al repository e al ramo, quindi la si richiama nel flusso di lavoro con l'azione 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

Il blocco permissions del flusso di lavoro concede al processo le autorizzazioni id-token necessarie per richiedere un token ad Azure. Il azure/login passaggio scambia tale token per una sessione di interfaccia della riga di comando di Azure autenticata. Dopo che un test diretto è riuscito, il flusso di lavoro invia il 10% del traffico alla nuova distribuzione green. Promuoverlo ulteriormente solo dopo che il suo comportamento di produzione soddisfa i criteri di accettazione.

Torna al modello precedente

Mantenere disponibile la distribuzione precedente blue fino a quando il nuovo modello non completa il periodo di osservazione. Se dopo la promozione si verificano errori o previsioni inaccettabili, reindirizzare tutto il traffico a blue:

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

La modifica del traffico mantiene l'URL dell'endpoint e offre un ripristino più rapido rispetto all'eliminazione e alla ricreazione dell'endpoint. Dopo il ritorno del traffico al modello precedente, esaminare la green distribuzione senza esporre gli utenti. Eliminare la distribuzione precedente solo dopo che il nuovo modello soddisfa i criteri di accettazione per il periodo di osservazione richiesto.