MLOps na krawędzi dzięki Amazon SageMaker Edge Manager i AWS IoT Greengrass

Internet rzeczy (IoT) umożliwił klientom z wielu branż, takich jak produkcja, motoryzacja i energetyka, monitorowanie i kontrolowanie rzeczywistych środowisk. Wdrażając różne urządzenia brzegowe IoT, takie jak kamery, termostaty i czujniki, możesz zbierać dane, wysyłać je do chmury i budować modele uczenia maszynowego (ML) w celu przewidywania anomalii, awarii i nie tylko. Jeśli jednak przypadek użycia wymaga przewidywania w czasie rzeczywistym, musisz wzbogacić swoje rozwiązanie IoT o możliwości ML na brzegu (ML@Edge). ML@Edge to koncepcja oddzielająca cykl życia modelu ML od cyklu życia aplikacji i umożliwiająca uruchomienie kompleksowego potoku ML, który obejmuje przygotowanie danych, budowanie modelu, kompilację i optymalizację modelu, wdrożenie modelu (do floty urządzeń brzegowych), wykonanie modelu oraz monitorowanie i zarządzanie modelem. Wdrażasz aplikację raz i uruchamiasz potok ML tyle razy, ile potrzebujesz.

Jak możesz sobie wyobrazić, wdrożenie wszystkich kroków proponowanych przez koncepcję ML@Edge nie jest trywialne. Istnieje wiele pytań, na które programiści muszą odpowiedzieć, aby wdrożyć kompletne rozwiązanie ML@Edge, na przykład:

• Jak obsługiwać modele ML na flocie (setki, tysiące lub miliony) urządzeń na brzegu sieci?
• Jak zabezpieczyć swój model podczas wdrażania i uruchamiania go na urządzeniach brzegowych?
• Jak monitorować wydajność mojego modelu i w razie potrzeby przeszkolić go?

W tym poście dowiesz się, jak odpowiedzieć na wszystkie te pytania i zbudować kompleksowe rozwiązanie do automatyzacji potoku ML@Edge. Zobaczysz, jak używać Menedżer krawędzi Amazon SageMaker, Studio Amazon SageMaker, AWS IoT Greengrass v2 stworzenie środowiska MLOps (ML Operations), które automatyzuje proces budowania i wdrażania modeli ML na dużych flotach urządzeń brzegowych.

W następnych sekcjach przedstawiamy architekturę referencyjną, która szczegółowo opisuje wszystkie komponenty i przepływy pracy wymagane do zbudowania kompletnego rozwiązania dla MLOps skupionych na obciążeniach brzegowych. Następnie zagłębiamy się w kroki, które to rozwiązanie uruchamia automatycznie, aby zbudować i przygotować nowy model. Pokazujemy również, jak przygotować urządzenia brzegowe do rozpoczęcia wdrażania, uruchamiania i monitorowania modeli ML oraz pokazujemy, jak monitorować i utrzymywać modele ML wdrożone w Twojej flocie urządzeń.

Omówienie rozwiązania

Produkcja solidnych modeli ML wymaga współpracy wielu osobistości, takich jak analitycy danych, inżynierowie ML, inżynierowie danych i interesariusze biznesowi, w ramach półautomatycznej infrastruktury wykonującej określone operacje (MLOps). Również modularyzacja środowiska jest ważna, aby zapewnić wszystkim tym różnym osobowościom elastyczność i sprawność w rozwijaniu lub ulepszaniu (niezależnie od przepływu pracy) komponentu, za który są odpowiedzialne. Przykładem takiej infrastruktury jest wiele kont AWS, które umożliwiają tę współpracę i produkcję modeli ML zarówno w chmurze, jak i na urządzeniach brzegowych. W poniższej architekturze referencyjnej pokazujemy, jak zorganizowaliśmy wiele kont i usług, które składają się na tę kompleksową platformę MLOps do budowania modeli ML i wdrażania ich na urządzeniach brzegowych.

To rozwiązanie składa się z następujących kont:

• Konto jeziora danych – Inżynierowie danych pobierają, przechowują i przygotowują dane z wielu źródeł danych, w tym lokalnych baz danych i urządzeń IoT.
• Konto narzędziowe – Operatorzy IT zarządzają i sprawdzają potoki CI/CD w celu zautomatyzowanego ciągłego dostarczania i wdrażania pakietów modeli ML na kontach przedprodukcyjnych i produkcyjnych dla zdalnych urządzeń brzegowych. Przebiegi potoków CI/CD są zautomatyzowane dzięki zastosowaniu Most zdarzeń Amazona, który monitoruje zdarzenia zmian statusu modeli i celów ML AWS Code Pipeline.
• Konto eksperymentów i rozwoju – Analitycy danych mogą prowadzić badania i eksperymentować z wieloma technikami modelowania i algorytmami, aby rozwiązywać problemy biznesowe oparte na ML, tworząc rozwiązania typu proof of concept. Inżynierowie ML i analitycy danych współpracują, aby skalować weryfikację koncepcji, tworząc zautomatyzowane przepływy pracy przy użyciu Rurociągi Amazon SageMaker do przygotowania danych i budowania, trenowania i pakowania modeli ML. Wdrażanie potoków odbywa się za pośrednictwem potoków CI/CD, podczas gdy kontrola wersji modeli odbywa się za pomocą Rejestr modeli Amazon SageMaker. Analitycy danych oceniają metryki wielu wersji modeli i żądają promocji najlepszego modelu do produkcji przez uruchomienie potoku CI/CD.
• Konto przedprodukcyjne – Przed promocją modelu do środowiska produkcyjnego model musi zostać przetestowany w celu zapewnienia odporności w środowisku symulacyjnym. Dlatego środowisko przedprodukcyjne jest symulatorem środowiska produkcyjnego, w którym punkty końcowe modelu SageMaker są wdrażane i testowane automatycznie. Metody testowe mogą obejmować test integracyjny, test warunków skrajnych lub testy specyficzne dla ML na wynikach wnioskowania. W tym przypadku środowisko produkcyjne nie jest punktem końcowym modelu SageMaker, ale urządzeniem brzegowym. Aby zasymulować urządzenie brzegowe w fazie przedprodukcyjnej, możliwe są dwa podejścia: użyj an Elastyczna chmura obliczeniowa Amazon (Amazon EC2) o tej samej charakterystyce sprzętowej lub użyj laboratorium testowego składającego się z rzeczywistych urządzeń. Dzięki tej infrastrukturze potok CI/CD wdraża model w odpowiednim symulatorze i automatycznie przeprowadza wiele testów. Po pomyślnym przeprowadzeniu testów potok CI/CD wymaga ręcznego zatwierdzenia (na przykład od interesariusza IoT w celu promowania modelu do produkcji).
• Rachunek produkcji – W przypadku hostowania modelu w chmurze AWS, potok CI/CD wdraża punkt końcowy modelu SageMaker na koncie produkcyjnym. W tym przypadku środowisko produkcyjne składa się z wielu flot urządzeń brzegowych. Dlatego też potok CI/CD wykorzystuje Edge Manager do wdrażania modeli do odpowiedniej floty urządzeń.
• Urządzenia brzegowe – Zdalne urządzenia brzegowe to urządzenia sprzętowe, które mogą uruchamiać modele ML za pomocą Edge Managera. Umożliwia aplikacji na tych urządzeniach zarządzanie modelami, wnioskowanie o modelach i bezpieczne przechwytywanie danych do Usługa Amazon Simple Storage (Amazonka S3).

Projekty SageMaker pomagają zautomatyzować proces udostępniania zasobów na każdym z tych kont. Nie zagłębiamy się w tę funkcję, ale aby dowiedzieć się więcej o tym, jak zbudować szablon projektu SageMaker, który wdraża modele ML na kontach, sprawdź Wdrożenie modelu dla wielu kont za pomocą Amazon SageMaker Pipelines.

Konto przedprodukcyjne: Cyfrowy bliźniak

Po procesie uczenia wynikowy model musi zostać oceniony. Na koncie przedprodukcyjnym masz symulowane urządzenie Edge. Reprezentuje cyfrowy bliźniak urządzenia brzegowego, na którym w produkcji pracuje model ML. To środowisko ma dwojaki cel: przeprowadzanie klasycznych testów (takich jak test jednostkowy, integracyjny i dymny) oraz bycie placem zabaw dla zespołu programistów. To urządzenie jest symulowane przy użyciu instancji EC2, w której zostały wdrożone wszystkie komponenty potrzebne do zarządzania modelem ML.

Zaangażowane usługi są następujące:

