Jak firma Medidata wykorzystała asynchroniczne wnioskowanie Amazon SageMaker, aby przyspieszyć przewidywanie wnioskowania ML do 30 razy szybciej

Ten post został napisany wspólnie z Rajnish Jain, Priyanka Kulkarni i Daniel Johnson z Medidata.

Dane medyczne przewodzi cyfrowej transformacji nauk przyrodniczych, dając nadzieję milionom pacjentów. Medidata pomaga generować dowody i spostrzeżenia, aby pomóc firmom z branży farmaceutycznej, biotechnologicznej, urządzeń medycznych i diagnostycznych, a także naukowcom akademickim, zwiększając wartość, minimalizując ryzyko i optymalizując wyniki ich rozwiązań. Ponad milion zarejestrowanych użytkowników z ponad 1,900 klientów i partnerów uzyskuje dostęp do najbardziej zaufanej na świecie platformy dla rozwoju klinicznego, danych komercyjnych i danych ze świata rzeczywistego.

Zespół AI Medidata łączy niezrównane dane kliniczne, zaawansowaną analitykę i wiedzę branżową, aby pomóc liderom nauk przyrodniczych w ponownym wyobrażeniu sobie tego, co jest możliwe, odkrywaniu przełomowych spostrzeżeń, aby podejmować pewne decyzje i dążyć do ciągłych innowacji. Pakiet rozwiązań AI Medidata jest wspierany przez zintegrowany zespół naukowców, lekarzy, technologów i byłych urzędników regulacyjnych — zbudowany na podstawowej platformie Medidata obejmującej ponad 27,000 8 badań i XNUMX milionów pacjentów.

Amazon Sage Maker to w pełni zarządzana platforma uczenia maszynowego (ML) w bezpiecznym środowisku AWS. Dzięki SageMaker naukowcy i programiści danych mogą szybko i łatwo tworzyć i trenować modele ML, a następnie bezpośrednio wdrażać je w hostowanym środowisku gotowym do produkcji. W przypadku hostingu przeszkolonych modeli ML, SageMaker oferuje szeroki wachlarz opcji. W zależności od typu wzorca ruchu i wymagań dotyczących opóźnień możesz wybrać jedną z tych kilku opcji. Na przykład, wnioskowanie w czasie rzeczywistym jest odpowiedni dla trwałych obciążeń z wymaganiami dotyczącymi opóźnień w milisekundach, wielkości ładunku do 6 MB i czasów przetwarzania do 60 sekund. Z Wnioskowanie bezserwerowe, możesz szybko wdrożyć modele ML do wnioskowania bez konieczności konfigurowania bazowej infrastruktury lub zarządzania nią, a płacisz tylko za moc obliczeniową używaną do przetwarzania żądań wnioskowania, co jest idealne w przypadku sporadycznych obciążeń. W przypadku żądań z dużymi nieustrukturyzowanymi danymi o rozmiarze ładunku do 1 GB, z czasem przetwarzania do 15 minut i wymaganiami dotyczącymi opóźnień w czasie zbliżonym do rzeczywistego można użyć wnioskowanie asynchroniczne. Transformacja wsadowa jest idealny do prognozowania offline na dużych partiach danych, które są dostępne z góry.

W tym wspólnym poście pokazujemy, w jaki sposób AWS pomógł Medidata wykorzystać różne możliwości hostingu w SageMaker do eksperymentowania z różnymi opcjami architektury w celu przewidywania sukcesu operacyjnego proponowanych badań klinicznych. Potwierdzamy również, dlaczego firma Medidata wybrała wnioskowanie asynchroniczne SageMaker do ostatecznego projektu i w jaki sposób ta ostateczna architektura pomogła firmie Medidata obsługiwać klientów z prognozami nawet 30 razy szybszymi przy stosunkowo niskich kosztach infrastruktury ML.

Ewolucja architektury

