Hvordan Medidata brukte Amazon SageMaker asynkron inferens for å akselerere ML-inferensprediksjoner opptil 30 ganger raskere

Dette innlegget er skrevet sammen med Rajnish Jain, Priyanka Kulkarni og Daniel Johnson fra Medidata.

Meditere leder den digitale transformasjonen av biovitenskap, og skaper håp for millioner av pasienter. Medidata bidrar til å generere bevis og innsikt for å hjelpe farmasøytiske, bioteknologiske, medisinske enheter og diagnostikkselskaper samt akademiske forskere med å øke verdien, minimere risiko og optimalisere resultatene for deres løsninger. Mer enn én million registrerte brukere på tvers av over 1,900 kunder og partnere får tilgang til verdens mest pålitelige plattform for klinisk utvikling, kommersielle og virkelige data.

Medidatas AI-team kombinerer uovertruffen kliniske data, avanserte analyser og bransjeekspertise for å hjelpe ledere innen biovitenskap med å tenke nytt om hva som er mulig, avdekke banebrytende innsikt for å ta sikre beslutninger og forfølge kontinuerlig innovasjon. Medidatas AI-pakke med løsninger støttes av et integrert team av forskere, leger, teknologer og tidligere regulatoriske tjenestemenn – bygget på Medidatas kjerneplattform som omfatter over 27,000 8 studier og XNUMX millioner pasienter.

Amazon SageMaker er en fullstendig administrert maskinlæringsplattform (ML) innenfor det sikre AWS-landskapet. Med SageMaker kan dataforskere og utviklere raskt og enkelt bygge og trene ML-modeller, og deretter distribuere dem direkte i et produksjonsklart vertsmiljø. For å være vert for trente ML-modeller tilbyr SageMaker et bredt utvalg av alternativer. Avhengig av typen trafikkmønster og latenskrav, kan du velge ett av disse flere alternativene. For eksempel, sanntidsslutning er egnet for vedvarende arbeidsbelastninger med millisekunders latenskrav, nyttelaststørrelser på opptil 6 MB og behandlingstider på opptil 60 sekunder. Med Serverløs slutning, kan du raskt distribuere ML-modeller for slutninger uten å måtte konfigurere eller administrere den underliggende infrastrukturen, og du betaler kun for beregningskapasiteten som brukes til å behandle slutningsforespørsler, som er ideell for intermitterende arbeidsbelastninger. For forespørsler med store ustrukturerte data med nyttelaststørrelser på opptil 1 GB, med behandlingstider på opptil 15 minutter og tilnærmet sanntids latenskrav, kan du bruke asynkron slutning. Batchtransformasjon er ideell for offline spådommer på store mengder data som er tilgjengelig på forhånd.

I dette samarbeidsinnlegget demonstrerer vi hvordan AWS hjalp Medidata med å dra nytte av de ulike vertskapsmulighetene i SageMaker til å eksperimentere med forskjellige arkitekturvalg for å forutsi operasjonssuksessen til foreslåtte kliniske studier. Vi validerer også hvorfor Medidata valgte SageMaker asynkron inferens for sin endelige utforming og hvordan denne endelige arkitekturen hjalp Medidata til å betjene sine kunder med spådommer opptil 30 ganger raskere samtidig som ML-infrastrukturkostnadene ble relativt lave.

Arkitektur evolusjon

Systemdesign handler ikke om å velge én riktig arkitektur. Det er muligheten til å diskutere og eksperimentere med flere mulige tilnærminger og veie avveiningene deres for å tilfredsstille de gitte kravene for vår brukssituasjon. Under denne prosessen er det viktig å ta hensyn til forkunnskaper om ulike typer krav og eksisterende vanlige systemer som kan samhandle med vårt foreslåtte design. Skalerbarheten til et system er dets evne til enkelt og kostnadseffektivt å variere ressursene som er allokert til det for å betjene endringer i belastning. Dette gjelder både økende eller reduserende brukertall eller forespørsler til systemet.

I de følgende avsnittene diskuterer vi hvordan Medidata jobbet med AWS ved å iterere over en liste over mulige skalerbare arkitekturdesign. Vi fokuserer spesielt på utviklingsreisen, designvalgene og avveiningene vi gikk gjennom for å komme frem til et endelig valg.