• Rdzeń IoT AWS - Używamy Rdzeń IoT AWS tworzyć obiekty AWS IoT, tworzyć flotę urządzeń, rejestrować flotę urządzeń, aby mogła wchodzić w interakcje z chmurą, tworzyć certyfikaty X.509 do uwierzytelniania urządzeń brzegowych w AWS IoT Core, kojarzyć alias ról z AWS IoT Core, który został wygenerowany podczas flota utworzyła, uzyskaj punkt końcowy specyficzny dla konta AWS dla dostawcy poświadczeń, uzyskaj oficjalny plik Amazon Root CA i prześlij plik Amazon CA do Amazon S3.
• Amazon Sagemaker Neo – Strzelec Neo automatycznie optymalizuje modele uczenia maszynowego, aby wnioskowanie przebiegało szybciej bez utraty dokładności. Obsługuje model uczenia maszynowego już zbudowany z DarkNet, Keras, MXNet, PyTorch, TensorFlow, TensorFlow-Lite, ONNX lub XGBoost i przeszkolony w Amazon SageMaker lub gdziekolwiek indziej. Następnie wybierasz docelową platformę sprzętową, którą może być instancja hostująca SageMaker lub urządzenie brzegowe oparte na procesorach Ambarella, Apple, ARM, Intel, MediaTek, Nvidia, NXP, Qualcomm, RockChip, Texas Instruments lub Xilinx.
• Menedżer krawędzi – Używamy Edge Managera do rejestracji i zarządzania urządzeniem brzegowym we flotach Sagemaker. Floty to zbiory logicznie pogrupowanych urządzeń, których można używać do zbierania i analizowania danych. Poza tym Edge Manager pakuje zoptymalizowany model i tworzy komponent AWS IoT Greengrass V2, który można bezpośrednio wdrożyć. Możesz użyć Edge Managera do obsługi modeli ML we flocie inteligentnych kamer, inteligentnych głośników, robotach i innych flotach urządzeń SageMaker.
• AWS IoT Greengrass V2 - Zielona trawa AWS IoT umożliwia wdrażanie komponentów do symulowanych urządzeń za pomocą instancji EC2. Korzystając z agenta AWS IoT Greengrass V2 w instancjach EC2, możemy uprościć dostęp, zarządzanie i wdrażanie agenta i modelu Edge Managera na urządzeniach. Bez AWS IoT Greengrass V2 konfigurowanie urządzeń i flot do korzystania z Edge Managera wymaga ręcznego skopiowania agenta z zasobnika wersji S3. Dzięki integracji AWS IoT Greengrass V2 i Edge Manager możliwe jest korzystanie z komponentów AWS IoT Greengrass V2. Komponenty to gotowe moduły oprogramowania, które mogą łączyć urządzenia brzegowe z usługami AWS lub usługami innych firm za pośrednictwem AWS IoT Greengrass.
• Agent Edge Manager – Agent Edge Manager jest wdrażany za pośrednictwem AWS IoT Greengrass V2 w instancji EC2. Agent może ładować wiele modeli jednocześnie i wyciągać wnioski z załadowanych modeli na urządzeniach brzegowych. Liczba modeli, które agent może załadować, zależy od dostępnej pamięci na urządzeniu.
• Amazon S3 – Używamy wiadra S3 do przechowywania wnioskowania przechwyconych danych z agenta Edge Managera.

Konto przedprodukcyjne możemy zdefiniować jako cyfrowego bliźniaka do testowania modeli ML przed przeniesieniem ich na urządzenia z rzeczywistymi krawędziami. Daje to następujące korzyści:

• Zwinność i elastyczność – Analitycy danych i inżynierowie ML muszą szybko sprawdzić, czy model ML i powiązane skrypty (skrypty przetwarzania wstępnego i wnioskowania) będą działać na urządzeniu. Jednak działy IoT i data science w dużych przedsiębiorstwach mogą być różnymi podmiotami. Poprzez identyczną replikację stosu technologicznego w chmurze, naukowcy zajmujący się danymi i inżynierowie ML mogą iterować i konsolidować artefakty przed wdrożeniem.
• Przyspieszona ocena ryzyka i czas produkcji – Wdrożenie na urządzeniu brzegowym to ostatni etap procesu. Po sprawdzeniu poprawności wszystkiego w odizolowanym i samowystarczalnym środowisku upewnij się, że jest ono zgodne ze specyfikacjami wymaganymi przez urządzenie brzegowe pod względem jakości, wydajności i integracji. Pomaga to uniknąć dalszego zaangażowania innych osób z działu IoT w celu naprawy i iteracji wersji artefaktów.
• Lepsza współpraca zespołowa oraz lepsza jakość i wydajność – Zespół programistów może natychmiast ocenić wpływ modelu ML, analizując metryki sprzętu brzegowego i mierząc poziom interakcji z narzędziami innych firm (np. szybkość I/O). Następnie zespół IoT jest odpowiedzialny tylko za wdrożenie w środowisku produkcyjnym i może mieć pewność, że artefakty są dokładne dla środowiska produkcyjnego.
• Zintegrowany plac zabaw do testowania – Biorąc pod uwagę cel modeli ML, środowisko przedprodukcyjne w tradycyjnym przepływie pracy powinno być reprezentowane przez urządzenie brzegowe poza środowiskiem chmury. To wprowadza kolejny poziom złożoności. Integracje są potrzebne do zbierania metryk i informacji zwrotnych. Zamiast tego, dzięki wykorzystaniu symulowanego środowiska cyfrowego bliźniaka, interakcje są zredukowane, a czas wprowadzenia na rynek skraca się.

