TrueFoundry's Vision

Gesamtvision: Eine Entwicklerplattform, die die Erstellung und Verwaltung von Services unter Einhaltung aller Best Practices vereinfacht und ein vollständiges Gesamtbild der Infrastruktur liefert – einschließlich des Monitorings von Systemen, Daten, Kosten und Auswirkungen, mit einem anfänglichen Fokus auf Machine Learning!

Vision für TrueFoundry (5–10 Jahre)

TrueFoundry zielt im Kern darauf ab, die Developer Experience für die Ausführung und Verwaltung von MicroServices nahtlos zu gestalten — wobei sich Entwickler dank der passenden Abstraktionsebenen mit extrem hoher Iterationsgeschwindigkeit voll und ganz auf das Schreiben der Business-Logik konzentrieren können.

Stellen Sie sich einen Ablauf vor, bei dem ich nach dem Schreiben des Codes einen Genie aufrufen und ihm meine Anforderungen mitteilen kann — etwa die Art des Service (Serverless, CronJob, Datenbank, ein API-Service), Ressourcenanforderungen wie CPU, Speicher usw. — und der Genie erstellt den Service nach Best Practices wie GitOps, Infrastructure as Code (IaC) und zeigt anschließend ein Dashboard mit allen erstellten Metriken an.

Wir möchten mit servicefoundry folgende Ziele erreichen:

Zentralisierte Infrastruktur-Bereitstellung mittels IaC

ServiceFoundry wird die am häufigsten verwendeten Open-Source-Infrastrukturkomponenten in der Cloud des Benutzers bereitstellen und hosten. Ein paar Beispiele hierfür sind:

1. Starten von Kubernetes-Clustern mit konfigurierten Security Best Practices.
2. Installieren zentraler Infrastrukturkomponenten (oder Nutzen verwalteter Dienste) wie Kafka, Spark, Redis, Prometheus, Grafana etc.
3. Wir können für einige davon verwaltete Cloud-Dienste nutzen, wie beispielsweise AWS ElasticSearch.
4. Bereitstellen von Datenbanken und Storage-Layern (vorerst verwaltete Versionen nutzen).
5. Pipeline-Orchestrierungssysteme wie Airflow, Argo etc.
6. CI / CD (GitHub Actions, GitLab, AWS CodePipelines)
7. Log-Aggregation (ELK, EFK)
8. Monitoring (Standard- und benutzerdefinierte Metriken)
9. Alerting

Service erstellen

1. Bauen und Deployen von Services auf Basis konfigurierbarer Templates. ServiceFoundry wird ein vordefiniertes Set von Prinzipien sein, um Folgendes über infrastructure-as-code zu automatisieren:

• Dependency Management und Packaging (Docker, Zip)
• Testing
• Konfigurationsmanagement (statische und dynamisch wechselnde Konfigurationen)
• Infrastruktur-Bereitstellung (aufbauend auf der zuvor bereitgestellten zentralen Infrastruktur)
• Autoscaling-Konfiguration
• CI/CD
• Log-Aggregation
• Dashboard-Erstellung mit Standardmetriken (Benutzer können benutzerdefinierte Metriken hinzufügen)
• Alerting

Ähnlich wie oben möchten wir dasselbe auch für ML-Modelle und Datenbanken umsetzen.

ServiceFoundry zielt darauf ab, das Deployment und die Überwachung der gängigen Service-Typen zu rationalisieren:

1. LoadBalanced API Service (mit Autoscaling nach verschiedenen Parametern)
2. Job Service (CronJobs, durch Events ausgelöste Jobs)
3. Serverless
4. Stateful Services
5. Statische Websites

Service-Katalog und -Graph

Alle mit ServiceFoundry erstellten Services können an einem zentralen Ort zusammen mit ihren vollständigen Metadaten eingesehen werden. Dieser Katalog zeigt auch alle Umgebungen für jede Anwendung wie Dev, Staging und Prod. Dies führt zu einem Entwickler-Plattform-Portal, auf dem Entwickler und Führungskräfte die in der Organisation laufenden Services einsehen können. Zu den wichtigsten Metadaten jedes Service gehören:

1. Link zum GitHub-Repository
2. Konfiguration
3. Monitoring-Links
4. Team und Verantwortliche
5. Möglichkeit, Mitglieder mit unterschiedlicher Zugriffskontrolle hinzuzufügen
6. Kosten

