Die Vision von TrueFoundry

Gesamtvision: Eine Entwicklerplattform, die die Erstellung und Verwaltung von Diensten nach allen Best Practices erleichtert und ein vollständiges Gesamtbild der Infrastruktur bietet, einschließlich der Überwachung von Systemen, Daten, Kosten und Auswirkungen, wobei der Schwerpunkt zunächst auf maschinellem Lernen liegt!

Vision für TrueFoundry (5—10 Jahre)

TrueFoundry zielt im Kern darauf ab, Entwicklern ein nahtloses Erlebnis für die Ausführung und Verwaltung von MicroServices zu bieten. Mit der richtigen Abstraktionsebene können sich Entwickler einfach darauf konzentrieren, die Geschäftslogik mit sehr hohen Iterationsgeschwindigkeiten zu schreiben.

Stellen Sie sich einen Ablauf vor, bei dem ich nach dem Schreiben des Codes einen Geist anrufen und ihm meine Anforderungen wie die Art des Dienstes (Serverless, CronJob, Datenbank, ein API-Dienst), Ressourcenanforderungen wie CPU, Speicher usw. mitteilen kann und der Geist den Dienst mit den besten Methoden wie Gitops, Infrastructure as Code (IAC) erstellt und dann ein Dashboard mit allen erstellten Metriken anzeigt.

Wir wollen mit servicefoundry die folgenden Dinge erreichen können:

Zentralisierte Infrastrukturbereitstellung mithilfe von IAC

ServiceFoundry stellt die am häufigsten verwendeten Open-Source-Infrastrukturkomponenten in der Cloud des Benutzers bereit und hostet sie. Ein paar Beispiele hierfür können sein:

1. Starten Sie den Kubernetes-Cluster mit konfigurierten Best Practices für die Sicherheit.
2. Installieren Sie zentralisierte Infrastrukturkomponenten (oder verwenden Sie verwaltete Dienste) wie Kafka, Spark, Redis, Prometheus, Grafana usw.
3. Für einige von ihnen können wir Cloud Managed Services wie AWS Elastic Search verwenden.
4. Starten Sie Datenbanken, Speicherebenen. (verwenden Sie vorerst verwaltete Versionen)
5. Pipeline-Orchestrierungssysteme wie Airflow, Argo usw.
6. CI/CD (Github-Aktionen, Gitlab, AWS-Code-Pipelines)
7. Protokollaggregation (ELK, EFK)
8. Überwachung (Standard- und benutzerdefinierte Metriken)
9. Alarmierend

Dienst erstellen

1. Erstellen und implementieren Sie Dienste auf der Grundlage konfigurierbarer Vorlagen. Bei ServiceFoundry wird es sich um eine Reihe von eigensinnigen Prinzipien handeln, mit denen Folgendes automatisiert werden soll:

• Abhängigkeitsmanagement und Packen (Docker, Zip)
• Testen
• Konfigurationsmanagement (Statische und sich dynamisch ändernde Konfigurationen)
• Bereitstellung der Infrastruktur (zusätzlich zur zuvor bereitgestellten zentralisierten Infrastruktur)
• Autoscaling-Konfiguration
• CI/CD
• Aggregation von Protokollen
• Dashboard-Generierung mit Standardmetriken (Benutzer können benutzerdefinierte Metriken hinzufügen)
• Alarmierend

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

ServiceFoundry wird sich zum Ziel setzen, die Bereitstellung und Überwachung der Standardtypen von Diensten zu rationalisieren:

1. LoadBalanced Api Service (mit Autoscaling für verschiedene Parameter)
2. Job Service (Cron-Jobs, durch Ereignisse ausgelöste Jobs)
3. Serverlos
4. Stateful-Dienste
5. Statische Website

Servicekatalog und Grafik

Alle mit ServiceFoundry erstellten Dienste können zusammen mit ihren vollständigen Metadaten an einem Ort angezeigt werden. Dieser Katalog zeigt auch alle Umgebungen für jede Anwendung wie Dev, Staging und Prod. Dies führt zu einem Portal für Entwicklerplattformen, auf dem Entwickler und Unternehmensleiter die im Unternehmen laufenden Dienste einsehen können. Einige der wichtigsten Metadaten, die mit jedem Dienst verknüpft sind, sind:

1. Link zum Github Repository
2. Konfiguration
3. Links überwachen
4. Team und Besitzer
5. Möglichkeit, Mitglieder mit unterschiedlicher Zugriffskontrolle hinzuzufügen.
6. Kosten