Konto produkcyjne i środowisko brzegowe

Po zakończeniu testów i osiągnięciu stabilności artefaktów możesz przejść do wdrożenia produkcyjnego za pośrednictwem potoków. Wdrażanie artefaktu odbywa się programowo po zatwierdzeniu artefaktu przez operatora. Dostęp do Konsola zarządzania AWS jest przyznawany operatorom w trybie tylko do odczytu, aby móc monitorować metadane związane z flotami, a tym samym mieć wgląd w wersję wdrożonego modelu ML i inne metryki związane z cyklem życia.

Floty urządzeń Edge należą do konta produkcyjnego AWS. To konto ma określone konfiguracje zabezpieczeń i sieci, aby umożliwić komunikację między chmurą a urządzeniami brzegowymi. Główne usługi AWS wdrożone na koncie produkcyjnym to Edge Manager, który odpowiada za zarządzanie wszystkimi flotami urządzeń, zbieranie danych i obsługę modeli ML oraz AWS IoT Core, który zarządza obiektami IoT, certyfikatami, aliasami ról i punktami końcowymi.

Jednocześnie musimy skonfigurować urządzenie brzegowe z usługami i komponentami do zarządzania modelami ML. Główne elementy to:

• AWS IoT Greengrass V2
• Agent Edge Managera
• Certyfikaty AWS IoT
• Application.py, który jest odpowiedzialny za orkiestrację procesu wnioskowania (pobieranie informacji ze źródła danych krawędzi i wykonywanie wnioskowania przy użyciu agenta Edge Manager i załadowanego modelu ML)
• Połączenie z Amazon S3 lub kontem Data Lake w celu przechowywania wnioskowanych danych

Zautomatyzowany potok ML

Teraz, gdy wiesz więcej o organizacji i składnikach architektury referencyjnej, możemy zagłębić się w potok ML, którego używamy do kompilowania, trenowania i oceny modelu ML na koncie deweloperskim.

Potok (zbudowany przy użyciu Modele budowy rurociągów Amazon SageMaker) to seria połączonych ze sobą kroków zdefiniowanych przez definicję potoku JSON. Ta definicja potoku koduje potok przy użyciu ukierunkowanego wykresu acyklicznego (DAG). Ten DAG zawiera informacje o wymaganiach i relacjach między każdym krokiem potoku. Struktura DAG potoku jest określana przez zależności danych między krokami. Te zależności danych są tworzone, gdy właściwości danych wyjściowych kroku są przekazywane jako dane wejściowe do innego kroku.

Aby umożliwić zespołom zajmującym się analizą danych łatwe zautomatyzowanie tworzenia nowych wersji modeli ML, ważne jest wprowadzenie etapów walidacji i zautomatyzowanych danych do ciągłego zasilania i ulepszania modeli ML, a także strategii monitorowania modeli umożliwiających wyzwalanie potoku. Poniższy diagram przedstawia przykładowy potok.

Aby umożliwić automatyzację i funkcje MLOps, ważne jest tworzenie modułowych komponentów do tworzenia artefaktów kodu wielokrotnego użytku, które można udostępniać w różnych krokach i przypadkach użycia ML. Umożliwia to szybkie przeniesienie wdrożenia z fazy eksperymentalnej do fazy produkcyjnej poprzez automatyzację przejścia.

Kroki definiowania potoku ML w celu włączenia ciągłego uczenia i wersjonowania modeli ML są następujące:

• Przetwarzanie wstępne – Proces czyszczenia danych, inżynierii funkcji i tworzenia zestawu danych do uczenia algorytmu ML
• Trening – Proces uczenia opracowanego algorytmu ML do generowania nowej wersji artefaktu modelu ML
• Ocena – Proces ewaluacji wygenerowanego modelu ML, w celu wyodrębnienia kluczowych metryk związanych z zachowaniem modelu na nowych danych nie widzianych podczas fazy uczenia
• Rejestracja – Proces wersjonowania nowego wytrenowanego artefaktu modelu ML poprzez połączenie metryk wyodrębnionych z wygenerowanym artefaktem

Poniżej możesz zobaczyć więcej szczegółów na temat budowania potoku SageMaker notatnik.

Wyzwalaj potoki CI/CD za pomocą EventBridge

