Créez des workflows de machine learning de bout en bout reproductibles, sécurisés et extensibles à l'aide de Kubeflow sur AWS

Ceci est un article de blog invité coécrit avec athenahealth.

athenahealth un fournisseur leader de logiciels et de services réseau pour les groupes médicaux et les systèmes de santé à l'échelle nationale. Ses dossiers de santé électroniques, sa gestion du cycle de revenus et ses outils d'engagement des patients permettent un accès à tout moment et en tout lieu, ce qui améliore les résultats financiers de ses clients et permet à ses clients fournisseurs de fournir des soins de meilleure qualité.

Dans le domaine de l'intelligence artificielle (IA), athenahealth utilise la science des données et l'apprentissage automatique (ML) pour accélérer les processus métier et fournir des recommandations, des prédictions et des informations sur plusieurs services. Depuis sa première implémentation dans des services de documents automatisés, traitant sans contact des millions de documents fournisseur-patient, jusqu'à ses travaux plus récents sur les assistants virtuels et l'amélioration des performances du cycle de revenus, athenahealth continue d'appliquer l'IA pour aider à accroître l'efficacité, les capacités de service et de meilleurs résultats pour les fournisseurs. et leurs malades.

Ce billet de blog montre comment athenahealth utilise Kubeflow sur AWS (une distribution de Kubeflow spécifique à AWS) pour créer et rationaliser un workflow de science des données de bout en bout qui préserve les outils essentiels, optimise l'efficacité opérationnelle, augmente la productivité des scientifiques des données et prépare le terrain pour étendre plus facilement leurs capacités de ML.

Kubeflow est la plate-forme ML open source dédiée à rendre les déploiements de flux de travail ML sur Kubernetes simples, portables et évolutifs. Kubeflow y parvient en incorporant des outils open source pertinents qui s'intègrent bien à Kubernetes. Certains de ces projets incluent Argo pour l'orchestration de pipeline, Istio pour le maillage de services, Jupyter pour les ordinateurs portables, Spark, TensorBoard et Katib. Kubeflow Pipelines permet de créer et de déployer des flux de travail ML portables et évolutifs pouvant inclure des étapes telles que l'extraction de données, le prétraitement, la formation de modèles et l'évaluation de modèles sous la forme de pipelines reproductibles.

AWS contribue à la communauté open source Kubeflow en fournissant sa propre distribution Kubeflow (appelée Kubeflow sur AWS) qui aide des organisations comme athenahealth à créer des flux de travail ML hautement fiables, sécurisés, portables et évolutifs avec des frais généraux opérationnels réduits grâce à l'intégration avec les services gérés AWS. AWS fournit diverses options de déploiement Kubeflow telles que le déploiement avec Amazon Cognito, déploiement avec Service de base de données relationnelle Amazon (Amazon RDS) et Service de stockage simple Amazon (Amazon S3) et déploiement vanille. Pour plus de détails sur l'intégration des services et les modules complémentaires disponibles pour chacune de ces options, reportez-vous à Déploiement.

Aujourd'hui, Kubeflow sur AWS fournit un chemin clair vers l'utilisation de Kubeflow, complété par les services AWS suivants :

De nombreux clients AWS profitent de la distribution Kubeflow sur AWS, y compris athenahealth.

Ici, l'équipe athenahealth MLOps discute des défis qu'ils ont rencontrés et des solutions qu'ils ont créées dans leur parcours Kubeflow.

Défis avec l'environnement ML précédent

Avant notre adoption de Kubeflow sur AWS, nos scientifiques des données utilisaient un ensemble d'outils standardisés et un processus qui permettait une flexibilité dans la technologie et le flux de travail utilisés pour former un modèle donné. Des exemples de composants de l'outillage standardisé incluent une API d'ingestion de données, des outils d'analyse de sécurité, le pipeline CI/CD construit et maintenu par une autre équipe au sein d'athenahealth, et une plate-forme de service commune construite et maintenue par l'équipe MLOps. Cependant, à mesure que notre utilisation de l'IA et du ML a mûri, la variété d'outils et d'infrastructures créés pour chaque modèle a augmenté. Bien que nous soyons toujours en mesure de soutenir le processus existant, nous avons vu les défis suivants se profiler à l'horizon :

