Analysez les dépenses d'Amazon SageMaker et déterminez les opportunités d'optimisation des coûts en fonction de l'utilisation, partie 3 : tâches de traitement et de Data Wrangler

Republié par Platon

Suiveurs: 0

En 2021, nous avons lancé Services proactifs d'assistance AWS dans le cadre de la Prise en charge des entreprises AWS plan. Depuis son introduction, nous avons aidé des centaines de clients à optimiser leurs charges de travail, à définir des garde-fous et à améliorer la visibilité du coût et de l'utilisation de leurs charges de travail de machine learning (ML).

Dans cette série d'articles, nous partageons les leçons apprises sur l'optimisation des coûts dans Amazon Sage Maker. Dans cet article, nous nous concentrons sur le prétraitement des données à l'aide de Traitement d'Amazon SageMaker et les Gestionnaire de données Amazon SageMaker emplois.

Le prétraitement des données joue un rôle central dans une approche d'IA centrée sur les données. Cependant, la préparation de données brutes pour la formation et l'évaluation du ML est souvent une tâche fastidieuse et exigeante en termes de ressources de calcul, de temps et d'effort humain. La préparation des données doit généralement être intégrée à partir de différentes sources et traiter les valeurs manquantes ou bruyantes, les valeurs aberrantes, etc.

De plus, en plus des tâches courantes d'extraction, de transformation et de chargement (ETL), les équipes ML ont parfois besoin de fonctionnalités plus avancées, telles que la création de modèles rapides pour évaluer les données et produire des scores d'importance des fonctionnalités ou une évaluation de modèle post-formation dans le cadre d'un pipeline MLOps.

SageMaker propose deux fonctionnalités spécialement conçues pour résoudre ces problèmes : SageMaker Processing et Data Wrangler. SageMaker Processing vous permet d'exécuter facilement le prétraitement, le post-traitement et l'évaluation des modèles sur une infrastructure entièrement gérée. Data Wrangler réduit le temps nécessaire pour agréger et préparer les données en simplifiant le processus d'intégration des sources de données et d'ingénierie des fonctionnalités à l'aide d'une interface visuelle unique et d'un environnement de traitement de données entièrement distribué.

Les deux fonctionnalités de SageMaker offrent une grande flexibilité avec plusieurs options d'E/S, de stockage et de calcul. Cependant, la définition incorrecte de ces options peut entraîner des coûts inutiles, en particulier lorsqu'il s'agit de grands ensembles de données.

Dans cet article, nous analysons les facteurs de tarification et fournissons des conseils d'optimisation des coûts pour les tâches SageMaker Processing et Data Wrangler.

Traitement SageMaker

SageMaker Processing est une solution gérée pour exécuter des charges de travail de traitement de données et d'évaluation de modèles. Vous pouvez l'utiliser dans les étapes de traitement des données telles que l'ingénierie des fonctionnalités, la validation des données, l'évaluation des modèles et l'interprétation des modèles dans les flux de travail ML. Avec SageMaker Processing, vous pouvez apporter vos propres scripts de traitement personnalisés et choisir de créer un conteneur personnalisé ou d'utiliser un conteneur géré SageMaker avec des frameworks communs tels que scikit-learn, Lime, Spark, etc.

SageMaker Processing vous facture pour le type d'instance que vous choisissez, en fonction de la durée d'utilisation et du stockage provisionné qui est attaché à cette instance. Dans la partie 1, nous avons montré comment commencer à utiliser Explorateur de coûts AWS pour identifier les opportunités d'optimisation des coûts dans SageMaker.

Vous pouvez filtrer les coûts de traitement en appliquant un filtre sur le type d'utilisation. Les noms de ces types d'utilisation sont les suivants :

REGION-Processing:instanceType (par exemple, USE1-Processing:ml.m5.large)
REGION-Processing:VolumeUsage.gp2 (par exemple, USE1-Processing:VolumeUsage.gp2)

Pour examiner votre coût de traitement SageMaker dans Cost Explorer, commencez par filtrer avec SageMaker pour Service, Et pour Type d'utilisation, vous pouvez sélectionner toutes les heures d'exécution des instances de traitement en saisissant processing:ml préfixe et en sélectionnant la liste dans le menu.

Éviter les coûts de traitement et de développement du pipeline

Avant de dimensionner correctement et d'optimiser la durée d'exécution d'une tâche de traitement SageMaker, nous vérifions les métriques de haut niveau sur les exécutions de tâches historiques. Vous pouvez choisir entre deux méthodes pour ce faire.

Tout d'abord, vous pouvez accéder à la En cours page sur la console SageMaker.

Alternativement, vous pouvez utiliser le API list_processing_jobs.

