Развертывание и оценка модели машинного обучения с помощью сетевой конечной точки

  • Статья

ПРИМЕНИМО К:Расширение ml Azure CLI версии 2 (текущая версия)Пакет SDK для Python azure-ai-ml версии 2 (текущая версия)

Из этой статьи вы узнаете, как развернуть модель в сетевой конечной точке для использования при выводе в режиме реального времени. Сначала вы развернете модель на локальном компьютере для отладки ошибок. Затем вы развернете и протестируете модель в Azure. Вы также узнаете, как просматривать журналы развертывания и отслеживать соглашение об уровне обслуживания (SLA). К концу этой статьи у вас будет масштабируемая конечная точка HTTPS/REST, которую можно использовать для вывода в режиме реального времени.

Сетевые конечные точки — это конечные точки, которые используются для вывода в режиме реального времени. Существует два типа сетевых конечных точек: управляемые и Kubernetes. Дополнительные сведения о конечных точках и различиях между управляемыми и сетевыми конечными точками Kubernetes см. в статье Что такое конечные точки Машинного обучения Azure?.

Управляемые сетевые конечные точки помогают развертывать модели ML в комплексном режиме. Управляемые сетевые конечные точки работают с мощными машинами ЦП и GPU в Azure масштабируемым и полностью управляемым образом. Управляемые сетевые конечные точки отвечают за обслуживание, масштабирование, безопасность и мониторинг моделей, избавляя вас от накладных расходов на настройку и управление базовой инфраструктурой.

В основном примере в этом документе для развертывания используются управляемые сетевые конечные точки. Чтобы использовать Kubernetes, ознакомьтесь с заметками в этом документе, которые являются встроенными в обсуждении управляемой сетевой конечной точки.

Предварительные требования

ОБЛАСТЬ ПРИМЕНЕНИЯ:Расширение ML для Azure CLI версии 2 (текущая версия)