• Entretien et croissance – La reproduction et la maintenance des environnements de formation de modèles ont demandé plus d'efforts à mesure que le nombre de modèles déployés augmentait. Chaque projet a conservé une documentation détaillée décrivant comment chaque script a été utilisé pour créer le modèle final. Dans de nombreux cas, il s'agissait d'un processus élaboré impliquant 5 à 10 scripts avec plusieurs sorties chacun. Celles-ci devaient être suivies manuellement avec des instructions détaillées sur la manière dont chaque sortie serait utilisée dans les processus ultérieurs. Maintenir cela dans le temps devenait fastidieux. De plus, à mesure que les projets devenaient plus complexes, le nombre d'outils augmentait également. Par exemple, la plupart des modèles utilisaient Spark et TensorFlow avec des GPU, ce qui nécessitait une plus grande variété de configurations d'environnement. Au fil du temps, les utilisateurs passaient à de nouvelles versions d'outils dans leurs environnements de développement, mais ne pouvaient pas exécuter d'anciens scripts lorsque ces versions devenaient incompatibles. Par conséquent, la maintenance et l'extension de projets plus anciens nécessitaient plus de temps et d'efforts d'ingénierie. De plus, à mesure que de nouveaux scientifiques des données rejoignaient l'équipe, les transferts de connaissances et l'intégration prenaient plus de temps, car la synchronisation des environnements locaux incluait de nombreuses dépendances non documentées. Le passage d'un projet à l'autre rencontrait les mêmes problèmes car chaque modèle avait ses propres flux de travail.
• Sécurité – Nous prenons la sécurité au sérieux et accordons donc la priorité au respect de toutes les obligations contractuelles, légales et réglementaires associées au ML et à la science des données. Les données doivent être utilisées, stockées et accessibles de manière spécifique, et nous avons intégré des processus robustes pour garantir que nos pratiques sont conformes à nos obligations légales et conformes aux meilleures pratiques du secteur. Avant l'adoption de Kubeflow, s'assurer que les données étaient stockées et accessibles d'une manière spécifique impliquait une vérification régulière sur plusieurs flux de travail divers. Nous savions que nous pouvions améliorer l'efficacité en consolidant ces divers flux de travail sur une seule plate-forme. Cependant, cette plate-forme devrait être suffisamment flexible pour bien s'intégrer à nos outils standardisés.
• Opérations – Nous avons également vu une opportunité d'augmenter l'efficacité opérationnelle et la gestion en centralisant la journalisation et la surveillance des flux de travail. Étant donné que chaque équipe avait développé ses propres outils, nous avons collecté ces informations de chaque flux de travail individuellement et les avons agrégées.

L'équipe de science des données a évalué diverses solutions pour consolider les flux de travail. En plus de répondre à ces exigences, nous avons recherché une solution qui s'intégrerait de manière transparente à l'infrastructure et aux outils standardisés existants. Nous avons sélectionné Amazon EKS et Kubeflow sur AWS comme solution de flux de travail.

Le cycle de développement des data scientists intégrant Kubeflow

Un projet de science des données commence par une table rase : pas de données, pas de code, uniquement le problème métier qui peut être résolu avec le ML. La première tâche est une preuve de concept (POC) pour découvrir si les données contiennent suffisamment de signaux pour rendre un modèle ML efficace pour résoudre le problème commercial, en commençant par interroger l'ensemble de données brutes de notre entrepôt de données Snowflake. Cette étape est itérative et les data scientists utilisent des pods Kubernetes ou des notebooks Kubeflow Jupyter au cours de ce processus.

Notre cluster Kubeflow utilise l'autoscaler de cluster Karpenter, ce qui facilite la rotation des ressources pour les scientifiques des données, car ils n'ont qu'à se concentrer sur la définition des types d'instances souhaités, tandis que le travail de provisionnement est effectué par un ensemble de provisionneurs Karpenter prédéfinis. Nous avons des provisionneurs distincts pour les types d'instance CPU et GPU, et toutes les instances prises en charge par Amazon EKS appartiennent à l'une de ces deux catégories selon notre configuration de provisionneur. Les data scientists choisissent les types d'instances à l'aide de sélecteurs de nœuds, et Karpenter s'occupe de la gestion du cycle de vie des nœuds.

Une fois la requête développée, les scientifiques des données extraient les données brutes vers un emplacement sur Amazon S3, puis lancent un bloc-notes Jupyter à partir de l'interface utilisateur AWS Kubeflow pour explorer les données. L'objectif est de créer l'ensemble de fonctionnalités qui sera utilisé pour former le premier modèle. Cela permet aux scientifiques des données de déterminer s'il y a suffisamment de signal dans les données pour répondre aux besoins commerciaux du client.