L'état d'une tâche de traitement peut être InProgress, Completed, Failed, Stoppingou Stopped.

Un nombre élevé de tâches ayant échoué est courant lors du développement de nouveaux pipelines MLOps. Cependant, vous devez toujours tester et faire tout votre possible pour valider les travaux avant de les lancer sur SageMaker car il y a des frais pour les ressources utilisées. Pour cela, vous pouvez utiliser SageMaker Processing dans mode local. Le mode local est une fonctionnalité du SDK SageMaker qui vous permet de créer des estimateurs, des processeurs et des pipelines, et de les déployer dans votre environnement de développement local. C'est un excellent moyen de tester vos scripts avant de les exécuter dans un environnement géré par SageMaker. Le mode local est pris en charge par les conteneurs gérés SageMaker et ceux que vous fournissez vous-même. Pour en savoir plus sur l'utilisation du mode local avec Pipelines Amazon SageMaker, faire référence à Mode local.

Optimiser les coûts liés aux E/S

Les tâches de traitement SageMaker offrent un accès à trois sources de données dans le cadre du entrée de traitement: Service de stockage simple Amazon (Amazon S3), Amazone Athénaet une Redshift d'Amazon. Pour plus d'informations, reportez-vous à TraitementS3Input, AthenaDatasetDéfinitionet une RedshiftDatasetDefinition, Respectivement.