SageMaker batch-transformasjon

Medidata opprinnelig brukt SageMaker batch-transformasjon for ML-slutning for å møte gjeldende krav og utvikle et minimum levedyktig produkt (MVP) for en ny prediktiv løsning på grunn av lav bruk og løse ytelseskrav til applikasjonen. Når en batch-transformeringsjobb starter, initialiserer SageMaker databehandlingsforekomster og fordeler slutningen eller forbehandlingsarbeidsbelastningen mellom dem. Det er en metode med høy ytelse og høy gjennomstrømning for å transformere data og generere slutninger. Den er ideell for scenarier der du har å gjøre med store mengder data, ikke trenger sekundvis ventetid, og trenger enten å forhåndsbehandle eller transformere dataene eller bruke en opplært modell for å kjøre batchprediksjoner på dem på en distribuert måte. Sagemaker batch transform arbeidsflyt bruker også Amazon enkel lagringstjeneste (Amazon S3) som det vedvarende laget, som tilordnes et av datakravene våre.

Til å begynne med fungerte det bra å bruke SageMaker batchtransformasjon for MVP, men etter hvert som kravene utviklet seg og Medidata trengte å støtte sine kunder i nesten sanntid, var batchtransformasjon ikke egnet fordi det var en offline-metode og kundene må vente hvor som helst mellom 5– 15 minutter for svar. Dette inkluderte først og fremst oppstartskostnaden for den underliggende dataklyngen for å spinne opp hver gang en batch-arbeidsbelastning må behandles. Denne arkitekturen krevde også konfigurering Amazon CloudWatch hendelsesregler for å spore fremdriften til batch-prediksjonsjobben sammen med bruk av en valgfri database for å spore tilstandene og metadataene til den utløste jobben. MVP-arkitekturen er vist i følgende diagram.

Flyten til denne arkitekturen er som følger:

1. Den innkommende massenyttelasten opprettholdes som en inngang til en S3-lokasjon. Denne hendelsen utløser igjen en AWS Lambda Send funksjon.
2. Send-funksjonen starter en SageMaker batch-transformeringsjobb ved å bruke SageMaker runtime-klient.
3. Send-funksjonen oppdaterer også en valgfri tilstands- og metadatasporingsdatabase med jobb-ID og setter statusen til jobben til inProgress. Funksjonen oppdaterer også jobb-IDen med tilhørende metadatainformasjon.
4. Den forbigående (on-demand) dataklyngen som kreves for å behandle nyttelasten spinner opp, og starter en SageMaker batch-transformeringsjobb. Samtidig sender jobben også ut statusvarsler og annen logginformasjon til CloudWatch-logger.
5. CloudWatch-hendelsesregelen fanger opp statusen til batchtransformeringsjobben og sender et statusvarsel til en Amazon enkel varslingstjeneste (Amazon SNS) emne konfigurert til å fange opp denne informasjonen.
6. SNS-emnet abonneres av en varslingslamda-funksjon som utløses hver gang en hendelsesregel utløses av CloudWatch og når det er en melding i SNS-emnet.
7. Meldingsfunksjonen oppdaterer deretter statusen til transformasjonsjobben for suksess eller fiasko i sporingsdatabasen.

Mens hun utforsket alternative strategier og arkitekturer, innså Medidata at trafikkmønsteret for applikasjonen besto av korte støt etterfulgt av perioder med inaktivitet. For å validere ulempene med denne eksisterende MVP-arkitekturen, utførte Medidata noen innledende benchmarking for å forstå og prioritere flaskehalsene i denne rørledningen. Som vist i følgende diagram, var den største flaskehalsen overgangstiden før kjøring av modellen for slutning på grunn av spinning opp nye ressurser med hver bulkforespørsel. Definisjonen av en bulkforespørsel her tilsvarer en nyttelast som er en samling av driftssteddata som skal behandles i stedet for en enkelt forekomst av en forespørsel. Den nest største flaskehalsen var tiden for å lagre og skrive utdataene, som også ble introdusert på grunn av batchmodellarkitekturen.