Po zakończeniu budowania modelu możesz rozpocząć proces wdrażania. Ostatni krok potoku SageMaker zdefiniowany w poprzedniej sekcji rejestruje nową wersję modelu w określonej grupie rejestru modeli SageMaker. Wdrażanie nowej wersji modelu ML jest zarządzane przy użyciu stanu rejestru modelu. Ręcznie zatwierdzając lub odrzucając wersję modelu ML, ten krok wywołuje zdarzenie przechwycone przez EventBridge. To zdarzenie może następnie uruchomić nowy potok (tym razem CI/CD) w celu utworzenia nowej wersji składnika AWS IoT Greengrass, który zostanie następnie wdrożony na kontach przedprodukcyjnych i produkcyjnych. Poniższy zrzut ekranu przedstawia naszą zdefiniowaną regułę EventBridge.

Ta reguła monitoruje grupę pakietów modeli SageMaker, wyszukując aktualizacje pakietów modeli w statusie Approved or Rejected.

Reguła EventBridge jest następnie konfigurowana do kierowania CodePipeline, co uruchamia przepływ pracy tworzenia nowego komponentu AWS IoT Greengrass za pomocą Amazon Sage Maker Neo i Edge Manager.

Zoptymalizuj modele ML dla docelowej architektury

Neo umożliwia optymalizację modeli ML pod kątem wnioskowania na urządzeniach brzegowych (oraz w chmurze). Automatycznie optymalizuje modele ML pod kątem lepszej wydajności w oparciu o architekturę docelową i oddziela model od oryginalnej platformy, umożliwiając uruchamianie go w lekkim środowisku uruchomieniowym.

Zapoznaj się z następującymi informacjami notatnik na przykład, jak skompilować model PyTorch Resnet18 za pomocą Neo.

Zbuduj pakiet wdrożeniowy, dołączając komponent AWS IoT Greengrass

Edge Manager umożliwia zarządzanie, zabezpieczanie, wdrażanie i monitorowanie modeli we flocie urządzeń brzegowych. W następującym notatnik, możesz zobaczyć więcej szczegółów na temat tworzenia minimalistycznej floty urządzeń brzegowych i przeprowadzić kilka eksperymentów z tą funkcją.

Po skonfigurowaniu floty i skompilowaniu modelu należy uruchomić zadanie pakowania Edge Manager, które przygotuje model do wdrożenia we flocie. Zadanie pakowania można rozpocząć za pomocą zestawu Boto3 SDK. Dla naszych parametrów używamy zoptymalizowanego modelu i metadanych modelu. Dodając następujące parametry do OutputConfig, zadanie przygotowuje również komponent AWS IoT Greengrass V2 z modelem:

• PresetDeploymentType
• PresetDeploymentConfig

Zobacz następujący kod:

import boto3
import time

SageMaker_client = boto3.client('SageMaker')

SageMaker_client.create_edge_packaging_job(
    EdgePackagingJobName="mlops-edge-packaging-{}".format(int(time.time()*1000)),
    CompilationJobName=compilation_job_name,
    ModelName="PytorchMLOpsEdgeModel",
    ModelVersion="1.0.0",
    RoleArn=role,
    OutputConfig={
        'S3OutputLocation': 's3://{}/model/'.format(bucket_name),
        "PresetDeploymentType": "GreengrassV2Component",
        "PresetDeploymentConfig": json.dumps(
            {"ComponentName": component_name, "ComponentVersion": component_version}
        ),
    }
)

Wdrażaj modele ML na urządzeniach brzegowych na dużą skalę

Teraz nadszedł czas na wdrożenie modelu we flocie urządzeń brzegowych. Po pierwsze, musimy upewnić się, że posiadamy niezbędne AWS Zarządzanie tożsamością i dostępem (JESTEM) uprawnienia udostępniać nasze urządzenia IoT i wdrażać na nich komponenty. Aby rozpocząć wdrażanie urządzeń do naszej platformy IoT, potrzebujemy dwóch podstawowych elementów:

• Polityka uprawnień – Ta zasada umożliwia automatyczne udostępnianie takich urządzeń, przypisanych do użytkownika lub roli wykonującej udostępnianie. Powinien mieć uprawnienia do zapisu IoT do tworzenia rzeczy i grupy IoT, a także do dołączania niezbędnych polityk do urządzenia. Aby uzyskać więcej informacji, zobacz Minimalna polityka uprawnień dla instalatora do udostępniania zasobów.
• Rola IAM – ta rola jest przypisana do rzeczy i grup IoT, które tworzymy. Możesz utworzyć tę rolę w czasie aprowizacji z podstawowymi uprawnieniami, ale będzie brakować funkcji, takich jak dostęp do Amazon S3 lub Usługa zarządzania kluczami AWS (AWS KMS), które mogą być potrzebne później. Możesz utworzyć tę rolę wcześniej i użyć jej ponownie, gdy udostępnimy urządzenie. Aby uzyskać więcej informacji, zobacz Autoryzuj podstawowe urządzenia do interakcji z AWS.