Projektowanie systemu nie polega na wyborze jednej odpowiedniej architektury. Jest to umiejętność omawiania i eksperymentowania z wieloma możliwymi podejściami oraz ważenia ich kompromisów w spełnianiu danych wymagań dla naszego przypadku użycia. Podczas tego procesu konieczne jest uwzględnienie wcześniejszej wiedzy na temat różnych typów wymagań i istniejących wspólnych systemów, które mogą wchodzić w interakcje z naszym proponowanym projektem. Skalowalność systemu to jego zdolność do łatwego i ekonomicznego zmieniania przydzielonych mu zasobów, aby obsłużyć zmiany obciążenia. Dotyczy to zarówno zwiększania, jak i zmniejszania liczby użytkowników lub żądań do systemu.

W kolejnych sekcjach omówimy, jak Medidata współpracowała z AWS w iteracji nad listą możliwych projektów architektury skalowalnej. Skupiamy się szczególnie na podróży ewolucyjnej, wyborach projektowych i kompromisach, przez które przeszliśmy, aby dokonać ostatecznego wyboru.

Transformacja wsadowa SageMaker

Pierwotnie używane Medidata Transformacja wsadowa SageMaker wnioskowanie ML w celu spełnienia aktualnych wymagań i opracowania minimalnego opłacalnego produktu (MVP) dla nowego rozwiązania predykcyjnego ze względu na niskie zużycie i luźne wymagania dotyczące wydajności aplikacji. Po uruchomieniu zadania transformacji wsadowej program SageMaker inicjuje instancje obliczeniowe i rozdziela między nie wnioskowanie lub obciążenie przetwarzania wstępnego. Jest to wysokowydajna i wysokoprzepustowa metoda przekształcania danych i generowania wniosków. Jest to idealne rozwiązanie w przypadku scenariuszy, w których masz do czynienia z dużymi partiami danych, nie potrzebujesz opóźnienia poniżej sekundy i musisz wstępnie przetworzyć lub przekształcić dane albo użyć wytrenowanego modelu do uruchamiania prognoz partii w sposób rozproszony. Przepływ pracy wsadowej transformacji Sagemaker również wykorzystuje Usługa Amazon Simple Storage (Amazon S3) jako warstwa trwała, która jest mapowana zgodnie z jednym z naszych wymagań dotyczących danych.

Początkowo użycie SageMaker transformacji wsadowej działało dobrze dla MVP, ale wraz z ewolucją wymagań i potrzebą Medidata do obsługi klientów w czasie zbliżonym do rzeczywistego, transformacja wsadowa nie była odpowiednia, ponieważ była to metoda offline, a klienci musieli czekać w dowolnym miejscu między 5– 15 minut na odpowiedzi. Obejmowało to przede wszystkim koszt uruchomienia bazowego klastra obliczeniowego, który ma być uruchamiany za każdym razem, gdy konieczne jest przetworzenie obciążenia wsadowego. Ta architektura również wymagała konfiguracji Amazon Cloud Watch reguły zdarzeń do śledzenia postępu zadania prognozowania wsadowego wraz z wykorzystaniem wybranej bazy danych do śledzenia stanów i metadanych uruchomionego zadania. Architekturę MVP przedstawiono na poniższym diagramie.

Przebieg tej architektury wygląda następująco:

1. Przychodzący ładunek zbiorczy jest utrwalany jako dane wejściowe do lokalizacji S3. To zdarzenie z kolei wyzwala AWS Lambda Prześlij funkcję.
2. Funkcja Submit uruchamia zadanie transformacji wsadowej programu SageMaker przy użyciu klienta środowiska wykonawczego SageMaker.
3. Funkcja Wyślij aktualizuje również wybraną bazę danych śledzenia stanu i metadanych o identyfikator zadania i ustawia status zadania na inProgress. Funkcja aktualizuje również identyfikator zadania wraz z odpowiednimi informacjami o metadanych.
4. Przejściowy (na żądanie) klaster obliczeniowy wymagany do przetworzenia ładunku rozkręca się, inicjując zadanie transformacji wsadowej programu SageMaker. W tym samym czasie zadanie wysyła również powiadomienia o stanie i inne informacje logowania do dzienników CloudWatch.
5. Reguła zdarzenia CloudWatch przechwytuje stan zadania transformacji wsadowej i wysyła powiadomienie o stanie do Usługa prostego powiadomienia Amazon Temat (Amazon SNS) skonfigurowany do przechwytywania tych informacji.
6. Temat SNS jest subskrybowany przez funkcję Lambda powiadomień, która jest wyzwalana za każdym razem, gdy reguła zdarzenia jest uruchamiana przez CloudWatch i gdy w wątku SNS pojawi się komunikat.
7. Funkcja powiadamiania następnie aktualizuje status zadania transformacji dla powodzenia lub niepowodzenia w śledzącej bazie danych.

