Dieser Beitrag wurde gemeinsam mit Jan Paul Assendorp, Thomas Lietzow, Christopher Masch, Alexander Meinert, Dr. Lars Palzer, Jan Schillemans von SIGNAL IDUNA verfasst.
Bei SIGNAL IDUNA, einem großen deutschen Versicherer, erfinden wir uns derzeit mit unserem Transformationsprogramm VISION2023 neu, um noch kundenorientierter zu werden. Zwei Aspekte stehen bei dieser Transformation im Mittelpunkt: die Reorganisation großer Teile der Belegschaft in funktionsübergreifende und agile Teams und hin zu einem echten datengetriebenen Unternehmen. Dabei ist das Motto „You build it, you run it“ eine wichtige Voraussetzung für ein funktionsübergreifendes Team, das ein Data- oder Machine Learning (ML)-Produkt baut. Dies setzt enge Grenzen, wie viel Arbeit ein Team für die Produktion und den Betrieb eines Produkts aufwenden kann.
Dieser Beitrag zeigt, wie SIGNAL IDUNA diese Herausforderung angeht und nutzt AWS-Wolke um es funktionsübergreifenden Teams zu ermöglichen, ihre eigenen ML-Produkte zu entwickeln und zu operationalisieren. Dazu stellen wir zunächst die Organisationsstruktur agiler Teams vor, die zentrale Anforderungen an die Cloud-Infrastruktur stellt, die für die Entwicklung und den Betrieb eines Produkts verwendet wird. Als Nächstes zeigen wir, wie drei zentrale Teams bei SIGNAL IDUNA es funktionsübergreifenden Teams ermöglichen, Datenprodukte in der AWS Cloud mit minimaler Unterstützung zu erstellen, indem sie einen geeigneten Workflow und Infrastrukturlösungen bereitstellen, die einfach verwendet und angepasst werden können. Abschließend überprüfen wir unseren Ansatz und vergleichen ihn mit einem eher klassischen Ansatz, bei dem Entwicklung und Betrieb strikter getrennt werden.
Agile@SI – die Grundlage des organisatorischen Wandels
Seit Anfang 2021 hat SIGNAL IDUNA damit begonnen, seine Strategie Agile@SI in die Tat umzusetzen und agile Methoden zur Entwicklung kundenorientierter Lösungen im gesamten Unternehmen zu etablieren [1]. Frühere Aufgaben und Ziele werden jetzt von funktionsübergreifenden Teams, genannt Mannschaften. Diese Squads wenden agile Methoden (wie das Scrum-Framework) an, treffen eigene Entscheidungen und bauen kundenorientierte Produkte. Typischerweise sind die Squads in Geschäftsbereichen wie dem Marketing angesiedelt, und viele haben einen starken Schwerpunkt auf der Entwicklung datengesteuerter und ML-basierter Produkte. Typische Anwendungsfälle im Versicherungswesen sind beispielsweise die Vorhersage von Kundenabwanderungen und Produktempfehlungen.
Aufgrund der Komplexität von ML ist die Erstellung einer ML-Lösung durch ein einzelnes Team eine Herausforderung und erfordert daher die Zusammenarbeit verschiedener Teams.
SIGNAL IDUNA hat drei wesentliche Teams, die die Erstellung von ML-Lösungen unterstützen. Umgeben von diesen drei Squads ist das Team, das für die Entwicklung und den langfristigen Betrieb der ML-Lösung verantwortlich ist. Dieser Ansatz folgt dem AWS-Modell der gemeinsamen Verantwortung [2].
Im Bild oben sind alle Squads in einer Übersicht dargestellt.
Cloud-Aktivierung
Die zugrunde liegende Cloud-Infrastruktur für die gesamte Organisation wird vom Squad Cloud Enablement bereitgestellt. Ihre Aufgabe ist es, die Teams zu befähigen, eigenständig Produkte auf Basis von Cloud-Technologien aufzubauen. Dies verkürzt die Zeit bis zur Markteinführung neuer Produkte wie ML und folgt dem Prinzip „You build it, you run it“.
Datenbüro/Data Lake
Das Verschieben von Daten in die Cloud sowie das Finden des richtigen Datensatzes wird durch das Team Data Office/Data Lake unterstützt. Sie richten einen Datenkatalog ein, mit dem benötigte Datensätze gesucht und ausgewählt werden können. Ihr Ziel ist es, Datentransparenz und Governance herzustellen. Darüber hinaus sind sie für die Einrichtung und den Betrieb eines Data Lake verantwortlich, der Teams dabei hilft, auf relevante Daten zuzugreifen und diese zu verarbeiten.
Datenanalyseplattform
Unser Team Data Analytics Platform (DAP) ist ein Cloud- und ML-fokussiertes Team bei SIGNAL IDUNA, das sich mit ML-Engineering, Data Engineering sowie Data Science auskennt. Wir ermöglichen internen Teams die Nutzung der Public Cloud für ML, indem wir Infrastrukturkomponenten und Wissen bereitstellen. Unsere Produkte und Dienstleistungen stellen wir Ihnen im Folgenden ausführlich vor.
Befähigung funktionsübergreifender Teams zum Erstellen von ML-Lösungen
Damit funktionsübergreifende Teams bei SIGNAL IDUNA ML-Lösungen erstellen können, benötigen wir eine schnelle und vielseitige Möglichkeit zur Bereitstellung einer wiederverwendbaren Cloud-Infrastruktur sowie einen effizienten Workflow für Onboarding-Teams zur Nutzung der Cloud-Funktionen.
Dazu haben wir einen standardisierten Onboarding- und Support-Prozess geschaffen und modulare Infrastrukturvorlagen als Infrastructure as Code (IaC) bereitgestellt. Diese Vorlagen enthalten Infrastrukturkomponenten, die für gängige ML-Anwendungsfälle entwickelt wurden und sich leicht an die Anforderungen eines bestimmten Anwendungsfalls anpassen lassen.
Der Workflow zum Erstellen von ML-Lösungen
An der Entwicklung und dem Betrieb von ML-Lösungen sind drei technische Hauptrollen beteiligt: Der Datenwissenschaftler, der ML-Ingenieur und der Dateningenieur. Jede Rolle ist Teil des funktionsübergreifenden Kaders und hat unterschiedliche Verantwortlichkeiten. Der Data Scientist verfügt über das erforderliche Domänenwissen der funktionalen sowie technischen Anforderungen des Anwendungsfalls. Der ML-Ingenieur ist auf den Aufbau automatisierter ML-Lösungen und die Modellbereitstellung spezialisiert. Und der Data Engineer stellt sicher, dass die Daten lokal und in der Cloud fließen.
Der Prozess der Bereitstellung der Plattform ist wie folgt:
Die Infrastruktur des konkreten Anwendungsfalls wird in IaC definiert und in einem zentralen Projektrepository versioniert. Dazu gehören auch Pipelines für Modelltraining und -bereitstellung sowie andere Data-Science-bezogene Codeartefakte. Datenwissenschaftler, ML-Ingenieure und Dateningenieure haben Zugriff auf das Projekt-Repository und können den gesamten Infrastrukturcode autonom konfigurieren und aktualisieren. Dadurch kann das Team die Infrastruktur bei Bedarf schnell ändern. Der ML-Ingenieur kann jedoch jederzeit bei der Entwicklung und Aktualisierung von Infrastruktur- oder ML-Modellen unterstützen.
Wiederverwendbare und modulare Infrastrukturkomponenten
Die hierarchischen und modularen IaC-Ressourcen sind implementiert in Terraform und beinhalten die Infrastruktur für gängige Data-Science- und ETL-Anwendungsfälle. Auf diese Weise können wir Infrastrukturcode wiederverwenden und erforderliche Sicherheits- und Compliance-Richtlinien durchsetzen, z AWS Key Management Service (KMS) Verschlüsselung für Daten sowie Kapselung der Infrastruktur in Amazon Virtual Private Cloud (VPC) Umgebungen ohne direkten Internetzugang.
Die hierarchische IaC-Struktur sieht wie folgt aus:
- Module Kapseln Sie grundlegende AWS-Services mit der erforderlichen Konfiguration für die Sicherheits- und Zugriffsverwaltung. Dazu gehören Best-Practice-Konfigurationen wie die Verhinderung des öffentlichen Zugriffs auf Amazon einfacher Speicherdienst (S3) Buckets oder das Erzwingen der Verschlüsselung für alle gespeicherten Dateien.
- In einigen Fällen benötigen Sie eine Vielzahl von Diensten, um Prozesse zu automatisieren, z. B. um ML-Modelle in verschiedenen Phasen bereitzustellen. Deshalb haben wir definiert Lösungen als Bündel verschiedener Module in gemeinsamer Konfiguration für unterschiedliche Aufgabenstellungen.
- Darüber hinaus bieten wir komplett Blaupausen die Lösungen in verschiedenen Umgebungen kombinieren, um die vielen potenziellen Anforderungen eines Projekts zu erfüllen. In unserem MLOps-Blueprint definieren wir eine bereitstellbare Infrastruktur zum Trainieren, Bereitstellen und Überwachen von ML-Modellen, die in AWS-Konten integriert und verteilt werden. Weitere Einzelheiten besprechen wir im nächsten Abschnitt.
Diese Produkte werden vom DAP-Team in einem zentralen Repository versioniert. Dadurch können wir unsere IaC kontinuierlich verbessern und neue Funktionen von AWS berücksichtigen, wie z Amazon Sage Maker Modellregistrierung. Jedes Squad kann auf diese Ressourcen verweisen, sie nach Bedarf parametrisieren und schließlich in ihren eigenen AWS-Konten bereitstellen.
MLOps-Architektur
Wir bieten einen gebrauchsfertigen Entwurf mit spezifischen Lösungen, um den gesamten MLOps-Prozess abzudecken. Der Blueprint enthält eine auf vier AWS-Konten verteilte Infrastruktur zum Erstellen und Bereitstellen von ML-Modellen. Dadurch können wir Ressourcen und Workflows für die verschiedenen Schritte im MLOps-Prozess isolieren. Die folgende Abbildung zeigt die Multi-Account-Architektur, und wir beschreiben, wie die Verantwortung für bestimmte Schritte des Prozesses zwischen den verschiedenen technischen Rollen aufgeteilt wird.
Das Modellieren Konto umfasst Dienste für die Entwicklung von ML-Modellen. Zunächst nutzt der Data Engineer einen ETL-Prozess, um relevante Daten aus dem SIGNAL IDUNA Data Lake bereitzustellen, dem zentralen Gateway für datengesteuerte Workflows in der AWS Cloud. Anschließend kann der Datensatz vom Datenwissenschaftler verwendet werden, um Modellkandidaten zu trainieren und zu bewerten. Sobald ein Modellkandidat für umfangreiche Experimente bereit ist, wird er vom ML-Ingenieur in eine automatisierte Trainingspipeline integriert. Wir verwenden Amazon SageMaker Pipelines, um Training, Hyperparameter-Tuning und Modellevaluierung im großen Maßstab zu automatisieren. Dazu gehören auch die Modellherkunft und ein standardisierter Genehmigungsmechanismus für Modelle, die für den Einsatz in der Produktion bereitgestellt werden sollen. Automatisierte Unit-Tests und Codeanalysen stellen die Qualität und Zuverlässigkeit des Codes für jeden Schritt der Pipeline sicher, wie z. B. Datenvorverarbeitung, Modelltraining und Evaluierung. Sobald ein Modell bewertet und genehmigt wurde, verwenden wir Amazon SageMaker ModelPackages als Schnittstelle zum trainierten Modell und den relevanten Metadaten.
Das Das Konto enthält automatisierte CI/CD-Pipelines mit verschiedenen Phasen zum Testen und Bereitstellen von trainierten Modellen. In der Testphase werden Modelle in die bereitgestellt Servier-Nonprod Konto. Obwohl die Modellqualität in der Trainingspipeline bewertet wird, bevor das Modell für die Produktion bereitgestellt wird, führen wir hier Leistungs- und Integrationstests in einer isolierten Testumgebung durch. Nachdem die Testphase bestanden wurde, werden die Modelle im bereitgestellt Servierprod Konto in Produktionsabläufe integriert werden.
Durch die Trennung der Phasen des MLOps-Workflows in verschiedene AWS-Konten können wir Entwicklung und Tests von der Produktion trennen. Daher können wir eine strenge Zugriffs- und Sicherheitsrichtlinie durchsetzen. Darüber hinaus stellen maßgeschneiderte IAM-Rollen sicher, dass bestimmte Dienste nur auf Daten und andere Dienste zugreifen können, die für ihren Umfang erforderlich sind, und zwar gemäß der Prinzip des geringsten Privilegs. Services innerhalb der Serving-Umgebungen können zusätzlich für externe Geschäftsprozesse zugänglich gemacht werden. Beispielsweise kann ein Geschäftsprozess einen Endpunkt innerhalb der Serving-Prod-Umgebung nach Modellvorhersagen abfragen.
Vorteile unseres Ansatzes
Dieses Vorgehen hat viele Vorteile gegenüber einer strikten Trennung von Entwicklung und Betrieb sowohl der ML-Modelle als auch der benötigten Infrastruktur:
- Isolation: Jedes Team erhält seinen eigenen Satz von AWS-Konten, die vollständig von den Umgebungen anderer Teams isoliert sind. Dies macht es einfach, Zugriffsrechte zu verwalten und die Daten für diejenigen geheim zu halten, die berechtigt sind, damit zu arbeiten.
- Cloud-Aktivierung: Teammitglieder mit wenig Vorerfahrung in Cloud-DevOps (wie viele Data Scientists) können den gesamten Prozess des Entwerfens und Verwaltens der Infrastruktur leicht beobachten, da ihnen (fast) nichts hinter einem zentralen Dienst verborgen ist. Dies schafft ein besseres Verständnis der Infrastruktur, was ihnen wiederum dabei helfen kann, Data-Science-Produkte effizienter zu erstellen.
- Produktbesitz: Der Einsatz von vorkonfigurierten Infrastrukturlösungen und Managed Services hält die Hürde zur Verwaltung eines ML-Produkts in der Produktion sehr gering. Daher kann ein Data Scientist problemlos ein Modell übernehmen, das in Produktion genommen wird. Dadurch wird das bekannte Risiko minimiert, ein Modell nach der Entwicklung nicht in Produktion zu bringen.
- Innovation: Da ML-Ingenieure schon lange eingebunden werden, bevor ein Modell produktionsreif ist, können sie Infrastrukturlösungen erstellen, die für neue Anwendungsfälle geeignet sind, während die Data Scientists ein ML-Modell entwickeln.
- Flexibilität: Da die von DAP entwickelten IaC-Lösungen frei verfügbar sind, kann jedes Team diese leicht an die spezifischen Anforderungen ihres Anwendungsfalls anpassen.
- Open Source: Alle neuen Infrastrukturlösungen können einfach über das zentrale DAP-Code-Repository zur Verfügung gestellt werden, um von anderen Teams verwendet zu werden. Im Laufe der Zeit entsteht so eine reichhaltige Codebasis mit Infrastrukturkomponenten, die auf unterschiedliche Anwendungsfälle zugeschnitten sind.
Zusammenfassung
In diesem Beitrag haben wir gezeigt, wie funktionsübergreifende Teams bei SIGNAL IDUNA in die Lage versetzt werden, ML-Produkte auf AWS zu entwickeln und auszuführen. Im Mittelpunkt unseres Ansatzes steht die Verwendung eines dedizierten Satzes von AWS-Konten für jedes Team in Kombination mit maßgeschneiderten IaC-Blaupausen und -Lösungen. Diese beiden Komponenten ermöglichen es einem funktionsübergreifenden Team, eine Qualitätsinfrastruktur für die Produktion aufzubauen und zu betreiben. Im Gegenzug können sie die vollständige End-to-End-Inhaberschaft für ihre ML-Produkte übernehmen.
Beziehen auf Amazon SageMaker-Modellerstellungspipelines – Amazon SageMaker um mehr zu erfahren.
Weitere Informationen finden Sie unter ML auf AWS auf unserer offiziellen Seite.
Bibliographie
[1] https://www.handelsblatt.com/finanzen/versicherungsbranche-vorbild-spotify-signal-iduna-wird-von-einer-handwerker-versicherung-zum-agilen-konzern/27381902.html
[2] https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
[3] https://aws.amazon.com/compliance/shared-responsibility-model/
Über die Autoren
Jan Paul Assendorf ist ein ML-Ingenieur mit einem starken Fokus auf Data Science. Er erstellt ML-Modelle und automatisiert das Modelltraining und die Bereitstellung in Produktionsumgebungen.
Thomas Lietzow ist der Scrum Master der Squad Data Analytics Platform.
Christoph Masch ist der Product Owner der Squad Data Analytics Platform mit Kenntnissen in Data Engineering, Data Science und ML Engineering.
Alexander Meinert ist Teil des Data Analytics Platform-Teams und arbeitet als ML-Ingenieur. Begann mit Statistik, wuchs in Data-Science-Projekten, fand Leidenschaft für ML-Methoden und -Architektur.
Dr. Lars Palzer ist Data Scientist und Teil des Teams der Data Analytics Platform. Nachdem er beim Erstellen der MLOps-Architekturkomponenten geholfen hat, verwendet er sie nun zum Erstellen von ML-Produkten.
Jan Schillemans ist ein ML-Ingenieur mit einem Software-Engineering-Hintergrund. Er konzentriert sich auf die Anwendung von Best Practices im Software-Engineering auf ML-Umgebungen (MLOps).
- Coinsmart. Europas beste Bitcoin- und Krypto-Börse.
- Platoblockkette. Web3-Metaverse-Intelligenz. Wissen verstärkt. DEN FREIEN ZUGANG.
- CryptoHawk. Altcoin-Radar. Kostenlose Testphase.
- Quelle: https://aws.amazon.com/blogs/machine-learning/how-signal-iduna-operationalizes-machine-learning-projects-on-aws/
- "
- 100
- 2021
- Zugang
- Konto
- über
- Action
- Vorteilen
- agil
- Alle
- Obwohl
- Amazon
- Analyse
- Analytik
- Anwendung
- Ansatz
- Architektur
- Automatisiert
- verfügbar
- AWS
- Sein
- BESTE
- Best Practices
- bauen
- Building
- bündeln
- Geschäft
- Fähigkeiten
- Fälle
- challenges
- Cloud
- Cloud-Infrastruktur
- Code
- Zusammenarbeit
- Kombination
- gemeinsam
- Unternehmen
- verglichen
- Compliance
- Konfiguration
- enthält
- Erstellen
- technische Daten
- Datenanalyse
- Datenwissenschaft
- Datenwissenschaftler
- gewidmet
- einsetzen
- Bereitstellen
- Einsatz
- Entwerfen
- Detail
- entwickeln
- entwickelt
- Entwicklung
- Entwicklung
- anders
- diskutieren
- verteilt
- Domain
- leicht
- Verschlüsselung
- Endpunkt
- Ingenieur
- Entwicklung
- Ingenieure
- Arbeitsumfeld
- essential
- etablieren
- Beispiel
- ERFAHRUNGEN
- FAST
- Eigenschaften
- Abbildung
- Endlich
- Vorname
- Setzen Sie mit Achtsamkeit
- konzentriert
- Folgende
- gefunden
- Foundation
- Unser Ansatz
- voller
- Ziele
- Governance
- Hilfe
- hilft
- hier
- Ultraschall
- HTTPS
- Image
- umgesetzt
- wichtig
- zu unterstützen,
- das
- Information
- Infrastruktur
- Versicherung
- integriert
- Integration
- Schnittstelle
- Internet
- beteiligt
- IT
- Wesentliche
- Wissen
- grosse
- LERNEN
- lernen
- wenig
- Lang
- Maschine
- Maschinelles Lernen
- Management
- flächendeckende Gesundheitsprogramme
- Markt
- Marketing
- Spiel
- Mitglieder
- Meta
- ML
- Modell
- für
- modulare
- Überwachung
- Neue Funktionen
- neue Produkte
- bieten
- offiziell
- Einsteigen
- die
- Organisation
- Andere
- Eigentümer
- Leistung
- Plattform
- Politik durchzulesen
- Datenschutzrichtlinien
- Prognose
- Prognosen
- abwehr
- privat
- Prozessdefinierung
- anpassen
- Produkt
- Produktion
- Produkte
- Programm
- Projekt
- Projekte
- die
- Öffentlichkeit
- Public Cloud
- Qualität
- Quelle
- falls angefordert
- Voraussetzungen:
- Downloads
- für ihren Verlust verantwortlich.
- Überprüfen
- Risiko
- Führen Sie
- Skalieren
- Wissenschaft
- Wissenschaftler
- Wissenschaftler
- Suche
- Sicherheitdienst
- Leistungen
- Dienst
- kompensieren
- von Locals geführtes
- Einfacher
- Software
- Softwareentwicklung
- Lösungen
- spezialisiert
- verbringen
- Stufe
- Anfang
- begonnen
- Statistiken
- Lagerung
- Strategie
- stark
- Anschließend
- Support
- Unterstützte
- umgeben
- und Aufgaben
- Team
- Technische
- Technologies
- Test
- Testen
- Tests
- Zeit
- Ausbildung
- Transformation
- Transparenz
- Aktualisierung
- us
- -
- Nutzen
- Assistent
- Ansehen
- WHO
- .
- ohne
- Arbeiten
- Belegschaft
- Werk