Etter hvert som antallet kunder økte og bruken ble mangedoblet, prioriterte Medidata brukeropplevelsen ved å skjerpe ytelseskravene. Derfor bestemte Medidata seg for å erstatte batchtransformasjonsarbeidsflyten med et raskere alternativ. Dette førte til at Medidata eksperimenterte med flere arkitekturdesign som involverte SageMaker sanntidsslutning, Lambda og SageMaker asynkron inferens. I de følgende avsnittene sammenligner vi disse evaluerte designene i dybden og analyserer de tekniske årsakene til å velge den ene fremfor den andre for Medidatas brukstilfelle.

SageMaker sanntidsslutning

Du kan bruke SageMaker sanntidsendepunkter for å betjene modellene dine for spådommer i sanntid med lav ventetid. Å betjene spådommene dine i sanntid krever en modellserveringsstabel som ikke bare har den trente modellen din, men også en vertsstabel for å kunne betjene disse spådommene. Vertsstakken inkluderer vanligvis en type proxy, en webserver som kan samhandle med den innlastede serveringskoden din, og den trente modellen. Modellen din kan deretter konsumeres av klientapplikasjoner gjennom en sanntidsanrops-API-forespørsel. Forespørselsnyttelasten som sendes når du påkaller endepunktet, rutes til en lastbalanser og rutes deretter til ML-forekomsten eller -instansene som er vert for modellene dine for prediksjon. SageMaker sanntidsslutning kommer med alle de nevnte komponentene og gjør det relativt enkelt å være vert for enhver type ML-modell for synkron sanntidsslutning.

SageMaker sanntidsslutning har en tidsavbrudd på 60 sekunder for endepunkt-påkalling, og maksimal nyttelaststørrelse for påkalling er begrenset til 6 MB. Fordi Medidatas inferenslogikk er kompleks og ofte krever mer enn 60 sekunder, kan ikke sanntidsslutning alene være et levedyktig alternativ for å håndtere bulkforespørsler som normalt krever utrulling og behandling av mange individuelle operasjonelle identifikatorer uten å rearkitektere den eksisterende ML-rørledningen. I tillegg må sanntidsslutningsendepunkter dimensjoneres for å håndtere toppbelastning. Dette kan være utfordrende fordi Medidata har raske utbrudd av høy trafikk. Automatisk skalering kan potensielt fikse dette problemet, men det vil kreve manuell innstilling for å sikre at det er nok ressurser til å håndtere alle forespørsler til enhver tid. Alternativt kan vi administrere en forespørselskø for å begrense antall samtidige forespørsler på et gitt tidspunkt, men dette vil introdusere ekstra overhead.

Lambda

Serverløse tilbud som Lambda eliminerer bryet med å klargjøre og administrere servere, og tar seg automatisk av skalering som svar på varierende arbeidsbelastning. De kan også være mye billigere for tjenester med lavere volum fordi de ikke kjører 24/7. Lambda fungerer godt for arbeidsbelastninger som tåler kaldstart etter perioder med inaktivitet. Hvis en serverløs funksjon ikke har blitt kjørt på omtrent 15 minutter, opplever neste forespørsel det som kalles en kaldstart fordi funksjonens beholder må klargjøres.

Medidata bygde flere proof of concept (POC) arkitekturdesign for å sammenligne Lambda med andre alternativer. Som en første enkel implementering ble ML-slutningskoden pakket som et Docker-bilde og distribuert som en container ved hjelp av Lambda. For å forenkle raskere spådommer med dette oppsettet, krever den påkalte Lambda-funksjonen et stort klargjort minnefotavtrykk. For større nyttelast er det en ekstra overhead for å komprimere inngangen før du kaller Lambda Docker-endepunktet. Ytterligere konfigurasjoner er også nødvendig for CloudWatch-hendelsesreglene for å lagre inngangene og utgangene, spore fremdriften til forespørselen og bruke en valgfri database for å spore de interne tilstandene og metadataene til de utsendte forespørslene. I tillegg er det også en driftsoverhead for lesing og skriving av data til Amazon S3. Medidata beregnet den anslåtte kostnaden for Lambda-tilnærmingen basert på bruksestimater og bestemte at den ville være mye dyrere enn SageMaker uten ekstra fordeler.