Une fois les résultats satisfaisants, les data scientists passent à l'étape suivante du cycle de développement et transforment leurs découvertes en un pipeline robuste. Ils convertissent le code POC en code de qualité production qui s'exécute à grande échelle. Pour garantir la conformité grâce à l'utilisation de bibliothèques approuvées, un conteneur est créé avec l'image Docker de base appropriée. Pour nos scientifiques des données, nous avons constaté que la fourniture d'une image de base Python, TensorFlow et Spark standard offre une flexibilité suffisante pour la plupart, sinon la totalité, des charges de travail. Ils peuvent ensuite utiliser le Dockerfile de leur composant pour personnaliser davantage leur environnement de développement. Ce Dockerfile est ensuite utilisé par le processus CI/CD pour créer l'image des composants qui seront utilisés en production, maintenant ainsi la cohérence entre les environnements de développement et de production.

Nous avons un outil qui donne aux data scientists la possibilité de lancer leur environnement de développement dans un pod fonctionnant sur Kubernetes. Lorsque ce pod est en cours d'exécution, les scientifiques des données peuvent alors attacher l'IDE Visual Studio Code directement au pod et déboguer leur code de modèle. Une fois le code exécuté avec succès, ils peuvent alors envoyer leurs modifications à git et un nouvel environnement de développement est créé avec les modifications les plus récentes.

Le pipeline standard de science des données se compose d'étapes comprenant l'extraction, le prétraitement, la formation et l'évaluation. Chaque étape du pipeline apparaît comme un composant dans Kubeflow, qui consiste en un pod Kubernetes qui exécute une commande avec certaines informations transmises en tant que paramètres. Ces paramètres peuvent être des valeurs statiques ou des références à la sortie d'un composant précédent. L'image Docker utilisée dans le pod est construite à partir du processus CI/CD. Les détails de ce processus apparaissent dans le flux de travail CI/CD abordé dans la section suivante.

Cycle de développement sur Kubeflow. Le workflow de développement commence à gauche avec le POC. Le modèle terminé est déployé sur la plate-forme de service de modèle athenahealth exécutée sur Amazon ECS.

Processus CI/CD prenant en charge les workflows automatisés

Dans le cadre de notre processus CI/CD, nous utilisons Jenkins pour créer et tester toutes les images de composants Kubeflow en parallèle. En cas de réussite, le modèle de composant de pipeline contient des pointeurs de référence vers les images et le pipeline résultant est téléchargé sur Kubeflow. Les paramètres du pipeline Jenkins permettent aux utilisateurs de lancer les pipelines et d'exécuter leurs tests de formation de modèle après des générations réussies.

Alternativement, pour maintenir un cycle de développement court, les scientifiques des données peuvent également lancer le pipeline à partir de leur machine locale, en modifiant tous les paramètres de pipeline qu'ils peuvent expérimenter.

Des outils existent pour s'assurer que les pointeurs de référence de la construction CI/CD sont utilisés par défaut. S'il existe un artefact déployable dans le référentiel, la logique CI/CD continuera à déployer l'artefact sur la plate-forme de service de modèle athenahealth (le service de prédiction) s'exécutant sur Amazon ECS avec AWSFargate. Une fois toutes ces étapes passées, le data scientist fusionne le code avec la branche primaire. Les pipelines et les artefacts déployables sont ensuite mis en production.

Workflow de déploiement CI/CD. Ce diagramme décrit le workflow de génération et de déploiement de Data Science. Le processus CI/CD est piloté par Jenkins.

Sécurité

En consolidant nos workflows de science des données, nous avons pu centraliser notre approche pour sécuriser le pipeline de formation. Dans cette section, nous abordons notre approche de la sécurité des données et des clusters.

Sécurité des données

La sécurité des données est de la plus haute importance chez athenahealth. Pour cette raison, nous développons et maintenons une infrastructure entièrement conforme aux réglementations et normes qui protègent la sécurité et l'intégrité de ces données.

Pour nous assurer que nous respectons les normes de conformité des données, nous fournissons notre infrastructure AWS conformément à nos directives d'entreprise athenahealth. Les deux principaux magasins de données sont Amazon RDS pour les métadonnées de pipeline hautement évolutives et Amazon S3 pour les artefacts de pipeline et de modèle. Pour Amazon S3, nous nous assurons que les compartiments sont chiffrés, que les points de terminaison HTTPS sont appliqués et que les stratégies de compartiment et Gestion des identités et des accès AWS (IAM) les rôles suivent les principes du moindre privilège lorsqu'ils autorisent l'accès aux données. Cela est également vrai pour les données Amazon RDS : le chiffrement est toujours activé, et les groupes de sécurité et l'accès aux informations d'identification suivent le principe du moindre privilège. Cette normalisation garantit que seules les parties autorisées ont accès aux données, et cet accès est suivi.

