Minimisez l'impact sur la production des mises à jour du modèle ML avec les tests fantômes d'Amazon SageMaker

Amazon Sage Maker vous permet désormais de comparer les performances d'une nouvelle version d'une pile de diffusion de modèles avec la version actuellement déployée avant un déploiement complet en production à l'aide d'une pratique de sécurité de déploiement appelée test de l'ombre. Les tests fantômes peuvent vous aider à identifier les erreurs de configuration potentielles et les problèmes de performances avant qu'ils n'affectent les utilisateurs finaux. Avec SageMaker, vous n'avez pas besoin d'investir dans la construction de votre infrastructure de test parallèle, ce qui vous permet de vous concentrer sur le développement de modèles. SageMaker se charge de déployer la nouvelle version parallèlement à la version actuelle servant les demandes de production, en acheminant une partie des demandes vers la version fantôme. Vous pouvez ensuite comparer les performances des deux versions à l'aide de mesures telles que la latence et le taux d'erreur. Cela vous donne une plus grande confiance dans le fait que les déploiements de production sur les points de terminaison d'inférence SageMaker n'entraîneront pas de régressions des performances et vous aident à éviter les interruptions dues à des erreurs de configuration accidentelles.

Dans cet article, nous démontrons cette nouvelle fonctionnalité SageMaker. L'exemple de notebook correspondant est disponible dans ce GitHub dépôt.

Présentation de la solution

Votre infrastructure de service de modèle se compose du modèle d'apprentissage automatique (ML), du conteneur de service ou de l'instance de calcul. Considérons les scénarios suivants :

• Vous envisagez de promouvoir un nouveau modèle qui a été validé hors ligne en production, mais vous souhaitez évaluer les mesures de performances opérationnelles, telles que la latence, le taux d'erreur, etc., avant de prendre cette décision.
• Vous envisagez d'apporter des modifications à votre conteneur d'infrastructure de service, telles que la correction de vulnérabilités ou la mise à niveau vers des versions plus récentes, et souhaitez évaluer l'impact de ces modifications avant la promotion en production.
• Vous envisagez de modifier votre instance de ML et souhaitez évaluer les performances de la nouvelle instance avec des requêtes d'inférence en direct.

Le diagramme suivant illustre notre architecture de solution.

Pour chacun de ces scénarios, sélectionnez une variante de production que vous souhaitez tester et SageMaker déploie automatiquement la nouvelle variante en mode fantôme et lui achemine une copie des demandes d'inférence en temps réel au sein du même point de terminaison. Seules les réponses de la variante de production sont renvoyées à l'application appelante. Vous pouvez choisir d'ignorer ou de consigner les réponses de la variante fantôme pour une comparaison hors ligne. En option, vous pouvez surveiller les variantes via un tableau de bord intégré avec une comparaison côte à côte des mesures de performance. Vous pouvez utiliser cette fonctionnalité via les API de point de terminaison de mise à jour d'inférence SageMaker ou via la console SageMaker.

Les variantes fantômes s'appuient sur la capacité de variante de production dans les points de terminaison d'inférence SageMaker. Pour réitérer, un variante de production se compose du modèle ML, du conteneur de service et de l'instance ML. Étant donné que chaque variante est indépendante des autres, vous pouvez avoir différents modèles, conteneurs ou types d'instance dans les variantes. SageMaker vous permet de spécifier des politiques de mise à l'échelle automatique par variante afin qu'elles puissent évoluer indépendamment en fonction de la charge entrante. SageMaker prend en charge jusqu'à 10 variantes de production par terminal. Vous pouvez soit configurer une variante pour recevoir une partie du trafic entrant en définissant des pondérations de variante, soit spécifier la variante cible dans la demande entrante. La réponse de la variante de production est renvoyée à l'appelant.

A variante d'ombre (nouveau) a les mêmes composants qu'une variante de production. Une partie des requêtes spécifiée par l'utilisateur, connue sous le nom de pourcentage d'échantillonnage du trafic, est transmis à la variante shadow. Vous pouvez choisir de consigner la réponse de la variante fantôme dans Service de stockage simple Amazon (Amazon S3) ou jetez-le.

Notez que SageMaker prend en charge un maximum d'une variante shadow par point de terminaison. Pour un point de terminaison avec une variante fantôme, il peut y avoir au maximum une variante de production.