SageMaker asynkron inferens

Asynkron inferens er et av de nyeste inferenstilbudene i SageMaker som bruker en intern kø for innkommende forespørsler og behandler dem asynkront. Dette alternativet er ideelt for slutninger med store nyttelaststørrelser (opptil 1 GB) eller lange behandlingstider (opptil 15 minutter) som må behandles etter hvert som forespørsler kommer. Asynkron inferens lar deg spare kostnader ved å autoskalere forekomsttellingen til null når det ikke er noen forespørsler å behandle, slik at du bare betaler når endepunktet ditt behandler forespørsler.

For brukstilfeller som tåler en kaldstartstraff på noen få minutter, kan du valgfritt nedskalere endepunktforekomsttellingen til null når det ikke er utestående forespørsler og skalere opp etter hvert som nye forespørsler kommer, slik at du kun betaler for varigheten som endepunkter behandler forespørsler aktivt.

Å lage et asynkront sluttpunkt er veldig likt å lage et sanntidsendepunkt. Du kan bruke din eksisterende SageMaker modeller og trenger bare å spesifisere ytterligere konfigurasjon av asynkron inferens parametere mens du oppretter endepunktkonfigurasjonen. I tillegg kan du legge ved en automatisk skaleringspolicy til endepunktet i henhold til dine skaleringskrav. For å påkalle endepunktet, må du plassere forespørselsnyttelasten i Amazon S3 og gi en peker til nyttelasten som en del av påkallingsforespørselen. Ved påkalling setter SageMaker forespørselen i kø for behandling og returnerer et utdatasted som et svar. Ved behandling plasserer SageMaker slutningsresponsen på den tidligere returnerte Amazon S3-posisjonen. Du kan valgfritt velge å motta suksess- eller feilmeldinger via Amazon SNS.

Basert på de forskjellige arkitekturdesignene som er diskutert tidligere, identifiserte vi flere flaskehalser og kompleksitetsutfordringer med disse arkitekturene. Med lanseringen av asynkron inferens og basert på vår omfattende eksperimentering og ytelsesbenchmarking, bestemte Medidata seg for å velge SageMaker asynkron inferens for deres endelige arkitektur for hosting på grunn av en rekke årsaker som er skissert tidligere. SageMaker er designet fra grunnen av for å støtte ML-arbeidsbelastninger, mens Lambda er mer et generellt verktøy. For vår spesifikke brukstilfelle og arbeidsbelastningstype er SageMaker asynkron inferens billigere enn Lambda. I tillegg er SageMaker asynkron inferens tidsavbrudd mye lengre (15 minutter) sammenlignet med sanntids inferens timeout på 60 sekunder. Dette sikrer at asynkron inferens kan støtte alle Medidatas arbeidsbelastninger uten endringer. I tillegg setter SageMaker asynkron inferens forespørsler i kø under raske utbrudd av trafikk i stedet for å droppe dem, noe som var et sterkt krav i henhold til vår brukssituasjon. Unntaks- og feilhåndtering ivaretas automatisk for deg. Asynkron inferens gjør det også enkelt å håndtere store nyttelaststørrelser, som er et vanlig mønster med våre inferenskrav. Det endelige arkitekturdiagrammet som bruker SageMaker asynkron inferens er vist i følgende figur.

Flyten av vår endelige arkitektur er som følger:

1. Send-funksjonen mottar massenyttelasten fra oppstrøms forbrukerapplikasjoner og er satt opp til å være hendelsesdrevet. Denne funksjonen laster opp nyttelasten til det forhåndsutpekte Amazon S3-stedet.
2. Send-funksjonen påkaller deretter SageMaker asynkrone endepunkt, og gir den Amazon S3-pekeren til den opplastede nyttelasten.
3. Funksjonen oppdaterer også tilstanden til forespørselen til inProgress i tilstands- og metadatasporingsdatabasen.
4. SageMaker asynkrone inferens-endepunktet leser input fra Amazon S3 og kjører inferenslogikken. Når ML-slutningen lykkes eller mislykkes, skrives inferensutgangen tilbake til Amazon S3 og statusen sendes til et SNS-emne.
5. En Lambda-varslingsfunksjon abonnerer på SNS-emnet. Funksjonen påkalles hver gang et statusoppdateringsvarsel publiseres til emnet.
6. Varslingsfunksjonen oppdaterer statusen til forespørselen til suksess eller fiasko i tilstands- og metadatasporerdatabasen.

