Hur Medidata använde Amazon SageMaker asynkron inferens för att accelerera ML-inferensförutsägelser upp till 30 gånger snabbare

Det här inlägget är skrivet tillsammans med Rajnish Jain, Priyanka Kulkarni och Daniel Johnson från Medidata.

Meditera leder den digitala omvandlingen av biovetenskap och skapar hopp för miljontals patienter. Medidata hjälper till att generera bevis och insikter för att hjälpa läkemedels-, bioteknik-, medicintekniska företag och diagnostikföretag samt akademiska forskare med accelererande värde, minimera risker och optimera resultat för sina lösningar. Mer än en miljon registrerade användare av över 1,900 XNUMX kunder och partners får tillgång till världens mest pålitliga plattform för klinisk utveckling, kommersiell och verklig data.

Medidatas AI-team kombinerar oöverträffad klinisk data, avancerad analys och branschexpertis för att hjälpa biovetenskapsledare att ompröva vad som är möjligt, upptäcka banbrytande insikter för att fatta säkra beslut och sträva efter kontinuerlig innovation. Medidatas AI-svit av lösningar stöds av ett integrerat team av forskare, läkare, teknologer och före detta regulatoriska tjänstemän – byggd på Medidatas kärnplattform som omfattar över 27,000 8 försök och XNUMX miljoner patienter.

Amazon SageMaker är en helt hanterad plattform för maskininlärning (ML) inom det säkra AWS-landskapet. Med SageMaker kan datavetare och utvecklare snabbt och enkelt bygga och träna ML-modeller och sedan direkt distribuera dem i en produktionsklar värdmiljö. För att vara värd för utbildade ML-modeller erbjuder SageMaker ett brett utbud av alternativ. Beroende på typen av trafikmönster och latenskrav kan du välja ett av dessa flera alternativ. Till exempel, slutledning i realtid är lämplig för ihållande arbetsbelastningar med millisekunders latenskrav, nyttolaststorlekar upp till 6 MB och bearbetningstider på upp till 60 sekunder. Med Serverlös slutledning, kan du snabbt distribuera ML-modeller för slutledning utan att behöva konfigurera eller hantera den underliggande infrastrukturen, och du betalar endast för den beräkningskapacitet som används för att behandla slutledningsförfrågningar, vilket är idealiskt för intermittenta arbetsbelastningar. För förfrågningar med stora ostrukturerade data med nyttolaststorlekar upp till 1 GB, med bearbetningstider på upp till 15 minuter och nästan realtidsfördröjningskrav kan du använda asynkron slutledning. Batchtransformation är idealisk för offlineförutsägelser om stora mängder data som är tillgängliga i förväg.

I det här samarbetsinlägget visar vi hur AWS hjälpte Medidata att dra nytta av de olika värdfunktionerna inom SageMaker för att experimentera med olika arkitekturval för att förutsäga den operativa framgången för föreslagna kliniska prövningar. Vi validerar också varför Medidata valde SageMaker asynkron inferens för sin slutliga design och hur denna slutliga arkitektur hjälpte Medidata att betjäna sina kunder med förutsägelser upp till 30 gånger snabbare samtidigt som ML-infrastrukturkostnaderna hölls relativt låga.

Arkitektur evolution

Systemdesign handlar inte om att välja en rätt arkitektur. Det är förmågan att diskutera och experimentera med flera möjliga tillvägagångssätt och väga deras avvägningar för att uppfylla de givna kraven för vårt användningsfall. Under denna process är det viktigt att ta hänsyn till förkunskaper om olika typer av krav och befintliga gemensamma system som kan interagera med vår föreslagna design. Skalbarheten hos ett system är dess förmåga att enkelt och kostnadseffektivt variera resurser som allokeras till det för att betjäna förändringar i belastning. Detta gäller både ökande eller minskande användarantal eller förfrågningar till systemet.

I de följande avsnitten diskuterar vi hur Medidata arbetade med AWS för att iterera över en lista över möjliga skalbara arkitekturdesigner. Vi fokuserar särskilt på utvecklingsresan, designval och avvägningar som vi gick igenom för att komma fram till ett slutgiltigt val.