Après avoir configuré les variantes de production et d'ombre, vous pouvez surveiller le métriques d'appel pour les variantes de production et d'ombre dans Amazon Cloud Watch sous le AWS/SageMaker espace de noms. Toutes les mises à jour du point de terminaison SageMaker sont orchestrées à l'aide déploiements bleu/vert et se produisent sans aucune perte de disponibilité. Vos points de terminaison continueront de répondre aux demandes de production à mesure que vous ajoutez, modifiez ou supprimez des variantes fantômes.

Vous pouvez utiliser cette fonctionnalité de deux manières :

• Tests fantômes gérés à l'aide de la console SageMaker – Vous pouvez tirer parti de la console pour une expérience guidée afin de gérer le parcours de bout en bout des tests fantômes. Cela vous permet de configurer des tests fantômes pour une durée prédéfinie, de surveiller la progression via un tableau de bord en direct, de nettoyer à la fin et d'agir sur les résultats.
• Tests parallèles en libre-service à l'aide des API d'inférence SageMaker - Si votre flux de travail de déploiement utilise déjà des API de création/mise à jour/suppression de point de terminaison, vous pouvez continuer à les utiliser pour gérer les variantes Shadow.

Dans les sections suivantes, nous passons en revue chacun de ces scénarios.

Scénario 1 – Tests fantômes gérés à l'aide de la console SageMaker

Si vous souhaitez choisir SageMaker pour gérer le workflow de bout en bout de création, de gestion et d'action sur les résultats des tests fantômes, envisagez d'utiliser la capacité des tests fantômes dans la section Inférence de la console SageMaker. Comme indiqué précédemment, cela vous permet de configurer des tests fantômes pour une durée prédéfinie, de surveiller la progression via un tableau de bord en direct, de présenter des options de nettoyage à la fin et d'agir sur les résultats. Pour en savoir plus, veuillez visiter les tests d'ombre de notre documentation pour une présentation pas à pas de cette fonctionnalité.

Conditions préalables

Les modèles de production et d'ombre doivent être créés sur SageMaker. Veuillez vous référer au CreateModel API ici.

Étape 1 - Créer un test fantôme

Accédez à la Inférence section du panneau de navigation de gauche de la console SageMaker, puis choisissez Tests fantômes. Cela vous amènera à un tableau de bord avec tous les tests fantômes planifiés, en cours et terminés. Cliquez sur 'créer un test fantôme'. Entrez un nom pour le test et choisissez suivant.

Cela vous mènera à la page des paramètres de test de l'ombre. Vous pouvez choisir un rôle IAM existant ou en créer un avec le AmazonSageMakerFullAccess Stratégie IAM jointe. Ensuite, choisissez 'Créer un nouveau point de terminaison' et entrez un nom (xgb-prod-shadow-1). Vous pouvez ajouter une variante de production et une variante shadow associées à ce point de terminaison en cliquant sur 'Ajouter' dans la section Variantes. Vous pouvez sélectionner les modèles que vous avez créés dans le 'Ajouter un modèle' boite de dialogue. Cela crée une production ou une variante. Si vous le souhaitez, vous pouvez modifier le type d'instance et le nombre associés à chaque variante.

Tout le trafic est dirigé vers la variante de production et celle-ci répond aux demandes d'invocation. Vous pouvez contrôler une partie des requêtes acheminées vers la variante shadow en modifiant le Traffic Sampling Percentage.

Vous pouvez contrôler la durée du test d'une heure à 30 jours. S'il n'est pas spécifié, la valeur par défaut est de 7 jours. Après cette période, le test est marqué comme terminé. Si vous exécutez un test sur un point de terminaison existant, il sera restauré à l'état précédant le démarrage du test une fois terminé.

Vous pouvez éventuellement capturer les demandes et les réponses de la variante Shadow à l'aide de la Capture de données options. Si elles ne sont pas spécifiées, les réponses de la variante fantôme sont rejetées.

Étape 2 - Surveiller un test fantôme

Vous pouvez afficher la liste des tests fantômes en accédant à la Shadow Tests section sous Inférence. Cliquez sur le test fantôme créé à l'étape précédente pour afficher les détails d'un test fantôme et le surveiller pendant qu'il est en cours ou après qu'il est terminé.

La section Métriques fournit une comparaison des métriques clés et fournit des graphiques superposés entre les variantes de production et fictives, ainsi que des statistiques descriptives. Vous pouvez comparer les métriques d'appel telles que ModelLatency et les Invocation4xxErrors ainsi que des métriques d'instance telles que CPUUtilization et les DiskUtilization.

