Hvordan Amazon Search kjører storskala, spenstige maskinlæringsprosjekter med Amazon SageMaker

Hvis du har søkt etter en vare å kjøpe på amazon.com, har du brukt Amazons søketjenester. Hos Amazon Search er vi ansvarlige for søke- og oppdagelsesopplevelsen for våre kunder over hele verden. I bakgrunnen indekserer vi vår verdensomspennende produktkatalog, distribuerer svært skalerbare AWS-flåter og bruker avansert maskinlæring (ML) for å matche relevante og interessante produkter til hver kundes forespørsel.

Våre forskere trener regelmessig tusenvis av ML-modeller for å forbedre kvaliteten på søkeresultatene. Å støtte storskala eksperimentering byr på sine egne utfordringer, spesielt når det gjelder å forbedre produktiviteten til forskerne som trener disse ML-modellene.

I dette innlegget deler vi hvordan vi bygget et styringssystem rundt Amazon SageMaker treningsjobber, slik at forskerne våre kan skyte og glemme tusenvis av eksperimenter og bli varslet ved behov. De kan nå fokusere på oppgaver med høy verdi og å løse algoritmiske feil, og spare 60 % av tiden deres.

Utfordringen

Hos Amazon Search løser forskerne våre problemer med informasjonsinnhenting ved å eksperimentere og kjøre en rekke ML-modellopplæringsjobber på SageMaker. For å holde tritt med teamets innovasjon har modellenes kompleksitet og antall treningsjobber økt over tid. SageMaker opplæringsjobber lar oss redusere tiden og kostnadene for å trene og justere disse modellene i stor skala, uten behov for å administrere infrastruktur.

Som alt annet i slike store ML-prosjekter, kan treningsjobber mislykkes på grunn av en rekke faktorer. Dette innlegget fokuserer på kapasitetsmangel og feil på grunn av algoritmefeil.

Vi designet en arkitektur med et jobbstyringssystem for å tolerere og redusere sannsynligheten for at en jobb mislykkes på grunn av utilgjengelighet av kapasitet eller algoritmefeil. Det lar forskere skyte og glemme tusenvis av treningsjobber, automatisk prøve dem på nytt ved forbigående feil, og bli varslet om suksess eller fiasko om nødvendig.

Løsningsoversikt

I det følgende løsningsdiagrammet bruker vi SageMaker opplæringsjobber som den grunnleggende enheten i løsningen vår. Det vil si at en jobb representerer ende-til-ende opplæring av en ML-modell.

Arbeidsflyten på høyt nivå for denne løsningen er som følger:

1. Forskere påkaller et API for å sende inn en ny jobb til systemet.
2. Jobben er registrert hos New status i et metadatalager.
3. En jobbplanlegger henter asynkront New jobber fra metadatalageret, analyserer innspillene deres og prøver å lansere SageMaker-opplæringsjobber for hver enkelt. Statusen deres endres til Launched or Failed avhengig av suksess.
4. En monitor sjekker jobbfremdriften med jevne mellomrom, og rapporterer deres Completed, Failedeller InProgress tilstand i metadatalageret.
5. En varsler utløses for å rapportere Completed og Failed jobber til forskerne.

Ved å opprettholde jobbhistorikken i metadatalageret kan teamet vårt også gjennomføre trendanalyse og overvåke prosjektfremdrift.

Denne jobbplanleggingsløsningen bruker løst koblede serverløse komponenter basert på AWS Lambda, Amazon DynamoDB, Amazon enkel varslingstjeneste (Amazon SNS), og Amazon EventBridge. Dette sikrer horisontal skalerbarhet, og lar forskerne våre lansere tusenvis av jobber med minimal driftsinnsats. Følgende diagram illustrerer den serverløse arkitekturen.

I de følgende avsnittene går vi nærmere inn på hver tjeneste og dens komponenter.

DynamoDB som metadatalager for jobbkjøringer

Brukervennligheten og skalerbarheten til DynamoDB gjorde det til et naturlig valg å beholde jobbmetadataene i en DynamoDB-tabell. Denne løsningen lagrer flere attributter for jobber som er sendt inn av forskere, og hjelper dermed med fremdriftssporing og arbeidsflytorkestrering. De viktigste egenskapene er som følger:

• JobId – En unik jobb-ID. Dette kan genereres automatisk eller leveres av forskeren.
• Jobb status – Status på jobben.
• JobArgs – Andre argumenter som kreves for å opprette en treningsjobb, for eksempel inngangsbanen i Amazon S3, opplæringsbildet URI og mer. For en fullstendig liste over parametere som kreves for å opprette en opplæringsjobb, se Opprett treningsjobb.

Lambda for kjernelogikken