En plus de ces mesures, la plate-forme est également soumise à des évaluations des menaces de sécurité et à des analyses continues de sécurité et de conformité.

Nous répondons également aux exigences de conservation des données via la gestion du cycle de vie des données pour tous les compartiments S3 contenant des données sensibles. Cette stratégie déplace automatiquement les données vers Glacier Amazon S3 après 30 jours de création. Les exceptions à cette règle sont gérées par le biais de demandes de récupération de données et sont approuvées ou refusées au cas par cas. Cela garantit que tous les workflows sont conformes à la politique de conservation des données. Cela résout également le problème de récupération des données si un modèle fonctionne mal et qu'un recyclage est nécessaire, ou lorsqu'un nouveau modèle doit être évalué par rapport à une itération historique de l'ensemble de données d'un modèle plus ancien.

Pour restreindre l'accès à Amazon S3 et Amazon RDS depuis Kubeflow sur AWS et Amazon EKS, nous utilisons IRSA (Rôles IAM pour les comptes de service), qui fournit un provisionnement d'autorisations basé sur IAM pour les ressources au sein de Kubernetes. Chaque locataire dans Kubeflow dispose d'un compte de service pré-créé unique que nous lions à un rôle IAM créé spécifiquement pour répondre aux exigences d'accès des locataires. L'accès des utilisateurs aux locataires est également limité à l'aide de l'appartenance au groupe de groupes d'utilisateurs Amazon Cognito pour chaque utilisateur. Lorsqu'un utilisateur est authentifié auprès du cluster, le jeton généré contient des revendications de groupe et Kubernetes RBAC utilise ces informations pour autoriser ou refuser l'accès à une ressource particulière du cluster. Cette configuration est expliquée plus en détail dans la section suivante.

Sécurité du cluster à l'aide de l'isolation multi-utilisateur

Comme nous l'avons noté dans la section précédente, les scientifiques des données effectuent des analyses de données exploratoires, exécutent des analyses de données et forment des modèles de ML. Pour allouer des ressources, organiser des données et gérer des flux de travail basés sur des projets, Kubeflow sur AWS fournit une isolation basée sur des espaces de noms Kubernetes. Cette isolation fonctionne pour interagir avec l'interface utilisateur de Kubeflow ; cependant, il ne fournit aucun outil pour contrôler l'accès à l'API Kubernetes à l'aide de Kubectl. Cela signifie que l'accès des utilisateurs peut être contrôlé sur l'interface utilisateur de Kubeflow, mais pas sur l'API Kubernetes via Kubectl.

L'architecture décrite dans le diagramme suivant résout ce problème en unifiant l'accès aux projets dans Kubeflow en fonction des appartenances aux groupes. Pour y parvenir, nous avons tiré parti des manifestes Kubeflow sur AWS, qui s'intègrent aux groupes d'utilisateurs Amazon Cognito. De plus, nous utilisons le contrôle d'accès basé sur les rôles Kubernetes (RBAC) pour contrôler l'autorisation au sein du cluster. Les autorisations utilisateur sont provisionnées en fonction de l'appartenance au groupe Amazon Cognito. Ces informations sont transmises au cluster avec le jeton généré par le client OIDC. Ce processus est simplifié grâce à la fonctionnalité Amazon EKS intégrée qui permet d'associer des fournisseurs d'identité OIDC pour s'authentifier auprès du cluster.

Par défaut, l'authentification Amazon EKS est effectuée par l'authentificateur IAM, qui est un outil qui permet de s'authentifier auprès d'un cluster EKS à l'aide des informations d'identification IAM. Cette méthode d'authentification a ses mérites ; cependant, cela ne convient pas à notre cas d'utilisation, car athenahealth utilise Microsoft Azure Active Directory pour le service d'identité dans l'ensemble de l'organisation.

Isolement de l'espace de noms Kubernetes. Les Data Scientists peuvent obtenir l'adhésion à un ou plusieurs groupes selon les besoins de leur travail. L'accès est revu régulièrement et supprimé le cas échéant.

