Résolution des problèmes de déploiement et de scoring de points de terminaison en ligne

S’APPLIQUE À :Extension Azure ML CLI v2 (actuelle)Kit de développement logiciel (SDK) Python azure-ai-ml v2 (préversion)

Découvrez comment résoudre les problèmes courants de déploiement et de scoring de points de terminaison en ligne Azure Machine Learning.

La structure de ce document est axée sur l’approche à adopter pour la résolution des problèmes :

  1. Utilisez un déploiement local pour tester et déboguer vos modèles localement avant le déploiement dans le cloud.
  2. Utilisez des journaux de conteneur pour déboguer les problèmes plus facilement.
  3. Appréhendez les erreurs de déploiement courantes et la façon de les résoudre.

La section Codes d’état HTTP explique comment les erreurs d’appel et de prédiction sont mappées aux codes d’état HTTP quand le scoring des points de terminaison est effectué avec des requêtes REST.

Prérequis

Déploiement local

Le déploiement local consiste à déployer un modèle dans un environnement Docker local. Le déploiement local est utile pour le test et le débogage avant le déploiement dans le cloud.

Conseil

Vous pouvez aussi utiliser le package Python du serveur HTTP d’inférence Azure Machine Learning pour déboguer votre script de scoring localement. Le débogage avec le serveur d’inférence vous aide à déboguer le script de scoring avant le déploiement sur des points de terminaison locaux afin de pouvoir déboguer sans être affecté par les configurations de conteneur de déploiement.

Le déploiement local prend en charge la création, la mise à jour et la suppression d’un point de terminaison local. Il vous permet également d’appeler et d’obtenir des journaux à partir du point de terminaison.

Pour utiliser le déploiement local, ajoutez --local à la commande CLI appropriée :

az ml online-deployment create --endpoint-name <endpoint-name> -n <deployment-name> -f <spec_file.yaml> --local

Le déploiement local inclut les étapes suivantes :

  • Docker génère une nouvelle image conteneur ou tire (pull) une image existante du cache Docker local. Si une image existante correspond à la partie environnement du fichier de spécification, elle est utilisée.
  • Docker démarre un nouveau conteneur avec les artefacts locaux montés tels que les fichiers de code et de modèle.

Pour plus d’informations, consultez Déployer localement dans Déployer et scorer un modèle Machine Learning.

Conseil

Utilisez Visual Studio Code pour tester et déboguer vos points de terminaison localement. Pour plus d’informations, consultez Déboguer les points de terminaison en ligne localement dans Visual Studio Code.

Installation de conda

En règle générale, les problèmes liés au déploiement MLflow résultent de problèmes liés à l’installation de l’environnement utilisateur spécifié dans le fichier conda.yaml.

Pour déboguer des problèmes d’installation de conda, essayez les étapes suivantes :

  1. Vérifiez les journaux d’activité pour l’installation de conda. Si le conteneur s’est bloqué ou prend trop de temps à démarrer, il est probable que la mise à jour de l’environnement conda n’a pas été résolue correctement.

  2. Installez le fichier mlflow conda localement avec la commande conda env create -n userenv -f <CONDA_ENV_FILENAME>.

  3. En cas d’erreurs localement, essayez de résoudre l’environnement conda et de créer un environnement fonctionnel avant de le redéployer.

  4. Si le conteneur se bloque même s’il se résout localement, la taille de la référence SKU utilisée pour le déploiement peut être trop petite.

    1. L’installation du package Conda se produit au moment du runtime. Par conséquent, si la taille de la référence SKU est trop petite pour prendre en charge tous les packages détaillés dans le fichier d’environnement conda.yaml, le conteneur peut se bloquer.
    2. Une machine virtuelle Standard_F4s_v2 est une bonne taille de référence SKU de départ, mais des tailles supérieures peuvent être nécessaires en fonction des dépendances spécifiées dans le fichier Conda.
    3. Pour le point de terminaison en ligne Kubernetes, le cluster Kubernetes doit disposer d’au moins 4 cœurs de processeur virtuel et 8 Go de mémoire.

Obtenir les journaux de conteneur

Vous ne pouvez pas accéder directement à la machine virtuelle sur laquelle le modèle est déployé. Toutefois, vous pouvez obtenir les journaux de certains des conteneurs qui s’exécutent sur la machine virtuelle. La quantité d’informations que vous obtenez dépend de l’état de provisionnement du déploiement. Si le conteneur spécifié est opérationnel, vous voyez la sortie de sa console ; sinon, vous obtenez un message vous invitant à réessayer plus tard.

Il existe deux types de conteneurs à partir lesquels vous pouvez obtenir les journaux :

  • Serveur d’inférence : Les journaux incluent le journal de console (à partir du serveur d’inférence) qui contient la sortie des fonctions d’affichage/de journalisation de votre script de scoring (code score.py).
  • Initialiseur de stockage : Les journaux contiennent des informations indiquant si le code et les données de modèle ont été correctement téléchargés dans le conteneur. Le conteneur s’exécute avant que le conteneur du serveur d’inférence ne commence à s’exécuter.

Pour voir la sortie de journal d’un conteneur, utilisez la commande CLI suivante :

az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100

ou

az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> --lines 100

Ajoutez --resource-group et --workspace-name à ces commandes si vous n’avez pas déjà défini ces paramètres avec az configure.

Pour afficher des informations sur la définition de ces paramètres et, si vous avez actuellement défini des valeurs, exécutez :

az ml online-deployment get-logs -h

Par défaut, les journaux sont tirés du serveur d’inférence.

Notes

Si vous utilisez la journalisation Python, veillez à utiliser l’ordre de niveau de journalisation approprié pour les messages à publier dans les journaux. Par exemple, INFO.

Vous pouvez également obtenir des journaux à partir du conteneur de l’initialiseur de stockage en passant –-container storage-initializer.

Ajoutez --help et/ou --debug aux commandes pour voir plus d’informations.

Pour le point de terminaison en ligne Kubernetes, les administrateurs peuvent accéder directement au cluster où vous avez déployé le modèle, ce qui leur permet de consulter plus facilement le journal dans Kubernetes. Par exemple :

kubectl -n <compute-namespace> logs <container-name>

Suivi des requêtes

Il existe deux en-têtes de suivi pris en charge :

  • x-request-id est réservé au suivi du serveur. Nous remplaçons cet en-tête pour garantir qu’il s’agit d’un GUID valide.

    Notes

    Lorsque vous créez un ticket de support pour une demande ayant échoué, attachez l’ID de la demande ayant échoué pour accélérer l’enquête.

  • x-ms-client-request-id est disponible pour les scénarios de suivi client. Cet en-tête est nettoyé pour accepter uniquement les caractères alphanumériques, les traits d’union et les traits de soulignement, et est tronqué à un maximum de 40 caractères.

Erreurs de déploiement courantes

La liste suivante comporte des erreurs de déploiement courantes signalées, liées à l’état de l’opération de déploiement :

Si vous créez ou que vous mettez à jour un déploiement Kubernetes en ligne, vous pouvez consulter Erreurs courantes spécifiques aux déploiements Kubernetes.

ERREUR : ImageBuildFailure

Cette erreur est retournée lorsque l’environnement (image docker) est généré. Vous pouvez vérifier le journal de génération pour plus d’informations sur la ou les défaillances. Le journal de génération se trouve dans le stockage par défaut de votre espace de travail Azure Machine Learning. L’emplacement exact peut être renvoyé dans le cadre de l’erreur. Par exemple : "the build log under the storage account '[storage-account-name]' in the container '[container-name]' at the path '[path-to-the-log]'".

La liste suivante contient des scénarios courants d’échec de génération d’images :

Nous vous recommandons également d’examiner les paramètres de sonde d’intégrité par défaut en cas d’expiration du délai d’attente d’ImageBuild.

