Comment résoudre l'erreur d'inférence d’Amazon SageMaker « délai en amont expiré (110 : la connexion a expiré) lors de la lecture de l'en-tête de réponse en amont » ?

Brève description

Cette erreur indique un problème avec la connexion entre NGINX et le serveur Web. Ces deux composants s'exécutent dans le conteneur modèle, que vous utilisiez votre propre conteneur ou un conteneur préconçu. Ces composants ne sont pas directement liés à l'hébergement SageMaker ou aux transformations par lots. Toutefois, lorsque la connexion entre NGINX et le serveur Web expire, SageMaker ne peut pas obtenir d'inférence à partir du point de terminaison /invocations.

Pour résoudre ce problème :

1. Réduisez la latence du conteneur de l'algorithme ou augmentez la limite de délai d'attente du conteneur.
2. Augmentez les paramètres de délai d'expiration de NGinx.conf.

Résolution

Réduire la latence du conteneur de l'algorithme ou augmenter la limite de délai

• Si vous exécutez un code d'inférence pour les services d'hébergement : vos conteneurs modèles doivent répondre aux requêtes dans un délai de 60 secondes. Le modèle lui-même peut avoir un temps de traitement maximal de 60 secondes. Si vous savez que votre modèle a besoin de 50 à 60 secondes de temps de traitement, définissez le délai d'expiration du socket SDK sur 70 secondes. Pour plus d'informations, consultez la section Comment votre conteneur doit répondre aux demandes d'inférence.
• Si vous exécutez un code d'inférence pour la transformation par lots : utilisez ModelClientConfig pour configurer les paramètres InvocationsTimeoutInSeconds (délai d’invocation en secondes) et InvocationsMaxRetries (tentatives maximum d’invocations).

Amazon SageMaker définit les variables d'environnement spécifiées dans CreateModel et CreateTransformJob sur votre conteneur. Ajustez les paramètres API suivants pour réduire la latence du conteneur d'algorithme. Par exemple, si l'entrée est fractionnable, limitez la taille de charge utile de chaque demande en définissant le champ MaxPayloadInMB lorsque vous créez un tâche de transformation.

• MaxPayloadInMB: taille maximale de la charge utile envoyée au conteneur. Si le conteneur peut traiter rapidement une transformation par lots, augmentez cette propriété. Si la transformation par lots prend plus de temps que prévu, réduisez cette propriété.
• MaxConcurrentTransforms (transformations simultanées maximales) : la valeur par défaut est 1. Augmentez ce paramètre si vous avez plusieurs travailleurs NGINX.
• BatchStrategy (stratégie de lots) : pour intégrer autant d'enregistrements que possible dans un mini-lot (jusqu'à la limite MaxPayloadInMB), définissez BatchStrategy sur MultiRecord (plusieurs enregistrements) et SplitType (type de fractionnement) sur Line.

Si vous utilisez un conteneur cadre SageMaker qui implémente Gunicorn, transmettez ces propriétés au conteneur Docker en tant que variables d'environnement :

• SAGEMAKER _MODEL_SERVER_TIMEOUT : délai d'expiration pour le serveur Gunicorn. Pour accorder plus de temps au traitement de la demande avant la fermeture de la connexion, augmentez cette valeur.
• SAGEMAKER _MODEL_SERVER_WORKERS : nombre de travailleurs par CPU.

Augmenter les paramètres de délai d'expiration de NGINX.conf

Si vous utilisez l'un des conteneurs Docker prédéfinis d'Amazon SageMaker, vous ne pouvez pas modifier le fichier NGINX.conf. Vous ne pouvez modifier NGINX.conf que si vous utilisez votre propre conteneur Docker.

Les délais d'expiration NGINX peuvent provoquer des échecs car Amazon SageMaker clôture la connexion après le délai d'expiration. Si votre conteneur tente de lire ou d'écrire à partir de la connexion clôturée, la demande échoue. Modifiez une ou plusieurs des propriétés suivantes pour tenir compte de la surcharge réseau.

• proxy_read_timeout : il s'agit du temps pendant lequel NGINX attend une réponse du modèle après un appel request.send. Augmentez cette valeur pour laisser plus de temps à Amazon SageMaker pour traiter la demande avant la fermeture de la connexion.
• worker_processes : nombre de threads pour les connexions entrantes. Dans la plupart des cas, la valeur doit être identique ou supérieure au nombre de cœurs CPU. Par exemple, pour un type d'instance à deux cœurs tel que ml.m5.large, définissez cette propriété sur un minimum de deux.
• worker_connections : il s'agit du nombre maximal de connexions simultanées pour chaque processus de travail. Il est recommandé de définir la valeur de départ pour ce paramètre sur 1024.

Pour plus d'informations sur les paramètres de configuration, consultez Module ngx_http_proxy_module dans la documentation NGINX.