Azure Active Directory, étant un service d'identité à l'échelle de l'entreprise, est la source de vérité pour contrôler l'accès des utilisateurs au cluster Kubeflow. La configuration pour cela inclut la création d'une application d'entreprise Azure qui agit en tant que principal de service et l'ajout de groupes pour divers locataires qui nécessitent un accès au cluster. Cette configuration sur Azure est reflétée dans Amazon Cognito en configurant un fournisseur d'identité OIDC fédéré qui sous-traite la responsabilité d'authentification à Azure. L'accès aux groupes Azure est contrôlé par SailPoint IdentityIQ, qui envoie des demandes d'accès au propriétaire du projet pour autoriser ou refuser, selon le cas. Dans le groupe d'utilisateurs Amazon Cognito, deux clients d'application sont créés : l'un est utilisé pour configurer l'authentification pour le cluster Kubernetes à l'aide du fournisseur d'identité OIDC, et l'autre pour sécuriser l'authentification Kubeflow dans l'interface utilisateur Kubeflow. Ces clients sont configurés pour transmettre les revendications de groupe lors de l'authentification avec le cluster, et ces revendications de groupe sont utilisées avec RBAC pour configurer l'autorisation au sein du cluster.

Les liaisons de rôle Kubernetes RBAC sont configurées entre les groupes et le rôle de cluster Kubeflow-edit, qui est créé lors de l'installation de Kubeflow dans le cluster. Cette liaison de rôle garantit que tout utilisateur interagissant avec le cluster après s'être connecté via OIDC peut accéder aux espaces de noms pour lesquels il dispose d'autorisations, comme défini dans ses revendications de groupe. Bien que cela fonctionne pour les utilisateurs qui interagissent avec le cluster à l'aide de Kubectl, l'interface utilisateur de Kubeflow ne fournit actuellement pas d'accès aux utilisateurs en fonction de l'appartenance au groupe, car elle n'utilise pas RBAC. Au lieu de cela, il utilise la ressource Istio Authorization Policy pour contrôler l'accès des utilisateurs. Pour surmonter ce défi, nous avons développé un contrôleur personnalisé qui synchronise les utilisateurs en interrogeant les groupes Amazon Cognito et ajoute ou supprime les liaisons de rôle correspondantes pour chaque utilisateur plutôt que par groupe. Cette configuration permet aux utilisateurs d'avoir le même niveau d'autorisations lorsqu'ils interagissent avec l'interface utilisateur Kubeflow et Kubectl.

efficacité opérationnelle

Dans cette section, nous expliquons comment nous avons tiré parti des outils open source et AWS à notre disposition pour gérer et déboguer nos workflows ainsi que pour minimiser l'impact opérationnel de la mise à niveau de Kubeflow.

Journalisation et surveillance

Pour la journalisation, nous utilisons FluentD pour pousser tous nos journaux de conteneurs vers Service Amazon OpenSearch et les métriques système à Prometheus. Nous utilisons ensuite Kibana et l'interface utilisateur Grafana pour rechercher et filtrer les journaux et les métriques. Le diagramme suivant décrit comment nous avons mis cela en place.

Journalisation Kubeflow. Nous utilisons à la fois l'interface utilisateur Grafana et Kibana pour afficher et parcourir les journaux

La capture d'écran suivante est une vue de l'interface utilisateur Kibana de notre pipeline.

Exemple de vue d'interface utilisateur Kibana. Kibana permet des vues personnalisées.

Mises à niveau sécurisées du cluster Kubeflow

Au fur et à mesure que nous intégrons des utilisateurs à Kubeflow sur AWS, nous maintenons une expérience utilisateur fiable et cohérente tout en permettant à l'équipe MLOps de rester agile en publiant et en intégrant de nouvelles fonctionnalités. En surface, Kustomize nous semble modulaire pour permettre de travailler et de mettre à niveau un composant à la fois sans affecter les autres, nous permettant ainsi d'ajouter de nouvelles fonctionnalités avec un minimum de perturbations pour les utilisateurs. Cependant, dans la pratique, il existe des scénarios où la meilleure approche consiste simplement à lancer un nouveau cluster Kubernetes plutôt que d'appliquer des mises à niveau au niveau des composants pour les clusters existants. Nous avons trouvé deux cas d'utilisation où il était plus logique de créer des clusters entièrement nouveaux :

• Mise à niveau vers une version de Kubernetes où AWS fournit des mises à niveau de cluster sur place. Cependant, il devient difficile de tester si chacune des ressources Kubeflow et Kubernetes fonctionne comme prévu et si les manifestes conservent la rétrocompatibilité.
• Mettre à niveau Kubeflow vers une version plus récente où plusieurs fonctionnalités ont été ajoutées ou modifiées et il n'est presque toujours pas une idée prometteuse d'effectuer des mises à niveau sur place sur un cluster Kubernetes existant.

