Detta inlägg har skrivits tillsammans med Jan Paul Assendorp, Thomas Lietzow, Christopher Masch, Alexander Meinert, Dr Lars Palzer, Jan Schillemans från SIGNAL IDUNA.
På SIGNAL IDUNA, ett stort tyskt försäkringsbolag, uppfinner vi för närvarande oss själva med vårt transformationsprogram VISION2023 för att bli ännu mer kundorienterade. Två aspekter är centrala i denna omvandling: omorganisationen av stora delar av personalstyrkan till tvärfunktionella och agila team, och att bli ett verkligt datadrivet företag. Här är mottot "You build it, you run it" ett viktigt krav för ett tvärfunktionellt team som bygger en data- eller maskininlärningsprodukt (ML). Detta sätter snäva begränsningar för hur mycket arbete team kan spendera för att producera och driva en produkt.
Det här inlägget visar hur SIGNAL IDUNA tacklar denna utmaning och använder AWS Cloud för att möjliggöra tvärfunktionella team att bygga och operationalisera sina egna ML-produkter. För detta ändamål introducerar vi först den organisatoriska strukturen för agila team, som ställer de centrala kraven för den molninfrastruktur som används för att utveckla och driva en produkt. Därefter visar vi hur tre centrala team på SIGNAL IDUNA gör det möjligt för tvärfunktionella team att bygga dataprodukter i AWS-molnet med minimal assistans, genom att tillhandahålla ett lämpligt arbetsflöde och infrastrukturlösningar som enkelt kan användas och anpassas. Slutligen ser vi över vårt tillvägagångssätt och jämför det med ett mer klassiskt tillvägagångssätt där utveckling och drift är strängare åtskilda.
Agile@SI – grunden för organisatorisk förändring
Sedan starten av 2021 har SIGNAL IDUNA börjat omsätta sin strategi Agile@SI i handling och etablera agila metoder för att utveckla kundorienterade lösningar över hela företaget [1]. Tidigare uppgifter och mål sköts nu av tvärfunktionella team, så kallade trupper. Dessa grupper använder agila metoder (som Scrum-ramverket), fattar sina egna beslut och bygger kundorienterade produkter. Vanligtvis är grupperna placerade i affärsdivisioner, såsom marknadsföring, och många har en stark tonvikt på att bygga datadrivna och ML-drivna produkter. Som ett exempel är typiska användningsfall inom försäkringar kundavgångsförutsägelser och produktrekommendationer.
På grund av komplexiteten i ML är det utmanande att skapa en ML-lösning av en enda trupp och kräver därför samarbete mellan olika grupper.
SIGNAL IDUNA har tre viktiga team som stödjer att skapa ML-lösningar. Omgiven av dessa tre trupper finns teamet som ansvarar för utvecklingen och den långsiktiga driften och av ML-lösningen. Detta tillvägagångssätt följer AWS-modellen för delat ansvar [2].
På bilden ovan är alla trupper representerade i en översikt.
Molnaktivering
Den underliggande molninfrastrukturen för hela organisationen tillhandahålls av truppen Cloud Enablement. Det är deras uppgift att göra det möjligt för teamen att bygga produkter på molnteknik på egen hand. Detta förbättrar tiden för att marknadsföra nya produkter som ML, och det följer principen "Du bygger det, du kör det".
Datakontor/Datasjö
Att flytta data till molnet, såväl som att hitta rätt datauppsättning, stöds av truppen Data Office/Data Lake. De skapar en datakatalog som kan användas för att söka och välja nödvändiga datauppsättningar. Deras mål är att etablera datatransparens och styrning. Dessutom är de ansvariga för att etablera och driva en Data Lake som hjälper team att komma åt och bearbeta relevant data.
Dataanalysplattform
Vår squad Data Analytics Platform (DAP) är ett moln- och ML-fokuserat team på SIGNAL IDUNA som är skickliga inom ML-teknik, datateknik och datavetenskap. Vi möjliggör för interna team som använder offentliga moln för ML genom att tillhandahålla infrastrukturkomponenter och kunskap. Våra produkter och tjänster presenteras i detalj i följande avsnitt.
Gör det möjligt för tvärfunktionella team att bygga ML-lösningar
För att göra det möjligt för tvärfunktionella team på SIGNAL IDUNA att bygga ML-lösningar behöver vi ett snabbt och mångsidigt sätt att tillhandahålla återanvändbar molninfrastruktur samt ett effektivt arbetsflöde för onboarding-team för att utnyttja molnkapaciteten.
För detta ändamål skapade vi en standardiserad onboarding- och supportprocess, och tillhandahöll modulära infrastrukturmallar som Infrastructure as Code (IaC). Dessa mallar innehåller infrastrukturkomponenter utformade för vanliga ML-användningsfall som enkelt kan skräddarsys efter kraven i ett specifikt användningsfall.
Arbetsflödet för att bygga ML-lösningar
Det finns tre huvudsakliga tekniska roller involverade i att bygga och driva ML-lösningar: datavetaren, ML-ingenjören och en dataingenjör. Varje roll är en del av den tvärfunktionella truppen och har olika ansvarsområden. Datavetaren har den nödvändiga domänkunskapen om funktionella såväl som tekniska krav för användningsfallet. ML-ingenjören är specialiserad på att bygga automatiserade ML-lösningar och modelldistribution. Och dataingenjören ser till att data flödar från lokaler och inom molnet.
Processen för att tillhandahålla plattformen är som följer:
Infrastrukturen för det specifika användningsfallet definieras i IaC och versioneras i ett centralt projektförråd. Detta inkluderar även pipelines för modellträning och implementering, såväl som andra datavetenskapsrelaterade kodartefakter. Datavetare, ML-ingenjörer och dataingenjörer har tillgång till projektförrådet och kan konfigurera och uppdatera all infrastrukturkod autonomt. Detta gör det möjligt för teamet att snabbt ändra infrastrukturen vid behov. Däremot kan ML-ingenjören alltid stödja vid utveckling och uppdatering av infrastruktur eller ML-modeller.
Återanvändbara och modulära infrastrukturkomponenter
De hierarkiska och modulära IaC-resurserna implementeras i Terraform och inkluderar infrastruktur för gemensam datavetenskap och ETL-användningsfall. Detta låter oss återanvända infrastrukturkod och upprätthålla nödvändiga säkerhets- och efterlevnadspolicyer, som att använda AWS Key Management Service (KMS) kryptering för data, samt inkapsling av infrastruktur i Amazon Virtual Private Cloud (VPC) miljöer utan direkt internetåtkomst.
Den hierarkiska IaC-strukturen är som följer:
- Moduler kapsla in grundläggande AWS-tjänster med den nödvändiga konfigurationen för säkerhet och åtkomsthantering. Detta inkluderar konfigurationer av bästa praxis som att förhindra allmänhetens tillgång till Amazon Simple Storage Service (S3) hinkar, eller genomdriva kryptering för alla lagrade filer.
- I vissa fall behöver du en mängd olika tjänster för att automatisera processer, till exempel för att distribuera ML-modeller i olika steg. Därför definierade vi Lösningar som en bunt av olika moduler i en gemensam konfiguration för olika typer av uppgifter.
- Dessutom erbjuder vi komplett Ritningar som kombinerar lösningar i olika miljöer för att möta ett projekts många potentiella behov. I vår MLOps-ritning definierar vi en implementeringsbar infrastruktur för utbildning, provisionering och övervakning av ML-modeller som är integrerade och distribuerade i AWS-konton. Vi diskuterar ytterligare detaljer i nästa avsnitt.
Dessa produkter är versionerade i ett centralt arkiv av DAP-teamet. Detta låter oss kontinuerligt förbättra vår IaC och överväga nya funktioner från AWS, som t.ex Amazon SageMaker Modellregister. Varje lag kan referera till dessa resurser, parametrisera dem efter behov och slutligen distribuera dem i sina egna AWS-konton.
MLOps arkitektur
Vi tillhandahåller en färdig att använda ritning med specifika lösningar för att täcka hela MLOps-processen. Ritningen innehåller infrastruktur fördelad över fyra AWS-konton för att bygga och distribuera ML-modeller. Detta låter oss isolera resurser och arbetsflöden för de olika stegen i MLOps-processen. Följande figur visar multi-account arkitekturen och vi beskriver hur ansvaret över specifika steg i processen är fördelat mellan de olika tekniska rollerna.
Smakämnen modellering konto omfattar tjänster för utveckling av ML-modeller. Först använder dataingenjören en ETL-process för att tillhandahålla relevant data från datasjön SIGNAL IDUNA, den centraliserade gatewayen för datadrivna arbetsflöden i AWS-molnet. Därefter kan datauppsättningen användas av datavetaren för att utbilda och utvärdera modellkandidater. När den är redo för omfattande experiment integreras en modellkandidat i en automatiserad utbildningspipeline av ML-ingenjören. Vi använder Amazon SageMaker Pipelines för att automatisera träning, justering av hyperparameter och modellutvärdering i stor skala. Detta inkluderar också modellavstamning och en standardiserad godkännandemekanism för modeller som ska sättas in för driftsättning i produktion. Automatiserade enhetstester och kodanalys säkerställer kodens kvalitet och tillförlitlighet för varje steg i pipelinen, såsom förbearbetning av data, modellträning och utvärdering. När en modell är utvärderad och godkänd använder vi Amazon SageMaker ModelPackages som ett gränssnitt till den tränade modellen och relevant metadata.
Smakämnen verktyg konto innehåller automatiserade CI/CD-pipelines med olika steg för testning och driftsättning av tränade modeller. I teststadiet distribueras modeller i servering-nonprod konto. Även om modellkvalitet utvärderas i utbildningspipelinen innan modellen sätts upp för produktion, kör vi här prestanda- och integrationstester i en isolerad testmiljö. Efter att ha klarat teststadiet distribueras modeller i serverings-prod integreras i produktionsarbetsflöden.
Genom att separera stadierna i MLOps-arbetsflödet i olika AWS-konton kan vi isolera utveckling och testning från produktion. Därför kan vi tillämpa en strikt åtkomst- och säkerhetspolicy. Dessutom säkerställer skräddarsydda IAM-roller att specifika tjänster endast kan komma åt data och andra tjänster som krävs för dess omfattning, efter principen om minst privilegium. Tjänster inom serveringsmiljöerna kan dessutom göras tillgängliga för externa affärsprocesser. Till exempel kan en affärsprocess fråga efter en slutpunkt inom serverings-prod-miljön för modellförutsägelser.
Fördelar med vårt tillvägagångssätt
Denna process har många fördelar jämfört med en strikt separation av utveckling och drift för både ML-modellerna, såväl som den nödvändiga infrastrukturen:
- Isolering: Varje team får sin egen uppsättning AWS-konton som är helt isolerade från andra teams miljöer. Detta gör det enkelt att hantera åtkomsträttigheter och hålla uppgifterna privata för dem som har rätt att arbeta med dem.
- Molnaktivering: Teammedlemmar med liten tidigare erfarenhet av moln DevOps (som många dataforskare) kan enkelt se hela processen med att designa och hantera infrastruktur eftersom (nästan) ingenting är dolt för dem bakom en central tjänst. Detta skapar en bättre förståelse för infrastrukturen, vilket i sin tur kan hjälpa dem att skapa datavetenskapliga produkter mer effektivt.
- Produktägande: Användningen av förkonfigurerade infrastrukturlösningar och hanterade tjänster håller barriären för att hantera en ML-produkt i produktion mycket låg. Därför kan en datavetare enkelt ta äganderätten till en modell som sätts i produktion. Detta minimerar den välkända risken att inte sätta en modell i produktion efter utveckling.
- Innovation: Eftersom ML-ingenjörer är inblandade långt innan en modell är redo att tas i produktion, kan de skapa infrastrukturlösningar som lämpar sig för nya användningsfall samtidigt som datavetarna utvecklar en ML-modell.
- Anpassningsförmåga: Eftersom IaC-lösningen som utvecklats av DAP är fritt tillgänglig kan vilket team som helst enkelt anpassa dessa för att matcha ett specifikt behov för deras användningsfall.
- Öppen källa: Alla nya infrastrukturlösningar kan enkelt göras tillgängliga via den centrala DAP-kodrepo för att användas av andra team. Med tiden kommer detta att skapa en rik kodbas med infrastrukturkomponenter som är skräddarsydda för olika användningsfall.
Sammanfattning
I det här inlägget illustrerade vi hur tvärfunktionella team på SIGNAL IDUNA möjliggörs för att bygga och köra ML-produkter på AWS. Centralt för vårt tillvägagångssätt är användningen av en dedikerad uppsättning AWS-konton för varje team i kombination med skräddarsydda IaC-ritningar och lösningar. Dessa två komponenter gör det möjligt för ett tvärfunktionellt team att skapa och driva produktionskvalitetsinfrastruktur. I sin tur kan de ta fullständigt ägande av sina ML-produkter.
Hänvisa till Amazon SageMaker Model Building Pipelines – Amazon SageMaker att lära sig mer.
Hitta mer information om ML på AWS på vår officiella sida.
Referensprojekt
[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 författarna
Jan Paul Assendorp är en ML-ingenjör med ett starkt datavetenskapligt fokus. Han bygger ML-modeller och automatiserar modellträning och distribution i produktionsmiljöer.
Thomas Lietzow är Scrum Master of the squad Data Analytics Platform.
Christopher Masch är produktägare för truppen Data Analytics Platform med kunskap inom datateknik, datavetenskap och ML-teknik.
Alexander Meinert är en del av Data Analytics Platform-teamet och arbetar som ML-ingenjör. Började med statistik, växte på datavetenskapliga projekt, hittade passion för ML-metoder och arkitektur.
Dr Lars Palzer är datavetare och en del av Data Analytics Platform-teamet. Efter att ha hjälpt till att bygga MLOps-arkitekturkomponenterna använder han dem nu för att bygga ML-produkter.
Jan Schillemans är en ML-ingenjör med en mjukvaruteknisk bakgrund. Han fokuserar på att tillämpa bästa praxis för mjukvaruteknik på ML-miljöer (MLOps).
- "
- 100
- 2021
- tillgång
- Konto
- tvärs
- Handling
- fördelar
- smidig
- Alla
- Även
- amason
- analys
- analytics
- Tillämpa
- tillvägagångssätt
- arkitektur
- Automatiserad
- tillgänglig
- AWS
- Där vi får lov att vara utan att konstant prestera,
- BÄST
- bästa praxis
- SLUTRESULTAT
- Byggnad
- Bunt
- företag
- kapacitet
- fall
- utmanar
- cloud
- molninfrastruktur
- koda
- samverkan
- kombination
- Gemensam
- företag
- jämfört
- Efterlevnad
- konfiguration
- innehåller
- Skapa
- datum
- Data Analytics
- datavetenskap
- datavetare
- dedicerad
- distribuera
- utplacera
- utplacering
- design
- detalj
- utveckla
- utvecklade
- utveckla
- Utveckling
- olika
- diskutera
- distribueras
- domän
- lätt
- kryptering
- Slutpunkt
- ingenjör
- Teknik
- Ingenjörer
- Miljö
- väsentlig
- etablera
- exempel
- erfarenhet
- SNABB
- Funktioner
- Figur
- Slutligen
- Förnamn
- Fokus
- fokuserade
- efter
- hittade
- fundament
- Ramverk
- full
- Mål
- styrning
- hjälpa
- hjälper
- här.
- Hur ser din drömresa ut
- HTTPS
- bild
- genomföras
- med Esport
- förbättra
- innefattar
- informationen
- Infrastruktur
- försäkring
- integrerade
- integrering
- Gränssnitt
- Internet
- involverade
- IT
- Nyckel
- kunskap
- Large
- LÄRA SIG
- inlärning
- liten
- Lång
- Maskinen
- maskininlärning
- ledning
- hantera
- marknad
- Marknadsföring
- Match
- Medlemmar
- meta
- ML
- modell
- modeller
- modulära
- övervakning
- Nya funktioner
- nya produkter
- erbjudanden
- tjänsteman
- Onboarding
- drift
- organisation
- Övriga
- ägaren
- prestanda
- plattform
- Strategier
- policy
- förutsägelse
- Förutsägelser
- Förebyggande
- privat
- process
- processer
- Produkt
- Produktion
- Produkter
- Program
- projektet
- projekt
- ge
- allmän
- Offentligt moln
- kvalitet
- Repository
- Obligatorisk
- Krav
- Resurser
- ansvarig
- översyn
- Risk
- Körning
- Skala
- Vetenskap
- Forskare
- vetenskapsmän
- Sök
- säkerhet
- service
- Tjänster
- portion
- in
- delas
- Enkelt
- Mjukvara
- mjukvaruutveckling
- Lösningar
- specialiserat
- spendera
- Etapp
- starta
- igång
- statistik
- förvaring
- Strategi
- stark
- Senare
- stödja
- Som stöds
- omgiven
- uppgifter
- grupp
- Teknisk
- Tekniken
- testa
- Testning
- tester
- tid
- Utbildning
- Transformation
- Öppenhet
- Uppdatering
- us
- användning
- utnyttja
- Virtuell
- Kolla på
- VEM
- inom
- utan
- Arbete
- arbetskraft
- fungerar