Étape 3 - Promouvoir la variante Shadow vers la nouvelle variante de production

Lors de la comparaison, vous pouvez soit choisir de promouvoir la variante fantôme en tant que nouvelle variante de production, soit supprimer la variante fantôme. Pour ces deux options, sélectionnez 'Marquer comme terminé' en haut de la page. Cela vous présente une option pour promouvoir ou supprimer la variante d'ombre.

Si vous choisissez de promouvoir, vous serez redirigé vers une page de déploiement, où vous pourrez confirmer les paramètres de la variante avant le déploiement. Avant le déploiement, nous vous recommandons de dimensionner vos variantes shadow pour pouvoir gérer 100 % du trafic d'appel. Si vous n'utilisez pas de test fantôme pour évaluer d'autres types ou tailles d'instances, vous pouvez utiliser le choix 'conserver les paramètres de variante de production. Sinon, vous pouvez choisir de 'conserver les paramètres de variante d'ombre. Si vous choisissez cette option, assurez-vous que votre échantillonnage du trafic est défini sur 100 %. Vous pouvez également spécifier le type et le nombre d'instances si vous souhaitez remplacer ces paramètres.

Une fois que vous avez confirmé le déploiement, SageMaker lancera une mise à jour de votre point de terminaison pour promouvoir la variante shadow vers la nouvelle variante de production. Comme pour toutes les mises à jour de SageMaker, votre point de terminaison sera toujours opérationnel pendant la mise à jour.

Scénario 2 : test parallèle à l'aide des API d'inférence SageMaker

Cette section explique comment utiliser les API de création/mise à jour/suppression de point de terminaison SageMaker existantes pour déployer des variantes fantômes.

Pour cet exemple, nous avons deux modèles XGBoost qui représentent deux versions différentes des modèles qui ont été pré-formés. model.tar.gz est le modèle actuellement déployé en production. model2 est le modèle le plus récent, et nous souhaitons tester ses performances en termes de mesures opérationnelles telles que la latence avant de décider de l'utiliser en production. Nous déployons model2 comme une variante ombrée de model.tar.gz. Les deux modèles pré-formés sont stockés dans le compartiment S3 public s3://sagemaker-sample-files. Nous téléchargeons d'abord le modèle de notre instance de calcul locale, puis nous le téléchargeons sur S3.

Les modèles de cet exemple sont utilisés pour prédire la probabilité qu'un client mobile quitte son opérateur mobile actuel. L'ensemble de données que nous utilisons est accessible au public et a été mentionné dans le livre Découvrir les connaissances dans les données par Daniel T. Larose. Ces modèles ont été entraînés à l'aide de Cahier de prédiction de désabonnement XGB dans Sage Maker. Vous pouvez également utiliser vos propres modèles pré-formés, auquel cas vous pouvez ignorer le téléchargement à partir de s3://sagemaker-sample-files et copiez vos propres modèles directement dans le dossier model/.

!aws s3 cp s3://sagemaker-sample-files/models/xgb-churn/xgb-churn-prediction-model.tar.gz model/
!aws s3 cp s3://sagemaker-sample-files/models/xgb-churn/xgb-churn-prediction-model2.tar.gz model/

Étape 1 - Créer des modèles

Nous téléchargeons les fichiers de modèle dans notre propre compartiment S3 et créons deux modèles SageMaker. Voir le code suivant :