Pour résoudre ce problème, nous avons développé une stratégie qui nous permet d'avoir des remplacements de clusters sûrs sans affecter les charges de travail existantes. Pour y parvenir, nous devions répondre aux critères suivants :

• Séparez les ressources de stockage et de calcul Kubeflow afin que les métadonnées du pipeline, les artefacts du pipeline et les données utilisateur soient conservés lors du déprovisionnement de l'ancien cluster
• Intégrez les manifestes Kubeflow sur AWS afin que, lorsqu'une mise à niveau de la version de Kubeflow se produit, des modifications minimales soient requises
• Avoir un moyen facile de revenir en arrière si les choses tournent mal après la mise à niveau du cluster
• Avoir une interface simple pour promouvoir un cluster candidat en production

Le diagramme suivant illustre cette architecture.

Mise à niveau sécurisée du cluster Kubeflow. Une fois que le test du candidat Kubeflow est réussi, il est promu vers Kubeflow Prod via une mise à jour vers Route 53.

Les manifestes Kubeflow sur AWS sont pré-emballés avec les intégrations Amazon RDS et Amazon S3. Avec ces services gérés agissant comme des magasins de données communs, nous pouvons mettre en place une stratégie de déploiement bleu-vert. Pour ce faire, nous nous sommes assurés que les métadonnées du pipeline sont conservées dans Amazon RDS, qui fonctionne indépendamment du cluster EKS, et que les journaux et les artefacts du pipeline sont conservés dans Amazon S3. En plus des métadonnées et des artefacts du pipeline, nous avons également configuré FluentD pour acheminer les journaux de pod vers Amazon OpenSearch Service.

Cela garantit que la couche de stockage est complètement séparée de la couche de calcul et permet ainsi de tester les modifications lors des mises à jour de version de Kubeflow sur un tout nouveau cluster EKS. Une fois tous les tests réussis, nous pouvons simplement changer le Amazon Route 53 Enregistrement DNS vers le cluster candidat hébergeant Kubeflow. De plus, nous gardons l'ancien cluster en cours d'exécution en tant que sauvegarde pendant quelques jours au cas où nous aurions besoin de revenir en arrière.

Avantages d'Amazon EKS et Kubeflow sur AWS pour notre pipeline ML

Amazon EKS et le package Kubeflow sur AWS ont déplacé notre flux de travail de développement vers un modèle qui encourage fortement la formation de modèles reproductibles. Ces outils nous permettent d'avoir des clusters entièrement définis avec des locataires entièrement définis et d'exécuter un code entièrement défini.

De nombreux gains liés à la construction de cette plate-forme sont moins quantitatifs et ont davantage à voir avec l'amélioration des flux de travail pour les développeurs et les utilisateurs de la plate-forme. Par exemple, MinIO a été remplacé par un accès direct à Amazon S3, ce qui nous rapproche de nos flux de travail d'origine et réduit le nombre de services que nous devons maintenir. Nous sommes également en mesure d'utiliser Amazon RDS comme backend pour Kubeflow, ce qui facilite les migrations entre les clusters et nous donne la possibilité de sauvegarder nos pipelines la nuit.

Nous avons également constaté que les améliorations apportées à l'intégration de Kubeflow avec les services gérés AWS étaient bénéfiques. Par exemple, avec Amazon RDS, Amazon S3 et Amazon Cognito préconfigurés dans les manifestes Kubeflow sur AWS, nous économisons du temps et des efforts lors de la mise à jour vers les nouvelles distributions de Kubeflow. Lorsque nous avions l'habitude de modifier manuellement les manifestes officiels de Kubeflow, la mise à jour vers une nouvelle version prenait plusieurs semaines, de la conception aux tests.

Le passage à Amazon EKS nous donne la possibilité de définir notre cluster dans Kustomize (qui fait maintenant partie de Kubectl) et Terraform. Il s'avère que pour le travail sur plateforme, Kubernetes et Terraform sont très faciles à utiliser après avoir mis suffisamment de temps à apprendre. Après de nombreuses itérations, les outils dont nous disposons permettent d'effectuer très facilement des opérations de plate-forme standard telles que la mise à niveau d'un composant ou l'échange d'un cluster de développement complet. Par rapport à l'exécution de tâches brutes Cloud de calcul élastique Amazon (Amazon EC2), il est difficile de comparer l'énorme différence que cela fait d'avoir des pods bien définis avec des mécanismes de nettoyage et de nouvelle tentative de ressources garantis intégrés.