Перед выполнением действий, описанных в этой статье, убедитесь, что выполнены следующие необходимые условия:

  • Управление доступом на основе ролей Azure (Azure RBAC) используется для предоставления доступа к операциям в Машинном обучении Azure. Чтобы выполнить действия, описанные в этой статье, учетной записи пользователя должна быть назначена роль владельца или участника для рабочей области Машинного обучения Azure либо пользовательская роль с разрешением Microsoft.MachineLearningServices/workspaces/onlineEndpoints/*. Если вы используете студию для создания сетевых конечных точек и развертываний и управления ими, вам потребуется дополнительное разрешение "Microsoft.Resources/deployments/write" от владельца группы ресурсов. Дополнительные сведения см. в статье Управление доступом к рабочей области Машинного обучения Azure.

  • (Необязательно) Для локального развертывания необходимо установить подсистему Docker на локальном компьютере. Настоятельно рекомендуем использовать этот вариант, чтобы упростить отладку.

Выделение квоты виртуальной машины для развертывания

Для управляемых сетевых конечных точек Машинное обучение Azure резервирует 20 % вычислительных ресурсов для выполнения обновлений. Таким образом, если вы запрашиваете заданное количество экземпляров в развертывании, необходимо иметь доступную квоту, ceil(1.2 * number of instances requested for deployment) * number of cores for the VM SKU чтобы избежать возникновения ошибки. Например, если вы запрашиваете 10 экземпляров виртуальной машины Standard_DS3_v2 (которая поставляется с 4 ядрами) в развертывании, у вас должна быть квота на 48 ядер (12 instances * 4 cores). Сведения о просмотре сведений об использовании и увеличении квот запросов см. в разделе Просмотр использования и квот в портал Azure.

Подготовка системы

Настройка переменных среды

Если вы еще не задали параметры по умолчанию для Azure CLI, сохраните их. Чтобы не указывать параметры для подписки, рабочей области и группы ресурсов несколько раз, используйте следующий код:

az account set --subscription <subscription ID>
az configure --defaults workspace=<Azure Machine Learning workspace name> group=<resource group>

Клонирование репозитория примеров

Чтобы выполнить действия из этой статьи, сначала клонируйте репозиторий примеров (azureml-examples). Затем выполните следующий код, чтобы перейти в каталог репозитория cli/ :

git clone --depth 1 https://github.com/Azure/azureml-examples
cd azureml-examples
cd cli

Совет

При использовании параметра --depth 1 клонируется только последняя фиксация, что сокращает время выполнения операции.

Команды в этом руководстве находятся в файлах deploy-local-endpoint.sh и deploy-managed-online-endpoint.sh каталоге cli , а файлы конфигурации YAML находятся в подкаталоге endpoints/online/managed/sample/ .

Примечание

Файлы конфигурации YAML для сетевых конечных точек Kubernetes находятся в подкаталоге endpoints/online/kubernetes/ .

Определение конечной точки

Чтобы определить конечную точку, необходимо указать следующее:

  • Имя конечной точки: имя конечной точки. Оно должно быть уникальным в рамках региона Azure. Дополнительные сведения о правилах именования см. в разделе Ограничения управляемых сетевых конечных точек.
  • Режим проверки подлинности. Метод проверки подлинности для конечной точки. Выберите проверку подлинности на основе ключей или проверку подлинности на основе маркеров Машинного обучения Azure. Срок действия ключа не истекает, а срок действия маркера истекает. Дополнительные сведения о проверке подлинности см. в статье Проверка подлинности подключенной конечной точки.
  • При необходимости можно добавить описание и теги в конечную точку.

Установка имени конечной точки

Чтобы задать имя конечной точки, выполните следующую команду (замените YOUR_ENDPOINT_NAME уникальным именем).

Для Linux выполните следующую команду:

export ENDPOINT_NAME="<YOUR_ENDPOINT_NAME>"

Настройка конечной точки

В следующем фрагменте кода показан файл endpoints/online/managed/sample/endpoint.yml:

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineEndpoint.schema.json
name: my-endpoint
auth_mode: key

Справка по формату YAML конечной точки представлена в приведенной ниже таблице. Сведения о том, как указать эти атрибуты, см. в справочнике по YAML для сетевых конечных точек. Сведения об ограничениях, связанных с управляемыми конечными точками, см. в статье Управление квотами на ресурсы для Машинного обучения Azure и их увеличение.

Ключ Описание
$schema (Необязательно) Схема YAML. Чтобы просмотреть все доступные параметры в файле YAML, можно просмотреть схему в предыдущем фрагменте кода в браузере.
name Имя конечной точки.
auth_mode Используйте key для аутентификации на основе ключей. Используйте aml_token для проверки подлинности в службе "Машинное обучение Azure" на основе маркеров. Чтобы получить последний маркер, используйте az ml online-endpoint get-credentials команду .

Определение развертывания

Развертывание представляет собой набор ресурсов, необходимых для размещения модели, которая выполняет процесс вывода. Для развертывания модели необходимо следующее:

  • Файлы модели (или имя и версия модели, уже зарегистрированной в рабочей области). В нашем примере есть модель scikit-learn, выполняющая регрессию.
  • Скрипт оценки, то есть код, который выполняет модель в заданном входном запросе. Скрипт оценки получает данные, отправленные в развернутую веб-службу, и передает их модели. Затем скрипт выполняет модель и возвращает ответ клиенту. Скрипт оценки предназначен для вашей модели и должен понимать данные, которые модель ожидает в качестве входных данных и возвращает в качестве выходных данных. В этом примере у нас есть файл score.py .
  • Среда, в которой работает модель. Среда может быть образом Docker с зависимостями Conda или Dockerfile.
  • Параметры для типа экземпляра и возможностей масштабирования.

В следующей таблице описаны ключевые атрибуты развертывания.

attribute Описание
Имя Имя развертывания.
имя конечной точки; Имя конечной точки для создания развертывания.
Моделирование Модель, которая будет использоваться для развертывания. Это значение может быть ссылкой на существующую модель с управлением версиями в рабочей области или спецификацией встроенной модели.
Путь к коду Путь к каталогу в локальной среде разработки, который содержит весь исходный код Python для оценки модели. Вы можете использовать вложенные каталоги и пакеты.
Scoring script (Скрипт оценки) Относительный путь к файлу оценки в каталоге исходного кода. Этот код Python должен содержать функции init() и run(). Функция init() будет вызываться после создания или обновления модели (например, ее можно использовать для кэширования модели в памяти). Функция run() вызывается при каждом вызове конечной точки для фактического выполнения оценки и прогнозирования.
Среда Среда для размещения модели и кода. Это значение может быть ссылкой на существующую среду управления версиями в рабочей области или спецификацией встроенной среды.
Тип экземпляра Размер виртуальной машины, используемый для развертывания. Список поддерживаемых размеров см. в списке SKU управляемых сетевых конечных точек.
Число экземпляров Число экземпляров, которые будут использоваться для развертывания. Это значение должно быть основано на предполагаемой рабочей нагрузке. Для обеспечения высокой доступности рекомендуется задать значение не менее 3. Мы резервируем дополнительные 20 % для выполнения обновлений. Дополнительные сведения см. в разделе Квоты управляемых подключенных конечных точек.

Примечание

  • На модель и образ контейнера (как определено в разделе Среда) развертывание может ссылаться снова в любое время, когда экземпляры, стоящие за развертыванием, проходят через исправления безопасности и (или) другие операции восстановления. Если вы использовали зарегистрированную модель или образ контейнера в Реестр контейнеров Azure для развертывания и удалили модель или образ контейнера, развертывания, использующие эти ресурсы, могут завершиться ошибкой при повторном создании образа. Если вы удалили модель или образ контейнера, убедитесь, что зависимые развертывания повторно созданы или обновлены с помощью альтернативной модели или образа контейнера.
  • Реестр контейнеров, на который ссылается среда, может быть частным, только если удостоверение конечной точки имеет разрешение на доступ к нему с помощью проверки подлинности Azure Active Directory и Azure RBAC. По этой же причине частные реестры Docker, отличные от Реестр контейнеров Azure, не поддерживаются.

Настройка развертывания

В следующем фрагменте кода показан файл endpoints/online/managed/sample/blue-deployment.yml со всеми необходимыми входными данными для настройки развертывания:

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json
name: blue
endpoint_name: my-endpoint
model:
  path: ../../model-1/model/
code_configuration:
  code: ../../model-1/onlinescoring/
  scoring_script: score.py
environment: 
  conda_file: ../../model-1/environment/conda.yaml
  image: mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest
instance_type: Standard_DS3_v2
instance_count: 1

Примечание

В файле blue-deployment.yml мы указали следующие атрибуты развертывания:

  • model — В этом примере мы задаем встроенные свойства модели с помощью path. Файлы модели автоматически передаются и зарегистрируются с помощью автоматического формирования имени.
  • environment — В этом примере у нас есть встроенные определения, включающие path. Мы будем использовать environment.docker.image в качестве образа. Зависимости conda_file будут установлены поверх образа.

Во время развертывания локальные файлы, такие как источник Python для модели оценки, отправляются из среды разработки.

Дополнительные сведения о схеме YAML см. в справочнике по подключенной конечной точке YAML.

Примечание

Чтобы использовать Kubernetes вместо управляемых конечных точек в качестве целевого объекта:

  1. Создайте и присоедините кластер Kubernetes в качестве целевого объекта вычислений к рабочей области Машинного обучения Azure с помощью студии машинного обучения Azure.
  2. Используйте эту конечную точку YAML для выбора целевого объекта Kubernetes вместо кода YAML управляемой конечной точки. Вам потребуется отредактировать код YAML и изменить значение target на имя зарегистрированного целевого объекта вычислений. Вы можете использовать этот файл deployment.yaml с дополнительными свойствами, применимыми к развертыванию Kubernetes.

Все команды, используемые в этой статье (кроме необязательной интеграции мониторинга SLA и Azure Log Analytics), можно использовать либо с управляемыми конечными точками, либо с конечными точками Kubernetes.

Отдельная регистрация модели и среды

В этом примере мы указываем path (откуда загружать файлы) встроенным. CLI автоматически отправляет файлы и регистрирует модель и среду. Для рабочей среды рекомендуется отдельно зарегистрировать модель и среду, а также указать зарегистрированное имя и версию в YAML. Используйте формат model: azureml:my-model:1 или environment: azureml:my-env:1.

Для регистрации вы можете извлечь определения YAML model и environment в отдельные файлы YAML и использовать команды az ml model create и az ml environment create. Чтобы узнать больше об этих командах, выполните команду az ml model create -h и az ml environment create -h.

Дополнительные сведения о регистрации модели в качестве ресурса см. в статье Регистрация модели в качестве ресурса в Машинном обучении с помощью интерфейса командной строки. Дополнительные сведения о создании среды см. в статье Управление средами Машинного обучения Azure с помощью пакета SDK для CLI & (версия 2).

Использование различных типов и образов экземпляров ЦП и GPU

Предыдущее определение в файле blue-deployment.yml использует экземпляр типа Standard_DS3_v2 общего назначения и образ mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latestDocker, отличный от GPU. Для вычислений GPU выберите SKU типа вычислений GPU и образ Docker GPU.

Поддерживаемые типы экземпляров общего назначения и GPU перечислены в статье о номерах SKU поддерживаемых виртуальных машин для управляемых сетевых конечных точек. Список базовых образов ЦП и GPU для Машинного обучения Azure см. на странице базовых образов Машинного обучения Azure.

Примечание

Сведения об использовании Kubernetes вместо управляемых конечных точек в качестве целевого объекта вычислений см. в статье Общие сведения о целевом объекте вычислений Kubernetes.

Использование нескольких моделей в развертывании

В настоящее время можно указать только одну модель для каждого развертывания в определении развертывания при использовании Azure CLI, пакета SDK для Python или любого другого клиентского средства.

Чтобы использовать несколько моделей в развертывании, зарегистрируйте папку модели, содержащую все модели в виде файлов или подкаталогов. В скрипте оценки используйте переменную среды AZUREML_MODEL_DIR, чтобы получить путь к корневой папке модели. Базовая структура каталогов будет сохранена. Пример развертывания нескольких моделей в одном развертывании см. в разделах Развертывание нескольких моделей в одном развертывании (пример CLI) и Развертывание нескольких моделей в одном развертывании (пример пакета SDK).

Совет

Если требуется зарегистрировать более 1500 файлов, при регистрации модели можно сжать файлы или подкаталоги как TAR.GZ. Для использования моделей можно распаковать файлы или подкаталоги в функции init() из скрипта оценки. Кроме того, при регистрации модели присвойте свойству azureml.unpack значение True, что позволит автоматически распаковку. В любом случае распаковка происходит один раз на этапе инициализации.

Общие сведения о скрипте оценки

Совет

Для сетевых конечных точек используется тот же формат скрипта оценки, что и в более ранних версиях CLI и в пакете SDK для Python.

Как отмечалось ранее, скрипт оценки, указанный в , code_configuration.scoring_script должен иметь функцию init() и функцию run() .

В этом примере используется файл score.py: score.py

import os
import logging
import json
import numpy
import joblib


def init():
    """
    This function is called when the container is initialized/started, typically after create/update of the deployment.
    You can write the logic here to perform init operations like caching the model in memory
    """
    global model
    # AZUREML_MODEL_DIR is an environment variable created during deployment.
    # It is the path to the model folder (./azureml-models/$MODEL_NAME/$VERSION)
    # Please provide your model's folder name if there is one
    model_path = os.path.join(
        os.getenv("AZUREML_MODEL_DIR"), "model/sklearn_regression_model.pkl"
    )
    # deserialize the model file back into a sklearn model
    model = joblib.load(model_path)
    logging.info("Init complete")


def run(raw_data):
    """
    This function is called for every invocation of the endpoint to perform the actual scoring/prediction.
    In the example we extract the data from the json input and call the scikit-learn model's predict()
    method and return the result back
    """
    logging.info("model 1: request received")
    data = json.loads(raw_data)["data"]
    data = numpy.array(data)
    result = model.predict(data)
    logging.info("Request processed")
    return result.tolist()

Функция init() вызывается при инициализации или запуске контейнера. Инициализация обычно происходит вскоре после создания или обновления развертывания. Функция init служит местом для записи логики для глобальных операций инициализации, таких как кэширование модели в памяти (как в этом примере).

Функция run() вызывается для каждого вызова конечной точки и выполняет фактическую оценку и прогнозирование. В этом примере мы извлекаем данные из входных данных JSON, вызываем метод модели predict() scikit-learn, а затем возвращаем результат.

Развертывание и отладка в локальной среде с помощью локальных конечных точек

Мы настоятельно рекомендуем протестировать конечную точку локально, проверив и отладив код и конфигурацию перед развертыванием в Azure. Azure CLI и пакет SDK для Python поддерживают локальные конечные точки и развертывания, а Студия машинного обучения Azure и шаблон ARM — нет.

Для локального развертывания необходимо установить и запустить подсистему Docker . Как правило, подсистема Docker запускается при включении компьютера. В противном случае вы можете устранить неполадки подсистемы Docker.

Совет

Вы можете использовать пакет Python http-сервера для вывода Машинного обучения Azure для локальной отладки скрипта оценки без подсистемы Docker. Отладка с помощью сервера вывода позволяет выполнить отладку скрипта оценки перед развертыванием в локальных конечных точках, чтобы можно было выполнить отладку, не затрагивая конфигурации контейнера развертывания.

Локальные конечные точки имеют следующие ограничения.

  • Они не поддерживают правила трафика, проверку подлинности или параметры пробы.
  • Они поддерживают только одно развертывание на конечную точку.
  • Они поддерживают только локальные файлы модели. Если вы хотите протестировать зарегистрированные модели, сначала скачайте их с помощью интерфейса командной строки или пакета SDK, а затем используйте path в определении развертывания ссылку на родительскую папку.

Дополнительные сведения об локальной отладке сетевых конечных точек перед развертыванием в Azure см. в статье Локальная отладка сетевых конечных точек в Visual Studio Code.

Локальное развертывание модели

Сначала создайте конечную точку. При необходимости для локальной конечной точки можно пропустить этот шаг и непосредственно создать развертывание (следующий шаг), которое, в свою очередь, создаст необходимые метаданные. Локальное развертывание моделей полезно для разработки и тестирования.

az ml online-endpoint create --local -n $ENDPOINT_NAME -f endpoints/online/managed/sample/endpoint.yml

Теперь создайте развертывание с именем blue в конечной точке.

az ml online-deployment create --local -n blue --endpoint $ENDPOINT_NAME -f endpoints/online/managed/sample/blue-deployment.yml

Флаг --local инструктирует CLI развернуть конечную точку в среде Docker.

Совет

Используйте Visual Studio Code для локального тестирования и отладки конечных точек. Дополнительные сведения см. в разделе Локальная отладка сетевых конечных точек в Visual Studio Code.

Проверка успешности локального развертывания

Проверьте статус, чтобы узнать, удалось ли развернуть модель без ошибок:

az ml online-endpoint show -n $ENDPOINT_NAME --local

Результат должен выглядеть аналогично следующему JSON. provisioning_state является Succeeded.

{
  "auth_mode": "key",
  "location": "local",
  "name": "docs-endpoint",
  "properties": {},
  "provisioning_state": "Succeeded",
  "scoring_uri": "http://localhost:49158/score",
  "tags": {},
  "traffic": {}
}

В следующей таблице приведены возможные значения для provisioning_state:

Состояние Описание
Создание Ресурс создается.
Обновление Ресурс обновляется.
Удаление Ресурс удаляется.
Успешно Операция создания или обновления выполнена успешно.
Сбой Не удалось выполнить операцию создания, обновления или удаления.

Вызов локальной конечной точки для оценки данных с помощью модели

Вызовите конечную точку для оценки модели с помощью команды invoke, передав ей параметры запроса, хранящиеся в JSON-файле:

az ml online-endpoint invoke --local --name $ENDPOINT_NAME --request-file endpoints/online/model-1/sample-request.json

Если вы хотите использовать клиент REST (например, curl), вам потребуется URI оценки. Чтобы получить URI оценки, используйте команду az ml online-endpoint show --local -n $ENDPOINT_NAME. Найдите атрибут scoring_uri в возвращенных данных. Примерные команды на основе cURL доступны далее в этом документе.

Проверка журналов на наличие выходных данных операции вызова

В примере файла score.py метод run() выводит некоторые выходные данные в консоли.

Эти выходные данные можно просмотреть с помощью get-logs команды :

az ml online-deployment get-logs --local -n blue --endpoint $ENDPOINT_NAME

Развертывание сетевой конечной точки в Azure

Теперь следует развернуть сетевую конечную точку в Azure.

Развернуть в Azure

Чтобы создать конечную точку в облаке, выполните следующий код:

az ml online-endpoint create --name $ENDPOINT_NAME -f endpoints/online/managed/sample/endpoint.yml

Чтобы создать развертывание с именем blue в конечной точке, выполните следующий код:

az ml online-deployment create --name blue --endpoint $ENDPOINT_NAME -f endpoints/online/managed/sample/blue-deployment.yml --all-traffic

Развертывание может занять до 15 минут в зависимости от того, впервые ли выполняется сборка базовой среды или образа. В дальнейшем развертывание с использованием той же среды будет выполняться быстрее.

Совет

  • Если вы не хотите блокировать консоль CLI, добавьте к команде флаг --no-wait. Однако так вы не сможете отслеживать состояние развертывания в интерактивном режиме.

Важно!

Флаг --all-traffic в приведенном выше az ml online-deployment create разделе выделяет 100 % трафика конечной точки только что созданному синему развертыванию. Хотя это полезно для целей разработки и тестирования, для рабочей среды может потребоваться открыть трафик в новое развертывание с помощью явной команды. Например, az ml online-endpoint update -n $ENDPOINT_NAME --traffic "blue=100".

Совет

Проверка состояния конечной точки

Команда show содержит сведения о provisioning_state конечной точке и развертывании:

az ml online-endpoint show -n $ENDPOINT_NAME

Вы можете вывести список всех конечных точек рабочей области в табличном формате с помощью команды list:

az ml online-endpoint list --output table

Проверка состояния развертывания в сети

Проверьте журналы, чтобы узнать, была ли модель развернута без ошибок.

Чтобы просмотреть выходные данные журнала из контейнера, используйте следующую команду CLI:

az ml online-deployment get-logs --name blue --endpoint $ENDPOINT_NAME

По умолчанию журналы извлекаются из контейнера сервера вывода. Чтобы просмотреть журналы из контейнера инициализатора хранилища, добавьте --container storage-initializer флаг . Дополнительные сведения о журналах развертывания см. в разделе Получение журналов контейнеров.

Вызов конечной точки для оценки данных с помощью модели

Для вызова конечной точки и оценки данных можно использовать либо команду invoke, либо клиент REST.

az ml online-endpoint invoke --name $ENDPOINT_NAME --request-file endpoints/online/model-1/sample-request.json

В следующем примере показано, как получить ключ, используемый для проверки подлинности в конечной точке.

Совет

Вы можете управлять тем, какие субъекты безопасности Azure Active Directory могут получить ключ проверки подлинности, назначив их пользовательской роли, которая разрешает Microsoft.MachineLearningServices/workspaces/onlineEndpoints/token/action иMicrosoft.MachineLearningServices/workspaces/onlineEndpoints/listkeys/action. Дополнительные сведения см. в статье Управление доступом к рабочей области Машинного обучения Azure.

ENDPOINT_KEY=$(az ml online-endpoint get-credentials -n $ENDPOINT_NAME -o tsv --query primaryKey)

Затем используйте cURL для оценки данных.

SCORING_URI=$(az ml online-endpoint show -n $ENDPOINT_NAME -o tsv --query scoring_uri)

curl --request POST "$SCORING_URI" --header "Authorization: Bearer $ENDPOINT_KEY" --header 'Content-Type: application/json' --data @endpoints/online/model-1/sample-request.json

Обратите внимание, что мы используем команды show и get-credentials для получения учетных данных для проверки подлинности. Мы используем флаг --query, чтобы отфильтровать только необходимые атрибуты. Дополнительные сведения о флаге --query см. в статье о выходных данных команды Query в Azure CLI.

Чтобы просмотреть журналы вызовов, снова введите команду get-logs.

Сведения о проверке подлинности с помощью токенов см. в разделе Проверка подлинности в подключенных конечных точках.

(Необязательно) Обновление развертывания

Если вы хотите обновить код, модель, среду или параметры масштабирования, обновите файл YAML и введите команду az ml online-endpoint update.

Примечание

При обновлении числа экземпляров (для масштабирования развертывания) вместе с другими параметрами модели (например, кодом, моделью или средой) в одной update команде сначала будет выполнена операция масштабирования, а затем будут применены другие обновления. Рекомендуется выполнять эти операции отдельно в рабочей среде.

Чтобы понять, как работает команда update:

  1. Откройте файл online/model-1/onlinescoring/score.py.

  2. Измените последнюю строку функции init(): после logging.info("Init complete") добавьте logging.info("Updated successfully").

  3. Сохраните файл.

  4. Выполните следующую команду:

    az ml online-deployment update -n blue --endpoint $ENDPOINT_NAME -f endpoints/online/managed/sample/blue-deployment.yml

    Примечание

    Обновление с помощью YAML является декларативным. Это означает, что изменения в YAML отражаются в базовых ресурсах Azure Resource Manager (конечных точках и развертываниях). В декларативном подходе используется GitOps: все изменения конечных точек и развертываний (даже instance_count) проходят через YAML.

    Совет

    • Можно использовать универсальные параметры обновления, такие как --set параметр , с помощью команды CLI update , чтобы переопределить атрибуты в YAML или задать определенные атрибуты, не передавая их в файл YAML. Использовать --set для отдельных атрибутов особенно удобно в сценариях разработки и тестирования. Например, с помощью флага --set instance_count=2 можно увеличить значение instance_count первого развертывания. Однако поскольку YAML не обновляется, этот метод не упрощает процесс GitOps.
    • Указание файла YAML НЕ является обязательным. Например, если вы хотите протестировать разные параметры параллелизма для конкретного развертывания, можно попробовать что-то вроде az ml online-deployment update -n blue -e my-endpoint --set request_settings.max_concurrent_requests_per_instance=4 environment_variables.WORKER_COUNT=4. При этом будут сохраняться все существующие конфигурации, но будут обновлены только указанные параметры.

  5. Так как вы изменили функцию init() , которая выполняется при создании или обновлении конечной точки, сообщение Updated successfully будет отображаться в журналах. Чтобы получить журналы, выполните следующую команду:

    az ml online-deployment get-logs --name blue --endpoint $ENDPOINT_NAME

Команда update также работает с локальными конечными точками. Используйте такую же команду az ml online-deployment update с флагом --local.

Примечание

Предыдущее обновление развертывания является примером последовательного обновления на месте.

  • Для управляемой сетевой конечной точки развертывание обновляется до новой конфигурации с 20 % узлов за раз. То есть, если развертывание содержит 10 узлов, то одновременно будут обновляться по 2 узла.
  • Для сетевой конечной точки Kubernetes система итеративно создаст новый экземпляр развертывания с новой конфигурацией и удалит старый.
  • Для использования в рабочей среде следует рассмотреть сине-зеленое развертывание, которое предлагает более безопасную альтернативу обновлению веб-службы.

(Дополнительно) Настройка автомасштабирования

Благодаря автомасштабированию автоматически запускается именно тот объем ресурсов, который нужен для обработки нагрузки в вашем приложении. Управляемые сетевые конечные точки поддерживают автоматическое масштабирование через интеграцию с функцией автомасштабирования Azure Monitor. Сведения о настройке автомасштабирования см. в разделе Автомасштабирование сетевых конечных точек.

(Необязательно) Мониторинг соглашения об уровне обслуживания с помощью Azure Monitor

Чтобы просмотреть метрики и настроить оповещения на основе соглашения об уровне обслуживания, выполните действия, описанные в статье Мониторинг сетевых конечных точек.

(Необязательно) Интеграция с Log Analytics

Команда get-logs для CLI или get_logs метод для пакета SDK предоставляет только последние несколько сотен строк журналов из автоматически выбранного экземпляра. Однако Log Analytics позволяет надежно хранить и анализировать журналы. Дополнительные сведения об использовании ведения журнала см. в статье Мониторинг сетевых конечных точек.

Удаление конечной точки и развертывания

Если вы не планируете использовать развертывание, удалите его с помощью следующего кода (он удаляет конечную точку и все базовые развертывания):

az ml online-endpoint delete --name $ENDPOINT_NAME --yes --no-wait

Дальнейшие действия