Avant de se pencher sur l'optimisation, il est important de noter que bien que les tâches de traitement SageMaker prennent en charge ces sources de données, elles ne sont pas obligatoires. Dans votre code de traitement, vous pouvez implémenter n'importe quelle méthode pour télécharger les données d'accès à partir de n'importe quelle source (à condition que l'instance de traitement puisse y accéder).

Pour mieux comprendre les performances de traitement et détecter les opportunités d'optimisation, nous vous recommandons de suivre meilleures pratiques de journalisation dans votre script de traitement. SageMaker publie vos journaux de traitement sur Amazon Cloud Watch.

Dans l'exemple de journal de travail suivant, nous voyons que le traitement du script a pris 15 minutes (entre Start custom script et les End custom script).

Cependant, sur la console SageMaker, nous constatons que la tâche a pris 4 minutes supplémentaires (près de 25 % du temps d'exécution total de la tâche).

Cela est dû au fait qu'en plus du temps que notre script de traitement a pris, le téléchargement et le téléchargement des données gérées par SageMaker ont également pris du temps (4 minutes). Si cela s'avère être une grande partie du coût, envisagez d'autres moyens d'accélérer le temps de téléchargement, comme l'utilisation de l'API Boto3 avec multitraitement pour télécharger des fichiers simultanément, ou l'utilisation de bibliothèques tierces comme WebDataset ou s5cmd pour un téléchargement plus rapide depuis Amazon S3. . Pour plus d'informations, reportez-vous à Paralléliser les charges de travail S3 avec s5cmd. Notez que ces méthodes peuvent introduire des frais dans Amazon S3 en raison de transfert de données.

Les tâches de traitement prennent également en charge Mode tuyau. Avec cette méthode, SageMaker diffuse les données d'entrée de la source directement vers votre conteneur de traitement dans des canaux nommés sans utiliser le volume de stockage ML, éliminant ainsi le temps de téléchargement des données et un volume de disque plus petit. Cependant, cela nécessite un modèle de programmation plus compliqué que la simple lecture de fichiers sur un disque.

Comme mentionné précédemment, SageMaker Processing prend également en charge Athena et Amazon Redshift en tant que sources de données. Lors de la configuration d'une tâche de traitement avec ces sources, SageMaker copie automatiquement les données vers Amazon S3, et l'instance de traitement récupère les données à partir de l'emplacement Amazon S3. Cependant, lorsque le travail est terminé, il n'y a pas de processus de nettoyage géré et les données copiées resteront toujours dans Amazon S3 et pourraient entraîner des frais de stockage indésirables. Par conséquent, lorsque vous utilisez des sources de données Athena et Amazon Redshift, veillez à implémenter une procédure de nettoyage, telle qu'une fonction Lambda qui fonctionne selon un horaire ou en Étape lambda dans le cadre d'un pipeline SageMaker.

Comme le téléchargement, le téléchargement d'artefacts de traitement peut également être une opportunité d'optimisation. Lorsque la sortie d'une tâche de traitement est configurée à l'aide de la ProcessingS3Output paramètre, vous pouvez spécifier quel S3UploadMode utiliser. le S3UploadMode la valeur par défaut du paramètre est EndOfJob, ce qui obligera SageMaker à télécharger les résultats une fois la tâche terminée. Toutefois, si votre tâche de traitement produit plusieurs fichiers, vous pouvez définir S3UploadMode à Continuous, permettant ainsi le téléchargement d'artefacts simultanément au fur et à mesure que le traitement se poursuit et réduisant la durée d'exécution de la tâche.

Instances de travail de traitement de la bonne taille

Le choix du type et de la taille d'instance appropriés est un facteur majeur dans l'optimisation du coût des tâches de traitement SageMaker. Vous pouvez redimensionner une instance en migrant vers une version différente au sein de la même famille d'instances ou en migrant vers une autre famille d'instances. Lors de la migration au sein de la même famille d'instances, il vous suffit de prendre en compte le CPU/GPU et la mémoire. Pour plus d'informations et des conseils généraux sur le choix des bonnes ressources de traitement, reportez-vous à Assurez des ressources de calcul efficaces sur Amazon SageMaker.

Pour affiner la sélection des instances, nous commençons par analyser les métriques de la tâche de traitement dans CloudWatch. Pour plus d'informations, reportez-vous à Surveillez Amazon SageMaker avec Amazon CloudWatch.

CloudWatch collecte les données brutes de SageMaker et les transforme en métriques lisibles en temps quasi réel. Bien que ces statistiques soient conservées pendant 15 mois, la console CloudWatch limite la recherche aux métriques qui ont été mises à jour au cours des 2 dernières semaines (cela garantit que seules les tâches en cours sont affichées). Les métriques des tâches de traitement se trouvent dans l'espace de noms /aws/sagemaker/ProcessingJobs et les métriques collectées sont CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilizationet une DiskUtilization.

La capture d'écran suivante montre un exemple dans CloudWatch du travail de traitement que nous avons vu précédemment.

Dans cet exemple, nous voyons les valeurs moyennes du processeur et de la mémoire (qui est la valeur par défaut dans CloudWatch) : l'utilisation moyenne du processeur est de 0.04 %, la mémoire de 1.84 % et l'utilisation du disque de 13.7 %. Afin de dimensionner correctement, tenez toujours compte de l'utilisation maximale du processeur et de la mémoire (dans cet exemple, l'utilisation maximale du processeur était de 98 % au cours des 3 premières minutes). En règle générale, si votre utilisation maximale du processeur et de la mémoire est constamment inférieure à 40 %, vous pouvez réduire de moitié la machine en toute sécurité. Par exemple, si vous utilisiez une instance ml.c5.4xlarge, vous pourriez passer à une instance ml.c5.2xlarge, ce qui pourrait réduire vos coûts de 50 %.

Emplois Data Wrangler

Data Wrangler est une fonctionnalité de Amazon SageMakerStudio qui fournit une solution reproductible et évolutive pour l'exploration et le traitement des données. Vous utilisez l'interface Data Wrangler pour importer, analyser, transformer et caractériser de manière interactive vos données. Ces étapes sont capturées dans une recette (un fichier .flow) que vous pouvez ensuite utiliser dans une tâche Data Wrangler. Cela vous aide à réappliquer les mêmes transformations de données sur vos données et également à évoluer vers un travail de traitement de données par lots distribué, soit dans le cadre d'un pipeline ML, soit indépendamment.

Pour obtenir des conseils sur l'optimisation de votre application Data Wrangler dans Studio, reportez-vous à la partie 2 de cette série.

Dans cette section, nous nous concentrons sur l'optimisation des tâches Data Wrangler.

Data Wrangler utilise Tâches de traitement SageMaker Spark avec un conteneur géré par Data Wrangler. Ce conteneur exécute les instructions à partir du fichier .flow dans le travail. Comme toutes les tâches de traitement, Data Wrangler vous facture les instances que vous choisissez, en fonction de la durée d'utilisation et du stockage provisionné qui est attaché à cette instance.

Dans Cost Explorer, vous pouvez filtrer les coûts des tâches Data Wrangler en appliquant un filtre sur le type d'utilisation. Les noms de ces types d'utilisation sont :

REGION-processing_DW:instanceType (par exemple, USE1-processing_DW:ml.m5.large)
REGION-processing_DW:VolumeUsage.gp2 (par exemple, USE1-processing_DW:VolumeUsage.gp2)

Pour afficher votre coût Data Wrangler dans Cost Explorer, filtrez le service pour utiliser SageMaker, et pour Type d'utilisation, choisir la processing_DW préfixe et sélectionnez la liste dans le menu. Cela vous montrera à la fois les coûts liés à l'utilisation de l'instance (heures) et au volume de stockage (Go). (Si vous voulez voir les coûts de Studio Data Wrangler, vous pouvez filtrer le type d'utilisation par le Studio_DW préfixe.)