Kubernetes fournit d'excellentes normes de sécurité, et nous n'avons fait qu'effleurer ce que l'isolation multi-utilisateur nous permet de faire. Nous considérons l'isolement multi-utilisateurs comme un modèle qui sera plus rentable à l'avenir lorsque la plate-forme de formation produira des données au niveau de la production et que nous ferons appel à des développeurs extérieurs à notre équipe.

Pendant ce temps, Kubeflow nous permet d'avoir une formation de modèle reproductible. Même avec les mêmes données, aucune formation ne produit des modèles identiques, mais nous avons la meilleure solution suivante. Avec Kubeflow, nous savons exactement quel code et quelles données ont été utilisés pour former un modèle. L'intégration s'est grandement améliorée car chaque étape de notre pipeline est clairement et programmatiquement définie. Lorsque de nouveaux scientifiques des données ont pour tâche de corriger un bogue, ils ont besoin de beaucoup moins de prise en main car il existe une structure claire sur la façon dont les sorties de code sont utilisées entre les étapes.

L'utilisation de Kubeflow apporte également de nombreuses améliorations de performances par rapport à l'exécution sur une seule instance EC2. Souvent, dans la formation de modèles, les data scientists ont besoin de différents outils et optimisations pour le prétraitement et la formation. Par exemple, le prétraitement est souvent exécuté à l'aide d'outils de traitement de données distribués, comme Spark, tandis que la formation est souvent exécutée à l'aide d'instances GPU. Avec les pipelines Kubeflow, ils peuvent spécifier différents types d'instances pour différentes étapes du pipeline. Cela leur permet d'utiliser les puissantes instances GPU à une étape et une flotte de machines plus petites pour le traitement distribué à une autre étape. De plus, comme les pipelines Kubeflow décrivent les dépendances entre les étapes, les pipelines peuvent exécuter des étapes en parallèle.

Enfin, comme nous avons créé un processus pour ajouter des locataires au cluster, il existe désormais un moyen plus formel d'enregistrer des équipes auprès d'un locataire sur le cluster. Étant donné que nous utilisons Kubecost pour suivre les coûts dans notre cluster EKS, cela nous permet d'attribuer les coûts à un seul projet plutôt que d'attribuer les coûts au niveau du compte, ce qui inclut tous les projets de science des données. Kubecost présente un rapport sur l'argent dépensé par espace de noms, qui est étroitement lié au locataire ou à l'équipe responsable de l'exécution du pipeline.

Malgré tous les avantages, nous serions prudents de n'entreprendre ce type de migration que s'il y a une adhésion totale des utilisateurs. Les utilisateurs qui y consacrent du temps tirent de nombreux avantages de l'utilisation d'Amazon EKS et de Kubernetes, mais la courbe d'apprentissage est importante.

Conclusion

Avec la mise en œuvre du pipeline Kubeflow sur AWS dans notre infrastructure ML de bout en bout, nous avons pu consolider et normaliser nos workflows de science des données tout en conservant nos outils essentiels (tels que CI/CD et service de modèle). Nos scientifiques des données peuvent désormais passer d'un projet à l'autre en fonction de ce flux de travail sans avoir à apprendre à gérer un ensemble d'outils complètement différent. Pour certains de nos modèles, nous avons également été agréablement surpris par la rapidité du nouveau workflow (cinq fois plus rapide), qui a permis plus d'itérations d'entraînement et par conséquent de produire des modèles avec de meilleures prédictions.