SageMaker batch-transformation

Medidata användes ursprungligen SageMaker batch-transformation för ML-slutledning för att möta nuvarande krav och utveckla en lägsta livskraftig produkt (MVP) för en ny prediktiv lösning på grund av låg användning och lösa prestandakrav för applikationen. När ett batchtransformeringsjobb startar, initierar SageMaker beräkningsinstanser och fördelar slutlednings- eller förbearbetningsarbetsbelastningen mellan dem. Det är en högpresterande och hög genomströmningsmetod för att transformera data och generera slutsatser. Den är idealisk för scenarier där du har att göra med stora partier av data, inte behöver fördröjning i sekunden och behöver antingen förbearbeta eller transformera data eller använda en tränad modell för att köra batchförutsägelser på det på ett distribuerat sätt. Sagemaker batch transform arbetsflöde använder också Amazon enkel lagringstjänst (Amazon S3) som det beständiga lagret, vilket mappar till ett av våra datakrav.

Till en början fungerade användningen av SageMaker batchtransform bra för MVP, men eftersom kraven utvecklades och Medidata behövde stödja sina kunder i nästan realtid, var batchtransform inte lämplig eftersom det var en offlinemetod och kunderna måste vänta någonstans mellan 5– 15 minuter för svar. Detta inkluderade i första hand startkostnaden för det underliggande beräkningsklustret att snurra upp varje gång en batch-arbetsbelastning behöver bearbetas. Denna arkitektur krävde också konfigurering amazoncloudwatch händelseregler för att spåra framstegen för batchförutsägelsejobbet tillsammans med användning av en valfri databas för att spåra tillstånden och metadata för det avfyrade jobbet. MVP-arkitekturen visas i följande diagram.

Flödet för denna arkitektur är som följer:

1. Den inkommande bulknyttolasten behålls som en ingång till en S3-plats. Denna händelse utlöser i sin tur en AWS Lambda Skicka funktion.
2. Submit-funktionen startar ett SageMaker batchtransformeringsjobb med SageMaker runtime-klient.
3. Skicka-funktionen uppdaterar också en valfri databas för tillstånd och metadataspårning med jobb-ID och ställer in statusen för jobbet till inProgress. Funktionen uppdaterar även jobb-ID med dess motsvarande metadatainformation.
4. Det transienta (on-demand) beräkningsklustret som krävs för att bearbeta nyttolasten snurrar upp och initierar ett SageMaker-batchtransformeringsjobb. Samtidigt skickar jobbet även ut statusmeddelanden och annan loggningsinformation till CloudWatch-loggar.
5. CloudWatch-händelseregeln fångar statusen för batchtransformeringsjobbet och skickar ett statusmeddelande till en Amazon enkel meddelandetjänst (Amazon SNS) ämne konfigurerat för att fånga denna information.
6. SNS-ämnet prenumereras av en Notification Lambda-funktion som utlöses varje gång en händelseregel aktiveras av CloudWatch och när det finns ett meddelande i SNS-ämnet.
7. Meddelandefunktionen uppdaterar sedan transformationsjobbets status för framgång eller misslyckande i spårningsdatabasen.

Medan Medidata utforskade alternativa strategier och arkitekturer insåg Medidata att trafikmönstret för applikationen bestod av korta skurar följt av perioder av inaktivitet. För att validera nackdelarna med denna befintliga MVP-arkitektur utförde Medidata en del inledande benchmarking för att förstå och prioritera flaskhalsarna i denna pipeline. Som visas i följande diagram var den största flaskhalsen övergångstiden innan modellen kördes för slutledning på grund av att nya resurser skapades med varje bulkförfrågan. Definitionen av en bulkbegäran här motsvarar en nyttolast som är en samling operativa platsdata som ska behandlas snarare än en enskild instans av en begäran. Den näst största flaskhalsen var tiden att spara och skriva utdata, som också introducerades på grund av batchmodellarkitekturen.