Podczas badania alternatywnych strategii i architektur firma Medidata zdała sobie sprawę, że wzorzec ruchu dla aplikacji składał się z krótkich impulsów, po których następowały okresy bezczynności. Aby sprawdzić wady istniejącej architektury MVP, firma Medidata przeprowadziła wstępne testy porównawcze, aby zrozumieć i ustalić priorytety wąskich gardeł tego potoku. Jak pokazano na poniższym diagramie, największym wąskim gardłem był czas przejścia przed uruchomieniem modelu w celu wnioskowania ze względu na uruchamianie nowych zasobów przy każdym żądaniu zbiorczym. Definicja żądania zbiorczego odpowiada tutaj ładunkowi, który jest zbiorem danych operacyjnych lokacji do przetworzenia, a nie pojedynczemu wystąpieniu żądania. Drugim największym wąskim gardłem był czas na zapisanie i zapisanie danych wyjściowych, co również wprowadzono ze względu na architekturę modelu wsadowego.

Wraz ze wzrostem liczby klientów i wzrostem użycia, Medidata nadała priorytet doświadczeniu użytkownika, zaostrzając wymagania dotyczące wydajności. Dlatego firma Medidata zdecydowała się zastąpić przepływ pracy z transformacją wsadową szybszą alternatywą. Doprowadziło to do eksperymentów Medidata z kilkoma projektami architektury obejmującymi: SageMaker wnioskowanie w czasie rzeczywistym, Lambda i Wnioskowanie asynchroniczne SageMaker. W kolejnych sekcjach szczegółowo porównujemy te ocenione projekty i analizujemy techniczne powody wyboru jednego z nich w przypadku użycia Medidata.

SageMaker wnioskowanie w czasie rzeczywistym

Możesz używać punktów końcowych SageMaker w czasie rzeczywistym, aby obsługiwać modele w celu prognozowania w czasie rzeczywistym z małym opóźnieniem. Udostępnianie prognoz w czasie rzeczywistym wymaga stosu obsługującego model, który ma nie tylko wytrenowany model, ale także stos hostingowy, aby móc obsługiwać te prognozy. Stos hostingu zazwyczaj zawiera typ serwera proxy, serwer sieci Web, który może wchodzić w interakcje z załadowanym kodem udostępniania i wytrenowanym modelem. Twój model może być następnie używany przez aplikacje klienckie za pośrednictwem żądania wywołania interfejsu API w czasie rzeczywistym. Ładunek żądania wysyłany podczas wywoływania punktu końcowego jest kierowany do modułu równoważenia obciążenia, a następnie kierowany do wystąpienia ML lub wystąpień hostujących modele w celu prognozowania. Wnioskowanie w czasie rzeczywistym SageMaker zawiera wszystkie wyżej wymienione komponenty i sprawia, że ​​hostowanie dowolnego typu modelu ML na potrzeby synchronicznego wnioskowania w czasie rzeczywistym jest stosunkowo proste.

Wnioskowanie w czasie rzeczywistym programu SageMaker ma 60-sekundowy limit czasu dla wywołania punktu końcowego, a maksymalny rozmiar ładunku dla wywołania jest ograniczony do 6 MB. Ponieważ logika wnioskowania Medidata jest złożona i często wymaga więcej niż 60 sekund, samo wnioskowanie w czasie rzeczywistym nie może być realną opcją radzenia sobie z żądaniami masowymi, które zwykle wymagają rozwijania i przetwarzania wielu indywidualnych identyfikatorów operacyjnych bez zmiany architektury istniejącego potoku ML. Ponadto punkty końcowe wnioskowania w czasie rzeczywistym muszą być odpowiednio dostosowane do obsługi szczytowego obciążenia. Może to być trudne, ponieważ Medidata ma szybkie wybuchy dużego ruchu. Automatyczne skalowanie może potencjalnie rozwiązać ten problem, ale wymagałoby ręcznego dostrojenia, aby zapewnić wystarczającą ilość zasobów do obsługi wszystkich żądań w dowolnym momencie. Alternatywnie moglibyśmy zarządzać kolejką żądań, aby ograniczyć liczbę jednoczesnych żądań w danym czasie, ale to spowodowałoby dodatkowe obciążenie.