For å oppsummere, tok batch-transformasjons-MVP-arkitekturen vi startet med 5–15 minutter å kjøre, avhengig av størrelsen på inngangen. Med overgangen til asynkron inferens, kjører den nye løsningen ende til ende på 10–60 sekunder. Vi ser en hastighetsøkning på minst fem ganger raskere for større input og opptil 30 ganger raskere for mindre input, noe som fører til bedre kundetilfredshet med ytelsesresultatene. Den reviderte endelige arkitekturen forenkler den tidligere asynkrone fan-out/fan-in-arkitekturen betraktelig fordi vi ikke trenger å bekymre oss for å dele inn den innkommende nyttelasten, skape arbeidere og delegere og konsolidere arbeid blant arbeidernes Lambda-funksjoner.

konklusjonen

Med SageMaker asynkron inferens, opplever Medidatas kunder som bruker denne nye prediktive applikasjonen nå en hastighet som er opptil 30 ganger raskere for spådommer. Forespørsler blir ikke droppet under trafikkøkninger fordi det asynkrone slutningspunktet setter forespørsler i kø i stedet for å droppe dem. Den innebygde SNS-varslingen var i stand til å overvinne den tilpassede CloudWatch-hendelsesloggvarslingen som Medidata hadde bygget for å varsle appen når jobben var fullført. I dette tilfellet er den asynkrone slutningsmetoden billigere enn Lambda. SageMaker asynkron inferens er et utmerket alternativ hvis teamet ditt kjører tunge ML-arbeidsbelastninger med burst-trafikk mens de prøver å minimere kostnadene. Dette er et flott eksempel på samarbeid med AWS-teamet for å flytte grensene og bruke nyskapende teknologi for maksimal effektivitet.

For detaljerte trinn for hvordan du oppretter, påkaller og overvåker asynkrone inferensendepunkter, se dokumentasjon, som også inneholder en prøve notatbok for å hjelpe deg i gang. For prisinformasjon, besøk Amazon SageMaker-priser. For eksempler på bruk av asynkron inferens med ustrukturerte data som datasyn og naturlig språkbehandling (NLP), se Kjør slutninger for datasyn på store videoer med Amazon SageMaker asynkrone endepunkter og Forbedre forskning med høy verdi med Hugging Face og Amazon SageMaker asynkrone inferensendepunkterHhv.

---

Om forfatterne

Rajnish Jain er Senior Director of Engineering ved Medidata AI med base i NYC. Rajnish leder engineering for en serie applikasjoner som bruker maskinlæring på AWS for å hjelpe kundene med å forbedre operasjonell suksess for foreslåtte kliniske studier. Han brenner for bruken av maskinlæring for å løse forretningsproblemer.

Priyanka Kulkarni er en ledende programvareingeniør innen Acorn AI hos Medidata Solutions. Hun arkitekter og utvikler løsninger og infrastruktur for å støtte ML-spådommer i stor skala. Hun er en datadrevet ingeniør som tror på å bygge innovative programvareløsninger for kundesuksess.

Daniel Johnson er senior programvareingeniør innen Acorn AI hos Medidata Solutions. Han bygger APIer for å støtte ML-spådommer rundt gjennomførbarheten av foreslåtte kliniske studier.

Arunprasath Shankar er en senior AI/ML-spesialistløsningsarkitekt med AWS, og hjelper globale kunder med å skalere AI-løsningene sine effektivt og effektivt i skyen. På fritiden liker Arun å se sci-fi-filmer og høre på klassisk musikk.

Raghu Ramesha er en ML Solutions Architect med Amazon SageMaker Service-teamet. Han fokuserer på å hjelpe kunder med å bygge, distribuere og migrere ML-produksjonsarbeidsmengder til SageMaker i stor skala. Han spesialiserer seg på maskinlæring, AI og datasynsdomener, og har en mastergrad i informatikk fra UT Dallas. På fritiden liker han å reise og fotografere.