Implantar, promover e reverter um modelo com GitHub Actions
Com o modelo registrado e a promoção para produção protegidos por um ambiente do GitHub, você está pronto para servir previsões sem expor todos os usuários a uma versão não testada.
Criar um endpoint e uma implantação
Um endpoint online gerenciado fornece um endereço HTTPS estável que uma aplicação cliente, como o sistema de agendamento da Proseware, chama para obter uma previsão. O ponto de extremidade em si não executa o modelo. Uma ou mais implantações, cada uma associando uma versão específica de modelo registrada a uma configuração computacional e, para modelos do MLflow, a um ambiente gerado automaticamente e a um script de inferência, são as responsáveis pela efetiva disponibilização do modelo. Manter a URL do endpoint estável enquanto você substitui as implantações subjacentes faz com que o sistema de agendamento nunca precise ser alterado, mesmo quando o modelo de não comparecimento é retreinado e reimplantado.
Dica
Saiba mais sobre como implantar modelos de aprendizado de máquina em endpoints online.
Promover uma nova versão com segurança
Um endpoint pode hospedar mais de uma implantação por vez, e você controla qual porcentagem do tráfego de entrada cada implantação recebe. Essa configuração permite que você implemente uma nova versão de modelo da mesma maneira que você implementaria qualquer alteração de software de produção: implantar a nova versão junto com a atual em 0% tráfego, confirmar que ela se comporta conforme o esperado e, em seguida, deslocar gradualmente o tráfego em direção a ela, uma abordagem comumente chamada de implantação azul-verde. Se a nova versão apresentar desempenho inferior, você redireciona o tráfego de volta para a versão implantada anteriormente, em vez de tirar o endpoint do ar.
Dica
Saiba mais sobre a implantação segura para endpoints online.
Teste antes de redirecionar o tráfego
Antes que uma nova implantação receba qualquer tráfego dinâmico, você envia solicitações diretamente para essa implantação e compara suas respostas com o que você espera. Você só aumenta a alocação de tráfego da nova implantação depois que ela passa por essas verificações. Como uma implantação pode levar alguns minutos para chegar a um estado pronto, um teste automatizado precisa aguardar a implantação concluir o provisionamento antes de enviar solicitações.
Automatizar o pipeline com GitHub Actions
Repetir manualmente o registro, a implantação e os testes de cada modelo retreinado não é escalável; por isso, a equipe da Proseware automatiza o pipeline com o GitHub Actions e a CLI do Azure Machine Learning (v2). A maneira recomendada atual de autenticar um fluxo de trabalho para Azure é as credenciais federadas do OpenID Connect (OIDC), que permitem GitHub Actions solicitar um token de acesso de curta duração em vez de armazenar um segredo do cliente como um segredo do repositório. Você configura uma credencial federada em um aplicativo do Microsoft Entra, com escopo para o seu repositório e a sua ramificação e, em seguida, faz referência a ela 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 permissions do fluxo de trabalho concede ao trabalho o id-token necessário para solicitar um token do Azure. A azure/login etapa troca esse token por uma sessão de CLI do Azure autenticada. Depois que um teste direto é bem-sucedido, o fluxo de trabalho envia 10% de tráfego para a nova green implantação. Promova-o ainda mais somente depois que seu comportamento de produção atender aos seus critérios de aceitação.
Reverter para o modelo anterior
Mantenha a blue implantação anterior disponível até que o novo modelo conclua seu período de observação. Se erros ou previsões inaceitáveis aparecerem 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 ponto de extremidade e fornece uma recuperação mais rápida do que excluir e recriar o ponto de extremidade. Depois que o tráfego retornar ao modelo anterior, investigue a green implantação sem expor os usuários a ele. Exclua a implantação anterior somente depois que o novo modelo atender aos critérios de aceitação para o período de observação necessário.
Dica
Saiba mais sobre como conectar GitHub Actions a Azure com o OpenID Connect.