Ten wpis na blogu jest współtworzony przez Jonathana Lee, Nelsona Leunga, Paula Mina i Troya Squillaciego z firmy Intel.
In Część 1 tego posta omówiliśmy współpracę z Intel®3DAT Profesjonalne usługi uczenia maszynowego AWS (MLPS) w celu zbudowania skalowalnej aplikacji AI SaaS. 3DAT wykorzystuje widzenie komputerowe i sztuczną inteligencję do rozpoznawania, śledzenia i analizowania ponad 1,000 punktów danych biomechanicznych ze standardowego wideo. Umożliwia klientom tworzenie bogatych i wydajnych produktów opartych na biomechanice, takich jak aplikacje internetowe i mobilne ze szczegółowymi danymi dotyczącymi wydajności i trójwymiarowymi wizualizacjami.
W części 2 tego posta zagłębiamy się w poszczególne etapy architektury. Badamy usługi AWS wykorzystywane do spełnienia wymagań projektowych 3DAT, w tym Strumienie danych Amazon Kinesis i Elastyczna usługa Amazon Kubernetes (Amazon EKS), w celu skalowalnego wdrożenia niezbędnych modeli szacowania pozycji dla tego oprogramowania jako aplikacji usługi (SaaS).
Przegląd architektury
Głównym celem zespołu MLPS była produkcja potoków modeli szacowania pozycji 2D i 3D oraz stworzenie funkcjonalnej i skalowalnej aplikacji. Poniższy diagram ilustruje architekturę rozwiązania.
Cała architektura jest podzielona na pięć głównych komponentów:
- Warstwy interfejsu aplikacji użytkownika
- Baza danych
- Orkiestracja przepływu pracy
- Generowanie wnioskowania skalowalnego estymacji pozycji
- Monitorowanie operacyjne
Przyjrzyjmy się szczegółowo każdemu komponentowi, ich interakcjom i uzasadnieniu wyboru projektu.
Warstwy interfejsu aplikacji użytkownika
Poniższy diagram przedstawia warstwy interfejsu aplikacji, które zapewniają użytkownikowi dostęp i kontrolę nad aplikacją i jej zasobami.
Te punkty dostępu obsługują różne przypadki użycia w oparciu o różne osobowości klientów. Na przykład użytkownik aplikacji może przesłać zadanie za pośrednictwem interfejsu wiersza polecenia, podczas gdy programista może zbudować aplikację za pomocą pakietu Python SDK i osadzić w swoich aplikacjach inteligencję szacowania pozycji. CLI i SDK są zbudowane jako komponenty modułowe — obie warstwy to wrappery warstwy API, która jest zbudowana przy użyciu Brama Amazon API aby rozwiązać wywołania API i powiązane AWS Lambda funkcje, które dbają o logikę zaplecza powiązaną z każdym wywołaniem API. Warstwy te były kluczowym elementem dla zespołu Intel OTG, ponieważ otwierają szeroką bazę klientów, którzy mogą efektywnie korzystać z tej aplikacji SaaS.
Warstwa API
Rozwiązanie posiada podstawowy zestaw dziewięciu interfejsów API, które odpowiadają typom obiektów działających na tej platformie. Każdy interfejs API ma plik Pythona, który definiuje działania interfejsu API, które można uruchomić. Przy tworzeniu nowych obiektów automatycznie przypisywany jest sekwencyjny identyfikator obiektu. Atrybuty tych obiektów są przechowywane i śledzone w Amazon Aurora bezserwerowy bazy danych przy użyciu tego identyfikatora. W związku z tym działania interfejsu API są powiązane z funkcjami zdefiniowanymi w pliku centralnym, który zawiera logikę zaplecza do wykonywania zapytań do bazy danych Aurora. Ta logika backendu używa Boto3 Klient Amazon RDS DataService aby uzyskać dostęp do klastra bazy danych.
Jedynym wyjątkiem jest /job
API, który ma create_job
metoda obsługująca przesyłanie wideo w celu utworzenia nowego zadania przetwarzania. Ta metoda rozpoczyna Funkcje kroków AWS logika przepływu pracy dla uruchomienia zadania. Przechodząc w a job_id
, ta metoda wykorzystuje Boto3 Klient funkcji Step zadzwonić do start_execution
metoda dla określonego stateMachineARN
(Nazwa zasobu Amazon).
Osiem obiektów API ma metody i podobny wzorzec dostępu, jak podsumowano w poniższej tabeli.
Rodzaj metody | Nazwa funkcji | Opis |
GET | list_[object_name]s |
Wybiera wszystkie obiekty tego typu z bazy danych i wyświetla. |
POST | create_[object] |
Wstawia do bazy danych nowy rekord obiektu z wymaganymi danymi wejściowymi. |
GET | get_[object] |
Wybiera atrybuty obiektu na podstawie identyfikatora obiektu z bazy danych i wyświetla. |
PUT | update_[object] |
Aktualizuje istniejący rekord obiektu o wymagane dane wejściowe. |
DELETE | delete_[object] |
Usuwa istniejący rekord obiektu z bazy danych na podstawie identyfikatora obiektu. |
Szczegóły dziewięciu interfejsów API są następujące:
- /użytkownik – Użytkownik to tożsamość osoby upoważnionej do przesyłania zadań do tej aplikacji. Utworzenie użytkownika wymaga nazwy użytkownika, adresu e-mail użytkownika i identyfikatora grupy, do której należy użytkownik.
- /grupa_użytkowników – Grupa użytkowników to zbiór użytkowników. Każda grupa użytkowników jest mapowana na jeden projekt i jeden zestaw parametrów potoku. Aby mieć różne poziomy (pod względem zasobów infrastrukturalnych i parametrów potoku), użytkownicy są podzieleni na grupy użytkowników. Każdy użytkownik może należeć tylko do jednej grupy użytkowników. Utworzenie grupy użytkowników wymaga identyfikatora projektu, identyfikatora zestawu parametrów potoku, nazwy grupy użytkowników i opisu grupy użytkowników. Pamiętaj, że grupy użytkowników różnią się od ról użytkowników zdefiniowanych na koncie AWS. Ten ostatni służy do zapewniania różnych poziomów dostępu w zależności od ich ról dostępu (na przykład admin).
- /projekt – Projekt służy do grupowania różnych zestawów zasobów infrastrukturalnych. Projekt jest powiązany z pojedynczym
project_cluster_url
(klaster Aurora) do rejestrowania użytkowników, zadań i innych metadanych, aproject_queue_arn
(Kinesis Data Streams ARN) oraz obliczeniowe środowisko wykonawcze (obecnie kontrolowane przez Cortex) używane do uruchamiania wnioskowania na partiach klatek lub przetwarzania końcowego filmów. Każda grupa użytkowników jest powiązana z jednym projektem, a ten mechanizm określa, w jaki sposób różne warstwy są włączane pod względem opóźnienia i mocy obliczeniowej dla różnych grup użytkowników. Do utworzenia projektu wymagana jest nazwa projektu, adres URL klastra projektu i kolejka projektu ARN. - /rurociąg – Potok jest powiązany z pojedynczą konfiguracją dla sekwencji kontenerów przetwarzania, które wykonują przetwarzanie wideo w klastrze generowania wnioskowania Amazon EKS koordynowanym przez Cortex (więcej szczegółów można znaleźć w sekcji poświęconej generowaniu wnioskowania przetwarzania wideo). Zazwyczaj składa się to z trzech kontenerów: wstępnego przetwarzania i dekodowania, wykrywania obiektów i szacowania pozy. Na przykład krok dekodowania i wykrywania obiektów jest taki sam dla potoków 2D i 3D, ale zamiana ostatniego kontenera za pomocą HRNet lub 3DMPPE skutkuje zestawem parametrów dla potoków przetwarzania 2D i 3D. Możesz tworzyćnowe konfiguracje, aby zdefiniowaćmożliwe potoki, które mogąbyćużyte do przetwarzania, a jako dane wejściowe wymagany jest nowy plik Pythona w repozytorium Cortex, który szczegółowo opisuje sekwencję wywołań punktów końcowych modelu definiujących ten potok (zobacz sekcję o generowaniu wnioskowania z przetwarzania wideo ). Punkt końcowy potoku to punkt końcowy Cortex, który jest wywoływany do przetwarzania pojedynczej ramki. Utworzenie potoku wymaga nazwy potoku, opisu potoku i punktu końcowego potoku.
- /zestaw_parametrów_potoku – Zestaw parametrów potoku to elastyczny zbiór wielu parametrów JSON (środowisko wykonawcze konfiguracji potoku) dla konkretnego potoku, który jest dodawany w celu zapewnienia elastyczności na potrzeby przyszłego dostosowywania, gdy wymaganych jest wiele środowisk wykonawczych konfiguracji potoku. Grupy użytkowników mogą być skojarzone z określonym zestawem parametrów potoku, a jego celem jest posiadanie różnych grup parametrów na grupę użytkowników i na potok. Był to ważny, perspektywiczny dodatek dla Intel OTG, umożliwiający dostosowanie, które obsługuje przenośność, gdy różni klienci, w szczególności niezależni dostawcy oprogramowania, zaczynają korzystać z aplikacji.
- /parametry_potoku – Pojedynczy zbiór parametrów potoku jest instancją zestawu parametrów potoku. To sprawia, że jest to mapowanie 1:wielu zestawu parametrów potoku do parametrów potoku. Ten interfejs API wymaga identyfikatora potoku do skojarzenia z zestawem parametrów potoku, który umożliwia tworzenie potoku dla mapowania 1:1 parametrów potoku do potoku. Inne dane wejściowe wymagane przez ten interfejs API to identyfikator zestawu parametrów potoku, wartość parametrów potoku i nazwa parametrów potoku.
- /wideo – Obiekt wideo służy do definiowania poszczególnych filmów, które składają się na pakiet .zip przesłany podczas zadania. Po przesłaniu ten plik jest podzielony na kilka filmów. Film jest powiązany z
job_id
dla zadania, w którym przesyłany jest pakiet .zip, oraz Usługa Amazon Simple Storage (Amazon S3) ścieżki dla lokalizacji nieprzetworzonych filmów wideo i wyniki przetwarzania końcowego każdego filmu. Obiekt wideo zawiera również procent postępu wideo, który jest stale aktualizowany podczas przetwarzania poszczególnych partii klatek tego wideo, a także flagę stanu wideo jako ukończona lub nieukończona. Utworzenie wideo wymaga identyfikatora zadania, ścieżki wideo, ścieżki wyników wideo, procentu postępu wideo i stanu wideo. - /paczka_ramek -
frame_batch
obiekt to mini-partia ramek utworzonych przez samplowanie pojedynczego wideo. Rozdzielenie wideo na partie klatek o regularnych rozmiarach zapewnia dźwignię do dostrajania opóźnień i zwiększa równoległość i przepustowość. Jest to jednostka granularna, która jest uruchamiana przez strumienie danych Kinesis w celu wnioskowania. Tworzenie partii ramek wymaga identyfikatora wideo, numeru początkowego partii ramek, numeru końcowego partii ramek, ścieżki wejściowej partii ramek, ścieżki wyników partii ramek i statusu partii ramek. - /stanowisko – Ten interfejs API interakcji służy do przesyłania plików w celu uruchomienia zadania przetwarzania. Ten interfejs API ma inną funkcję niż inne interfejsy API obiektów, ponieważ jest to bezpośrednia ścieżka do interakcji z koordynacją przepływu pracy zaplecza przetwarzania wideo Step Functions i klastrem Amazon EKS. Ten interfejs API wymaga identyfikatora użytkownika, identyfikatora projektu, identyfikatora potoku, identyfikatora zestawu parametrów potoku, parametrów zadania i stanu zadania. W parametrach zadania określona jest ścieżka pliku wejściowego, czyli lokalizacja w Amazon S3, w której znajduje się pakiet .zip filmów do przetworzenia. Przesyłanie plików jest obsługiwane za pomocą
upload_handler
metoda, która generuje predefiniowany adres URL S3, aby użytkownik mógł umieścić plik. WORKFLOW_STATEMACHINE_ARN to zmienna środowiskowa przekazywana docreate_job
Interfejs API do określenia, gdzie przesyłany jest pakiet .zip wideo ze ścieżką do pliku wejściowego w celu rozpoczęcia zadania.
Poniższa tabela zawiera podsumowanie funkcji API.
Rodzaj metody | Funkcjonować | Opis |
GET | list_jobs |
Wybiera wszystkie zadania z bazy danych i wyświetla. |
POST | create_ job |
Wstawia nowy rekord zadania z identyfikatorem użytkownika, identyfikatorem projektu, identyfikatorem potoku, identyfikatorem zestawu parametrów potoku, ścieżką wyników zadania, parametrami zadania i stanem zadania. |
GET | get_ job |
Wybiera atrybuty zadania na podstawie identyfikatora zadania z bazy danych i wyświetla. |
GET | upload_handler |
Generuje wstępnie podpisany adres URL S3 jako lokalizację do przesłania pliku .zip. Wymaga nazwy zasobnika S3 i oczekuje typu aplikacji/pliku ZIP. |
Warstwa Pythona SDK
Opierając się na API, zespół stworzył bibliotekę klienta Python SDK jako opakowanie, aby ułatwić programistom dostęp do metod API. Wykorzystali open-source Poezja, który obsługuje pakowanie w Pythonie i zarządzanie zależnościami. Stworzyli client.py
plik zawierający funkcje opakowujące każdy z interfejsów API przy użyciu Python requests
biblioteka do obsługi żądań API i wyjątków.
Aby programiści mogli uruchomić Intel 3DAT SDK, muszą zainstalować i zbudować pakiet Poetry. Następnie mogą dodać prosty import Pythona z intel_3dat_sdk
do dowolnego kodu Pythona.
Aby użyć klienta, możesz utworzyć instancję klienta, określając punkt końcowy API:
Następnie możesz użyć klienta do wywołania poszczególnych metod, takich jak create_pipeline
metody (patrz poniższy kod), przyjmując odpowiednie argumenty, takie jak nazwa potoku i opis potoku.
Warstwa CLI
Podobnie zespół wykorzystał API, aby stworzyć interfejs wiersza poleceń dla użytkowników, którzy chcą uzyskać dostęp do metod API za pomocą prostego interfejsu, bez konieczności pisania kodu w Pythonie. Wykorzystali pakiet Pythona o otwartym kodzie źródłowym Kliknij (Zestaw do tworzenia interfejsu wiersza poleceń). Zaletami tego frameworka są dowolne zagnieżdżanie poleceń, automatyczne generowanie stron pomocy oraz obsługa leniwego ładowania podkomend w czasie wykonywania. W tym samym client.py
tak jak w SDK, każda metoda klienta SDK została opakowana za pomocą Click, a wymagane argumenty metody zostały przekonwertowane na flagi wiersza poleceń. Wejścia flag są następnie używane podczas wywoływania polecenia SDK.
Aby uruchomić CLI, możesz użyć CLI configure
Komenda. Zostaniesz poproszony o podanie adresu URL punktu końcowego:
Teraz możesz używać CLI do wywoływania różnych poleceń związanych z metodami API, na przykład:
Baza danych
Jako baza danych aplikacja używa Aurora Serverless do przechowywania metadanych powiązanych z każdym z interfejsów API z MYSQL jako silnikiem bazy danych. Wybór usługi bazy danych Aurora Serverless jest zgodny z zasadą projektowania, aby zminimalizować koszty infrastruktury poprzez wykorzystanie bezserwerowych usług AWS, gdy tylko jest to możliwe. Poniższy diagram ilustruje tę architekturę.
Połączenia tryb silnika bezserwerowego spełnia wzorce przerywanego użytkowania, ponieważ ta aplikacja jest skalowana do nowych klientów, a obciążenia są nadal niepewne. Podczas uruchamiania punktu końcowego bazy danych nie jest wymagany określony rozmiar wystąpienia bazy danych, tylko minimalny i maksymalny zakres pojemności klastra. Aurora Serverless obsługuje odpowiednie przydzielanie floty routerów i rozdziela obciążenie między zasoby. Aurora Serverless automatycznie wykonuje przechowywanie kopii zapasowych przez co najmniej 1 dzień do 35 dni. Zespół zoptymalizował pod kątem bezpieczeństwa, ustawiając domyślną maksymalną wartość 35.
Ponadto zespół wykorzystał Interfejs API danych do obsługi dostępu do klastra Aurora Serverless, który nie wymaga stałego połączenia, a zamiast tego zapewnia bezpieczny punkt końcowy HTTP i integrację z zestawami SDK AWS. Ta funkcja wykorzystuje Menedżer tajemnic AWS do przechowywania poświadczeń bazy danych, dzięki czemu nie ma potrzeby jawnego przekazywania poświadczeń. Skrypty CREATE TABLE zostały napisane w plikach .sql dla każdej z dziewięciu tabel, które odpowiadają dziewięciu API. Ponieważ baza ta zawierała wszystkie metadane i stan obiektów w systemie, metody API były uruchamiane za pomocą odpowiednich poleceń SQL (np. select * from Job
dla list_jobs
API) i przekazany do execute_statement
metoda z klienta Amazon RDS w Data API.
Orkiestracja przepływu pracy
Funkcjonalny szkielet aplikacji był obsługiwany przy użyciu funkcji krokowych do koordynowania przepływu pracy, jak pokazano na poniższym diagramie.
Maszyna stanów składała się z sekwencji czterech funkcji Lambda, która rozpoczyna się, gdy zadanie jest przesyłane za pomocą create_job
metoda z job
API. Do utworzenia zadania wymagane są identyfikator użytkownika, identyfikator projektu, identyfikator potoku, identyfikator zestawu parametrów potoku, ścieżka wyników zadania, parametry zadania i status zadania. Możesz najpierw przesłać pakiet .zip plików wideo za pomocą upload_handler
metoda z interfejsu API zadania, aby wygenerować wstępnie podpisany adres URL S3. Podczas przesyłania zadania ścieżka pliku wejściowego jest przekazywana za pośrednictwem parametrów zadania w celu określenia lokalizacji pliku. Spowoduje to uruchomienie maszyny stanów przepływu pracy, wyzwalając cztery główne kroki:
- Inicjator funkcji Lambda
- Funkcja Lambda nadawcy
- Sprawdzanie zakończenia funkcji Lambda
- Funkcja kolektora Lambda
Inicjator funkcji Lambda
Główną funkcją Inicjatora jest rozdzielenie pakietu .zip na pojedyncze pliki wideo i przygotowanie ich dla Przesyłającego. Najpierw pobierany jest plik .zip, a następnie każdy plik, w tym pliki wideo, jest rozpakowywany i wyodrębniany. Filmy, najlepiej w formacie .mp4, są przesyłane z powrotem do zasobnika S3. Używając create_video
metoda w video
API, tworzony jest obiekt wideo ze ścieżką wideo jako dane wejściowe. Spowoduje to wstawienie danych o każdym filmie do bazy danych Aurora. Wszelkie inne typy plików, takie jak pliki JSON, są traktowane jako metadane i podobnie przesyłane, ale nie jest tworzony żaden obiekt wideo. Lista nazw plików i wyodrębnionych plików wideo jest przekazywana do następnego kroku.
Funkcja Lambda nadawcy
Funkcja Submitter pobiera pliki wideo, które zostały wyodrębnione przez inicjator i tworzy mini-partie klatek wideo jako obrazy. Większość obecnych w produkcji modeli wizji komputerowych została przeszkolona na obrazach, więc nawet podczas przetwarzania wideo są one najpierw rozdzielane na klatki obrazu przed wnioskowaniem modelu. To obecne rozwiązanie wykorzystujące najnowocześniejszy model estymacji pozy nie różni się niczym — partie ramek z programu Submitter są przekazywane do strumieni danych Kinesis w celu zainicjowania etapu generowania wnioskowania.
Najpierw plik wideo jest pobierany przez funkcję Lambda. Szybkość klatek i liczba klatek są obliczane za pomocą FileVideoStream
moduł z imutils.video
biblioteka przetwarzania. Ramki są wyodrębniane i grupowane zgodnie z określonym rozmiarem mini-partii, co jest jednym z kluczowych parametrów tego potoku, które można dostrajać. Korzystając z biblioteki Python pickle, dane są serializowane i przesyłane do Amazon S3. Następnie tworzony jest obiekt wsadowy ramek, a w bazie danych Aurora tworzony jest wpis metadanych. Ta funkcja Lambda została zbudowana przy użyciu pliku Dockerfile z zależnościami od opencv-python
, numpy
, imutils
biblioteki.
Sprawdzanie zakończenia funkcji Lambda
Funkcja sprawdzania ukończenia kontynuuje wysyłanie zapytań do bazy danych Aurora, aby zobaczyć, dla każdego filmu w pakiecie .zip dla bieżącego zadania, ile partii klatek ma status ZAKOŃCZONE. Proces sprawdzania jest zakończony, gdy wszystkie partie klatek dla wszystkich filmów są gotowe.
Funkcja kolektora Lambda
Funkcja kolektora pobiera dane wyjściowe wniosków, które zostały wykonane na każdej klatce na etapie konsumenta, i łączy je w partii klatek i wideo. Połączone scalone dane są następnie przesyłane do zasobnika S3. Następnie funkcja wywołuje interfejs API przetwarzania końcowego Cortex dla określonego potoku ML w celu wykonania obliczeń przetwarzania końcowego i dodaje zagregowane wyniki za pomocą wideo do zasobnika wyjściowego. Wiele z tych metryk jest obliczanych w różnych klatkach, takich jak prędkość, przyspieszenie i kąt stawu, więc to obliczenie należy przeprowadzić na danych zagregowanych. Główne dane wyjściowe obejmują dane o kluczowych punktach ciała (zagregowane w formacie CSV), obliczenia BMA (takie jak przyspieszenie) oraz wizualną nakładkę kluczowych punktów dodawanych do każdej klatki w pliku obrazu.
Generowanie wnioskowania skalowalnego estymacji pozycji
Na tym etapie występuje silnik przetwarzania, który obsługuje skalowanie wnioskowania ML. Obejmuje trzy główne elementy, z których każdy ma własne dźwignie współbieżności, które można dostroić pod kątem kompromisów dotyczących opóźnień (patrz poniższy diagram).
Ta architektura pozwala na eksperymentowanie w testowaniu opóźnień, a także elastyczność na przyszłość, gdy obciążenia mogą się zmieniać wraz z różnymi kombinacjami segmentów użytkowników końcowych, którzy uzyskują dostęp do aplikacji.
Strumienie danych kinezy
Zespół wybrał Kinesis Data Streams, ponieważ jest zwykle używany do obsługi danych przesyłanych strumieniowo, a w tym przypadku jest to dobre dopasowanie, ponieważ może obsługiwać partie ramek w podobny sposób, aby zapewnić skalowalność i równoległość. W funkcji Submitter Lambda używany jest klient Kinesis Boto3, z: put_record
metoda przekazująca metadane związane z pojedynczą partią ramek, takie jak identyfikator partii ramek, ramka początkowa partii ramek, ramka końcowa partii ramek, kształt obrazu, liczba klatek na sekundę i identyfikator wideo.
Zdefiniowaliśmy różne konfiguracje kolejki zadań i strumienia danych Kinesis, aby ustawić poziomy przepustowości, które są powiązane z poziomem priorytetu różnych grup użytkowników. Dostęp do różnych poziomów mocy obliczeniowej jest połączony poprzez przekazanie kolejki projektu ARN podczas tworzenia nowego projektu za pomocą project
API. Każda grupa użytkowników jest następnie połączona z określonym projektem podczas tworzenia grupy użytkowników. Trzy domyślne konfiguracje strumieni są zdefiniowane w AWS Serverless Model aplikacji (AWS SAM) szablon infrastruktury:
- Standard -
JobStreamShardCount
- Priorytet -
PriorityJobStreamShardCount
- Wysoki priorytet -
HighPriorityJobStreamShardCount
Zespół użył kilku różnych dźwigni, aby zróżnicować moc przetwarzania każdego strumienia lub dostroić opóźnienie systemu, jak podsumowano w poniższej tabeli.
Dźwignia | Opis | Domyślna wartość |
Czerep | Fragment jest natywny dla strumieni danych Kinesis; to podstawowa jednostka przepustowości przetwarzania. Wartość domyślna to 1 MB/s, co odpowiada 1,000 rekordów danych na sekundę. | 2 |
KinesisBatchSize |
Maksymalna liczba rekordów, które Kinesis Data Streams pobiera w jednej partii przed wywołaniem konsumenckiej funkcji Lambda. | 1 |
KinesisParallelizationFactor |
Liczba partii do przetworzenia z każdego fragmentu jednocześnie. | 1 |
Ulepszone rozchodzenie się | Odbiorcy danych, którzy aktywowali rozszerzone rozszerzanie, mają dedykowaną przepustowość pozyskiwania na konsumenta (na przykład domyślną 1 MB/s), zamiast współdzielić przepływność między konsumentami. | poza |
Funkcja Lambda konsumencka
Z perspektywy strumieni danych Kinesis konsument danych jest usługą AWS, która pobiera dane z fragmentu strumienia danych, gdy dane są generowane w strumieniu. Ta aplikacja używa funkcji Consumer Lambda, która jest wywoływana, gdy komunikaty są przekazywane z kolejek strumienia danych. Każda funkcja konsumenta przetwarza jedną partię ramek, wykonując następujące kroki. Najpierw wywołanie jest wykonywane synchronicznie do interfejsu API procesora Cortex, który jest punktem końcowym obsługującym potok wnioskowania o modelu (więcej szczegółów znajduje się w następnej sekcji dotyczącej Amazon EKS z Cortex). Wyniki są przechowywane w Amazon S3, a aktualizacja jest dokonywana w bazie danych poprzez zmianę statusu przetworzonej partii ramek na Complete
. Obsługa błędów jest wbudowana w celu zarządzania wywołaniem Cortex API z pętlą ponawiania w celu obsługi wszelkich błędów 504 z klastra Cortex, z liczbą ponownych prób ustawioną na 5.
Amazon EKS z Cortex do wnioskowania ML
Zespół wykorzystał Amazon EKS, zarządzaną usługę Kubernetes w AWS, jako silnik obliczeniowy do wnioskowania ML. Podjęto decyzję projektową, aby używać Amazon EKS do hostowania punktów końcowych ML, co zapewnia elastyczność uruchamiania Kubernetes z opcją klastrów w pełni zarządzanych w AWS za pośrednictwem AWS-Fargatelub sprzęt lokalny za pośrednictwem Amazon EKS Wszędzie. Był to kluczowy element funkcjonalności wymagany przez Intel OTG, który zapewniał na przykład opcję podłączenia tej aplikacji do specjalistycznego sprzętu lokalnego.
Trzy modele ML, które były elementami konstrukcyjnymi do konstruowania potoków wnioskowania, były niestandardowym modelem Yolo (do wykrywania obiektów), niestandardowym modelem HRNet (do oszacowania pozy 2D) i modelem 3DMPPE (do oszacowania pozy 3D) (patrz poprzedni Więcej szczegółów w sekcji ML). Wykorzystali open-source Kora biblioteka do obsługi wdrażania i zarządzania punktami końcowymi potoku wnioskowania ML oraz uruchamiania i wdrażania klastrów Amazon EKS. Każdy z tych modeli został spakowany w kontenerach Dockera — pliki modeli były przechowywane w Amazon S3, a obrazy modeli były przechowywane w Rejestr elastycznego pojemnika Amazon (Amazon ECR) — i wdrażane jako interfejsy API Cortex Realtime. Wersje kontenerów modeli, które działają na procesorze CPU i GPU, zostały utworzone, aby zapewnić elastyczność dla typu sprzętu obliczeniowego. W przyszłości, jeśli trzeba będzie dodać dodatkowe modele lub potoki modeli, mogą po prostu utworzyć dodatkowe interfejsy API Cortex Realtime.
Następnie skonstruowali potoki wnioskowania, składając razem interfejsy API modelu Cortex Realtime w interfejsy API potoku Cortex Realtime. Pojedynczy interfejs API potoku czasu rzeczywistego składał się z wywołania sekwencji interfejsów API modelu czasu rzeczywistego. Funkcje Lambda konsumencka traktowane a pipeline
Interfejs API jako czarna skrzynka, przy użyciu pojedynczego wywołania interfejsu API do pobrania końcowych danych wyjściowych wnioskowania dla obrazu. Utworzono dwa rurociągi: rurociąg 2D i rurociąg 3D.
Potok 2D łączy etap wstępnego przetwarzania dekodowania, wykrywanie obiektów przy użyciu niestandardowego modelu Yolo w celu zlokalizowania sportowca i stworzenia ramek ograniczających, a na koniec niestandardowy model HRNet do tworzenia kluczowych punktów 2D w celu oszacowania pozy.
Potok 3D łączy etap wstępnego przetwarzania dekodowania, wykrywanie obiektów przy użyciu niestandardowego modelu Yolo w celu zlokalizowania sportowca i stworzenia ramek ograniczających, a na koniec model 3DMPPE do tworzenia kluczowych punktów 3D do oszacowania pozy.
Po wygenerowaniu wnioskowania na partii ramek, każdy potok zawiera również oddzielny punkt końcowy Cortex w czasie rzeczywistym, który generuje trzy główne dane wyjściowe:
- Zagregowane dane punktów kluczowych treści w jednym pliku CSV
- Obliczenia BMA (takie jak przyspieszenie)
- Wizualna nakładka kluczowych punktów dodana do każdej klatki w pliku obrazu
Funkcja Collector Lambda przesyła do punktu końcowego odpowiednie metadane związane z konkretnym wideo, takie jak identyfikatory klatek i lokalizacje S3 danych wyjściowych wnioskowania oszacowania pozycji, w celu wygenerowania tych danych wyjściowych przetwarzania końcowego.
Cortex został zaprojektowany do integracji z Amazon EKS i wymaga jedynie pliku konfiguracyjnego klastra i prostego polecenia do uruchomienia klastra Kubernetes:
Inną dźwignią dostrajania wydajności była konfiguracja instancji dla klastrów obliczeniowych. Utworzono trzy warstwy z różnymi kombinacjami wystąpień M5 i G4dn, skodyfikowanych jako pliki .yaml ze specyfikacjami, takimi jak nazwa klastra, region oraz konfiguracja i miks wystąpienia. Instancje M5 są oparte na tańszych procesorach CPU, a G4dn są oparte na droższych procesorach graficznych, co zapewnia pewien kompromis między kosztami a wydajnością.
Monitorowanie operacyjne
Aby zachować operacyjne standardy rejestrowania, wszystkie funkcje Lambda zawierają kod do rejestrowania i pozyskiwania dzienników za pośrednictwem Wąż strażacki Amazon Kinesis Data. Na przykład każda partia ramek przetwarzana z funkcji Submitter Lambda jest rejestrowana ze znacznikiem czasu, nazwą akcji i odpowiedzią funkcji Lambda w formacie JSON i zapisywana w Amazon S3. Poniższy diagram ilustruje ten krok w architekturze.
Rozlokowanie
Wdrożenie odbywa się za pomocą AWS SAM, frameworka open source do tworzenia aplikacji bezserwerowych w AWS. AWS SAM umożliwia skodyfikowanie i łatwe wdrażanie w nowych środowiskach AWS projektowania infrastruktury, w tym funkcji, interfejsów API, baz danych i mapowania źródeł zdarzeń. Podczas wdrażania składnia AWS SAM jest tłumaczona na Tworzenie chmury AWS do obsługi udostępniania infrastruktury.
A template.yaml
plik zawiera specyfikacje infrastruktury wraz z parametrami dostrajalnymi, takimi jak dźwignie opóźnienia strumieni danych Kinesis wyszczególnione w poprzednich sekcjach. A samconfig.toml
plik zawiera parametry wdrożenia, takie jak nazwa stosu, nazwa zasobnika S3, w którym przechowywane są pliki aplikacji, takie jak kod funkcji Lambda, oraz znaczniki zasobów do śledzenia kosztów. Skrypt powłoki deploy.sh z prostymi poleceniami to wszystko, co jest wymagane do zbudowania i wdrożenia całego szablonu:
Przepływ pracy użytkownika
Podsumowując, po wdrożeniu infrastruktury, możesz zacząć od tego przepływu pracy:
- Utwórz klienta Intel 3DAT przy użyciu biblioteki klienta.
- Użyj interfejsu API, aby utworzyć nowe wystąpienie potoku odpowiadające wymaganemu typowi przetwarzania, takie jak szacowanie pozycji 3D.
- Utwórz nową instancję projektu, przekazując w klastrze ARN i kolejce Kinesis ARN.
- Utwórz nowe wystąpienie zestawu parametrów potoku.
- Utwórz nowe wystąpienie parametrów potoku, które są mapowane na zestaw parametrów potoku.
- Utwórz nową grupę użytkowników skojarzoną z identyfikatorem projektu i identyfikatorem zestawu parametrów potoku.
- Utwórz nowego użytkownika powiązanego z grupą użytkowników.
- Prześlij plik .zip z filmami do Amazon S3, korzystając z gotowego adresu URL S3 wygenerowanego przez funkcję przesyłania w interfejsie API zadań.
- Prześlij
create_job
Wywołanie API z parametrami zadania, które określają lokalizację plików wideo. To rozpoczyna zadanie przetwarzania.
Wnioski
Aplikacja jest już dostępna i gotowa do przetestowania zarówno ze sportowcami, jak i trenerami. Intel OTG jest podekscytowany możliwością udostępnienia innowacyjnej technologii szacowania pozycji za pomocą wizji komputerowej różnym użytkownikom, od programistów przez sportowców po partnerów dostawców oprogramowania.
Zespół AWS z pasją pomaga klientom, takim jak Intel OTG, przyspieszyć ich podróż do ML, od etapu tworzenia pomysłów i odkrywania w ML Solutions Lab do etapu utwardzania i wdrażania z AWS ML ProServe. Wszyscy będziemy uważnie obserwować tegoroczne igrzyska olimpijskie w Tokio w 2021 roku, aby wyobrazić sobie wszystkie postępy, które ML może odblokować w sporcie.
Zacznij dziś! Poznaj swój przypadek użycia z usługami wymienionymi w tym poście i wieloma innymi w Konsola zarządzania AWS.
O autorach
Han Man jest starszym menedżerem ds. uczenia maszynowego i sztucznej inteligencji w AWS z siedzibą w San Diego w Kalifornii. Posiada doktorat z inżynierii na Northwestern University i posiada kilkuletnie doświadczenie jako konsultant ds. zarządzania doradzający klientom w zakresie produkcji, usług finansowych i energetyki. Dziś z pasją współpracuje z klientami z różnych branż, aby opracowywać i wdrażać rozwiązania uczenia maszynowego i sztucznej inteligencji w AWS. Lubi śledzić NBA i grać w koszykówkę w wolnym czasie.
Iman Kamyabi jest inżynierem ML w AWS Professional Services. Współpracował z szeroką gamą klientów AWS, aby promować najlepsze praktyki w tworzeniu powtarzalnych i niezawodnych potoków ML.
Jonathan Lee jest dyrektorem Sports Performance Technology w Olympic Technology Group w firmie Intel. Studiował zastosowanie uczenia maszynowego w zdrowiu na studiach licencjackich na UCLA oraz podczas pracy podyplomowej na Uniwersytecie Oksfordzkim. Jego kariera koncentrowała się na opracowywaniu algorytmów i czujników dla zdrowia i wydajności człowieka. Obecnie kieruje projektem 3D Athlete Tracking w firmie Intel.
Nelsona Leunga jest architektem platform w Sports Performance CoE w firmie Intel, gdzie definiuje kompleksową architekturę dla najnowocześniejszych produktów, które zwiększają wydajność sportowców. Kieruje także wdrażaniem, wdrażaniem i produkcją tych rozwiązań uczenia maszynowego na dużą skalę dla różnych partnerów firmy Intel.
Troya Squillaci’ego jest inżynierem DecSecOps w firmie Intel, gdzie dostarcza klientom profesjonalne rozwiązania programowe w oparciu o najlepsze praktyki DevOps. Lubi integrować rozwiązania AI ze skalowalnymi platformami w różnych dziedzinach.
Paweł Min jest stażystą Associate Solutions Architect w Amazon Web Services (AWS), gdzie pomaga klientom z różnych branż w realizacji ich misji i przyspieszaniu ich wdrażania w chmurze. Wcześniej pracował w firmie Intel jako stażysta ds. inżynierii oprogramowania, aby pomóc w opracowaniu pakietu SDK 3D Athlete Tracking Cloud SDK. Poza pracą Paul lubi grać w golfa i można go usłyszeć, jak śpiewa.
- Coinsmart. Najlepsza w Europie giełda bitcoinów i kryptowalut.
- Platoblockchain. Web3 Inteligencja Metaverse. Wzmocniona wiedza. DARMOWY DOSTĘP.
- CryptoJastrząb. Radar Altcoin. Bezpłatna wersja próbna.
- Źródło: https://aws.amazon.com/blogs/machine-learning/the-intel3d-athlete-tracking-3dat-scalable-architecture-deploys-pose-estimation-models-using-amazon-kinesis-data-streams- i-amazon-eks/
- "
- &
- 000
- 100
- 2021
- 3d
- O nas
- przyśpieszyć
- dostęp
- dostępny
- Stosownie
- Konto
- w poprzek
- Działania
- działania
- dodatek
- Dodatkowy
- Admin
- Przyjęcie
- AI
- algorytm
- Wszystkie kategorie
- Amazonka
- Amazon Web Services
- wśród
- api
- Pszczoła
- Zastosowanie
- aplikacje
- właściwy
- architektura
- argumenty
- przydzielony
- Współpracownik
- sportowców
- atrybuty
- automatycznie
- AWS
- backup
- Koszykówka
- zanim
- Korzyści
- BEST
- Najlepsze praktyki
- Czarny
- Blog
- ciało
- Pudełko
- budować
- Budowanie
- wezwanie
- Pojemność
- który
- Kariera
- Etui
- centralny
- mistrz
- zmiana
- wybory
- klientów
- Chmura
- kod
- kolekcja
- kolektor
- połączony
- składnik
- obliczać
- komputer
- systemu
- połączenie
- konsultant
- konsument
- Konsumenci
- Pojemnik
- Pojemniki
- zawiera
- ciągły
- kontrola
- koordynować
- rdzeń
- Odpowiedni
- Stwórz
- stworzony
- tworzy
- Tworzenie
- tworzenie
- Listy uwierzytelniające
- krytyczny
- istotny
- Aktualny
- Obecnie
- zwyczaj
- klient
- Klientów
- pionierski nowatorski
- dane
- Baza danych
- Bazy danych
- dzień
- dedykowane
- głębiej
- dostarcza
- rozwijać
- wdrażane
- Wdrożenie
- wdraża się
- Wnętrze
- zaprojektowany
- detal
- szczegółowe
- detale
- Wykrywanie
- rozwijać
- Deweloper
- deweloperzy
- oprogramowania
- różne
- różnicować
- kierować
- Dyrektor
- odkrycie
- wyświetlacze
- Doker
- Nie
- domeny
- na dół
- podczas
- z łatwością
- Punkt końcowy
- energia
- silnik
- inżynier
- Inżynieria
- Środowisko
- wydarzenie
- przykład
- podniecony
- Przede wszystkim system został opracowany
- oczekuje
- doświadczenie
- odkryj
- Cecha
- W końcu
- budżetowy
- usługi finansowe
- i terminów, a
- dopasować
- FLOTA
- Elastyczność
- elastyczne
- koncentruje
- obserwuj
- następujący
- następujący sposób
- format
- przyszłościowe
- FRAME
- Framework
- funkcjonować
- funkcjonalny
- Funkcjonalność
- Funkcje
- przyszłość
- Generować
- generujący
- generacja
- Dający
- cel
- dobry
- GPU
- absolwent
- Zarządzanie
- Grupy
- uchwyt
- Prowadzenie
- sprzęt komputerowy
- Zdrowie
- wysłuchany
- pomoc
- pomoc
- pomaga
- tutaj
- wyższy
- W jaki sposób
- HTTPS
- człowiek
- tożsamość
- obraz
- wdrożenia
- realizacja
- ważny
- zawierać
- obejmuje
- Włącznie z
- indywidualny
- przemysłowa
- przemysł
- Infrastruktura
- Innowacyjny
- wkład
- Wkłady
- zainstalować
- zintegrowany
- integracja
- Intel
- Inteligencja
- wzajemne oddziaływanie
- Interfejs
- IT
- Praca
- Oferty pracy
- podróż
- Klawisz
- laboratorium
- uruchomić
- wodowanie
- Wyprowadzenia
- nauka
- poziom
- Biblioteka
- Linia
- Lista
- załadunek
- lokalizacja
- lokalizacji
- maszyna
- uczenie maszynowe
- zrobiony
- utrzymać
- poważny
- WYKONUJE
- mężczyzna
- zarządzanie
- zarządzane
- i konserwacjami
- produkcja
- mapa
- mapowanie
- wzmiankowany
- metody
- Metryka
- minimum
- Misja
- ML
- Aplikacje mobilne
- Aplikacje mobilne
- model
- modele
- Modułowa
- jeszcze
- większość
- wielokrotność
- Nazwy
- NBA
- niezbędny
- wymagania
- numer
- Igrzyska Olimpijskie
- otwiera
- działać
- zoptymalizowane
- Option
- zamówienie
- Inne
- własny
- Oxford
- pakiet
- część
- szczególny
- szczególnie
- wzmacniacz
- Przechodzący
- namiętny
- Wzór
- procent
- jest gwarancją najlepszej jakości, które mogą dostarczyć Ci Twoje monitory,
- wykonywania
- perspektywa
- kawałek
- Platforma
- Platformy
- gra
- Poezja
- zwrotnica
- możliwy
- power
- mocny
- Przygotować
- poprzedni
- pierwotny
- zasada
- priorytet
- wygląda tak
- procesów
- przetwarzanie
- Procesor
- produkować
- Produkcja
- Produkty
- profesjonalny
- projekt
- zapewniać
- zapewnia
- cel
- zasięg
- Surowy
- realtime
- rozpoznać
- rekord
- dokumentacja
- w sprawie
- rzetelny
- wywołań
- wymagać
- wymagany
- wymagania
- Wymaga
- Zasób
- Zasoby
- odpowiedź
- Efekt
- run
- bieganie
- Bezpieczeństwo
- San
- Skalowalność
- skalowalny
- Skala
- skalowaniem
- Sdk
- bezpieczne
- Segmenty
- Bezserwerowe
- usługa
- Usługi
- zestaw
- ustawienie
- Shape
- dzielenie
- Powłoka
- pokazane
- podobny
- Podobnie
- Prosty
- Rozmiar
- So
- Tworzenie
- Oprogramowanie jako usługa
- Inżynieria oprogramowania
- rozwiązanie
- Rozwiązania
- kilka
- Ktoś
- wyspecjalizowanym
- Specyfikacje
- prędkość
- SPORTOWE
- stos
- STAGE
- standard
- standardy
- początek
- rozpoczęty
- rozpocznie
- Stan
- state-of-the-art
- Rynek
- przechowywanie
- sklep
- strumień
- Streaming
- składane
- Następnie
- lato
- wsparcie
- podpory
- system
- biorąc
- zespół
- Technologia
- Testowanie
- w związku z tym
- Przez
- TIE
- czas
- już dziś
- razem
- Tokio
- śledzić
- Śledzenie
- typy
- zazwyczaj
- ucla
- uniwersytet
- University of Oxford
- odblokować
- Aktualizacja
- posługiwać się
- Użytkownicy
- Wykorzystując
- wartość
- różnorodność
- różnorodny
- pionowe
- Wideo
- Filmy
- wizja
- sieć
- usługi internetowe
- KIM
- bez
- Praca
- pracował
- pracujący
- lat