Dimensionnez et planifiez correctement les instances de tâche Data Wrangler

Pour le moment, Data Wrangler ne prend en charge que les instances m5 avec les tailles d'instance suivantes : ml.m5.4xlarge, ml.m5.12xlarge et ml.m5.24xlarge. Vous pouvez utiliser la fonction de travail distribué pour affiner le coût de votre travail. Par exemple, supposons que vous deviez traiter un jeu de données nécessitant 350 Gio de RAM. Le 4xlarge (128 Gio) et le 12xlarge (256 Gio) peuvent ne pas être en mesure de traiter et vous conduiront à utiliser l'instance m5.24xlarge (768 Gio). Cependant, vous pouvez utiliser deux instances m5.12xlarge (2 * 256 Gio = 512 Gio) et réduire le coût de 40 % ou trois instances m5.4xlarge (3 * 128 Gio = 384 Gio) et économiser 50 % du m5.24xlarge coût de l'instance. Vous devez noter qu'il s'agit d'estimations et que le traitement distribué peut introduire une surcharge qui affectera le temps d'exécution global.

Lorsque vous modifiez le type d'instance, assurez-vous de mettre à jour le Configuration Spark par conséquent. Par exemple, si vous avez une première tâche d'instance ml.m5.4xlarge configurée avec des propriétés spark.driver.memory réglé sur 2048 et spark.executor.memory défini sur 55742, puis mis à l'échelle jusqu'à ml.m5.12xlarge, ces valeurs de configuration doivent être augmentées, sinon elles constitueront le goulot d'étranglement de la tâche de traitement. Vous pouvez mettre à jour ces variables dans l'interface graphique de Data Wrangler ou dans un fichier de configuration ajouté au chemin de configuration (voir les exemples suivants).

Une autre caractéristique intéressante de Data Wrangler est la possibilité de définir une tâche planifiée. Si vous traitez des données périodiquement, vous pouvez créer une planification pour exécuter automatiquement la tâche de traitement. Par exemple, vous pouvez créer une planification qui exécute automatiquement une tâche de traitement lorsque vous obtenez de nouvelles données (pour des exemples, voir Exporter vers Amazon S3 or Exporter vers Amazon SageMaker Feature Store). Cependant, vous devez noter que lorsque vous créez une planification, Data Wrangler crée une eventRule dans Event Bridge. Cela signifie que vous êtes également facturé pour les règles d'événement que vous créez (ainsi que les instances utilisées pour exécuter la tâche de traitement). Pour plus d'informations, voir Tarifs Amazon EventBridge.

Conclusion

Dans cet article, nous avons fourni des conseils sur l'analyse des coûts et les meilleures pratiques lors du prétraitement

données à l'aide des tâches SageMaker Processing et Data Wrangler. Comme pour le prétraitement, il existe de nombreuses options et paramètres de configuration dans la création, la formation et l'exécution de modèles ML qui peuvent entraîner des coûts inutiles. Par conséquent, alors que l'apprentissage automatique s'impose comme un outil puissant dans tous les secteurs, les charges de travail ML doivent rester rentables.

SageMaker offre un ensemble de fonctionnalités large et approfondi pour faciliter chaque étape du pipeline ML.

Cette robustesse offre également des opportunités d'optimisation continue des coûts sans compromettre les performances ou l'agilité.

À propos des auteurs

Analysez les dépenses Amazon SageMaker et déterminez les opportunités d'optimisation des coûts en fonction de l'utilisation, Partie 3 : tâches de traitement et de Data Wrangler | Amazon Web Services PlatoBlockchain Data Intelligence. Recherche verticale. Aï. Deepali Rajale est spécialiste senior IA/ML chez AWS. Elle travaille avec des entreprises clientes en fournissant des conseils techniques sur les meilleures pratiques pour le déploiement et la maintenance des solutions AI/ML dans l'écosystème AWS. Elle a travaillé avec un large éventail d'organisations sur divers cas d'utilisation d'apprentissage en profondeur impliquant la PNL et la vision par ordinateur. Elle se passionne pour donner aux organisations les moyens de tirer parti de l'IA générative pour améliorer leur expérience d'utilisation. Dans ses temps libres, elle aime les films, la musique et la littérature.

Uri Rosenberg est le responsable technique spécialisé en IA et ML pour l'Europe, le Moyen-Orient et l'Afrique. Basé en Israël, Uri s'efforce d'autonomiser les entreprises clientes sur tout ce qui concerne le ML pour concevoir, construire et exploiter à grande échelle. Dans ses temps libres, il aime faire du vélo, de la randonnée et regarder les couchers de soleil (au moins une fois par jour).