Vi bruker tre containerbasert Lambda-funksjoner for å orkestrere jobbens arbeidsflyt:

• Send inn jobb – Denne funksjonen påberopes av forskere når de skal lansere nye jobber. Det fungerer som et API for enkelhets skyld. Du kan også fronte den med Amazon API-gateway, hvis nødvendig. Denne funksjonen registrerer jobbene i DynamoDB-tabellen.
• Start Jobs – Denne funksjonen hentes med jevne mellomrom New jobber fra DynamoDB-tabellen og lanserer dem ved hjelp av SageMaker Opprett treningsjobb kommando. Den prøver på nytt på forbigående feil, som f.eks ResourceLimitExceeded og CapacityError, for å instrumentere spenst i systemet. Den oppdaterer deretter jobbstatusen som Launched or Failed avhengig av suksess.
• Overvåk jobber – Denne funksjonen holder med jevne mellomrom oversikt over jobbfremdriften ved å bruke BeskrivTreningJobb kommandoen, og oppdaterer DynamoDB-tabellen tilsvarende. Det avstemninger Failed jobber fra metadataene og vurderer om de skal sendes inn på nytt eller merkes som terminalt mislykkede. Den publiserer også varslingsmeldinger til forskerne når jobbene deres når en terminal tilstand.

EventBridge for planlegging

Vi bruker EventBridge til å kjøre Launch Jobs og Monitor Jobs Lambda-funksjonene etter en tidsplan. For mer informasjon, se Opplæring: Planlegg AWS Lambda-funksjoner ved hjelp av EventBridge.

Alternativt kan du bruke Amazon DynamoDB-strømmer for utløserne. For mer informasjon, se DynamoDB Streams og AWS Lambda utløser.

Varsler med Amazon SNS

Våre forskere er varslet via e-post ved hjelp av Amazon SNS når jobbene deres når en terminal tilstand (Failed etter maksimalt antall forsøk), Completedeller Stopped.

konklusjonen

I dette innlegget delte vi hvordan Amazon Search gir robusthet til ML-modelltreningsarbeidsbelastninger ved å planlegge dem og prøve dem på nytt ved kapasitetsmangel eller algoritmefeil. Vi brukte Lambda-funksjoner i forbindelse med en DynamoDB-tabell som et sentralt metadatalager for å orkestrere hele arbeidsflyten.

Et slikt planleggingssystem lar forskere sende inn jobbene sine og glemme dem. Dette sparer tid og lar dem fokusere på å skrive bedre modeller.

For å gå videre i læringen kan du besøke Fantastisk SageMaker og finn alle de relevante og oppdaterte ressursene som trengs for å jobbe med SageMaker på ett enkelt sted.

---

Om forfatterne

Luochao Wang er programvareingeniør hos Amazon Search. Han fokuserer på skalerbare distribuerte systemer og automatiseringsverktøy på skyen for å akselerere tempoet i vitenskapelig innovasjon for maskinlæringsapplikasjoner.

Ishan Bhatt er programvareingeniør i Amazon Prime Video-teamet. Han jobber hovedsakelig i MLOps-området og har erfaring med å bygge MLOps-produkter de siste 4 årene ved å bruke Amazon SageMaker.

Abhinandan Patni er senior programvareingeniør hos Amazon Search. Han fokuserer på å bygge systemer og verktøy for skalerbar distribuert dyp læringstrening og sanntidsslutning.

Eiman Elnahrawy er en hovedprogramvareingeniør hos Amazon Search som leder arbeidet med maskinlæringsakselerasjon, skalering og automatisering. Hennes ekspertise spenner over flere områder, inkludert maskinlæring, distribuerte systemer og personalisering.

Sofian Hamiti er en AI / ML-spesialist Solutions Architect hos AWS. Han hjelper kunder på tvers av bransjer å få fart på AI / ML-reisen ved å hjelpe dem med å bygge og operasjonalisere helhetlige maskinlæringsløsninger.

Dr. Romi Datta  er seniorleder for produktledelse i Amazon SageMaker-teamet med ansvar for opplæring, prosessering og funksjonsbutikk. Han har vært i AWS i over 4 år, og hatt flere lederroller for produktledelse i SageMaker, S3 og IoT. Før AWS jobbet han i ulike produktledelses-, ingeniør- og operative lederroller hos IBM, Texas Instruments og Nvidia. Han har en MS og Ph.D. i elektro- og datateknikk fra University of Texas i Austin, og en MBA fra University of Chicago Booth School of Business.

RJ er en ingeniør i Search M5-teamet som leder arbeidet med å bygge store dype læringssystemer for trening og slutninger. Utenom jobben utforsker han ulike matkjøkken og driver med racketsport.