model_url = S3Uploader.upload(
    local_path="model/xgb-churn-prediction-model.tar.gz",
    desired_s3_uri=f"s3://{bucket}/{prefix}",
)
model_url2 = S3Uploader.upload(
    local_path="model/xgb-churn-prediction-model2.tar.gz",
    desired_s3_uri=f"s3://{bucket}/{prefix}",
from sagemaker import image_uris
image_uri = image_uris.retrieve("xgboost", boto3.Session().region_name, "0.90-1")
image_uri2 = image_uris.retrieve("xgboost", boto3.Session().region_name, "0.90-2")

model_name = f"DEMO-xgb-churn-pred-{datetime.now():%Y-%m-%d-%H-%M-%S}"
model_name2 = f"DEMO-xgb-churn-pred2-{datetime.now():%Y-%m-%d-%H-%M-%S}"

resp = sm.create_model(
    ModelName=model_name,
    ExecutionRoleArn=role,
    Containers=[{"Image": image_uri, "ModelDataUrl": model_url}],
)

resp = sm.create_model(
    ModelName=model_name2,
    ExecutionRoleArn=role,
    Containers=[{"Image": image_uri2, "ModelDataUrl": model_url2}],
)

Étape 2 - Déployer les deux modèles en tant que variantes de production et d'ombre sur un point de terminaison d'inférence en temps réel

Nous créons une configuration de point de terminaison avec les variantes production et shadow. La ProductionVariants et les ShadowProductionVariants présentent un intérêt particulier. Ces deux variantes ont des instances ml.m5.xlarge avec 4 processeurs virtuels et 16 Gio de mémoire, et le nombre d'instances initial est défini sur 1. Consultez le code suivant :

ep_config_name = f"Shadow-EpConfig-{datetime.now():%Y-%m-%d-%H-%M-%S}"
production_variant_name = "production"
shadow_variant_name = "shadow"
create_endpoint_config_response = sm.create_endpoint_config(
    EndpointConfigName=ep_config_name,
    ProductionVariants=[
    # Type: Array of ProductionVariant (https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ProductionVariant.html) objects
      { 
         "VariantName": shadow_variant_name,
        {
            "VariantName": production_variant_name,
            "ModelName": model_name,
            "InstanceType": "ml.m5.xlarge",
            "InitialInstanceCount": 2,
            "InitialVariantWeight": 1,
        }
    ],
     # Type: Array of ShadowProductionVariants 
    ShadowProductionVariants = [
         "ModelName": model_name2,
         "InitialInstanceCount": 1,
         "InitialVariantWeight": 0.5,
         "InstanceType": "ml.m5.xlarge" 
      }
   ]
)

Enfin, nous créons la variante de production et d'ombre :

endpoint_name = f"xgb-prod-shadow-{datetime.now():%Y-%m-%d-%H-%M-%S}"
create_endpoint_api_response = sm.create_endpoint(
                                    EndpointName=endpoint_name,
                                    EndpointConfigName=ep_config_name,
                                )

Étape 3 - Appeler le point de terminaison pour le test

Une fois le point de terminaison créé avec succès, vous pouvez commencer à l'appeler. Nous envoyons environ 3,000 XNUMX demandes de manière séquentielle :

def invoke_endpoint(endpoint_name, wait_interval_sec=0.01, should_raise_exp=False):
    with open("test_data/test-dataset-input-cols.csv", "r") as f:
        for row in f:
            payload = row.rstrip("n")
            try:
                for i in range(10): #send the same payload 10 times for testing purpose
                    response = sm_runtime.invoke_endpoint(
                        EndpointName=endpoint_name, ContentType="text/csv", Body=payload
                    )
            except Exception as e:
                print("E", end="", flush=True)
                if should_raise_exp:
                    raise e

invoke_endpoint(endpoint_name)

Étape 4 – Comparer les métriques

Maintenant que nous avons déployé les modèles de production et fantôme, comparons les métriques d'appel. Pour obtenir une liste des métriques d'appel disponibles à des fins de comparaison, reportez-vous à Surveillez Amazon SageMaker avec Amazon CloudWatch. Commençons par comparer les invocations entre les variantes production et shadow.

Le InvocationsPerInstance La métrique fait référence au nombre d'invocations envoyées à la variante de production. Une fraction de ces invocations, spécifiée dans le poids de la variante, est envoyée à la variante shadow. L'invocation par instance est calculée en divisant le nombre total d'invocations par le nombre d'instances dans une variante. Comme indiqué dans les graphiques suivants, nous pouvons confirmer que les variantes de production et shadow reçoivent des demandes d'appel en fonction des pondérations spécifiées dans la configuration du point de terminaison.

Ensuite, comparons la latence du modèle (ModelLatency métrique) entre les variantes production et shadow. La latence du modèle est le temps mis par un modèle pour répondre tel qu'il est vu depuis SageMaker. Nous pouvons observer comment la latence du modèle de la variante fantôme se compare à la variante de production sans exposer les utilisateurs finaux à la variante fantôme.

Nous nous attendons à la latence de surcharge (OverheadLatency metric) pour être comparables entre les variantes de production et shadow. La latence supplémentaire est l'intervalle mesuré entre le moment où SageMaker reçoit la demande et celui où il renvoie une réponse au client, moins la latence du modèle.

Étape 5- Faites la promotion de votre variante d'ombre

Pour promouvoir le modèle fantôme en production, créez une nouvelle configuration de point de terminaison avec ShadowProductionVariant comme le nouveau ProductionVariant et retirez le ShadowProductionVariant. Cela supprimera le courant ProductionVariant et promouvoir la variante fantôme pour qu'elle devienne la nouvelle variante de production. Comme toujours, toutes les mises à jour de SageMaker sont orchestrées sous forme de déploiements bleu/vert sous le capot, et il n'y a aucune perte de disponibilité lors de l'exécution de la mise à jour.

En option, vous pouvez tirer parti Garde-corps de déploiement si vous souhaitez utiliser le transfert de trafic et les annulations automatiques en une seule fois lors de votre mise à jour.

promote_ep_config_name = f"PromoteShadow-EpConfig-{datetime.now():%Y-%m-%d-%H-%M-%S}"

create_endpoint_config_response = sm.create_endpoint_config(
    EndpointConfigName=promote_ep_config_name,
    ProductionVariants=[
        {
            "VariantName": shadow_variant_name,
            "ModelName": model_name2,
            "InstanceType": "ml.m5.xlarge",
            "InitialInstanceCount": 2,
            "InitialVariantWeight": 1.0,
        }
    ],
)
print(f"Created EndpointConfig: {create_endpoint_config_response['EndpointConfigArn']}")

update_endpoint_api_response = sm.update_endpoint(
    EndpointName=endpoint_name,
    EndpointConfigName=promote_ep_config_name,
)

wait_for_endpoint_in_service(endpoint_name)

sm.describe_endpoint(EndpointName=endpoint_name)

Étape 6 - Nettoyer

Si vous ne prévoyez pas d'utiliser davantage ce point de terminaison, vous devez supprimer le point de terminaison pour éviter d'encourir des frais supplémentaires et nettoyer les autres ressources créées dans ce blog.

dsm.delete_endpoint(EndpointName=endpoint_name)
sm.delete_endpoint_config(EndpointConfigName=ep_config_name)
sm.delete_endpoint_config(EndpointConfigName=promote_ep_config_name)
sm.delete_model(ModelName=model_name)
sm.delete_model(ModelName=model_name2)

Conclusion

Dans cet article, nous avons introduit une nouvelle capacité d'inférence SageMaker pour comparer les performances de la nouvelle version d'une pile de service de modèle avec la version actuellement déployée avant un déploiement de production complet à l'aide d'une pratique de sécurité de déploiement connue sous le nom de test fantôme. Nous vous avons présenté les avantages de l'utilisation de variantes masquées et de méthodes pour configurer les variantes avec un exemple de bout en bout. Pour en savoir plus sur les variantes d'ombre, reportez-vous aux tests d'ombre Documentation.

À propos des auteurs

Raghu Ramesha est un architecte de solutions d'apprentissage automatique au sein de l'équipe Amazon SageMaker Service. Il se concentre sur l'aide aux clients pour créer, déployer et migrer les charges de travail de production ML vers SageMaker à grande échelle. Il est spécialisé dans les domaines de l'apprentissage automatique, de l'IA et de la vision par ordinateur, et est titulaire d'une maîtrise en informatique de l'UT Dallas. Dans ses temps libres, il aime voyager et photographier.

Qingwei Li est un spécialiste de l'apprentissage automatique chez Amazon Web Services. Il a obtenu son doctorat. en recherche opérationnelle après avoir cassé le compte de subvention de recherche de son conseiller et échoué à décerner le prix Nobel qu'il avait promis. Actuellement, il aide les clients du secteur des services financiers et de l'assurance à créer des solutions d'apprentissage automatique sur AWS. Dans ses temps libres, il aime lire et enseigner.

Qi Yun Zhao est ingénieur principal en développement logiciel au sein de l'équipe de la plate-forme d'inférence Amazon SageMaker. Il est le développeur principal des garde-corps de déploiement et des déploiements fantômes, et il se concentre sur l'aide aux clients pour gérer les charges de travail et les déploiements ML à grande échelle avec une haute disponibilité. Il travaille également sur les évolutions de l'architecture de la plate-forme pour un déploiement rapide et sécurisé des tâches de ML et l'exécution d'expériences en ligne de ML en toute simplicité. Dans ses temps libres, il aime lire, jouer et voyager.

Tarun Saïram est chef de produit senior pour Amazon SageMaker Inference. Il souhaite en savoir plus sur les dernières tendances en matière d'apprentissage automatique et aider les clients à les exploiter. Dans ses temps libres, il aime faire du vélo, du ski et jouer au tennis.