Instalacja i udostępnianie AWS IoT Greengrass

Po ustaleniu zasad i roli uprawnień jesteśmy gotowi do zainstaluj oprogramowanie AWS IoT Greengrass Core z automatycznym przydzielaniem zasobów. Chociaż możliwe jest udostępnienie zasobów IoT po wykonaniu czynności ręcznych, istnieje wygodna procedura automatycznego udostępniania tych zasobów podczas instalacji jądra AWS IoT Greengrass v2. Jest to preferowana opcja szybkiego wprowadzania nowych urządzeń do platformy. Oprócz default-jdk, wymagane jest zainstalowanie innych pakietów, takich jak curl, unzip, python3.

Kiedy udostępniamy nasze urządzenie, nazwa rzeczy IoT musi być dokładnie taka sama, jak urządzenie brzegowe zdefiniowane w Edge Manager, w przeciwnym razie dane nie zostaną przechwycone do docelowego zasobnika S3.

Instalator może utworzyć rolę i alias AWS IoT Greengrass podczas instalacji, jeśli nie istnieją. Zostaną one jednak utworzone z minimalnymi uprawnieniami i będą wymagały ręcznego dodania większej liczby zasad w celu interakcji z innymi usługami, takimi jak Amazon S3. Zalecamy wcześniejsze utworzenie tych zasobów uprawnień, jak pokazano wcześniej, a następnie ponowne ich wykorzystanie podczas wprowadzania nowych urządzeń na konto.

Opakowanie komponentów modelu i wnioskowania

Po opracowaniu naszego kodu możemy wdrożyć zarówno kod (w celu wnioskowania), jak i nasze modele ML jako komponenty na naszych urządzeniach.

Po przeszkoleniu modelu ML w programie SageMaker można zoptymalizować model za pomocą Neo, korzystając z zadania kompilacji Sagemaker. Powstałe artefakty skompilowanego modelu można następnie spakować do komponentu GreenGrass V2 za pomocą programu do pakowania Edge Manager. Następnie można go zarejestrować jako niestandardowy komponent w Moje komponenty sekcji na konsoli AWS IoT Greengrass. Ten składnik zawiera już niezbędne polecenia cyklu życia, aby pobrać i zdekompresować artefakt modelu w naszym urządzeniu, aby kod wnioskowania mógł go załadować, aby wysłać przechwycone przez niego obrazy.

Jeśli chodzi o kod wnioskowania, musimy utworzyć komponent za pomocą konsoli lub Interfejs wiersza poleceń AWS (AWS CLI). Najpierw pakujemy nasz kod źródłowy i niezbędne zależności do Amazon S3. Po przesłaniu kodu możemy stworzyć nasz komponent za pomocą przepisu w .yaml lub JSON, jak w poniższym przykładzie:

---
RecipeFormatVersion: 2020-01-25
ComponentName: dummymodel.inference
ComponentVersion: 0.0.1
ComponentDescription: Deploys inference code to a client
ComponentPublisher: Amazon Web Services, Inc.
ComponentDependencies:
  aws.GreenGrass.TokenExchangeService:
    VersionRequirement: '>=0.0.0'
    DependencyType: HARD
  dummymodel:
    VersionRequirement: '>=0.0.0'
    DependencyType: HARD
Manifests:
  - Platform:
      os: linux
      architecture: "*"
    Lifecycle:
      install: |-
        apt-get install python3-pip
        pip3 install numpy
        pip3 install sysv_ipc
        pip3 install boto3
        pip3 install grpcio-tools
        pip3 install grpcio
        pip3 install protobuf
        pip3 install SageMaker
        tar xf {artifacts:path}/sourcedir.tar.gz
      run:
        script: |-
          sleep 5 && sudo python3 {work:path}/inference.py 
    Artifacts:
      - URI: s3://BUCKET-NAME/path/to/inference/sourcedir.tar.gz
        Permission:
          Execute: OWNER

Ten przykładowy przepis pokazuje nazwę i opis naszego komponentu, a także niezbędne wymagania wstępne przed wykonaniem polecenia skryptu. Przepis rozpakowuje artefakt w środowisku folderu roboczego na urządzeniu i używamy tej ścieżki do uruchomienia naszego kodu wnioskowania. Polecenie AWS CLI do utworzenia takiej receptury to:

aws greengrassv2 create-component-version --region $REGION 
                                          --inline-recipe fileb://path/to/recipe.yaml

Możesz teraz zobaczyć ten komponent utworzony na konsoli AWS IoT Greengrass.

Uważaj na fakt, że wersja komponentu ma znaczenie i musi być określona w pliku receptury. Powtórzenie tego samego numeru wersji zwróci błąd.