Échec d’autorisation du registre de conteneurs

Si le message d’erreur mentionne "container registry authorization failure", cela signifie que vous ne pouvez pas accéder au registre de conteneurs avec les informations d’identification actuelles. La désynchronisation des clés d’une ressource d’espace de travail peut provoquer cette erreur, et un certain temps est nécessaire pour la synchronisation automatique. Cependant, vous pouvez appeler manuellement une synchronisation de clés, qui peut résoudre l’échec d’autorisation.

Les registres de conteneurs qui se trouvent derrière un réseau virtuel peuvent également rencontrer cette erreur s’ils sont configurés de manière incorrecte. Vous devez vérifier que le réseau virtuel est configuré correctement.

Calcul de génération d’image non défini dans un espace de travail privé avec un VNet

Si le message d’erreur mentionne "failed to communicate with the workspace's container registry", que vous utilisez des réseaux virtuels, et que le registre de conteneurs Azure de l’espace de travail est privé et configuré avec un point de terminaison privé, vous devez activer Azure Container Registry pour autoriser la génération d’images dans le réseau virtuel.

Échec de génération d’une image générique

Comme indiqué précédemment, vous pouvez vérifier le journal de génération pour plus d’informations sur la défaillance. Si aucune erreur évidente n’est trouvée dans le journal de génération et que la dernière ligne est Installing pip dependencies: ...working..., c’est qu’une dépendance peut provoquer l’erreur. L’épinglage des dépendances de version dans votre fichier conda peut résoudre ce problème.

Nous recommandons aussi de déployer localement pour tester et déboguer vos modèles localement avant de déployer dans le cloud.

ERREUR : OutOfQuota

La liste suivante recense des ressources courantes qui pourraient dépasser les quotas lors de l’utilisation des services Azure :

De plus, vous trouverez dans la liste suivante des ressources courantes qui peuvent dépasser les quotas uniquement pour le point de terminaison en ligne Kubernetes :

Quota de processeur

Avant de déployer un modèle, vous devez disposer d’un quota de calcul suffisant. Ce quota définit le nombre de vCores disponibles par abonnement, par espace de travail, par référence SKU et par région. Chaque déploiement puise dans le quota disponible (qu’il rétablit après la suppression) en fonction du type de référence SKU.

Pour atténuer le risque de quota insuffisant, vous pouvez vérifier s’il existe des déploiements inutilisés que vous pouvez supprimer. Vous pouvez également envoyer une demande d’augmentation du quota.

Quota de cluster

Ce problème survient lorsque le quota de cluster de capacité de calcul Azure Machine Learning est insuffisant. Ce quota définit le nombre total de clusters qui peuvent être utilisés à la fois par abonnement pour déployer des nœuds d’UC ou de GPU dans Azure Cloud.

Pour atténuer le risque de quota insuffisant, vous pouvez vérifier s’il existe des déploiements inutilisés que vous pouvez supprimer. Vous pouvez également envoyer une demande d’augmentation du quota. Veillez à sélectionner Machine Learning Service: Cluster Quota comme type de quota pour cette demande d’augmentation de quota.

Quota de disque

Ce problème se produit lorsque la taille du modèle est supérieure à l’espace disque disponible, et que le modèle ne peut pas être téléchargé. Essayez une référence SKU dotée de plus de d’espace disque ou en réduisant la taille de l’image et du modèle.

Quota de mémoire

Ce problème se produit lorsque l’encombrement mémoire du modèle est supérieur à la mémoire disponible. Essayez une référence SKU dotée de plus de mémoire.

Quota d’attribution de rôle

Quand vous créez un point de terminaison en ligne managé, l’attribution de rôles est nécessaire pour que l’identité managée puisse accéder aux ressources de l’espace de travail. Si la limite d’attribution de rôle est atteinte, essayez de supprimer certaines attributions de rôle inutilisées dans cet abonnement. Vous pouvez vérifier toutes les attributions de rôles dans le portail Azure en accédant au menu Contrôle d’accès.

Quota de point de terminaison

Essayez de supprimer les points de terminaison non utilisés dans cet abonnement. Si tous vos points de terminaison sont activement utilisés, vous pouvez essayer de demander une augmentation de la limite de points de terminaison. Pour en savoir plus sur la limite de point de terminaison, consultez quota de points de terminaison avec des points de terminaison en ligne Azure Machine Learning et des points de terminaison de lots.

Quota Kubernetes

Ce problème se produit lorsque le processeur ou la mémoire requis n’est pas en mesure d’être fourni(e) en raison de nœuds non planifiables pour ce déploiement. Par exemple, les nœuds peuvent être bloqués ou indisponibles.

Le message d’erreur indique généralement la ressource insuffisante dans le cluster, par exemple OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods..., ce qui signifie qu’il y a trop de pods dans le cluster et pas assez de ressources pour déployer le nouveau modèle en fonction de votre requête.

Vous pouvez essayer les mesures d'atténuation des risques suivantes pour résoudre ce problème :

  • Pour les opérateurs informatiques qui gèrent le cluster Kubernetes, vous pouvez essayer d’ajouter d’autres nœuds ou d’effacer certains pods inutilisés dans le cluster pour libérer des ressources.
  • Pour les ingénieurs en apprentissage automatique qui déploient des modèles, vous pouvez essayer de réduire la demande de ressources de votre déploiement :
    • Si vous définissez directement la demande de ressources dans la configuration du déploiement via la section des ressources, vous pouvez essayer de réduire la demande de ressources.
    • Si vous utilisez instance type pour définir la ressource pour le modèle de déploiement, vous pouvez contacter les opérateurs informatiques pour ajuster la configuration des ressources de type instance. Pour plus d’informations, consultez l’article Comment gérer les types d’instances Kubernetes.

Capacité des machines virtuelles à l’échelle de la région

En raison d’un manque de capacité Azure Machine Learning dans la région, le service n’a pas pu provisionner la taille de machine virtuelle spécifiée. Réessayez ultérieurement ou essayez d’effectuer le déploiement dans une autre région.

Autre quota

Pour exécuter le code score.py fourni dans le cadre du déploiement, Azure crée un conteneur qui comprend toutes les ressources qui lui sont nécessaires, puis exécute le script de scoring sur ce conteneur.

Si votre conteneur n’a pas pu démarrer, cela signifie que le scoring n’a pas pu se produire. Cela peut être dû au fait que le conteneur demande une quantité de ressources supérieure à celle prise en charge par instance_type. Si c’est le cas, envisagez de mettre à jour le instance_type du déploiement en ligne.

Pour obtenir la raison exacte d’une erreur, exécutez :

az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100

ERREUR : BadArgument

Vous trouverez ci-après une liste des raisons pour lesquelles vous pouvez rencontrer cette erreur quand vous utilisez un point de terminaison en ligne managé ou un point de terminaison en ligne Kubernetes :

De plus, vous trouverez ci-après une liste des raisons pour lesquelles vous pouvez rencontrer cette erreur seulement quand vous utilisez un point de terminaison en ligne Kubernetes :

L'abonnement n'existe pas

L’abonnement Azure entré doit être existant. Cette erreur se produit lorsque nous ne trouvons pas l’abonnement Azure référencé. Cette erreur est probablement due à une faute de frappe dans l’ID d’abonnement. Re-vérifiez que l’ID d’abonnement a été correctement tapé et qu’il est actuellement actif.

Pour plus d’informations sur les abonnements Azure, consultez la section Prérequis.

Erreur d’autorisation

Une fois que vous avez provisionné la ressource de calcul (lors de la création d’un déploiement), Azure tente d’extraire l’image conteneur utilisateur à partir de l’espace de travail Azure Container Registry (ACR). Il tente de monter le modèle utilisateur et les artefacts de code dans le conteneur utilisateur à partir du compte de stockage de l’espace de travail.

