Implemente, promova e reverta um modelo com o GitHub Actions

Com o modelo registado e a promoção de produção protegida por um ambiente GitHub, está pronto para apresentar previsões sem expor todos os utilizadores a uma versão não testada.

Crie um endpoint e uma implementação

Um ponto final online gerido fornece um endereço HTTPS estável que uma aplicação cliente, como o sistema de agendamento da Proseware, invoca para obter uma previsão. O endpoint em si não executa o modelo. Uma ou mais implementações, cada uma emparelhando uma versão específica do modelo registado com uma configuração de computação e, para modelos MLflow, um ambiente autogerado e um script de pontuação, realizam o serviço efetivo. Manter a URL do endpoint inalterada enquanto substitui as implementações em produção subjacentes significa que o sistema de agendamento nunca precisa de mudar, mesmo quando o modelo de faltas é retreinado e novamente colocado em produção.

Promova uma nova versão de forma segura

Um endpoint pode alojar mais do que uma implementação ao mesmo tempo, e tu controlas a percentagem do tráfego recebido por cada implementação. Esta configuração permite-lhe disponibilizar uma nova versão do modelo da mesma forma que disponibilizaria qualquer alteração de software em produção: implementar a nova versão a par da versão atual, com 0% de tráfego, confirmar que se comporta como esperado e, em seguida, desviar gradualmente o tráfego para ela, numa abordagem normalmente designada por implementação azul/verde. Se a nova versão tiver um desempenho inferior, transferes o tráfego de volta para a implementação anterior em vez de derrubares o endpoint.

Teste antes de redirecionar o tráfego

Antes de uma nova implantação receber qualquer tráfego real, envia pedidos diretamente para essa implantação e compara as suas respostas com o que é esperado. Só depois de a nova implementação passar estas verificações é que se aumenta a alocação de tráfego. Como uma implementação pode demorar alguns minutos a atingir um estado de prontidão, um teste automatizado precisa de esperar que a implementação termine o provisionamento antes de enviar pedidos.

Automatize o pipeline com GitHub Actions

Repetir manualmente o registo, a implementação em produção e os testes para cada modelo retreinado não é escalável, pelo que a equipa da Proseware automatiza o pipeline com o GitHub Actions e a CLI do Azure Machine Learning (v2). A forma atualmente recomendada de autenticar um fluxo de trabalho no Azure são as credenciais federadas OpenID Connect (OIDC), que permitem ao GitHub Actions pedir um token de acesso de curta duração em vez de armazenar um segredo do cliente como segredo de repositório. Configura uma credencial federada numa aplicação Microsoft Entra, com âmbito limitado ao seu repositório e ramo, e depois faz-lhe referência no fluxo de trabalho com a ação 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

O bloco do fluxo de trabalho permissions concede ao trabalho a id-token de que este precisa para pedir um token ao Azure. O azure/login step troca esse token por uma sessão CLI do Azure autenticada. Após um teste direto bem-sucedido, o fluxo de trabalho envia 10% de tráfego para a nova green implementação. Promova-o ainda mais apenas depois de o seu comportamento de produção cumprir os seus critérios de aceitação.

Voltar ao modelo anterior

Mantenha a implementação anterior blue disponível até que o novo modelo complete o seu período de observação. Se surgirem erros ou previsões inaceitáveis após a promoção, encaminhe todo o tráfego de volta para blue:

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

Alterar o tráfego preserva a URL do endpoint e proporciona uma recuperação mais rápida do que eliminar e recriar o endpoint. Depois de o tráfego regressar ao modelo anterior, investigue a implementação green sem expor os utilizadores à mesma. Elimine a implementação anterior apenas depois de o novo modelo cumprir os seus critérios de aceitação para o período de observação exigido.