Lambda

Oferty bezserwerowe, takie jak Lambda, eliminują kłopoty z udostępnianiem i zarządzaniem serwerami oraz automatycznie zajmują się skalowaniem w odpowiedzi na zmieniające się obciążenia. Mogą być również znacznie tańsze w przypadku usług o mniejszym wolumenie, ponieważ nie działają 24/7. Lambda działa dobrze w przypadku obciążeń, które tolerują zimne starty po okresach bezczynności. Jeśli funkcja bezserwerowa nie została uruchomiona przez około 15 minut, w następnym żądaniu wystąpi tak zwany zimny start, ponieważ należy udostępnić kontener funkcji.

Firma Medidata stworzyła kilka projektów architektury typu proof of concept (POC), aby porównać Lambda z innymi alternatywami. Jako pierwsza prosta implementacja, kod wnioskowania ML został spakowany jako obraz Docker i wdrożony jako kontener przy użyciu Lambda. Aby ułatwić szybsze przewidywanie przy tej konfiguracji, wywoływana funkcja Lambda wymaga dużej ilości pamięci aprowizowanej. W przypadku większych ładunków istnieje dodatkowy narzut na kompresję danych wejściowych przed wywołaniem punktu końcowego Docker Lambda. Potrzebne są również dodatkowe konfiguracje, aby reguły zdarzeń CloudWatch zapisywały dane wejściowe i wyjściowe, śledziły postęp żądania i wykorzystywały wybraną bazę danych do śledzenia stanów wewnętrznych i metadanych uruchomionych żądań. Dodatkowo istnieje również obciążenie operacyjne związane z odczytywaniem i zapisywaniem danych w Amazon S3. Medidata obliczyła przewidywany koszt podejścia Lambda na podstawie szacunków użytkowania i ustaliła, że ​​będzie ono znacznie droższe niż SageMaker bez żadnych dodatkowych korzyści.

Wnioskowanie asynchroniczne SageMaker

Wnioskowanie asynchroniczne to jedna z najnowszych ofert wnioskowania w programie SageMaker, która używa wewnętrznej kolejki dla żądań przychodzących i przetwarza je asynchronicznie. Ta opcja jest idealna w przypadku wniosków z dużymi rozmiarami ładunku (do 1 GB) lub długimi czasami przetwarzania (do 15 minut), które muszą być przetwarzane w miarę napływania żądań. Wnioskowanie asynchroniczne pozwala zaoszczędzić na kosztach przez automatyczne skalowanie liczby wystąpień do zera, gdy nie ma żądań do przetworzenia, więc płacisz tylko wtedy, gdy punkt końcowy przetwarza żądania.

W przypadkach użycia, które mogą tolerować karę zimnego startu wynoszącą kilka minut, można opcjonalnie zmniejszyć liczbę wystąpień punktu końcowego do zera, gdy nie ma żadnych oczekujących żądań, i skalować kopię zapasową w miarę pojawiania się nowych żądań, aby płacić tylko za czas trwania punkty końcowe aktywnie przetwarzają żądania.

Tworzenie asynchronicznego punktu końcowego wnioskowania jest bardzo podobne do tworzenia punktu końcowego w czasie rzeczywistym. Możesz użyć swojego istniejącego SageMakera modele i wystarczy określić dodatkowe konfiguracja wnioskowania asynchronicznego parametry podczas tworzenia konfiguracji punktu końcowego. Ponadto możesz dołączyć zasady automatycznego skalowania do punktu końcowego zgodnie z wymaganiami dotyczącymi skalowania. Aby wywołać punkt końcowy, musisz umieścić ładunek żądania w Amazon S3 i podać wskaźnik do ładunku jako część żądania wywołania. Po wywołaniu SageMaker umieszcza żądanie w kolejce do przetworzenia i zwraca lokalizację wyjściową jako odpowiedź. Po przetworzeniu SageMaker umieszcza odpowiedź wnioskowania we wcześniej zwróconej lokalizacji Amazon S3. Możesz opcjonalnie wybrać otrzymywanie powiadomień o powodzeniu lub błędach za pośrednictwem Amazon SNS.