Pour effectuer ces actions, Azure utilise des identités managées pour accéder au compte de stockage et au registre de conteneurs.

  • Si vous avez créé le point de terminaison associé à une identité affectée par le système, l’autorisation du contrôle d’accès en fonction du rôle (RBAC) Azure est accordée automatiquement et aucune autre autorisation n’est nécessaire.

  • Si vous avez créé le point de terminaison associé à l’identité affectée par l’utilisateur, l’identité affectée par l’utilisateur doit disposer de l’autorisation lecteur de données blob de stockage sur le compte de stockage de l’espace de travail et de l’autorisation AcrPull du registre ACR (Azure Container Registry) de l’espace de travail. Vérifiez que votre identité affectée par l’utilisateur dispose de l’autorisation appropriée.

Pour plus d’informations, consultez Erreur d’autorisation de Container Registry.

Spécification de la fonction de modèle non valide

Cette erreur se produit lorsqu’une fonction de modèle a été spécifiée de manière incorrecte. Corrigez la stratégie ou supprimez l’affectation de stratégie pour débloquer. Le message d’erreur peut inclure le nom de l’affectation de stratégie et la définition de stratégie pour vous faciliter le débogage de ladite erreur, ainsi que l’article sur la structure de définition de la stratégie Azure qui donne des conseils pour éviter les échecs du modèle.

Impossible de télécharger l’image conteneur utilisateur

Il est possible que le conteneur utilisateur soit introuvable. Vérifiez les journaux des conteneurs pour obtenir plus de détails.

Vérifiez que l’image conteneur est disponible dans le registre ACR de l’espace de travail.

Par exemple, si l’image est testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest, vérifiez le dépôt avec az acr repository show-tags -n testacr --repository azureml/azureml_92a029f831ce58d2ed011c3c42d35acb --orderby time_desc --output table.

Impossible de télécharger le modèle utilisateur

Il est possible que le modèle de l’utilisateur soit introuvable. Vérifiez les journaux des conteneurs pour obtenir plus de détails.

Vérifiez que vous avez inscrit le modèle auprès du même espace de travail que le déploiement. Pour montrer les détails d’un modèle dans un espace de travail :

az ml model show --name <model-name> --version <version>

Avertissement

Vous devez spécifier la version ou l’intitulé pour obtenir les informations du modèle.

Vous pouvez également vérifier si les blobs sont présents dans le compte de stockage de l’espace de travail.

  • Par exemple, si l’objet blob est https://foobar.blob.core.windows.net/210212154504-1517266419/WebUpload/210212154504-1517266419/GaussianNB.pkl, vous pouvez utiliser cette commande pour vérifier s’il existe :

    az storage blob exists --account-name foobar --container-name 210212154504-1517266419 --name WebUpload/210212154504-1517266419/GaussianNB.pkl --subscription <sub-name>`
    
  • Si l’objet blob est présent, vous pouvez utiliser cette commande pour obtenir les journaux à partir de l’initialiseur de stockage :

    az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> –-container storage-initializer`
    

Le format du modèle MLFlow avec un réseau privé n’est pas pris en charge

Cette erreur se produit lorsque vous essayez de déployer un modèle MLflow avec une approche de déploiement sans code conjointement avec la méthode d’isolation réseau héritée pour les points de terminaison en ligne managés. Cette fonctionnalité de réseau privé ne peut pas être utilisée conjointement avec un format de modèle MLFlow si vous utilisez la méthode d’isolement réseau héritée. Si vous devez déployer un modèle MLflow avec l’approche de déploiement sans code, essayez d’utiliser un réseauvirtuel managé par l’espace de travail.

Demandes de ressource supérieures aux limites

Les demandes de ressources doivent être inférieures ou égales aux limites. Si vous ne définissez pas de limites, nous définissons les valeurs par défaut lorsque vous associez votre calcul à un espace de travail Azure Machine Learning. Vous pouvez vérifier les limites dans le portail Azure ou à l’aide de la commande az ml compute show.

azureml-fe non prêt

Le composant frontal (azureml-fe) qui achemine les demandes d’inférence entrantes vers les services déployés se met à l’échelle automatiquement selon les besoins. Il est installé pendant votre installation de k8s-extension.

Ce composant doit être sain sur le cluster, au moins un réplica sain. Vous obtenez ce message d’erreur s’il n’est pas disponible lorsque vous déclenchez un point de terminaison en ligne Kubernetes et une requête de création/mise à jour du déploiement.

Vérifiez l’état et les journaux des pods pour résoudre ce problème, vous pouvez également essayer de mettre à jour l’extension k8s-extension installée sur le cluster.

ERREUR : ResourceNotReady

Pour exécuter le code score.py fourni dans le cadre du déploiement, Azure crée un conteneur qui comprend toutes les ressources qui lui sont nécessaires, puis exécute le script de scoring sur ce conteneur. Dans ce scénario, l’erreur est la suivante : ce conteneur se bloque à l’exécution, ce qui signifie que le scoring ne peut pas être effectué. Cette erreur se produit dans les cas suivants :

  • Il y a une erreur dans score.py. Utilisez get-logs pour diagnostiquer les problèmes courants :
    • Un package que score.py tente d’importer n’est pas inclus dans l’environnement conda.
    • Erreur de syntaxe.
    • Échec dans la méthode init().
  • Si get-logs ne produit aucun journal, cela signifie généralement que le conteneur n’a pas pu démarrer. Pour déboguer ce problème, essayez plutôt de déployer localement.
  • Les probes readiness ou liveness ne sont pas configurées correctement.
  • L’initialisation du conteneur prend trop de temps si bien que la sonde probe readiness ou probe liveness échoue au-delà du seuil d’échec. Dans ce cas, ajustez les paramètres de la sonde d’intégrité pour laisser plus de temps à l’initialisation du conteneur. Vous pouvez également essayer une référence SKU de machine virtuelle plus grande parmi les références SKU de machine virtuelle prises en charge, ce qui accélère l’initialisation.
  • Il y a une erreur dans la configuration de l’environnement du conteneur, comme par exemple une dépendance manquante.
  • Lorsque vous recevez l’erreur TypeError: register() takes 3 positional arguments but 4 were given, vérifiez la dépendance entre flask v2 et azureml-inference-server-http. Pour plus d’informations, consultez FAQ sur le serveur HTTP d’inférence.

ERREUR : ResourceNotFound

Vous trouverez ci-dessous une liste des raisons pour lesquelles vous pouvez rencontrer cette erreur uniquement quand vous utilisez un point de terminaison en ligne managé ou un point de terminaison en ligne Kubernetes :

Resource Manager ne parvient pas à trouver une ressource

Cette erreur se produit quand Azure Resource Manager ne trouve pas une ressource nécessaire. Par exemple, vous pouvez recevoir cette erreur si un compte de stockage est référencé, mais qu’il est introuvable dans le chemin spécifié. Vérifiez attentivement les ressources qui peuvent avoir été fournies par un chemin exact ou l’orthographe des noms.

Pour plus d’informations, consultez Résoudre les erreurs liées à des ressources introuvables.

Erreur d’autorisation du registre de conteneurs

Cette erreur se produit quand une image appartenant à un registre de conteneurs privé ou inaccessible a été fournie pour le déploiement. À ce stade, nos API ne peuvent pas accepter d’informations d’identification de registre privé.

Pour atténuer cette erreur, vérifiez que le registre de conteneurs n’est pas privé ou effectuez les étapes suivantes :

  1. Accordez le rôle acrPull de votre registre privé à l’identité système de votre point de terminaison en ligne.
  2. Dans la définition de votre environnement, spécifiez l’adresse de votre image privée ainsi que l’instruction de ne pas modifier (générer) l’image.

Si l’atténuation réussit, l’image ne nécessite pas de génération et l’adresse de l’image finale est l’adresse d’image donnée. Au moment du déploiement, l’identité système de votre point de terminaison en ligne extrait l’image du registre privé.

