La vision de TrueFoundry

Vision globale : une plateforme de développement qui facilite la création et la gestion de services en suivant toutes les meilleures pratiques et donne une image globale complète de l'infrastructure, y compris la surveillance des systèmes, des données, des coûts et de l'impact, en mettant l'accent initialement sur l'apprentissage automatique !

Vision pour TrueFoundry (5 à 10 ans)

TrueFoundry vise essentiellement à rendre l'expérience des développeurs fluide pour l'exécution et la gestion des microservices. Avec le bon niveau d'abstractions, les développeurs peuvent se concentrer uniquement sur l'écriture de la logique métier à des vitesses d'itération très élevées.

Imaginez un flux où, après avoir écrit le code, je peux appeler un génie et lui faire part de mes besoins, tels que le type de service (Serverless, CronJob, base de données, un service API), les exigences en matière de ressources telles que le processeur, la mémoire, etc. et le génie crée le service avec les meilleures pratiques telles que Gitops, Infrastructure as Code (IAC), puis affiche un tableau de bord avec toutes les métriques créées.

Nous voulons être en mesure de réaliser les objectifs suivants avec Servicefoundry :

Provisionnement d'infrastructure centralisé à l'aide d'IAC

ServiceFoundry fournira et hébergera les composants d'infrastructure open source les plus couramment utilisés sur le cloud de l'utilisateur. Voici quelques exemples :

1. Lancez le cluster Kubernetes avec les meilleures pratiques de sécurité configurées.
2. Installez des composants d'infrastructure centralisés (ou utilisez des services gérés) tels que Kafka, Spark, Redis, Prometheus, Grafana, etc.
3. Nous pouvons utiliser des services gérés dans le cloud pour certains d'entre eux, comme AWS Elastic Search.
4. Lancez des bases de données, des couches de stockage. (utilisez les versions gérées pour le moment)
5. Systèmes d'orchestration de pipelines tels que Airflow, Argo, etc.
6. CI/CD (Github Actions, Gitlab, pipelines de code AWS)
7. Agrégation de journaux (ELK, EFK)
8. Surveillance (mesures standard et personnalisées)
9. Alerte

Créer un service

1. Créez et déployez des services sur la base de modèles configurables. ServiceFoundry sera un ensemble de principes avisés visant à automatiser les opérations suivantes :

• Gestion des dépendances et empaquetage (Docker, Zip)
• Tests
• Gestion de la configuration (configurations statiques et changeantes dynamiquement)
• Approvisionnement de l'infrastructure (en plus de l'infrastructure centralisée fournie précédemment)
• Configuration de mise à l'échelle automatique
• CI/CD
• Agrégation de journaux
• Génération de tableaux de bord avec des mesures standard (les utilisateurs peuvent ajouter des mesures personnalisées)
• Alerte

Comme ci-dessus, nous souhaitons également faire de même pour les modèles ML et les bases de données.

ServiceFoundry visera à rationaliser le déploiement et la surveillance des types de services standard :

1. Service d'API LoadBalanced (avec mise à l'échelle automatique sur différents paramètres)
2. Job Service (tâches cron, tâches déclenchées par des événements)
3. Sans serveur
4. Services dynamiques
5. Site Web statique

Catalogue de services et graphique

Tous les services créés à l'aide de ServiceFoundry peuvent être consultés en un seul endroit avec leurs métadonnées complètes. Ce catalogue présentera également tous les environnements de chaque application, tels que dev, staging et prod. Cela conduit à un portail de plate-forme pour développeurs où les développeurs et les chefs d'entreprise peuvent consulter les services en cours d'exécution dans l'organisation. Voici quelques-unes des métadonnées clés associées à chaque service :

1. Lien vers le référentiel Github
2. Configuration
3. Liens de surveillance
4. L'équipe et les propriétaires
5. Possibilité d'ajouter des membres avec un contrôle d'accès différent.
6. Coût