W oparciu o różne projekty architektury omówione wcześniej, zidentyfikowaliśmy kilka wąskich gardeł i wyzwań związanych ze złożonością tych architektur. Wraz z uruchomieniem wnioskowania asynchronicznego i na podstawie naszych szeroko zakrojonych eksperymentów i testów wydajności, firma Medidata zdecydowała się wybrać wnioskowanie asynchroniczne SageMaker jako ostateczną architekturę hostingu z wielu powodów opisanych wcześniej. SageMaker został zaprojektowany od podstaw do obsługi obciążeń ML, podczas gdy Lambda jest narzędziem bardziej ogólnego przeznaczenia. W przypadku konkretnego przypadku użycia i typu obciążenia wnioskowanie asynchroniczne SageMaker jest tańsze niż Lambda. Ponadto limit czasu wnioskowania asynchronicznego SageMaker jest znacznie dłuższy (15 minut) w porównaniu z limitem czasu wnioskowania w czasie rzeczywistym wynoszącym 60 sekund. Gwarantuje to, że wnioskowanie asynchroniczne może obsługiwać wszystkie obciążenia Medidata bez modyfikacji. Dodatkowo, asynchroniczne wnioskowanie SageMaker kolejkuje żądania podczas szybkich serii ruchu, zamiast je odrzucać, co było silnym wymaganiem w naszym przypadku użycia. Obsługa wyjątków i błędów jest automatycznie obsługiwana za Ciebie. Wnioskowanie asynchroniczne ułatwia również obsługę dużych rozmiarów ładunku, co jest powszechnym wzorcem w naszych wymaganiach dotyczących wnioskowania. Ostateczny diagram architektury wykorzystujący wnioskowanie asynchroniczne SageMaker pokazano na poniższym rysunku.

Przebieg naszej ostatecznej architektury wygląda następująco:

1. Funkcja Prześlij odbiera zbiorczy ładunek z nadrzędnych aplikacji konsumenckich i jest skonfigurowana tak, aby była sterowana zdarzeniami. Ta funkcja przesyła ładunek do wstępnie wyznaczonej lokalizacji Amazon S3.
2. Funkcja Submit następnie wywołuje asynchroniczny punkt końcowy SageMaker, dostarczając mu wskaźnik Amazon S3 do przesłanego ładunku.
3. Funkcja aktualizuje również stan żądania, aby inProgress w bazie danych śledzenia stanu i metadanych.
4. Punkt końcowy wnioskowania asynchronicznego programu SageMaker odczytuje dane wejściowe z usługi Amazon S3 i uruchamia logikę wnioskowania. Gdy wnioskowanie ML zakończy się powodzeniem lub niepowodzeniem, dane wyjściowe wnioskowania są zapisywane z powrotem do Amazon S3, a stan jest wysyłany do tematu SNS.
5. Funkcja Lambda powiadomień subskrybuje temat SNS. Funkcja jest wywoływana za każdym razem, gdy w temacie publikowane jest powiadomienie o aktualizacji statusu.
6. Funkcja powiadamiania aktualizuje status żądania do powodzenia lub niepowodzenia w bazie danych śledzenia stanu i metadanych.

Podsumowując, architektura MVP z transformacją wsadową, od której zaczęliśmy, zajęła 5–15 minut, w zależności od rozmiaru danych wejściowych. Po przełączeniu na wnioskowanie asynchroniczne nowe rozwiązanie działa od końca do końca w ciągu 10–60 sekund. Widzimy przyspieszenie co najmniej pięciokrotnie szybsze w przypadku większych nakładów i do 30 razy szybsze w przypadku mniejszych nakładów, co prowadzi do większego zadowolenia klientów z wyników wydajności. Zmieniona ostateczna architektura znacznie upraszcza poprzednią architekturę asynchronicznego rozmieszczania/dokładania, ponieważ nie musimy się martwić o partycjonowanie przychodzącego ładunku, tarło robotników oraz delegowanie i konsolidację pracy pomiędzy roboczymi funkcjami Lambda.