Pour plus d’informations de diagnostic, consultez Guide pratique pour utiliser l’API de diagnostic d’espace de travail.

ERROR: OperationCanceled

Vous trouverez ci-après une liste des raisons pour lesquelles vous pouvez rencontrer cette erreur quand vous utilisez un point de terminaison en ligne managé ou un point de terminaison en ligne Kubernetes :

Opération annulée par une autre opération de priorité supérieure

Les opérations Azure disposent d’un certain niveau de priorité. Elles sont exécutées dans l’ordre de la priorité la plus élevée à la plus faible. Cette erreur se produit quand votre opération a été remplacée par une autre opération disposant d’une priorité plus élevée.

Une nouvelle tentative de l’opération peut permettre de l’exécuter sans annulation.

Opération annulée en attente de confirmation du verrouillage

Les opérations Azure ont une courte période d’attente après avoir été envoyées pendant laquelle elles récupèrent un verrou pour s’assurer que nous ne sommes pas soumis à des conditions de concurrence. Cette erreur se produit lorsque l’opération que vous avez envoyée est identique à une autre opération. L’autre opération attend actuellement la confirmation qu’elle a reçu le verrou pour continuer. Cela peut indiquer que vous avez envoyé une requête très similaire trop tôt après la requête initiale.

Si vous effectuez une nouvelle tentative de l’opération après avoir attendu plusieurs secondes, voire une minute, cela peut permettre de l’exécuter sans l’annuler.

ERREUR : SecretsInjectionError