I takt med att antalet kunder ökade och användningen ökade, prioriterade Medidata användarupplevelsen genom att skärpa prestandakraven. Därför beslutade Medidata att ersätta batchtransformeringsarbetsflödet med ett snabbare alternativ. Detta ledde till att Medidata experimenterade med flera arkitekturdesigner SageMaker inferens i realtid, Lambda och SageMaker asynkron slutledning. I de följande avsnitten jämför vi dessa utvärderade design på djupet och analyserar de tekniska skälen till att välja den ena framför den andra för Medidatas användningsfall.

SageMaker inferens i realtid

Du kan använda SageMaker realtidsslutpunkter för att betjäna dina modeller för förutsägelser i realtid med låg latens. Att servera dina förutsägelser i realtid kräver en modellserverstack som inte bara har din tränade modell, utan också en värdstack för att kunna tjäna dessa förutsägelser. Värdstacken inkluderar vanligtvis en typ av proxy, en webbserver som kan interagera med din laddade serveringskod och din utbildade modell. Din modell kan sedan konsumeras av klientapplikationer genom en API-förfrågan i realtid. Begärans nyttolast som skickas när du anropar slutpunkten dirigeras till en lastbalanserare och dirigeras sedan till din eller de ML-instanser som är värd för dina modeller för förutsägelse. SageMaker realtidsinferens kommer med alla de ovan nämnda komponenterna och gör det relativt enkelt att vara värd för alla typer av ML-modeller för synkron realtidsslutning.

SageMaker realtidsinferens har en 60-sekunders timeout för slutpunktsanrop, och den maximala nyttolaststorleken för anrop är begränsad till 6 MB. Eftersom Medidatas slutledningslogik är komplex och ofta kräver mer än 60 sekunder, kan realtidsinferens ensam inte vara ett genomförbart alternativ för att hantera bulkförfrågningar som normalt kräver avrullning och bearbetning av många individuella operativa identifierare utan att bygga om den befintliga ML-pipelinen. Dessutom måste slutpunkter i realtid dimensioneras för att hantera toppbelastning. Detta kan vara utmanande eftersom Medidata har snabba skurar av hög trafik. Automatisk skalning skulle eventuellt kunna lösa det här problemet, men det skulle kräva manuell inställning för att säkerställa att det finns tillräckligt med resurser för att hantera alla förfrågningar vid varje given tidpunkt. Alternativt kan vi hantera en förfrågningskö för att begränsa antalet samtidiga förfrågningar vid en given tidpunkt, men detta skulle införa ytterligare overhead.

Lambda

Serverlösa erbjudanden som Lambda eliminerar besväret med att tillhandahålla och hantera servrar och tar automatiskt hand om skalningen som svar på varierande arbetsbelastning. De kan också vara mycket billigare för tjänster med lägre volym eftersom de inte körs 24/7. Lambda fungerar bra för arbetsbelastningar som tål kallstarter efter perioder av inaktivitet. Om en serverlös funktion inte har körts på cirka 15 minuter får nästa begäran en så kallad kallstart eftersom funktionens behållare måste tillhandahållas.

Medidata byggde flera proof of concept (POC) arkitekturdesigner för att jämföra Lambda med andra alternativ. Som en första enkel implementering paketerades ML-inferenskoden som en Docker-avbildning och distribuerades som en container med Lambda. För att underlätta snabbare förutsägelser med den här inställningen, kräver den anropade Lambda-funktionen ett stort tillhandahållet minnesutrymme. För större nyttolaster finns det en extra overhead för att komprimera ingången innan du anropar Lambda Docker-ändpunkten. Ytterligare konfigurationer behövs också för CloudWatch-händelsereglerna för att spara in- och utdata, spåra framsteg för begäran och använda en valfri databas för att spåra de interna tillstånden och metadata för de skickade förfrågningarna. Dessutom finns det också en operativ overhead för att läsa och skriva data till Amazon S3. Medidata beräknade den beräknade kostnaden för Lambda-metoden baserat på användningsuppskattningar och fastställde att den skulle bli mycket dyrare än SageMaker utan några extra fördelar.

SageMaker asynkron slutledning