TrueFoundry MLOps (ML First Platform)

Der anfängliche Schwerpunkt von TrueFoundry wird auf der Bereitstellung einer nahtlosen MLOps-Plattform liegen, die sich auf die Pipeline nach der Modellerstellung konzentriert und es Datenwissenschaftlern wirklich einfach macht, ihre Modelle bereitzustellen, zu überwachen und neu zu trainieren.

Eine Pipeline für maschinelles Lernen besteht aus der folgenden zentralisierten Infrastruktur:

Eine kurze Erläuterung der verschiedenen Schritte lautet:

1. Datenpipeline und Feature-Store: Dies ist im Wesentlichen ein Big-Data-Problem, bei dem wir die im Modell zu verwendenden Funktionen aus dem Datensee berechnen und in den Zeitbeschränkungen, die sowohl für das Training als auch für die Produktion erforderlich sind, ohne Unterschiede verfügbar machen müssen. In der Regel wird eine Workflow-Orchestrierungs-Engine wie Airflow-, Argo- und Kubeflow-Pipelines verwendet.
2. Modelltraining: Das Modelltraining ist im Wesentlichen ein rechenintensiver verteilter Job, der auf mehreren Computern ausgeführt werden kann. Es sollte auch eine integrierte Resilienz durch das Speichern und Wiederherstellen von Checkpoints bieten.
3. Modell Serving: Dies ist im Grunde ein Microservice, der Anfragen zur Erstellung von Modellvorhersagen erhält und unterschiedliche Anforderungen wie GPU-, hohe Rechen- und Speicheranforderungen haben kann. Jedes Modell wird in der Regel als ein einziger Microservice gehostet. Wenn ein Team also auf mehrere zehn Modelle skaliert, wird es zu einem Problem, zehn von Microservices zu verwalten, was an sich schon ein großes Problem darstellt.
4. Modellüberwachung: Dazu gehören sowohl die Überwachung der Systemkennzahlen als auch die Überwachung, die speziell auf maschinelles Lernen zugeschnitten ist und sich auf die Leistung und den Verfall des Modells bezieht. Dazu müssen die Systeme auch die protokollierten Daten speichern, sie aggregieren und schließlich die Metriken berechnen.
5. Modellmanagement: Dies verfolgt alle Daten zu Modellen und ihren verschiedenen Versionen und Experimenten. Es ist sehr nützlich, um Probleme später zu debuggen und ein Rollback durchzuführen.

Da so viele bewegliche Teile und unterschiedliche Technologien involviert sind, sind in der Regel mehrere Personen an einem ML-Projekt beteiligt, wie DataEngineer, Datascientist, ML Engineer, Devops und Product Manager. Ein erfolgreiches Projekt erfordert die Koordination zwischen all diesen verschiedenen Personen, was zu vielen Verzögerungen führt und die Geschwindigkeit eines Datenwissenschaftlers beeinträchtigt.

Ein typischer Arbeitsablauf in Unternehmen für eine Pipeline für maschinelles Lernen sieht in etwa so aus:

Wichtiges Ziel hinter der ML-Plattform

Wir wollen die Teile in der ML-Pipeline, die automatisiert werden können, automatisieren und den Datenwissenschaftler in die Lage versetzen, seine Modelle in der Produktion zu testen und schnell zu iterieren, wobei die Abhängigkeiten von anderen Teams so gering wie möglich sind. Unsere Motivation schöpfen wir aus den Produkten, die von Plattformteams in Top-Technologieunternehmen entwickelt wurden und die es allen Teams ermöglichen, viel schneller voranzukommen und eigenständig zu implementieren und zu iterieren.

Wir lösen derzeit keines der datenbezogenen Probleme — dieser Abschnitt wird später eingeführt.

Eine wichtige ML-Plattform umfasst die folgenden Dienste (abgesehen von der zentralen Infrastruktur)

1. Schulung (Ein geplanter Job mit verschiedenen Auslösern)
2. Modelldienst (ein LoadBalanced API-Dienst)
3. Speicher (Artefakte, Datensätze, Modellinferenzdaten)
4. ML Monitoring Service (Ein Dienst zur Berechnung von Metriken aus Daten)
5. Feature-Engineering-Service

Wenn wir diese Dienste einfach bereitstellen, die Versionierung über verschiedene Stufen hinweg verwalten und für jeden von ihnen eine Überwachung generieren können, wird das ML Ops-Problem ein viel einfacheres Problem sein.

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