Wnioski

Dzięki asynchronicznemu wnioskowaniu SageMaker klienci Medidata korzystający z tej nowej aplikacji predykcyjnej doświadczają teraz przyspieszenia, które jest do 30 razy szybsze w przypadku predykcji. Żądania nie są odrzucane podczas skoków ruchu, ponieważ asynchroniczny punkt końcowy wnioskowania kolejkuje żądania zamiast je odrzucać. Wbudowane powiadomienie SNS było w stanie pokonać niestandardowe powiadomienie dziennika zdarzeń CloudWatch, które Medidata zbudowała, aby powiadomić aplikację o zakończeniu zadania. W tym przypadku podejście wnioskowania asynchronicznego jest tańsze niż Lambda. Asynchroniczne wnioskowanie SageMaker to doskonała opcja, jeśli Twój zespół pracuje z dużymi obciążeniami ML z dużym ruchem, próbując zminimalizować koszty. To świetny przykład współpracy z zespołem AWS w celu przekraczania granic i wykorzystywania najnowocześniejszej technologii w celu uzyskania maksymalnej wydajności.

Aby uzyskać szczegółowe instrukcje dotyczące tworzenia, wywoływania i monitorowania punktów końcowych wnioskowania asynchronicznego, zobacz dokumentacja, który zawiera również przykładowy notatnik aby pomóc Ci zacząć. Aby uzyskać informacje o cenach, odwiedź Cennik Amazon SageMaker. Aby zapoznać się z przykładami używania wnioskowania asynchronicznego z nieustrukturyzowanymi danymi, takimi jak widzenie komputerowe i przetwarzanie języka naturalnego (NLP), zobacz Uruchom wnioskowanie o wizji komputerowej na dużych filmach za pomocą asynchronicznych punktów końcowych Amazon SageMaker i Popraw wartościowe badania dzięki asynchronicznym punktom końcowym wnioskowania Hugging Face i Amazon SageMaker, Odpowiednio.

---

O autorach

Rajnizm dżinski jest starszym dyrektorem ds. inżynierii w Medidata AI z siedzibą w Nowym Jorku. Rajnish kieruje inżynierią nad pakietem aplikacji, które wykorzystują uczenie maszynowe w AWS, aby pomóc klientom poprawić sukces operacyjny proponowanych badań klinicznych. Pasjonuje się wykorzystaniem uczenia maszynowego do rozwiązywania problemów biznesowych.

Priyanka Kulkarni jest głównym inżynierem oprogramowania w Acorn AI w Medidata Solutions. Zajmuje się architekturą i rozwojem rozwiązań oraz infrastruktury do obsługi prognoz ML na dużą skalę. Jest inżynierem opartym na danych, który wierzy w tworzenie innowacyjnych rozwiązań programowych dla sukcesu klienta.

Daniel Johnson jest starszym inżynierem oprogramowania w Acorn AI w Medidata Solutions. Buduje interfejsy API do obsługi prognoz ML wokół wykonalności proponowanych badań klinicznych.

Arunprasath Shankar jest starszym architektem rozwiązań AI/ML z AWS, pomagającym globalnym klientom skutecznie i wydajnie skalować ich rozwiązania AI w chmurze. W wolnym czasie Arun lubi oglądać filmy science fiction i słuchać muzyki klasycznej.

Raghu Ramesza jest architektem rozwiązań ML w zespole Amazon SageMaker Service. Koncentruje się na pomaganiu klientom w tworzeniu, wdrażaniu i migracji obciążeń produkcyjnych ML do programu SageMaker na dużą skalę. Specjalizuje się w uczeniu maszynowym, sztucznej inteligencji i domenach widzenia komputerowego. Posiada tytuł magistra informatyki uzyskany na UT Dallas. W wolnym czasie lubi podróżować i fotografować.