TrueFoundry MLOps (ML-First-Plattform)

Der anfängliche Fokus von TrueFoundry wird darauf liegen, eine nahtlose MLOps-Plattform bereitzustellen, die sich auf die Pipeline nach der Modellerstellung konzentriert und es Data Scientists extrem einfach macht, ihre Modelle zu deployen, zu überwachen und neu zu trainieren.

Eine Machine-Learning-Pipeline umfasst die folgende zentrale Infrastruktur:

Eine kurze Erklärung der verschiedenen Schritte:

1. Data Pipeline und Feature Store: Dies ist im Wesentlichen ein Big-Data-Problem, bei dem die im Modell zu verwendenden Features aus dem Datalake berechnet werden und unter den erforderlichen Zeitvorgaben sowohl für das Training als auch für die Produktion ohne Diskrepanzen verfügbar sein müssen. Normalerweise wird dafür eine Workflow-Orchestrierungs-Engine wie Airflow, Argo oder Kubeflow Pipelines verwendet.
2. Modelltraining: Das Modelltraining ist im Wesentlichen ein rechenintensiver, verteilter Job, der über mehrere Maschinen laufen kann. Es sollte auch integrierte Resilienz durch das Speichern und Wiederherstellen von Checkpoints bieten.
3. Model Serving: Hierbei handelt es sich im Grunde um einen Microservice, der Anfragen für Modellvorhersagen erhält und unterschiedliche Anforderungen wie GPU, hohe Rechenleistung und viel Speicher haben kann. Jedes Modell wird in der Regel als einzelner Microservice gehostet — wenn ein Team also auf Dutzende von Modellen skaliert, wird die Verwaltung von Dutzenden Microservices selbst zu einer großen Herausforderung.
4. Model Monitoring: Dies umfasst sowohl das Monitoring von Systemmetriken als auch das ML-spezifische Monitoring bezüglich Performance und Modell-Decay. Hierfür sind zudem Systeme erforderlich, die geloggte Daten speichern, Aggregationen darauf ausführen und schließlich die Metriken berechnen.
5. Modellverwaltung: Nachverfolgung aller Daten zu Modellen sowie deren verschiedenen Versionen und Experimenten. Dies ist äußerst nützlich, um Probleme später zu debuggen und Rollbacks durchzuführen.

Aufgrund der vielen beweglichen Teile und unterschiedlichen Technologien sind an einem ML-Projekt meist mehrere Personen beteiligt, darunter Data Engineers, Data Scientists, ML Engineers, DevOps und Product Manager. Ein erfolgreiches Projekt erfordert die Abstimmung zwischen all diesen verschiedenen Rollen, was zu vielen Verzögerungen führt und die Geschwindigkeit eines Data Scientists beeinträchtigt.

Ein typischer Workflow für eine Machine-Learning-Pipeline in Unternehmen sieht etwa so aus:

Zentrales Ziel hinter der ML-Plattform

Wir möchten die Teile der ML-Pipeline automatisieren, die automatisiert werden können, und den Data Scientist in die Lage versetzen, seine Modelle in der Produktion zu testen und schnell zu iterieren — mit so wenigen Abhängigkeiten von anderen Teams wie möglich. Wir lassen uns von den Produkten inspirieren, die von Plattform-Teams in führenden Tech-Unternehmen entwickelt wurden und die es allen Teams ermöglichen, viel schneller zu agieren sowie eigenständig zu deployen und zu iterieren.

Datenbezogene Probleme decken wir derzeit noch nicht ab — dieser Bereich wird später eingeführt.

Eine zentrale ML-Plattform umfasst die folgenden Services (neben der zentralen Infrastruktur):

1. Training (Ein geplanter Job mit verschiedenen Triggern)
2. Model Service (Ein LoadBalanced API Service)
3. Storage (Artefakte, Datasets, Modell-Inferenzdaten)
4. ML-Monitoring-Service (Ein Service zur Berechnung von Metriken aus Daten)
5. Feature-Engineering-Service

Wenn wir diese Services einfach deployen, die Versionierung über verschiedene Phasen hinweg aufrechterhalten und das Monitoring für jeden einzelnen Service generieren können, wird das Thema MLOps zu einer wesentlich einfacheren Aufgabe.

Dieser Blogbeitrag wurde zuerst auf Medium veröffentlicht unter https://abhishekch09.medium.com/d8e159743a4b