Nous avons également établi une base solide pour augmenter nos capacités MLOps et faire évoluer le nombre et la taille de nos projets. Par exemple, alors que nous renforçons notre posture de gouvernance dans la lignée et le suivi des modèles, nous avons réduit notre concentration de plus de 15 flux de travail à un seul. Et lorsque la vulnérabilité Log4shell est apparue fin 2021, nous avons pu nous concentrer sur un seul flux de travail et y remédier rapidement si nécessaire (effectuer Registre des conteneurs élastiques Amazon (Amazon ECR), mise à niveau d'Amazon OpenSearch Service, mise à jour de nos outils, etc.) avec un impact minimal sur le travail en cours des data scientists. Au fur et à mesure que les améliorations d'AWS et de Kubeflow deviennent disponibles, nous pouvons les intégrer comme bon nous semble.

Cela nous amène à un aspect important et discret de notre adoption de Kubeflow sur AWS. L'un des résultats critiques de ce voyage est la capacité à déployer des mises à niveau et des améliorations de Kubeflow de manière transparente pour nos scientifiques des données. Bien que nous ayons discuté de notre approche à cet égard plus tôt, nous nous appuyons également sur les manifestes Kubeflow fournis par AWS. Nous avons commencé notre parcours Kubeflow en tant que preuve de concept en 2019, avant la sortie de la version 1.0.0. (Nous sommes actuellement sur 1.4.1, évaluant 1.5. AWS travaille déjà sur la version 1.6.) Au cours des 3 dernières années, il y a eu au moins six versions avec un contenu substantiel. Grâce à leur approche disciplinée pour intégrer et valider ces mises à niveau et publier les manifestes selon un calendrier prévisible et fiable, l'équipe Kubeflow d'AWS a joué un rôle crucial en permettant à l'équipe athenahealth MLOps de planifier notre feuille de route de développement, et par conséquent nos allocations de ressources et nos domaines d'intérêt. , plus loin dans le futur avec plus de confiance.

Vous pouvez suivre les Référentiel AWS Labs GitHub pour suivre toutes les contributions AWS à Kubeflow. Vous pouvez également trouver des équipes AWS sur le Chaîne Kubeflow #AWS Slack; vos commentaires là-bas aident AWS à hiérarchiser les prochaines fonctionnalités à contribuer au projet Kubeflow.

---

À propos des auteurs

Kanwaljit Khurmi est architecte de solutions senior chez Amazon Web Services. Il travaille avec les clients AWS pour fournir des conseils et une assistance technique les aidant à améliorer la valeur de leurs solutions lors de l'utilisation d'AWS. Kanwaljit est spécialisé dans l'aide aux clients avec des applications conteneurisées et d'apprentissage automatique.

Tyler Kalbach est membre principal du personnel technique chez athenahealth. Tyler a environ 7 ans d'expérience dans l'analyse, la science des données, les réseaux de neurones et le développement d'applications d'apprentissage automatique dans le domaine de la santé. Il a contribué à plusieurs solutions d'apprentissage automatique qui servent actuellement le trafic de production. Travaillant actuellement en tant que scientifique principal des données dans l'organisation d'ingénierie d'athenahealth, Tyler a fait partie de l'équipe qui a construit la nouvelle plate-forme de formation en apprentissage automatique pour athenahealth depuis le début de cet effort.

Victor Krylov est membre principal du personnel technique chez athenahealth. Victor est un ingénieur et scrum master, aidant les scientifiques des données à construire des pipelines d'apprentissage automatique rapides et sécurisés. Chez athenahealth, il a travaillé sur les interfaces, les commandes cliniques, les prescriptions, la planification, l'analyse et maintenant l'apprentissage automatique. Il apprécie le code proprement écrit et bien testé par unité, mais a une obsession malsaine pour les one-liners de code. Dans ses temps libres, il aime écouter des podcasts tout en promenant son chien.

Sasank Vemuri est membre principal du personnel technique chez athenahealth. Il a de l'expérience dans le développement de solutions axées sur les données dans des domaines tels que la santé, l'assurance et la bioinformatique. Sasank travaille actuellement à la conception et au développement de plates-formes de formation et d'inférence d'apprentissage automatique sur AWS et Kubernetes qui aident à la formation et au déploiement de solutions ML à grande échelle.

Anu Tumkur est architecte chez athenahealth. Anu a plus de deux décennies d'expérience en architecture, conception et développement dans la construction de divers produits logiciels dans l'apprentissage automatique, les opérations cloud, le big data, les pipelines de données distribuées en temps réel, la technologie publicitaire, l'analyse de données, l'analyse des médias sociaux. Anu travaille actuellement en tant qu'architecte dans l'organisation Product Engineering d'athenahealth au sein des équipes Machine Learning Platform et Data Pipeline.

Guillaume Tsen est directeur principal de l'ingénierie chez athenahealth. Il a plus de 20 ans d'expérience en leadership en ingénierie dans la création de solutions dans les domaines de l'informatique de santé, de l'informatique distribuée Big Data, des réseaux optiques intelligents, des systèmes de montage vidéo en temps réel, des logiciels d'entreprise et de la souscription de soins de santé collectifs. William dirige actuellement deux équipes formidables chez athenahealth, les équipes d'ingénierie Machine Learning Operations et DevOps, au sein de l'organisation Product Engineering.