TrueFoundry MLOps (première plateforme ML)

L'objectif initial de TrueFoundry sera de fournir une plate-forme MLOps fluide qui se concentre sur le pipeline de création post-modèle et qui permet aux data cientists de déployer, de surveiller et de reformer très facilement leurs modèles.

Un pipeline d'apprentissage automatique comprend l'infrastructure centralisée suivante :

Voici une brève explication des différentes étapes à suivre :

1. Pipeline de données et magasin de fonctionnalités : Il s'agit essentiellement d'un problème de mégadonnées dans lequel nous devons obtenir les fonctionnalités à utiliser dans le modèle calculées à partir du datalake et disponibles dans les contraintes de temps requises à la fois pour la formation et la production sans disparité. Il utilise généralement un moteur d'orchestration des flux de travail tel que les pipelines Airflow, Argo et Kubeflow.
2. Modèle de formation : L'apprentissage des modèles est essentiellement une tâche distribuée gourmande en calcul qui peut être exécutée sur plusieurs machines. Il devrait également offrir une résilience intégrée grâce à la sauvegarde et à la restauration des points de contrôle.
3. Modèle au service de : Il s'agit essentiellement d'un microservice qui reçoit des demandes pour effectuer les prédictions du modèle et qui peut avoir des exigences variées, telles que le GPU, des besoins de calcul et de mémoire élevés. Chaque modèle est généralement hébergé en tant que microservice unique. Ainsi, lorsqu'une équipe passe à des dizaines de modèles, elle devient difficile de gérer des dizaines de microservices, ce qui constitue en soi un gros problème.
4. Surveillance du modèle : Cela inclut à la fois la surveillance des métriques du système et la surveillance spécifique à l'apprentissage automatique liée aux performances et à la dégradation du modèle. Cela nécessite également que les systèmes stockent les données enregistrées, exécutent des agrégations dessus et calculent enfin les métriques.
5. Gestion des modèles : Cela permet de suivre toutes les données relatives aux modèles et à leurs différentes versions et expériences. C'est très utile pour résoudre les problèmes plus tard et revenir en arrière.

En raison du grand nombre de pièces mobiles et des différentes technologies impliquées, plusieurs personnes sont généralement impliquées dans un projet de machine learning, comme DataEngineer, Datascientist, ML engineer, Devops et Product Manager. Un projet réussi nécessite la coordination entre toutes ces différentes personnes, ce qui entraîne de nombreux retards et entrave la rapidité d'un data scientist.

Dans les entreprises, un flux de travail typique pour un pipeline d'apprentissage automatique ressemble à ceci :

Objectif clé de la plateforme ML

Nous voulons automatiser les parties du pipeline de machine learning qui peuvent être automatisées et permettre aux data cientists de tester leurs modèles en production et d'itérer rapidement en dépendant le moins possible des autres équipes. Nous puisons notre motivation dans les produits créés par les équipes de la plateforme dans les meilleures entreprises technologiques, qui permettent à toutes les équipes d'avancer beaucoup plus rapidement, de se déployer et d'itérer elles-mêmes.

Nous ne traitons aucun des problèmes liés aux données pour le moment. Cette section sera présentée plus tard.

Une plate-forme ML clé comprend les services suivants (en plus de l'infrastructure centrale)

1. Formation (un travail planifié avec différents déclencheurs)
2. Model Service (un service d'API à charge équilibrée)
3. Stockage (artefacts, ensembles de données, données d'inférence de modèles)
4. ML Monitoring Service (un service permettant de calculer des métriques à partir de données)
5. Service d'ingénierie des fonctionnalités

Si nous pouvons facilement déployer ces services, maintenir la gestion des versions à différentes étapes et générer une surveillance pour chacune d'entre elles, le problème ML Ops sera beaucoup plus simple.

Ce blog a été publié pour la première fois sur Medium à l'adresse https://abhishekch09.medium.com/d8e159743a4b