Asynkron inferens är ett av de senaste slutledningserbjudandena i SageMaker som använder en intern kö för inkommande förfrågningar och behandlar dem asynkront. Det här alternativet är idealiskt för slutsatser med stora nyttolaststorlekar (upp till 1 GB) eller långa bearbetningstider (upp till 15 minuter) som måste behandlas när förfrågningar kommer in. Asynkron slutledning gör att du kan spara på kostnader genom att autoskala instansräkningen till noll när det inte finns några förfrågningar att behandla, så du betalar bara när din slutpunkt behandlar förfrågningar.

För användningsfall som kan tolerera en kallstartsavgift på några minuter, kan du valfritt skala ner slutpunktsinstansräkningen till noll när det inte finns några utestående förfrågningar och skala upp igen när nya förfrågningar kommer så att du bara betalar för den tid som endpoints bearbetar aktivt förfrågningar.

Att skapa en asynkron slutpunktsslutpunkt är mycket likt att skapa en slutpunkt i realtid. Du kan använda din befintliga SageMaker modeller och behöver bara ange ytterligare asynkron slutledningskonfiguration parametrar när du skapar din slutpunktskonfiguration. Dessutom kan du bifoga en policy för automatisk skalning till slutpunkten enligt dina skalningskrav. För att anropa slutpunkten måste du placera förfrågans nyttolast i Amazon S3 och tillhandahålla en pekare till nyttolasten som en del av anropsbegäran. Vid anrop ställer SageMaker begäran i kö för bearbetning och returnerar en utdataplats som ett svar. Vid bearbetning placerar SageMaker slutledningssvaret på den tidigare returnerade Amazon S3-platsen. Du kan valfritt välja att få framgångs- eller felmeddelanden via Amazon SNS.

Baserat på de olika arkitekturdesignerna som diskuterats tidigare, identifierade vi flera flaskhalsar och komplexitetsutmaningar med dessa arkitekturer. Med lanseringen av asynkron slutledning och baserat på våra omfattande experiment och prestandabenchmarking, beslutade Medidata att välja SageMaker asynkron slutledning för sin slutliga arkitektur för värd på grund av ett antal skäl som beskrivits tidigare. SageMaker är designad från grunden för att stödja ML-arbetsbelastningar, medan Lambda är mer av ett allmänt verktyg. För vårt specifika användningsfall och arbetsbelastningstyp är SageMaker asynkron inferens billigare än Lambda. Även SageMaker asynkron slutlednings timeout är mycket längre (15 minuter) jämfört med realtidsinferens timeout på 60 sekunder. Detta säkerställer att asynkron slutledning kan stödja alla Medidatas arbetsbelastningar utan modifiering. Dessutom köar SageMaker asynkron inferens förfrågningar under snabba skurar av trafik i stället för att släppa dem, vilket var ett starkt krav enligt vårt användningsfall. Undantags- och felhantering sköts automatiskt åt dig. Asynkron inferens gör det också enkelt att hantera stora nyttolaststorlekar, vilket är ett vanligt mönster med våra slutledningskrav. Det slutliga arkitekturdiagrammet med SageMaker asynkron slutledning visas i följande figur.

Flödet för vår slutliga arkitektur är som följer:

1. Submit-funktionen tar emot bulknyttolasten från uppströms konsumentapplikationer och är inställd för att vara händelsestyrd. Den här funktionen laddar upp nyttolasten till den förutbestämda Amazon S3-platsen.
2. Submit-funktionen anropar sedan SageMaker asynkrona slutpunkt och förser den med Amazon S3-pekaren till den uppladdade nyttolasten.
3. Funktionen uppdaterar också statusen för begäran till inProgress i tillstånds- och metadataspårningsdatabasen.
4. SageMaker asynkron slutpunkt slutpunkt läser indata från Amazon S3 och kör inferens logik. När ML-inferensen lyckas eller misslyckas skrivs slutledningsutgången tillbaka till Amazon S3 och statusen skickas till ett SNS-ämne.
5. En Lambda-funktion för meddelanden prenumererar på SNS-ämnet. Funktionen anropas när ett meddelande om statusuppdatering publiceras till ämnet.
6. Meddelandefunktionen uppdaterar statusen för begäran till framgång eller misslyckande i tillstånds- och metadataspårningsdatabasen.