Po skonfigurowaniu naszego modelu i kodu wnioskowania jako składników jesteśmy gotowi do ich wdrożenia.

Wdróż aplikację i model za pomocą AWS IoT Greengrass

W poprzednich sekcjach dowiedziałeś się, jak spakować kod wnioskowania i modele ML. Teraz możemy utworzyć wdrożenie z wieloma komponentami, które zawierają zarówno komponenty, jak i konfiguracje potrzebne do współdziałania naszego kodu wnioskowania z modelem na urządzeniu brzegowym.

Agent Edge Manager to komponent, który należy zainstalować na każdym urządzeniu brzegowym, aby umożliwić korzystanie ze wszystkich funkcji Edge Managera. W konsoli SageMaker mamy zdefiniowaną flotę urządzeń, która ma skojarzony zasobnik S3. Wszystkie urządzenia brzegowe powiązane z flotą będą przechwytywać i raportować swoje dane do tej ścieżki S3. Agenta można wdrożyć jako komponent w AWS IoT Greengrass v2, co ułatwia instalację i konfigurację niż w przypadku wdrożenia agenta w trybie autonomicznym. Wdrażając agenta jako komponent, musimy określić jego parametry konfiguracyjne, a mianowicie flotę urządzeń i ścieżkę S3.

Tworzymy konfigurację wdrożenia z niestandardowymi komponentami dla właśnie utworzonego modelu i kodu. Ta konfiguracja jest zdefiniowana w pliku JSON, który zawiera nazwę i miejsce docelowe wdrożenia, a także składniki we wdrożeniu. Możemy dodawać i aktualizować parametry konfiguracyjne każdego komponentu, np. w agencie Edge Manager, gdzie określamy nazwę floty i łyżkę.

{
    "targetArn": "targetArn",
    "deploymentName": "dummy-deployment",
    "components": {
        "aws.GreenGrass.Nucleus": {
            "version": "2.5.3",
        },
        "aws.GreenGrass.Cli": {
            "version": "2.5.3"
        },
        "aws.GreenGrass.SageMakerEdgeManager": {
            "version": 1.1.0,
            "configurationUpdate": {
                "merge": {
                "DeviceFleetName": "FLEET-NAME",
                "BucketName": "BUCKET-NAME-URI"
                }
            }
        },
        "dummymodel.inference": {
            "version": "0.0.1"
        },
        "dummymodel": {
            "version": "0.0.1"
        }
    }
}

Warto zauważyć, że dodaliśmy nie tylko model, komponenty wnioskowania i agenta, ale także AWS IoT Greengrass CLI i jądro jako komponenty. Ten pierwszy może pomóc w debugowaniu niektórych wdrożeń lokalnie na urządzeniu. Ten ostatni jest dodawany do wdrożenia, aby w razie potrzeby skonfigurować niezbędny dostęp do sieci z samego urządzenia (na przykład ustawienia proxy), a także w przypadku, gdy chcesz przeprowadzić aktualizację OTA jądra AWS IoT Greengrass v2. Jądro nie jest wdrażane, ponieważ jest zainstalowane w urządzeniu i zostanie zastosowana tylko aktualizacja konfiguracji (chyba że aktualizacja jest na miejscu). Aby wdrożyć, wystarczy uruchomić następującą komendę na poprzedniej konfiguracji. Pamiętaj, aby skonfigurować docelową ARN, do której zostanie zastosowane wdrożenie (rzecz IoT lub grupa IoT). Możemy również wdrożyć te komponenty z konsoli.

aws greengrassv2 create-deployment --region $REGION 
                                   --cli-input-json file://path/to/deployment.json

Monitoruj i zarządzaj modelami ML wdrożonymi na urządzeniach brzegowych

Teraz, gdy Twoja aplikacja działa na urządzeniach brzegowych, nadszedł czas, aby zrozumieć, jak monitorować flotę, aby poprawić zarządzanie, konserwację i widoczność. W konsoli SageMaker wybierz Menedżer krawędzi w okienku nawigacji, a następnie wybierz Floty urządzeń brzegowych. Stąd wybierz swoją flotę.

Na stronie szczegółów floty możesz zobaczyć niektóre metadane modeli działających na każdym urządzeniu Twojej floty. Raport flotowy generowany jest co 24 godziny.

Dane przechwycone przez każde urządzenie za pośrednictwem Edge Agenta są wysyłane do zasobnika S3 w formacie json lines (JSONL). Proces wysyłania przechwyconych danych jest zarządzany z punktu widzenia aplikacji. W związku z tym możesz swobodnie decydować, czy chcesz wysyłać te dane, jak i jak często.

