Развертывание, повышение уровня и откат модели с помощью GitHub Actions

Завершено

Когда модель зарегистрирована, а продвижение в рабочую среду защищено с помощью среды GitHub, вы готовы предоставлять прогнозы, не предоставляя всем пользователям непроверенную версию.

Создайте конечную точку и развертывание

Управляемая конечная точка в Сети предоставляет стабильный HTTPS-адрес, который клиентское приложение, например система планирования Proseware, вызывает для получения прогноза. Сама конечная точка не запускает модель. Одно или несколько развертываний, каждое из которых сопоставляет определенную зарегистрированную версию модели с конфигурацией вычислительных ресурсов, а для моделей MLflow — с автоматически созданной средой и скриптом оценки, обеспечивают фактическое обслуживание. Сохранение стабильного URL конечной точки при замене связанных с ней развертываний означает, что систему планирования никогда не придется менять, даже если модель прогнозирования неявок переобучается и повторно развертывается.

Совет

Дополнительные сведения о развертывании моделей машинного обучения в сетевых конечных точках.

Безопасное повышение уровня новой версии

Конечная точка может одновременно размещать несколько развертываний, и вы управляете тем, какой процент входящего трафика получает каждое развертывание. Эта настройка позволяет развернуть новую версию модели так же, как и вы развертываете любые изменения в рабочем программном обеспечении: разверните новую версию вместе с текущей версией в 0% трафике, убедитесь, что она ведет себя должным образом, а затем постепенно переместите трафик на него, подход, обычно называемый сине-зеленым развертыванием. Если новая версия работает хуже, вы возвращаете трафик на предыдущее развертывание, а не отключаете конечную точку.

Совет

Узнайте больше о безопасном развертывании для оперативных конечных точек.

Тестирование перед сменой трафика

Прежде чем новое развертывание получает любой динамический трафик, вы отправляете запросы непосредственно в это развертывание и сравниваете ответы с ожидаемыми. Только после того, как новое развертывание пройдет эти проверки, увеличьте распределение трафика. Так как развертывание может занять несколько минут, чтобы достичь состояния готовности, автоматизированный тест должен ждать завершения подготовки развертывания, прежде чем отправлять запросы.

Автоматизация конвейера с помощью GitHub Actions

Вручную повторять регистрацию, развертывание и тестирование для каждой заново обученной модели нецелесообразно в таком масштабе, поэтому команда Proseware автоматизирует этот конвейер с помощью GitHub Actions и Машинное обучение Azure CLI (v2). Текущий рекомендуемый способ проверки подлинности рабочего процесса для Azure является федеративными учетными данными OpenID Connect (OIDC), что позволяет GitHub Actions запрашивать маркер доступа с коротким сроком действия, а не хранить секрет клиента в качестве секрета репозитория. Вы настраиваете федеративные учетные данные в приложении Microsoft Entra для вашего репозитория и ветви, а затем используете их в рабочем процессе с помощью действия 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

Блок permissions в рабочем процессе предоставляет заданию id-token, необходимые для запроса токена от Azure. На этапе azure/login этот маркер обменивается на сеанс Azure CLI с проверкой подлинности. После успешного прямого теста процесс направляет 10 % трафика на новое green развертывание. Продвигайте его дальше только после того, как его поведение в рабочей среде будет соответствовать вашим критериям приемки.

Откат к предыдущей модели

Оставьте предыдущее blue развертывание доступным до тех пор, пока новая модель не завершит свой период наблюдения. Если ошибки или неприемлемые прогнозы появляются после повышения, перенаправите весь трафик обратно в blue:

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

Изменение трафика сохраняет URL-адрес конечной точки и обеспечивает быстрое восстановление, чем удаление и восстановление конечной точки. После возврата трафика на предыдущую модель проверьте развертывание green, не открывая к нему доступ пользователям. Удалите предыдущее развертывание только после того, как новая модель соответствует его критериям принятия для требуемого периода наблюдения.

Совет

Дополнительные сведения о подключении GitHub Actions к Azure с помощью OpenID Connect.