Sammanfattningsvis tog den batchtransformerings-MVP-arkitektur vi började med 5–15 minuter att köra beroende på storleken på ingången. Med övergången till asynkron slutledning körs den nya lösningen från början till slut på 10–60 sekunder. Vi ser en hastighetsökning på minst fem gånger snabbare för större ingångar och upp till 30 gånger snabbare för mindre ingångar, vilket leder till bättre kundnöjdhet med prestationsresultaten. Den reviderade slutliga arkitekturen förenklar avsevärt den tidigare asynkrona fan-out/fan-in-arkitekturen eftersom vi inte behöver oroa oss för att dela upp den inkommande nyttolasten, skapa arbetare och delegera och konsolidera arbete bland arbetarens Lambda-funktioner.

Slutsats

Med SageMaker asynkron inferens upplever Medidatas kunder som använder denna nya prediktiva applikation nu en hastighet som är upp till 30 gånger snabbare för förutsägelser. Begäranden släpps inte under trafikspikar eftersom den asynkrona slutpunkten för slutpunkten köar förfrågningar istället för att ta bort dem. Den inbyggda SNS-aviseringen kunde övervinna den anpassade CloudWatch-händelseloggaviseringen som Medidata hade byggt för att meddela appen när jobbet var klart. I det här fallet är metoden med asynkron slutledning billigare än Lambda. SageMaker asynkron slutledning är ett utmärkt alternativ om ditt team kör tunga ML-arbetsbelastningar med burst-trafik samtidigt som de försöker minimera kostnaderna. Det här är ett bra exempel på samarbete med AWS-teamet för att tänja på gränserna och använda avancerad teknologi för maximal effektivitet.

För detaljerade steg om hur man skapar, anropar och övervakar asynkrona slutpunkter, se dokumentation, som också innehåller en prov anteckningsbok för att hjälpa dig komma igång. För prisinformation, besök Amazon SageMaker Prissättning. För exempel på användning av asynkron slutledning med ostrukturerad data som datorseende och naturlig språkbehandling (NLP), se Kör datorseende inferens på stora videor med Amazon SageMaker asynkrona slutpunkter och Förbättra forskning med högt värde med Hugging Face och Amazon SageMaker asynkrona slutpunkter, Respektive.

---

Om författarna

Rajnish Jain är Senior Director of Engineering på Medidata AI baserad i NYC. Rajnish leder tekniken för en uppsättning applikationer som använder maskininlärning på AWS för att hjälpa kunder att förbättra den operativa framgången för föreslagna kliniska prövningar. Han brinner för användningen av maskininlärning för att lösa affärsproblem.

Priyanka Kulkarni är en Lead Software Engineer inom Acorn AI på Medidata Solutions. Hon arkitekter och utvecklar lösningar och infrastruktur för att stödja ML-förutsägelser i stor skala. Hon är en datadriven ingenjör som tror på att bygga innovativa mjukvarulösningar för kundernas framgång.

Daniel Johnson är Senior Software Engineer inom Acorn AI på Medidata Solutions. Han bygger API:er för att stödja ML-förutsägelser kring genomförbarheten av föreslagna kliniska prövningar.

Arunprasath Shankar är en Senior AI/ML Specialist Solutions Architect med AWS, som hjälper globala kunder att skala sina AI-lösningar effektivt och effektivt i molnet. På fritiden tycker Arun om att titta på sci-fi-filmer och lyssna på klassisk musik.

Raghu Ramesha är en ML Solutions Architect med Amazon SageMaker Service-teamet. Han fokuserar på att hjälpa kunder att bygga, distribuera och migrera ML-produktionsarbetsbelastningar till SageMaker i stor skala. Han är specialiserad på domäner för maskininlärning, AI och datorseende och har en magisterexamen i datavetenskap från UT Dallas. På fritiden tycker han om att resa och fotografera.