Możesz używać tych danych do wielu celów, takich jak monitorowanie dryfu danych i jakości modelu, budowanie nowego zestawu danych, wzbogacanie jeziora danych i nie tylko. Prostym przykładem wykorzystania tych danych jest zidentyfikowanie pewnych odchyleń danych w sposobie interakcji użytkowników z aplikacją i konieczności wytrenowania nowego modelu. Następnie tworzysz nowy zestaw danych z przechwyconymi danymi i kopiujesz go z powrotem na konto deweloperskie. Może to automatycznie rozpocząć nowe uruchomienie Twojego środowiska, które zbuduje nowy model i ponownie wdroży go w całej flocie, aby utrzymać wydajność wdrożonego rozwiązania.

Wnioski

W tym poście dowiedziałeś się, jak zbudować kompletne rozwiązanie, które łączy MLOps i ML@Edge przy użyciu usług AWS. Zbudowanie takiego rozwiązania nie jest trywialne, ale mamy nadzieję, że architektura referencyjna przedstawiona w tym poście może zainspirować i pomóc w zbudowaniu solidnej architektury dla własnych wyzwań biznesowych. Możesz także użyć tylko części lub modułów tej architektury, które integrują się z istniejącym środowiskiem MLOps. Prototypując jeden pojedynczy moduł na raz i korzystając z odpowiednich usług AWS, aby sprostać każdemu elementowi tego wyzwania, możesz dowiedzieć się, jak zbudować solidne środowisko MLOps, a także jeszcze bardziej uprościć ostateczną architekturę.

W następnym kroku zachęcamy do wypróbowania Sagemaker Edge Manager do zarządzania cyklem życia ML w Edge. Aby uzyskać więcej informacji na temat działania Menedżera Edge, zobacz Wdrażaj modele na urządzeniach brzegowych dzięki SageMaker Edge Manager .

O autorach

Bruno Piston jest specjalistą ds. rozwiązań AI/ML dla AWS z siedzibą w Mediolanie. Współpracuje z klientami dowolnej wielkości, pomagając im dogłębnie zrozumieć ich potrzeby techniczne i zaprojektować rozwiązania AI i uczenia maszynowego, które najlepiej wykorzystują AWS Cloud i stos Amazon Machine Learning. Jego specjalizacja to kompleksowe uczenie maszynowe, industrializacja uczenia maszynowego i MLOps. Lubi spędzać czas z przyjaciółmi i odkrywać nowe miejsca, a także podróżować do nowych miejsc.

Matteo Calabrese jest architektem AI/ML Customer Delivery w zespole AWS Professional Services. Współpracuje z dużymi przedsiębiorstwami z regionu EMEA przy projektach AI/ML, pomagając im w proponowaniu, projektowaniu, dostarczaniu, skalowaniu i optymalizacji obciążeń produkcyjnych ML. Jego główne kompetencje to ML Operation (MLOps) i Machine Learning w Edge. Jego celem jest skrócenie ich czasu na docenienie i przyspieszenie wyników biznesowych poprzez dostarczanie najlepszych praktyk AWS. W wolnym czasie lubi wędrówki i podróże.

Raúl Díaz García jest Sr Data Scientist w zespole AWS Professional Services. Współpracuje z dużymi klientami korporacyjnymi w regionie EMEA, gdzie pomaga im we wdrażaniu rozwiązań związanych z widzeniem komputerowym i uczeniem maszynowym w przestrzeni IoT.

Sokratis Kartakis jest starszym specjalistą ds. rozwiązań w zakresie uczenia maszynowego w Amazon Web Services. Sokratis koncentruje się na umożliwieniu klientom korporacyjnym uprzemysłowienia ich rozwiązań Machine Learning (ML) poprzez wykorzystanie usług AWS i kształtowanie ich modelu operacyjnego, tj. podstawy MLOps i mapy drogowej transformacji z wykorzystaniem najlepszych praktyk programistycznych. Spędził ponad 15 lat na wymyślaniu, projektowaniu, prowadzeniu i wdrażaniu innowacyjnych, kompleksowych rozwiązań ML na poziomie produkcyjnym i Internetu rzeczy (IoT) w dziedzinach energetyki, handlu detalicznego, zdrowia, finansów/bankowości, sportów motorowych itp. Sokratis lubi spędzać wolny czas z rodziną i przyjaciółmi lub jeździć na motocyklach.

Samira Araújo jest architektem rozwiązań AI / ML w AWS. Pomaga klientom w tworzeniu rozwiązań AI / ML, które rozwiązują ich problemy biznesowe za pomocą AWS. Pracował nad kilkoma projektami AI / ML związanymi z wizją komputerową, przetwarzaniem języka naturalnego, prognozowaniem, ML na krawędzi i nie tylko. W wolnym czasie lubi bawić się projektami sprzętowymi i automatyki, a szczególnie interesuje go robotyka.