La récupération et l'injection de secrets lors de la création d'un déploiement en ligne utilise l'identité associée au point de terminaison en ligne pour récupérer les secrets des connexions de l'espace de travail et/ou des coffres-forts de clés. Cette erreur se produit dans les cas suivants :

  • L'identité du point de terminaison n'a pas l'autorisation Azure RBAC de lire les secrets des connexions de l'espace de travail et/ou des coffres-forts de clés, même si les secrets ont été spécifiés par la définition du déploiement en tant que références (mappées à des variables d'environnement). N'oubliez pas que l'attribution des rôles peut prendre un certain temps avant que les changements ne prennent effet.
  • Le format des références secrètes n'est pas valide ou les secrets spécifiés n'existent pas dans les connexions de l'espace de travail et/ou les coffres de clés.

Pour plus d’informations, consultez Injection de secrets dans les points de terminaison en ligne (préversion) et Accéder aux secrets à partir du déploiement en ligne à l’aide de l’injection de secrets (préversion).

ERREUR : InternalServerError

Nous faisons de notre mieux pour fournir un service stable et fiable. Cependant, il arrive que les opérations ne se déroulent pas comme prévu. Si vous recevez cette erreur, cela signifie qu’il y a un problème de notre côté et que nous devons le corriger. Envoyez un ticket de support client avec toutes les informations associées et nous résoudrons le problème.

Erreurs courantes spécifiques aux déploiements Kubernetes

Erreurs relatives à l’identité et à l’authentification :

Erreurs relatives à crashloopbackoff :

Erreurs relatives au script de scoring :

Autres :

ERREUR : ACRSecretError

Vous trouverez ci-après une liste des raisons pour lesquelles vous risquez de rencontrer cette erreur quand vous créez/mettez à jour les déploiements en ligne Kubernetes :

  • L’attribution de rôle n’a pas été achevée. Dans ce cas, attendez quelques secondes, puis réessayez plus tard.
  • L’extension Azure ARC (pour les clusters Kubernetes avec Azure Arc) ou Azure Machine Learning (pour AKS) n’est pas correctement installée ou configurée. Essayez de vérifier la configuration et l’état de l’extension Azure ARC ou Azure Machine Learning.
  • Le cluster Kubernetes a une configuration réseau incorrecte. Vérifiez le proxy, la stratégie réseau ou le certificat.
    • Si vous utilisez un cluster AKS privé, il est nécessaire de configurer des points de terminaison privés pour le registre ACR, le compte de stockage et l’espace de travail dans le réseau virtuel AKS.
  • Vérifiez que la version de votre extension Azure Machine Learning est supérieure à la version 1.1.25.

ERREUR : TokenRefreshFailed

Cette erreur est due au fait que l’extension ne peut pas obtenir les informations d’identification du principal à partir d’Azure, car l’identité du cluster Kubernetes n’est pas définie correctement. Réinstallez l’extension Azure Machine Learning et réessayez.

ERREUR : GetAADTokenFailed

Cette erreur s’explique par le fait que le jeton Azure AD de la requête du cluster Kubernetes a échoué ou est arrivé à expiration. Vérifiez l’accessibilité de votre réseau, puis réessayez.

  • Vous pouvez suivre la procédure Configurer le trafic réseau requis pour vérifier le proxy sortant. Assurez-vous que le cluster peut se connecter à l’espace de travail.
  • L’URL du point de terminaison de l’espace de travail se trouve dans la définition CRD du point de terminaison en ligne du cluster.

Si votre espace de travail est un espace de travail privé, sur lequel l’accès au réseau public est désactivé, le cluster Kubernetes ne doit communiquer avec cet espace de travail privé qu’en empruntant la liaison privée.

ERREUR : ACRAuthenticationChallengeFailed

Cette erreur se produit à cause du cluster Kubernetes qui ne peut pas accéder au service ACR de l’espace de travail pour effectuer une demande d’authentification. Vérifiez votre réseau, en particulier l’accès au réseau public ACR, puis réessayez.

Pour vérifier le réseau, vous pouvez suivre les étapes de résolution des problèmes décrites dans GetAADTokenFailed.

ERREUR : ACRTokenExchangeFailed

Cette erreur est due au fait que le jeton de l’enregistrement de contrôle d’accès (ACR) d’échange de cluster Kubernetes a échoué, car le jeton Azure AD n’est pas encore autorisé. Étant donné que l’attribution de rôle prend un certain temps, vous pouvez attendre un moment, puis réessayer.

Cet échec peut également être dû à un trop grand nombre de demandes adressées au service ACR à ce moment-là. Dans ce cas, il s’agit d’une erreur temporaire et vous pouvez réessayer ultérieurement.

ERREUR : KubernetesUnaccessible

Vous pouvez obtenir le message d’erreur suivant pendant les déploiements de modèles Kubernetes :

{"code":"BadRequest","statusCode":400,"message":"The request is invalid.","details":[{"code":"KubernetesUnaccessible","message":"Kubernetes error: AuthenticationException. Reason: InvalidCertificate"}],...}

Pour corriger cette erreur, vous pouvez :

ERREUR : ImagePullLoopBackOff

La raison pour laquelle vous risquez de rencontrer cette erreur lors de la création/mise à jour de déploiements en ligne Kubernetes est que vous ne pouvez pas télécharger les images à partir du registre de conteneurs, ceci provoquant l’échec de l’extraction des images.

Dans ce cas, vous pouvez vérifier la stratégie réseau du cluster et le registre de conteneurs de l’espace de travail pour voir si le cluster peut extraire l’image du registre de conteneurs.

ERREUR : DeploymentCrashLoopBackOff

La raison pour laquelle vous risquez de rencontrer cette erreur lors de la création/mise à jour de déploiements en ligne Kubernetes est que le conteneur de l’utilisateur a planté lors de l’initialisation. Il existe deux raisons possibles à cette erreur :

  • Le script utilisateur score.py rencontre une erreur de syntaxe ou une erreur d’importation, puis déclenche des exceptions lors de l’initialisation.
  • Le pod de déploiement a besoin de plus de mémoire que sa limite.

Pour corriger cette erreur, vous pouvez d’abord vérifier les journaux de déploiement pour y rechercher des exceptions dans les scripts utilisateur. Si l’erreur persiste, essayez d’étendre la limite de mémoire du type de ressources/de l’instance.

ERREUR : KubernetesCrashLoopBackOff

Voici une liste des raisons pour lesquelles vous risquez de rencontrer cette erreur quand vous créez/mettez à jour des points de terminaison/déploiements en ligne Kubernetes :

  • Un ou plusieurs pods sont bloqués dans l’état CrashLoopBackoff. Vous pouvez vérifier si le journal de déploiement existe et vérifier s’il existe des messages d’erreur dans le journal.
  • Une erreur s’est produite dans score.py et le conteneur a planté au moment de l’initialisation du code de votre score ; vous pouvez suivre la partie ERREUR : ResourceNotReady.
  • Votre processus de scoring nécessite plus de mémoire que la limite configurée pour le déploiement. Vous pouvez essayer de mettre à jour le déploiement avec une limite de mémoire plus importante.

ERREUR : NamespaceNotFound

Vous risquez de rencontrer cette erreur quand vous créez/mettez à jour les points de terminaison en ligne Kubernetes, car l’espace de noms utilisé par votre calcul Kubernetes n’est pas disponible dans votre cluster.

Vous pouvez consulter le calcul Kubernetes dans le portail de votre espace de travail ainsi que l’espace de noms dans votre cluster Kubernetes. Si l’espace de noms n’est pas disponible, vous pouvez détacher le calcul hérité, et le rattacher pour en créer un nouveau, en spécifiant un espace de noms qui existe déjà dans votre cluster.

ERREUR : UserScriptInitFailed

La raison pour laquelle vous pouvez rencontrer cette erreur lors de la création/mise à jour des déploiements en ligne Kubernetes est que la fonction d’initialisation dans votre fichier score.py chargé a déclenché une exception.

Vous pouvez consulter les journaux de déploiement pour voir le message d’exception en détail et corriger l’exception.

ERREUR : UserScriptImportError

La raison pour laquelle vous pouvez rencontrer cette erreur lors de la création/mise à jour des déploiements en ligne Kubernetes est que le fichier score.py que vous avez chargé a importé des packages non disponibles.

Vous pouvez consulter les journaux de déploiement pour voir le message d’exception en détail et corriger l’exception.

ERREUR : UserScriptFunctionNotFound

La raison pour laquelle vous pouvez rencontrer cette erreur lors de la création/mise à jour des déploiements en ligne Kubernetes est que le fichier score.py que vous avez chargé n’a pas de fonction nommée init() ou run(). Vous pouvez vérifier votre code et ajouter la fonction.

ERREUR : EndpointNotFound

La raison pour laquelle vous risquez de rencontrer cette erreur lors de la création/mise à jour de déploiements en ligne Kubernetes est que le système ne trouve pas la ressource de point de terminaison pour le déploiement dans le cluster. Vous devez créer le déploiement dans un point de terminaison existant ou créer ce point de terminaison en premier dans votre cluster.

ERREUR : EndpointAlreadyExists

La raison pour laquelle vous pouvez tomber sur cette erreur lors de la création d’un point de terminaison en ligne Kubernetes est que le point de terminaison que vous créez existe déjà dans votre cluster.

Le nom du point de terminaison doit être unique par espace de travail et par cluster. Donc, dans le cas présent, vous devez créer un point de terminaison avec un autre nom.

ERREUR : ScoringFeUnhealthy

La raison pour laquelle vous risquez de tomber sur cette erreur lors de la création/mise à jour d’un point de terminaison/déploiement en ligne Kubernetes est due au fait qu’Azureml-fe, qui est le service système exécuté dans le cluster, est introuvable ou non sain.

Pour résoudre ce problème, vous pouvez réinstaller ou mettre à jour l’extension Azure Machine Learning dans votre cluster.

ERREUR : ValidateScoringFailed

La raison pour laquelle vous risquez de rencontrer cette erreur lors de la création/mise à jour de déploiements en ligne Kubernetes est que la validation de l’URL de demande de scoring a échoué lors du traitement du déploiement du modèle.

Dans ce cas, vous pouvez d’abord vérifier l’URL du point de terminaison, puis essayer de redéployer le déploiement.

ERREUR : InvalidDeploymentSpec

Vous risquez de rencontrer cette erreur lors de la création/mise à jour de déploiements en ligne Kubernetes parce que la spécification du déploiement n’est pas valide.

Dans ce cas, vous pouvez vérifier le message d’erreur.

  • Vérifiez que instance count est valide.
  • Si vous avez activé la mise à l’échelle automatique, vérifiez que le minimum instance count et le maximum instance count sont tous les deux valides.

ERREUR : PodUnschedulable

Voici une liste des raisons pour lesquelles vous risquez de rencontrer cette erreur quand vous créez/mettez à jour des points de terminaison/déploiements en ligne Kubernetes :

  • Impossible de planifier le pod sur les nœuds en raison de ressources insuffisantes dans votre cluster.
  • Aucun nœud ne correspond à l’affinité/au sélecteur de nœud.

Pour corriger cette erreur, vous pouvez effectuer ces étapes :

  • Vérifiez la définition du node selector du instance type que vous avez utilisé et la configuration node label de vos nœuds de cluster.
  • Vérifiez le instance type et la taille SKU du nœud pour le cluster AKS ou la ressource du nœud pour le cluster Arc-Kubernetes.
    • Si le cluster n’a pas assez de ressources, vous pouvez réduire les besoins en ressources du type d’instance ou utiliser un autre type d’instance avec une ressource plus petite requise.
  • Si le cluster n’a plus de ressources pour répondre aux besoins du déploiement, supprimez un déploiement pour libérer des ressources.

ERREUR : PodOutOfMemory

La raison pour laquelle vous pouvez rencontrer cette erreur quand vous créez/mettez à jour un déploiement en ligne est que la limite de mémoire que vous donnez pour le déploiement est insuffisante. Vous pouvez définir la limite de mémoire sur une valeur plus élevée ou utiliser un type d’instance plus grand pour corriger cette erreur.

ERREUR : InferencingClientCallFailed

La raison pour laquelle vous risquez de rencontrer cette erreur quand vous créez/mettez à jour des points de terminaison/déploiements en ligne Kubernetes est qu’il est impossible de connecter l’extension k8s-extension du cluster Kubernetes.

Dans ce cas, vous pouvez détacher votre calcul, puis l’attacher de nouveau.

Notes

Pour résoudre les erreurs en effectuant un rattachement, veillez à effectuer cette opération avec exactement la même configuration que le calcul précédemment détaché, par exemple avec le même nom de calcul et le même espace de noms ; sinon, vous risquez de rencontrer d’autres erreurs.

Si cela ne fonctionne toujours pas, vous pouvez demander à l’administrateur ayant accès au cluster d’utiliser kubectl get po -n azureml pour vérifier si les pods du serveur relais sont en cours d’exécution.

Problèmes de mise à l’échelle automatique

Si vous rencontrez des problèmes de mise à l’échelle automatique, consultez Résolution des problèmes liés à la mise à l’échelle automatique Azure.

Pour le point de terminaison en ligne Kubernetes, il existe un routeur d’inférence Azure Machine Learning qui est un composant front-end permettant de gérer la mise à l’échelle automatique de tous les modèles de déploiement sur le cluster Kubernetes. Pour plus d’informations, consultez Mise à l’échelle automatique du routage d’inférence Kubernetes

Erreurs courantes de consommation de modèle

Voici une liste d’erreurs courantes de consommation de modèle résultant de l’état de l’opération invoke du point de terminaison.

Problèmes de limite de bande passante

Chaque point de terminaison en ligne managé a ses propres limites de bande passante. Vous trouverez la configuration de limite dans limites pour les points de terminaison en ligne. Si votre utilisation de la bande passante dépasse la limite, votre requête est retardée. Pour monitorer le délai de bande passante :

  • Utilisez la métrique « Network bytes » (Octets réseau) pour comprendre l’utilisation actuelle de la bande passante. Pour plus d’informations, consultez Superviser des points de terminaison en ligne managés.
  • Deux amorces de fin de réponse sont retournées si une limite de bande passante est appliquée :
    • ms-azureml-bandwidth-request-delay-ms : délai en millisecondes nécessaire au transfert du flux de requête.
    • ms-azureml-bandwidth-response-delay-ms : délai en millisecondes nécessaire au transfert du flux de réponse.

Codes d’état HTTP

Quand vous accédez à des points de terminaison en ligne avec des requêtes REST, les codes d’état retournés correspondent aux codes d’état HTTP standard. Voici des informations détaillées sur la façon dont les erreurs d’appel et de prédiction des points de terminaison sont mappées aux codes d’état HTTP.

Codes d’erreur courants pour les points de terminaison en ligne managés

Le tableau suivant contient des codes d’erreur courants lors de l’utilisation de points de terminaison en ligne managés avec des requêtes REST :

Code d’état Motif Raison pour laquelle ce code peut être retourné
200 OK Votre modèle a été exécuté correctement et dans le cadre de votre limite de latence.
401 Non autorisé Vous n’avez pas l’autorisation d’effectuer l’action demandée, par exemple un scoring, ou votre jeton a expiré ou n’a pas le bon format. Pour plus d’informations, consultez les articles Concept d’authentification de point de terminaison et Comment s’authentifier pour le point de terminaison.
404 Introuvable Le point de terminaison n’a pas de déploiement valide avec un poids positif.
408 Délai d’expiration de la demande L’exécution du modèle a dépassé le délai d’expiration spécifié dans request_timeout_ms sous request_settings dans la configuration du déploiement de votre modèle.
424 Erreur de modèle Si votre conteneur de modèle retourne une réponse autre que 200, Azure retourne un code 424. Vérifiez la dimension Model Status Code sous la métrique Requests Per Minute sur l’Explorateur de métriques Azure Monitor de votre point de terminaison. Vous pouvez également vérifier les en-têtes de réponse ms-azureml-model-error-statuscode et ms-azureml-model-error-reason pour plus d’informations. Si 424 est mentionné avec l’échec de la sonde probe liveness ou probe readiness, envisagez d’ajuster les paramètres de sonde pour accorder plus de temps à probe readiness ou probe readiness du conteneur.
429 Requêtes en attente trop nombreuses Votre modèle obtient actuellement plus de requêtes qu’il ne peut en gérer. Azure Machine Learning a implémenté un système qui permet le traitement d’un maximum de 2 * max_concurrent_requests_per_instance * instance_count requests en parallèle à tout moment pour garantir un fonctionnement sans heurts. Les autres requêtes dépassant ce maximum sont rejetées. Vous pouvez passer en revue la configuration de votre déploiement de modèle dans les sections request_settings et scale_settings pour vérifier et ajuster ces paramètres. En outre, comme indiqué dans la définition YAML pour RequestSettings, il est important de s’assurer que la variable d’environnement WORKER_COUNT est transmise.

Si vous utilisez la mise à l’échelle automatique et obtenez cette erreur, cela signifie que votre modèle obtient les requêtes trop rapidement par rapport à la vitesse de scale-up du système. Dans ce cas, envisagez de renvoyer les requêtes avec un backoff exponentiel pour donner au système le temps nécessaire de s’ajuster. Vous pouvez également augmenter le nombre d’instances en utilisant le code pour calculer le nombre d’instances. Ces étapes, combinées à la définition de la mise à l’échelle automatique, vous permettent de garantir que votre modèle est prêt à gérer l’afflux de requêtes.
429 Limité en débit Le nombre de demandes par seconde a atteint les limites des points de terminaison en ligne managés.
500 Erreur interne du serveur L’infrastructure provisionnée par Azure Machine Learning échoue.

Codes d’erreur courants pour les points de terminaison en ligne Kubernetes

Le tableau suivant contient des codes d’erreur courants lors de l’utilisation de points de terminaison en ligne Kubernetes avec des requêtes REST :

Code d’état Motif Raison pour laquelle ce code peut être retourné
409 Erreur de conflit Quand une opération est déjà en cours, toute nouvelle opération sur ce même point de terminaison en ligne répond en indiquant une erreur de conflit 409. Par exemple, si une opération de création ou de mise à jour du point de terminaison en ligne est en cours, et que vous déclenchez une nouvelle opération de suppression, une erreur est générée.
502 A levé une exception ou a planté dans la méthode run() du fichier score.py Quand il existe une erreur dans score.py, par exemple un package importé inexistant dans l’environnement Conda, une erreur de syntaxe ou un échec dans la méthode init(). Vous pouvez suivre les indications fournies ici pour déboguer le fichier.
503 Recevoir des pics importants de requêtes par seconde L'Autoscaler est conçu pour gérer des changements progressifs de charge. Si vous recevez des pics importants de requêtes par seconde, les clients peuvent recevoir un code d’état HTTP 503. Même si la mise à l'échelle automatique réagit rapidement, il faut beaucoup de temps à AKS pour créer d'autres conteneurs. Vous pouvez suivre les indications fournies ici pour éviter les codes d’état 503.
504 Le délai d’expiration de la requête a été dépassé Un code d’état 504 indique que la requête a expiré. Le délai d’expiration par défaut est de 5 secondes. Vous pouvez augmenter le délai d’expiration ou essayer d’accélérer le point de terminaison en modifiant le fichier score.py pour supprimer les appels inutiles. Si ces actions ne permettent pas de résoudre le problème, vous pouvez suivre les indications fournies ici pour déboguer le fichier score.py. Le code peut être dans un état sans réponse ou une boucle infinie.
500 Erreur interne du serveur L’infrastructure provisionnée par Azure Machine Learning échoue.

Comment éviter les codes d’état 503

Les déploiements en ligne de Kubernetes prennent en charge la mise à l’échelle automatique, ce qui permet d’ajouter des réplicas pour gérer les charges supplémentaire. Vous trouverez plus d’informations dans la rubrique relative au routeur d’inférence Azure Machine Learning. La décision d’effectuer un scale-up/down est basée sur l’utilisation des réplicas de conteneur actuels.

Il existe deux mesures permettant d’empêcher les codes d’état 503 :

Conseil

Ces deux approches peuvent être utilisées individuellement ou conjointement.

  • Modifiez le niveau d’utilisation auquel la mise à l’échelle automatique crée de nouveaux réplicas. Vous pouvez ajuster la cible de l’utilisation en définissant autoscale_target_utilization sur une valeur inférieure.

    Important

    Cette modification n’entraîne pas la création de réplicas plus rapidement. Ils sont créés à un seuil d’utilisation inférieur. Au lieu d’attendre jusqu’à ce que le service soit utilisé à 70 %, la modification de la valeur sur 30 % provoque la création de réplicas lors d’une utilisation à 30 %.

    Si le point de terminaison en ligne Kubernetes utilise déjà le nombre maximal de réplicas actuel, et si vous voyez toujours des codes d’état 503, augmentez la valeur de autoscale_max_replicas pour accroître le nombre maximal de réplicas.

  • Modifiez le nombre minimal de réplicas. L’augmentation du nombre minimal de réplicas offre un plus grand pool pour gérer les pics entrants.

    Pour augmenter le nombre d’instances, vous pouvez calculer les réplicas requis d’après ces codes.

    from math import ceil
    # target requests per second
    target_rps = 20
    # time to process the request (in seconds, choose appropriate percentile)
    request_process_time = 10
    # Maximum concurrent requests per instance
    max_concurrent_requests_per_instance = 1
    # The target CPU usage of the model container. 70% in this example
    target_utilization = .7
    
    concurrent_requests = target_rps * request_process_time / target_utilization
    
    # Number of instance count
    instance_count = ceil(concurrent_requests / max_concurrent_requests_per_instance)
    

    Notes

    Si vous recevez des pics de demande supérieurs au nouveau nombre minimal pouvant être géré par les réplicas, il se peut que des codes d’état 503 réapparaissent. Par exemple, à mesure que le trafic vers votre point de terminaison augmente, vous devrez peut-être augmenter le nombre minimal de réplicas.

Calcul du nombre d’instances

Pour augmenter le nombre d’instances, vous pouvez calculer les réplicas nécessaires à l’aide du code suivant :

from math import ceil
# target requests per second
target_rps = 20
# time to process the request (in seconds, choose appropriate percentile)
request_process_time = 10
# Maximum concurrent requests per instance
max_concurrent_requests_per_instance = 1
# The target CPU usage of the model container. 70% in this example
target_utilization = .7

concurrent_requests = target_rps * request_process_time / target_utilization

# Number of instance count
instance_count = ceil(concurrent_requests / max_concurrent_requests_per_instance)

Bloqué par la stratégie CORS

Les points de terminaison en ligne (v2) ne prennent pas en charge de manière native le partage de ressources CORS (cross-origin). Si votre application web tente d’appeler le point de terminaison sans gérer les requêtes préalables CORS de façon appropriée, vous pouvez voir le message d’erreur suivant :

Access to fetch at 'https://{your-endpoint-name}.{your-region}.inference.ml.azure.com/score' from origin http://{your-url} has been blocked by CORS policy: Response to preflight request doesn't pass access control check. No 'Access-control-allow-origin' header is present on the request resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with the CORS disabled.

Nous vous recommandons d’utiliser Azure Functions, Azure Application Gateway ou tout autre service en tant que couche temporaire pour gérer les requêtes préalables CORS.

Problèmes courants d’isolation réseau

Échec de la création du point de terminaison en ligne avec un message V1LegacyMode == true

L’espace de travail Azure Machine Learning peut être configuré pour v1_legacy_mode, ce qui désactive les API v2. Les points de terminaison en ligne managés sont une fonctionnalité de la plateforme d’API v2 et ne fonctionnent pas si v1_legacy_mode est activé pour l’espace de travail.

Important

Vérifiez avec votre équipe de sécurité réseau avant de désactiver v1_legacy_mode. Il a peut-être été activé par votre équipe de sécurité réseau pour une certaine raison.

Pour plus d’informations sur la désactivation de v1_legacy_mode, consultez Isolement réseau avec v2.

Échec de la création d’un point de terminaison en ligne avec l’authentification basée sur une clé

Utilisez la commande suivante pour lister les règles réseau du coffre Azure Key Vault pour votre espace de travail. Remplacez <keyvault-name> par le nom de votre coffre de clés :

az keyvault network-rule list -n <keyvault-name>

Cette commande retourne une réponse similaire au document JSON suivant :

{
    "bypass": "AzureServices",
    "defaultAction": "Deny",
    "ipRules": [],
    "virtualNetworkRules": []
}

Si bypass n’a pas la valeur AzureServices, suivez les conseils donnés dans Configurer les paramètres réseau du coffre de clés pour lui affecter la valeur AzureServices.

Échec des déploiements en ligne avec une erreur de téléchargement d’image

Remarque

Ce problème s’applique lorsque vous utilisez la méthode d’isolation réseau héritée pour les points de terminaison en ligne managés, dans laquelle Azure Machine Learning crée un réseau virtuel managé pour chaque déploiement sous un point de terminaison.

  1. Vérifiez si l’indicateur egress-public-network-access est désactivé pour le déploiement. Si cet indicateur est activé et que la visibilité du registre de conteneurs est privée, cet échec est normal.

  2. Utilisez la commande suivante pour vérifier l’état de la connexion au point de terminaison privé. Remplacez <registry-name> par le nom du registre Azure Container Registry de votre espace de travail :

    az acr private-endpoint-connection list -r <registry-name> --query "[?privateLinkServiceConnectionState.description=='Egress for Microsoft.MachineLearningServices/workspaces/onlineEndpoints'].{Name:name, status:privateLinkServiceConnectionState.status}"
    

    Dans le document de réponse, vérifiez que le champ status a la valeur Approved. S’il n’est pas approuvé, utilisez la commande suivante pour l’approuver. Remplacez <private-endpoint-name> par le nom retourné par la commande précédente :

    az network private-endpoint-connection approve -n <private-endpoint-name>
    

Impossible de résoudre le point de terminaison de scoring

  1. Vérifiez que le client qui émet la requête de scoring est un réseau virtuel ayant accès à l’espace de travail Azure Machine Learning.

  2. Utilisez la commande nslookup sur le nom d’hôte du point de terminaison pour récupérer les informations d’adresse IP :

    nslookup endpointname.westcentralus.inference.ml.azure.com
    

    La réponse contient une adresse. Cette adresse doit faire partie de la plage fournie par le réseau virtuel

    Notes

    Pour le point de terminaison en ligne Kubernetes, le nom d’hôte du point de terminaison doit être le CName (nom de domaine) spécifié dans votre cluster Kubernetes. S’il s’agit d’un point de terminaison HTTP, l’adresse IP est contenue dans l’URI de point de terminaison, que vous pouvez obtenir directement dans l’IU de Studio. Vous trouverez d’autres façons d’obtenir l’adresse IP du point de terminaison dans Sécuriser le point de terminaison en ligne Kubernetes.

  3. Si le nom d’hôte n’est pas résolu par la commande nslookup :

    Pour un point de terminaison en ligne managé,

    1. Vérifiez s’il existe un enregistrement A dans la zone DNS privée du réseau virtuel.

      Pour vérifier les enregistrements, utilisez la commande suivante :

      az network private-dns record-set list -z privatelink.api.azureml.ms -o tsv --query [].name
      

      Les résultats doivent contenir une entrée similaire à celle-ci : *.<GUID>.inference.<region>.

    2. Si aucune valeur d’inférence n’est retournée, supprimez le point de terminaison privé de l’espace de travail, puis recréez-le. Pour plus d’informations, consultez Guide pratique pour configurer un point de terminaison privé.

    3. Si l’espace de travail avec un point de terminaison privé est configuré avec un DNS personnalisé Utilisation de votre espace de travail avec un serveur DNS personnalisé, utilisez la commande suivante pour vérifier si la résolution fonctionne correctement à partir du DNS personnalisé.

      dig endpointname.westcentralus.inference.ml.azure.com
      

    Pour un point de terminaison en ligne Kubernetes,

    1. Vérifiez la configuration DNS dans le cluster Kubernetes.

    2. De plus, vous pouvez vérifier si azureml-fe fonctionne comme prévu, à l’aide de la commande suivante :

      kubectl exec -it deploy/azureml-fe -- /bin/bash
      (Run in azureml-fe pod)
      
      curl -vi -k https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json
      "Swagger not found"
      

      Pour HTTP, utilisez

      curl https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json
      "Swagger not found"
      

    Si les connexions HTTPS via cURL n’aboutissent pas (dépassement du délai d’expiration, par exemple) mais que les connexions HTTP fonctionnent, vérifiez que le certificat est valide.

    Si cela n’opère pas de résolution en enregistrement A, vérifiez si la résolution fonctionne à partir d’Azure DNS (168.63.129.16).

    dig @168.63.129.16 endpointname.westcentralus.inference.ml.azure.com
    

    Si l’opération réussit, vous pouvez résoudre les problèmes de redirecteur conditionnel pour la liaison privée sur le DNS personnalisé.

Les déploiements en ligne ne peuvent pas faire l’objet d’un scoring

  1. Utilisez la commande suivante pour voir si le déploiement a été correctement effectué :

    az ml online-deployment show -e <endpointname> -n <deploymentname> --query '{name:name,state:provisioning_state}' 
    

    Si le déploiement a réussi, la valeur de state est Succeeded.

  2. Si le déploiement a réussi, utilisez la commande suivante pour vérifier que le trafic est affecté au déploiement. Remplacez <endpointname> par le nom du fichier de votre point de terminaison :

    az ml online-endpoint show -n <endpointname>  --query traffic
    

    Conseil

    Cette étape n’est pas nécessaire si vous utilisez l’en-tête azureml-model-deployment dans votre requête pour cibler ce déploiement.

    La réponse de cette commande doit indiquer le pourcentage du trafic affecté aux déploiements.

  3. Si les affectations de trafic (ou l’en-tête de déploiement) sont définies correctement, utilisez la commande suivante pour obtenir les journaux du point de terminaison. Remplacez <endpointname> par le nom du point de terminaison, et <deploymentname> par le déploiement :

    az ml online-deployment get-logs  -e <endpointname> -n <deploymentname> 
    

    Examinez les journaux pour voir s’il y a un problème d’exécution du code de scoring lorsque vous soumettez une requête au déploiement.

Résoudre les problèmes liés au serveur d’inférence

Dans cette section, nous donnons des conseils de résolution des problèmes de base pour le serveur HTTP d’inférence Azure Machine Learning.

Étapes de base

Les étapes de base pour la résolution des problèmes sont les suivantes :

  1. Collectez des informations de version pour votre environnement Python.
  2. Assurez-vous que la version du package python azureml-inference-server-http spécifiée dans le fichier d’environnement correspond à la version du serveur HTTP d’inférence AzureML affichée dans le journal de démarrage. Parfois, le programme de résolution de dépendances de pip conduit à des versions inattendues des packages installés.
  3. Si vous spécifiez Flask (et/ou ses dépendances) dans votre environnement, supprimez-les. Les dépendances incluent Flask, Jinja2, itsdangerous, Werkzeug, MarkupSafe, et click. Flask est répertorié en tant que dépendance dans le package de serveur et il est préférable de laisser notre serveur l’installer. De cette façon, lorsque le serveur prend en charge de nouvelles versions de Flask, vous les obtiendrez automatiquement.

Version du serveur

Le package de serveur azureml-inference-server-http est publié dans PyPI. Vous trouverez notre journal des modifications et toutes les versions précédentes sur notre page PyPI. Mettez à jour vers la dernière version si vous utilisez une version antérieure.

  • 0.4.x : version groupée dans les images d’entraînement ≤ 20220601 et dans azureml-defaults>=1.34,<=1.43. 0.4.13 est la dernière version stable. Si vous utilisez le serveur avant la version 0.4.11, vous pouvez voir des problèmes de dépendance Flask tels que l’impossibilité d’importer le nom Markup à partir de jinja2. Il est recommandé d’effectuer une mise à niveau vers 0.4.13 ou 0.8.x (la dernière version), si possible.
  • 0.6.x : version préinstallée dans les images d’inférence ≤ 20220516. La dernière version stable est la version 0.6.1.
  • 0.7.x : première version qui prend en charge Flask 2. La dernière version stable est la version 0.7.7.
  • 0.8.x : le format du journal a changé et la prise en charge de Python 3.6 n’est plus effective.

Dépendances de package

Les packages les plus pertinents pour le serveur azureml-inference-server-http sont les packages suivants :

  • flask
  • opencensus-ext-azure
  • inference-schema

Si vous avez spécifié azureml-defaults dans votre environnement Python, le package azureml-inference-server-http en dépendra et sera installé automatiquement.

Conseil

Si vous utilisez le kit de développement logiciel (SDK) Python v1 et que vous ne spécifiez pas azureml-defaults explicitement dans votre environnement Python, le SDK peut ajouter le package à votre place. Toutefois, il le verrouille avec la version sur laquelle le SDK est activé. Par exemple, si la version du SDK est 1.38.0, elle ajoutera azureml-defaults==1.38.0 aux exigences pip de l’environnement.

Forum aux questions

1. J’ai rencontré l’erreur suivante lors du démarrage du serveur :


TypeError: register() takes 3 positional arguments but 4 were given

  File "/var/azureml-server/aml_blueprint.py", line 251, in register

    super(AMLBlueprint, self).register(app, options, first_registration)

TypeError: register() takes 3 positional arguments but 4 were given

Flask 2 est installé dans votre environnement Python, mais vous exécutez une version de azureml-inference-server-http qui ne prend pas en charge Flask 2. La prise en charge de Flask 2 est ajoutée dans azureml-inference-server-http>=0.7.0, qui se trouve également dans azureml-defaults>=1.44.

  • Si vous ne vous servez pas de ce package dans une image Docker AzureML, utilisez la dernière version de azureml-inference-server-http ou de azureml-defaults.

  • Si vous utilisez ce package avec une image Docker AzureML, vérifiez que celle-ci a été générée en juillet 2022 ou après. La version de l’image est disponible dans les journaux du conteneur. Vous devriez trouver un journal qui se présente ainsi :

    2022-08-22T17:05:02,147738763+00:00 | gunicorn/run | AzureML Container Runtime Information
    2022-08-22T17:05:02,161963207+00:00 | gunicorn/run | ###############################################
    2022-08-22T17:05:02,168970479+00:00 | gunicorn/run | 
    2022-08-22T17:05:02,174364834+00:00 | gunicorn/run | 
    2022-08-22T17:05:02,187280665+00:00 | gunicorn/run | AzureML image information: openmpi4.1.0-ubuntu20.04, Materializaton Build:20220708.v2
    2022-08-22T17:05:02,188930082+00:00 | gunicorn/run | 
    2022-08-22T17:05:02,190557998+00:00 | gunicorn/run | 
    

    La date de génération de l’image s’affiche après « Build de matérialisation » : 20220708 dans l’exemple ci-dessus, soit le 8 juillet 2022. Cette image est compatible avec Flask 2. Si vous ne voyez pas de bannière comme celle-ci dans le journal de votre conteneur, cela signifie que votre image est obsolète et doit être mise à jour. Si vous utilisez une image CUDA et que vous ne parvenez pas à trouver une image plus récente, vérifiez si elle est déconseillée dans AzureML-Containers. Si c’est le cas, vous devriez trouver des remplacements.

  • Si vous utilisez le serveur avec un point de terminaison en ligne, vous trouverez également les journaux sous « Journaux de déploiement » sur la page des points de terminaison en ligne d’Azure Machine Learning studio. Si vous effectuez le déploiement avec le kit SDK v1 et que vous ne spécifiez pas explicitement d’image dans la configuration de votre déploiement, le kit SDK utilise par défaut une version de openmpi4.1.0-ubuntu20.04 correspondant à votre ensemble d’outils SDK local. Il ne s’agit pas nécessairement de la dernière version de l’image. Par exemple, le kit SDK 1.43 emploie par défaut openmpi4.1.0-ubuntu20.04:20220616, qui est incompatible. Veillez à utiliser la dernière version du kit SDK pour votre déploiement.

  • Si, pour une raison quelconque, vous ne parvenez pas à mettre à jour l’image, vous pouvez éviter temporairement le problème en épinglant azureml-defaults==1.43 ou azureml-inference-server-http~=0.4.13. Cette action aura pour effet d’installer le serveur de l’ancienne version avec Flask 1.0.x.

2. J’ai rencontré une erreur ImportError ou ModuleNotFoundError sur des modules opencensus, jinja2, MarkupSafe ou click pendant le démarrage :

ImportError: cannot import name 'Markup' from 'jinja2'

Les versions antérieures (<= 0.4.10) du serveur n’épinglaient pas la dépendance de Flask à des versions compatibles. Ce problème est corrigé dans la dernière version du serveur.

Étapes suivantes