Dette indlæg er skrevet sammen med Jan Paul Assendorp, Thomas Lietzow, Christopher Masch, Alexander Meinert, Dr. Lars Palzer, Jan Schillemans fra SIGNAL IDUNA.
Hos SIGNAL IDUNA, et stort tysk forsikringsselskab, genopfinder vi i øjeblikket os selv med vores transformationsprogram VISION2023 for at blive endnu mere kundeorienterede. To aspekter er centrale i denne transformation: omorganiseringen af store dele af arbejdsstyrken til tværfunktionelle og agile teams og at blive en virkelig datadrevet virksomhed. Her er mottoet "You build it, you run it" et vigtigt krav for et tværfunktionelt team, der bygger et data- eller machine learning (ML) produkt. Dette sætter snævre begrænsninger for, hvor meget arbejde teamet kan bruge på at producere og drive et produkt.
Dette indlæg viser, hvordan SIGNAL IDUNA tackler denne udfordring og udnytter AWS Cloud at gøre det muligt for tværfunktionelle teams at bygge og operationalisere deres egne ML-produkter. Til dette formål introducerer vi først den organisatoriske struktur af agile teams, som sætter de centrale krav til den cloud-infrastruktur, der bruges til at udvikle og drive et produkt. Dernæst viser vi, hvordan tre centrale teams hos SIGNAL IDUNA gør det muligt for tværfunktionelle teams at bygge dataprodukter i AWS Cloud med minimal assistance, ved at levere et passende workflow og infrastrukturløsninger, der nemt kan bruges og tilpasses. Til sidst gennemgår vi vores tilgang og sammenligner den med en mere klassisk tilgang, hvor udvikling og drift adskilles strengere.
Agile@SI – grundlaget for organisatorisk forandring
Siden starten af 2021 er SIGNAL IDUNA begyndt at sætte sin strategi Agile@SI ud i livet og etablere agile metoder til at udvikle kundeorienterede løsninger på tværs af hele virksomheden [1]. Tidligere opgaver og mål varetages nu af tværgående teams, kaldet squads. Disse hold anvender agile metoder (såsom Scrum-rammerne), træffer deres egne beslutninger og bygger kundeorienterede produkter. Typisk er squads placeret i forretningsdivisioner, såsom marketing, og mange har stor vægt på at bygge datadrevne og ML-drevne produkter. Som et eksempel er typiske use cases i forsikring kundeafgang forudsigelse og produktanbefaling.
På grund af kompleksiteten af ML er det udfordrende at skabe en ML-løsning af et enkelt hold, og det kræver derfor samarbejde mellem forskellige hold.
SIGNAL IDUNA har tre essentielle teams, der understøtter at skabe ML-løsninger. Omgivet af disse tre hold er det team, der er ansvarlig for udviklingen og den langsigtede drift og af ML-løsningen. Denne tilgang følger AWS delt ansvarsmodel [2].
På billedet ovenfor er alle trupperne repræsenteret i en oversigt.
Cloud-aktivering
Den underliggende cloud-infrastruktur for hele organisationen leveres af holdet Cloud Enablement. Det er deres opgave at sætte teamene i stand til at bygge produkter på cloud-teknologier på egen hånd. Dette forbedrer tiden til at markedsføre nye produkter som ML, og det følger princippet om "You build it, you run it".
Datakontor/Data Lake
Flytning af data ind i skyen, samt at finde det rigtige datasæt, understøttes af holdet Data Office/Data Lake. De opretter et datakatalog, der kan bruges til at søge og vælge nødvendige datasæt. Deres mål er at etablere datagennemsigtighed og styring. Derudover er de ansvarlige for at etablere og drive en Data Lake, der hjælper teams med at få adgang til og behandle relevante data.
Dataanalyseplatform
Vores squad Data Analytics Platform (DAP) er et cloud- og ML-fokuseret team hos SIGNAL IDUNA, som er dygtige i ML-teknik, datateknik samt datavidenskab. Vi aktiverer interne teams, der bruger public cloud til ML ved at levere infrastrukturkomponenter og viden. Vores produkter og tjenester præsenteres i detaljer i det følgende afsnit.
Gør det muligt for tværfunktionelle teams at bygge ML-løsninger
For at gøre det muligt for tværfunktionelle teams hos SIGNAL IDUNA at bygge ML-løsninger, har vi brug for en hurtig og alsidig måde at levere genanvendelig cloud-infrastruktur samt en effektiv arbejdsgang for onboarding-teams til at udnytte cloud-kapaciteterne.
Til dette formål skabte vi en standardiseret onboarding- og supportproces og leverede modulære infrastrukturskabeloner som Infrastructure as Code (IaC). Disse skabeloner indeholder infrastrukturkomponenter designet til almindelige ML use cases, som nemt kan skræddersyes til kravene i en specifik use case.
Workflowet ved at bygge ML-løsninger
Der er tre tekniske hovedroller involveret i at bygge og drive ML-løsninger: Dataforskeren, ML-ingeniøren og en dataingeniør. Hver rolle er en del af den tværfunktionelle trup og har forskellige ansvarsområder. Dataforskeren har den nødvendige domæneviden om funktionelle såvel som tekniske krav til use casen. ML-ingeniøren har specialiseret sig i at bygge automatiserede ML-løsninger og modelimplementering. Og dataingeniøren sørger for, at data flyder fra on-premises og inde i skyen.
Processen med at levere platformen er som følger:
Infrastrukturen for den specifikke use case er defineret i IaC og versioneret i et centralt projektlager. Dette inkluderer også pipelines til modeltræning og -implementering samt andre datavidenskabsrelaterede kodeartefakter. Dataforskere, ML-ingeniører og dataingeniører har adgang til projektets lager og kan konfigurere og opdatere al infrastrukturkoden selvstændigt. Dette gør det muligt for teamet hurtigt at ændre infrastrukturen, hvis det er nødvendigt. ML-ingeniøren kan dog altid støtte i udvikling og opdatering af infrastruktur eller ML-modeller.
Genanvendelige og modulære infrastrukturkomponenter
De hierarkiske og modulære IaC-ressourcer er implementeret i terraform og inkludere infrastruktur til almindelig datavidenskab og ETL-brugssager. Dette lader os genbruge infrastrukturkode og håndhæve nødvendige sikkerheds- og overholdelsespolitikker, såsom brug AWS Key Management Service (KMS) kryptering af data, samt indkapsling af infrastruktur i Amazon Virtual Private Cloud (VPC) miljøer uden direkte internetadgang.
Den hierarkiske IaC-struktur er som følger:
- Moduler indkapsle grundlæggende AWS-tjenester med den nødvendige konfiguration til sikkerhed og adgangsstyring. Dette omfatter konfigurationer af bedste praksis såsom forebyggelse af offentlig adgang til Amazon Simple Storage Service (S3) buckets eller håndhævelse af kryptering for alle lagrede filer.
- I nogle tilfælde har du brug for en række tjenester for at automatisere processer, såsom at implementere ML-modeller i forskellige stadier. Derfor definerede vi Løsninger som et bundt af forskellige moduler i en fælles konfiguration til forskellige typer opgaver.
- Derudover tilbyder vi komplet blueprints der kombinerer løsninger i forskellige miljøer for at imødekomme et projekts mange potentielle behov. I vores MLOps-plan definerer vi en deployerbar infrastruktur til træning, levering og overvågning af ML-modeller, der er integreret og distribueret i AWS-konti. Vi diskuterer yderligere detaljer i næste afsnit.
Disse produkter er versioneret i et centralt lager af DAP-teamet. Dette lader os løbende forbedre vores IaC og overveje nye funktioner fra AWS, som f.eks Amazon SageMaker Modelregister. Hvert hold kan referere til disse ressourcer, parametrere dem efter behov og til sidst implementere dem i deres egne AWS-konti.
MLOps arkitektur
Vi leverer en klar-til-brug plan med specifikke løsninger til at dække hele MLOps-processen. Planen indeholder infrastruktur fordelt på fire AWS-konti til opbygning og implementering af ML-modeller. Dette lader os isolere ressourcer og arbejdsgange for de forskellige trin i MLOps-processen. Følgende figur viser multi-account arkitekturen, og vi beskriver, hvordan ansvaret over specifikke trin i processen er fordelt mellem de forskellige tekniske roller.
modellering konto omfatter tjenester til udvikling af ML-modeller. For det første anvender dataingeniøren en ETL-proces til at levere relevante data fra SIGNAL IDUNA-datasøen, den centraliserede gateway for datadrevne arbejdsgange i AWS Cloud. Efterfølgende kan datasættet bruges af dataforskeren til at træne og evaluere modelkandidater. Når først klar til omfattende eksperimenter, integreres en modelkandidat i en automatiseret træningspipeline af ML-ingeniøren. Vi bruger Amazon SageMaker Pipelines til at automatisere træning, justering af hyperparameter og modelevaluering i skala. Dette omfatter også modelafstamning og en standardiseret godkendelsesmekanisme for modeller, der skal iscenesættes til implementering i produktion. Automatiserede enhedstests og kodeanalyse sikrer kvalitet og pålidelighed af koden for hvert trin i pipelinen, såsom dataforbehandling, modeltræning og evaluering. Når en model er evalueret og godkendt, bruger vi Amazon SageMaker ModelPackages som en grænseflade til den trænede model og relevante metadata.
værktøj konto indeholder automatiserede CI/CD-pipelines med forskellige stadier til test og implementering af trænede modeller. I testfasen indsættes modeller i servering-nonprod konto. Selvom modelkvalitet evalueres i træningspipelinen, før modellen iscenesættes til produktion, kører vi her præstations- og integrationstest i et isoleret testmiljø. Efter at have bestået teststadiet, implementeres modeller i serverings-prod konto, der skal integreres i produktionsarbejdsgange.
Ved at adskille faserne af MLOps-arbejdsgangen i forskellige AWS-konti lader os isolere udvikling og test fra produktion. Derfor kan vi håndhæve en streng adgangs- og sikkerhedspolitik. Ydermere sikrer skræddersyede IAM-roller, at specifikke tjenester kun kan få adgang til data og andre tjenester, der kræves for dets omfang, efter princippet om mindst privilegium. Tjenester inden for serveringsmiljøerne kan desuden gøres tilgængelige for eksterne forretningsprocesser. For eksempel kan en forretningsproces forespørge et slutpunkt i serverings-prod-miljøet for modelforudsigelser.
Fordele ved vores tilgang
Denne proces har mange fordele sammenlignet med en streng adskillelse af udvikling og drift for både ML-modellerne såvel som den nødvendige infrastruktur:
- Isolation: Hvert team modtager deres eget sæt AWS-konti, der er fuldstændig isoleret fra andre teams miljøer. Dette gør det nemt at administrere adgangsrettigheder og holde dataene private for dem, der har ret til at arbejde med dem.
- Cloud-aktivering: Teammedlemmer med ringe tidligere erfaring med cloud-DevOps (såsom mange dataforskere) kan nemt se hele processen med at designe og administrere infrastruktur, da (næsten) intet er skjult for dem bag en central tjeneste. Dette skaber en bedre forståelse af infrastrukturen, hvilket igen kan hjælpe dem med at skabe data science-produkter mere effektivt.
- Produktejerskab: Brugen af prækonfigurerede infrastrukturløsninger og administrerede tjenester holder barrieren for at administrere et ML-produkt i produktion meget lav. Derfor kan en data scientist sagtens tage ejerskab over en model, der sættes i produktion. Dette minimerer den velkendte risiko for ikke at sætte en model i produktion efter udvikling.
- Innovation: Da ML-ingeniører er involveret længe før en model er klar til at blive sat i produktion, kan de skabe infrastrukturløsninger, der egner sig til nye use cases, mens dataforskerne udvikler en ML-model.
- Tilpasningsevne: Da IaC-løsningen udviklet af DAP er frit tilgængelig, kan ethvert team nemt tilpasse disse til at matche et specifikt behov for deres use case.
- Open source: Alle nye infrastrukturløsninger kan nemt gøres tilgængelige via den centrale DAP-koderepo til brug for andre teams. Over tid vil dette skabe en rig kodebase med infrastrukturkomponenter, der er skræddersyet til forskellige use cases.
Resumé
I dette indlæg illustrerede vi, hvordan tværfunktionelle teams hos SIGNAL IDUNA bliver sat i stand til at bygge og køre ML-produkter på AWS. Det centrale i vores tilgang er brugen af et dedikeret sæt AWS-konti til hvert team i kombination med skræddersyede IaC-planer og -løsninger. Disse to komponenter gør det muligt for et tværfunktionelt team at skabe og drive produktionskvalitetsinfrastruktur. Til gengæld kan de tage fuldt end-to-end ejerskab af deres ML-produkter.
Der henvises til Amazon SageMaker Model Building Pipelines – Amazon SageMaker at lære mere.
Find mere information om ML på AWS på vores officielle side.
Referencer
[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/
Om forfatterne
Jan Paul Assendorp er en ML-ingeniør med et stærkt datavidenskabsfokus. Han bygger ML-modeller og automatiserer modeltræning og implementering i produktionsmiljøer.
Thomas Lietzow er Scrum Master of the squad Data Analytics Platform.
Christopher Masch er Product Owner af teamet Data Analytics Platform med viden inden for data engineering, data science og ML engineering.
Alexander Meinert er en del af Data Analytics Platform-teamet og arbejder som ML-ingeniør. Startede med statistik, voksede på datavidenskabelige projekter, fandt passion for ML metoder og arkitektur.
læge Lars Palzer er data scientist og en del af Data Analytics Platform-teamet. Efter at have hjulpet med at bygge MLOps-arkitekturkomponenterne, bruger han dem nu til at bygge ML-produkter.
Jan Schillemans er en ML-ingeniør med en softwareingeniørbaggrund. Han fokuserer på at anvende software engineering best practices på ML-miljøer (MLOps).
- "
- 100
- 2021
- adgang
- Konto
- tværs
- Handling
- fordele
- adræt
- Alle
- Skønt
- Amazon
- analyse
- analytics
- Anvendelse
- tilgang
- arkitektur
- Automatiseret
- til rådighed
- AWS
- være
- BEDSTE
- bedste praksis
- bygge
- Bygning
- Bundle
- virksomhed
- kapaciteter
- tilfælde
- udfordre
- Cloud
- sky infrastruktur
- kode
- samarbejde
- kombination
- Fælles
- selskab
- sammenlignet
- Compliance
- Konfiguration
- indeholder
- Oprettelse af
- data
- Dataanalyse
- datalogi
- dataforsker
- dedikeret
- indsætte
- implementering
- implementering
- designe
- detail
- udvikle
- udviklet
- udvikling
- Udvikling
- forskellige
- diskutere
- distribueret
- domæne
- nemt
- kryptering
- Endpoint
- ingeniør
- Engineering
- Ingeniører
- Miljø
- væsentlig
- etablere
- eksempel
- erfaring
- FAST
- Funktionalitet
- Figur
- Endelig
- Fornavn
- Fokus
- fokuserede
- efter
- fundet
- Foundation
- Framework
- fuld
- Mål
- regeringsførelse
- hjælpe
- hjælper
- link.
- Hvordan
- HTTPS
- billede
- implementeret
- vigtigt
- Forbedre
- omfatter
- oplysninger
- Infrastruktur
- forsikring
- integreret
- integration
- grænseflade
- Internet
- involverede
- IT
- Nøgle
- viden
- stor
- LÆR
- læring
- lidt
- Lang
- maskine
- machine learning
- ledelse
- styring
- Marked
- Marketing
- Match
- Medlemmer
- Meta
- ML
- model
- modeller
- modulær
- overvågning
- Nye funktioner
- nye produkter
- tilbyde
- officiel
- onboarding
- drift
- organisation
- Andet
- ejer
- ydeevne
- perron
- politikker
- politik
- forudsigelse
- Forudsigelser
- Forebyggelse
- private
- behandle
- Processer
- Produkt
- produktion
- Produkter
- Program
- projekt
- projekter
- give
- offentlige
- Offentlig sky
- kvalitet
- Repository
- påkrævet
- Krav
- Ressourcer
- ansvarlige
- gennemgå
- Risiko
- Kør
- Scale
- Videnskab
- Videnskabsmand
- forskere
- Søg
- sikkerhed
- tjeneste
- Tjenester
- servering
- sæt
- delt
- Simpelt
- Software
- software Engineering
- Løsninger
- specialiseret
- tilbringe
- Stage
- starte
- påbegyndt
- statistik
- opbevaring
- Strategi
- stærk
- Efterfølgende
- support
- Understøttet
- omgivet
- opgaver
- hold
- Teknisk
- Teknologier
- prøve
- Test
- tests
- tid
- Kurser
- Transformation
- Gennemsigtighed
- Opdatering
- us
- brug
- udnytte
- Virtual
- Ur
- WHO
- inden for
- uden
- Arbejde
- Workforce
- virker