W jaki sposób firma Yara wykorzystuje funkcje MLOps usługi Amazon SageMaker do skalowania optymalizacji zużycia energii w swoich zakładach produkcji amoniaku

Yara jest wiodącą na świecie firmą zajmującą się odżywianiem upraw oraz dostawcą rozwiązań środowiskowych i rolniczych. Ambicja firmy Yara koncentruje się na rozwijaniu przyszłości żywności przyjaznej dla środowiska, która tworzy wartość dla klientów, akcjonariuszy i ogółu społeczeństwa oraz zapewnia bardziej zrównoważony łańcuch wartości żywności. Wspierając naszą wizję świata bez głodu i szanowanej planety, Yara realizuje strategię zrównoważonego wzrostu wartości, promując przyjazne dla klimatu odżywianie upraw i bezemisyjne rozwiązania energetyczne. Yara jest także największym na świecie producentem amoniaku, azotanów i azotanów NPK nawozy. Segment produkcyjny jest zatem integralną częścią składową realizacji ich misji — z jasno określoną ambicją, aby stać się światowym liderem pod względem wskaźników, takich jak bezpieczeństwo, ślad środowiskowy, jakość i koszty produkcji. Długoterminowym celem firmy Yara jest „Zakład Przyszłości” charakteryzujący się zerową emisją i niskimi kosztami.

Opierając się na odchudzonej transformacji, Yara koncentruje się na rozwiązaniach cyfrowych, aby pomóc im osiągnąć ich ambicje. Aby przewodzić tym wysiłkom, Yara utworzyła globalną jednostkę o nazwie Digital Production. Sukces Cyfrowej Produkcji i jej rozwiązań jest kluczowym priorytetem dla Yara, a Yara znacznie zwiększyła swoje wysiłki w tej dziedzinie. Kluczowym obszarem zainteresowania jest wykorzystanie ogromnej ilości danych generowanych w ramach ich operacji. Dlatego Yara buduje produkty oparte na danych, które pomagają im optymalizować produkcję, podnosić jakość produktów, zwiększać niezawodność zakładów produkcyjnych, zmniejszać emisje, zwiększać bezpieczeństwo i produktywność pracowników, automatyzować ręczne procesy i nie tylko.

Energia jest głównym składnikiem kosztów dla wielu zakładów produkcyjnych; w związku z tym efektywność energetyczna ma istotny wpływ na rentowność. Jednak często brakuje solidnych odniesień do tego, jak wygląda dobra wydajność i jak się tam dostać. Krzywa obciążenia energetycznego (ELC) firmy Yara to rozwiązanie wykorzystujące najlepsze historyczne wyniki w zakresie zużycia energii w porównaniu z obecnymi wynikami. Jeśli bieżące zużycie zbytnio odbiega od historycznego rekordu, narzędzie daje operatorom zalecenia, aby sterować zużyciem energii.

Aby wdrożyć ELC w zakładach produkcyjnych i skalować go do wielu lokalizacji na całym świecie, firma Yara musiała zbudować platformę MLOps. Dzięki temu firma Yara będzie szkolić, wdrażać i utrzymywać modele w sposób niezawodny i wydajny. Ponadto, aby skalować to do wielu lokalizacji, firma Yara musiała zautomatyzować procesy wdrażania i konserwacji. W tym poście omawiamy, jak Yara używa Amazon Sage Maker funkcje, w tym rejestr modeli, Monitor modelu Amazon SageMaker, Rurociągi Amazon SageMaker usprawnić cykl życia uczenia maszynowego (ML) poprzez automatyzację i standaryzację praktyk MLOps. Zapewniamy przegląd konfiguracji, prezentując proces budowania, szkolenia, wdrażania i monitorowania modeli ML dla zakładów na całym świecie.

Przegląd rozwiązania

ELC wykorzystuje dane z czujników Internetu rzeczy (IoT) z zakładu. Czujniki te mierzą takie wskaźniki, jak przepustowość produkcji, warunki otoczenia, stan surowców itp. Dane te są wykorzystywane do trenowania modelu przewidywania zużycia energii, który jest następnie wykorzystywany do generowania prognoz godzinowych. Operatorzy instalacji monitorują rzeczywiste zużycie energii i porównują je z optymalnym zużyciem przewidywanym przez ELC. Jeśli bieżące zużycie energii zbytnio odbiega od optymalnego punktu, ELC zapewnia działanie w celu dostosowania wewnętrznych zmiennych procesowych w celu optymalizacji efektywności energetycznej w oparciu o modele analityczne.

ELC jest hostowane w chmurze. Aby przesyłać strumieniowo dane z czujników z zakładu w czasie rzeczywistym, Yara używa Zielona trawa AWS IoT bezpiecznie komunikować się z Rdzeń IoT AWS i eksportuj dane IoT do chmury AWS. AWS IoT SiteWise to zarządzana usługa, która może gromadzić, organizować, wyszukiwać i wykorzystywać dane sprzętu z urządzeń przemysłowych na dużą skalę. Firma Yara zbudowała interfejsy API przy użyciu Brama Amazon API aby udostępnić dane czujnika aplikacjom, takim jak ELC.

Backend aplikacji ELC jest wdrażany za pośrednictwem Amazon ECS i zasila pulpity nawigacyjne ELC na froncie, z których korzystają operatorzy zakładów. Aplikacja ELC jest odpowiedzialna za dostarczanie godzinowych predykcyjnych wskaźników zużycia energii operatorom instalacji. Każda instalacja jest wyposażona we własny model, ponieważ różnią się charakterystyką zużycia energii. Ponadto zakłady są grupowane w różne regiony AWS w zależności od ich lokalizacji.

Poniższy diagram ilustruje tę architekturę.

Do budowania ELC i skalowania do wielu zakładów potrzebowaliśmy rozwiązania MLOps, które obsługuje następujące elementy:

• Skalowalność – Może skalować się w odpowiedzi na wolumeny danych. Niektóre rośliny wytwarzają więcej danych niż inne; każda fabryka może wyprodukować kilka gigabajtów danych dziennie.
• Rozszerzalność – Można go wdrażać w nowych regionach i na nowych kontach.
• Powtarzalność – Ma wspólne szablony, których możemy użyć do wdrożenia nowego zakładu.
• Elastyczność – Może zmienić konfigurację wdrożenia w zależności od potrzeb każdego zakładu.
• Niezawodność i monitorowanie – Może przeprowadzać testy i mieć jasny wgląd w stan wszystkich aktywnych instalacji. W przypadku awarii może przywrócić poprzedni stabilny stan.
• Konserwacja – Rozwiązanie powinno charakteryzować się niskimi kosztami utrzymania. Tam, gdzie to możliwe, powinno korzystać z usług bezserwerowych, aby zmniejszyć obciążenie infrastruktury.

W przypadku ML Yara zdecydowała się użyć SageMaker. SageMaker to w pełni zarządzana usługa, która obejmuje cały przepływ pracy ML. Następujące funkcje były krytyczne przy wyborze SageMaker:

• Kontenery ramowe SageMaker – Yara wyszkoliła modele predykcyjne ELC w TensorFlow, a dzięki kontenerom ramowym SageMaker Yara była w stanie podnosić i przenosić te modele przy minimalnych zmianach kodu w SageMaker.
• Rurociągi SageMaker – SageMaker Pipelines oferuje interfejs Python dla analityków danych do pisania potoków ML. Duża część kodu ELC składa się z potoku uczącego i wnioskowania, które są zdefiniowane w Pythonie.
• Rejestr modeli SageMaker – Rejestr modeli SageMaker umożliwia katalogowanie i kontrolę wersji modeli. Ponadto ułatwia zarządzanie metadanymi modelu, takimi jak metryki szkoleniowe.
• Monitor modelu SageMaker – Firma Yara chciała monitorować jakość i dystrybucję przychodzących danych oraz wydajność modelu ELC. Interfejsy API SageMaker Model Monitor oferują monitorowanie jakości danych i modeli.

Aby zarządzać ciągłą integracją i ciągłym dostarczaniem (CI/CD) dla potoków ML, Yara używa Ramy wdrażania Amazon (ADF). ADF to platforma typu open source opracowana przez AWS do zarządzania i wdrażania zasobów na wielu kontach i regionach AWS w ramach organizacji AWS. ADF umożliwia stopniowe, równoległe, wielokontowe i międzyregionalne wdrażanie aplikacji lub zasobów za pośrednictwem struktury zdefiniowanej w Organizacje AWS, korzystając jednocześnie z usług takich jak AWS Code Pipeline, Tworzenie kodu AWS, Zatwierdzenie kodu AWS, Tworzenie chmury AWS w celu ułatwienia podnoszenia ciężarów i zarządzania w porównaniu z tradycyjną konfiguracją CI/CD.

Omówienie rozwiązania

Całe rozwiązanie dla platformy MLOps zostało zbudowane w ciągu dwóch miesięcy we współpracy z Usługi profesjonalne AWS. Zespół pracujący nad projektem składał się z analityków danych, inżynierów danych oraz specjalistów DevOps. Aby ułatwić szybszy rozwój w środowisku wielozespołowym, firma Yara zdecydowała się na użycie Zoo lądowania AWSne i Organizacje do centralnego tworzenia, zarządzania i zarządzania różnymi kontami AWS. Na przykład Yara ma centralne konto wdrażania i używa kont obciążenia do hostowania aplikacji biznesowych. ELC to przypadek użycia optymalizacji procesów i jest wdrażany w celu optymalizacji kont obciążeń. Zespół Yara Digital Production pracuje również nad przypadkami użycia ML w obszarach innych niż optymalizacja. Struktura MLOps obsługuje wdrażanie na dowolnych kontach obciążeń, o ile konta są tworzone za pośrednictwem organizacji.

Poniższy diagram ilustruje tę architekturę.

Korzystanie z centralnego konta wdrażania ułatwia zarządzanie typowymi artefaktami i potokami CI/CD. Pod względem zarządzania dostępem i bezpieczeństwem tych wspólnych artefaktów jest to prostsza konstrukcja, ponieważ granice uprawnień i klucze szyfrowania są zarządzane centralnie w jednym miejscu. W poniższych sekcjach przeprowadzimy Cię przez kroki wymagane do wdrożenia nowego przypadku użycia do platformy MLOps firmy Yara.

Jeśli chodzi o strategię konta, Yara ma konfigurację piaskownicy, DEV, TEST i PROD. Konto piaskownicy służy do eksperymentowania i wypróbowywania nowych pomysłów. Konto DEV jest punktem początkowym potoków CI/CD i tutaj zaczyna się cały rozwój. Konto wdrożenia zawiera definicję potoku CI/CD i może być wdrażane na kontach DEV, TEST i PROD. Ta konfiguracja konta jest przedstawiona na poniższym rysunku.

Wprowadzenie nowego przypadku użycia

W tym poście zakładamy, że mamy działający prototyp przypadku użycia, a teraz chcemy go zoperacjonalizować. W przypadku, gdy ten przypadek użycia należy do nowego obszaru produktu, najpierw musimy udostępnić konta przy użyciu organizacji, co automatycznie uruchamia usługę ADF, aby załadować te konta do wdrożenia. Yara stosuje strategię konta DEV>TEST>PROD; jednak ta konfiguracja nie jest obowiązkowa. Konta danych udostępniają interfejsy API umożliwiające dostęp do danych, a w przypadku nowego przypadku użycia role muszą zostać przyznane w razie potrzeby AWS Zarządzanie tożsamością i dostępem (IAM), aby mogli uzyskać dostęp do interfejsów API danych.

Następnie musimy zdefiniować, na których kontach zostanie wdrożony ten przypadek użycia. Odbywa się to przy użyciu mapy wdrażania w ADF. Mapa wdrożenia to plik konfiguracyjny, który zawiera mapowanie etapów i celów dla potoku. Aby uruchomić mapę wdrożenia, usługa ADF używa CodePipeline. ADF zapewnia elastyczność zarządzania parametrami dla każdego środowiska docelowego, w którym stos jest wdrażany. Ułatwia to zarządzanie wdrożeniami i testowanie na mniejszych instancjach.

W celu zaszyfrowania wszystkich artefaktów, takich jak kod, dane i pliki modeli, generujemy plik Usługa zarządzania kluczami AWS (AWS KMS). Możesz także użyć szyfrowania po stronie serwera. Ponieważ jednak niektóre z wygenerowanych artefaktów są dostępne na różnych kontach, musimy wygenerować własny klucz i zarządzać jego zasadami uprawnień, aby zapewnić dostęp między kontami.

Na koniec musimy utworzyć grupę pakietów modeli, aby pogrupować różne wersje modelu przy użyciu rejestru modeli SageMaker, który umożliwia SageMaker śledzenie modeli i zarządzanie nimi w trakcie ich przechodzenia przez cykl życia ML.

Potok szkolenia modelu

Dla każdej nowej fabryki włączonej do ELC tworzymy nowy proces szkoleniowy SageMaker. Ten potok składa się z kroków wstępnego przetwarzania danych i szkolenia modelu. Potoki SageMaker dobrze pasują do Yara, ponieważ oferują interfejs Pythona do definiowania przepływu pracy ML. Co więcej, różne etapy przepływu pracy można skonfigurować tak, aby skalowały się w różny sposób. Na przykład można zdefiniować znacznie większą instancję do trenowania niż do etapu oceny modelu. Parametry wejściowe i wyjściowe dla każdego etapu potoku są przechowywane, co ułatwia śledzenie każdego przebiegu i jego wyników. Ogólny zarys przepływu pracy szkoleniowej jest następujący.

W ramach etapu oceny modelu zestaw danych oceny jest używany do generowania metryk, takich jak dokładność i odchylenie średniej kwadratowej błędu (RMSE) w wyuczonym modelu. Te metryki są dodawane do metadanych modelu przed zarejestrowaniem modelu w rejestrze modeli. Obecnie modele są ręcznie promowane do wyższych środowisk, a osoba zatwierdzająca model może przeglądać metryki modelu, aby upewnić się, że nowa wersja działa lepiej niż bieżący model.

Modele są kontrolowane pod względem wersji za pomocą rejestru modeli, przy czym każda fabryka ma własną grupę pakietów modeli. Ponadto można użyć rejestru modeli do śledzenia, które wersje modeli są wdrażane w poszczególnych środowiskach. Modelka może być w odrzucony, Oczekuje na ręczne zatwierdzenielub Zatwierdzony stan i tylko modele, które są w Zatwierdzony państwo może zostać wdrożone. Zapewnia to również ochronę przed przypadkowym wdrożeniem niezatwierdzonej wersji modelu.

Potok wnioskowania i monitorowania modelu

Aby wdrożyć model i skonfigurować monitorowanie modelu, skonfigurowaliśmy drugi potok SageMaker. Aplikacja ELC zapewnia operatorom zakładów prognozy na żądanie, dlatego dostęp do modeli uzyskuje się za pośrednictwem wywołań API wykonywanych z zaplecza ELC. Punkty końcowe wnioskowania SageMaker zapewniają w pełni zarządzane rozwiązanie hostingu modeli z warstwą API; punkty końcowe przyjmują dane wejściowe modelu jako prognozy ładunku i zwracają. Ponieważ opóźnienie jest również kluczowym czynnikiem dla użytkowników końcowych, którzy nie chcą długo czekać na zaktualizowane prognozy, firma Yara wybrała punkty końcowe wnioskowania w czasie rzeczywistym SageMaker, które są szczególnie odpowiednie dla obciążeń o bardzo niskich wymaganiach dotyczących opóźnień. Wreszcie, ponieważ aplikacja ELC nie może mieć przestojów podczas wdrażania zaktualizowanych modeli, opiera się ona na niebieskich/zielonych możliwościach wdrażania punktów końcowych SageMaker w czasie rzeczywistym, aby zapewnić, że stara wersja modelu będzie nadal służyć do przewidywania, dopóki nowa wersja nie zostanie wdrożona .

Na poniższym diagramie przedstawiono konfigurację wdrażania i monitorowania.

Do monitorowania modelu Yara uruchamia SageMaker jakość danych, jakość modelu, wyjaśnialność modelu monitorowanie. Monitorowanie jakości danych sprawdza spójność i generuje statystyki dystrybucji danych. Monitorowanie jakości modelu sprawdza wydajność modelu i porównuje dokładność modelu z metrykami szkoleniowymi. Raporty z monitorowania modelu są generowane co godzinę. Raporty te służą do monitorowania wydajności modelu w środowisku produkcyjnym. Monitorowanie wyjaśnialności modelu służy do zrozumienia, jakie cechy najbardziej przyczyniają się do prognozy.

Te wyniki wyjaśnialności modelu są udostępniane na pulpicie nawigacyjnym ELC, aby zapewnić operatorom instalacji większy kontekst na temat tego, co napędza zużycie energii. Pomaga to również określić działania mające na celu dostosowanie procesu wewnętrznego w przypadku, gdy zużycie energii odbiega od optymalnego punktu.

Przepływ CI/CD

Przepływ CI/CD dla potoków szkoleniowych rozpoczyna się na koncie DEV. Yara postępuje zgodnie z modelem rozwoju opartym na funkcjach, a gdy opracowywana jest nowa funkcja, gałąź funkcji jest łączona z łączem głównym, co rozpoczyna wdrażanie. Modele ELC są szkolone na koncie DEV, a po przeszkoleniu i ocenie modelu są rejestrowane w rejestrze modeli. Osoba zatwierdzająca model przeprowadza kontrolę poprawności przed aktualizacją statusu modelu do Zatwierdzony. Ta akcja generuje zdarzenie, które wyzwala wdrożenie potoku wnioskowania modelu. Potok wnioskowania o modelu wdraża nową wersję modelu w punkcie końcowym SageMaker w DEV.

Po wdrożeniu punktu końcowego uruchamiane są testy sprawdzające zachowanie instalacji. Do testowania używa Yara Raporty z testów CodeBuild. Ta funkcja umożliwia programistom uruchamianie testów jednostkowych, testów konfiguracji i testów funkcjonalnych przed i po wdrożeniu. W takim przypadku Yara przeprowadza testy funkcjonalne, przekazując ładunki testowe do punktów końcowych SageMaker i oceniając odpowiedź. Po przejściu tych testów potok przechodzi do wdrażania punktów końcowych SageMaker w TEST. Zaplecze ELC jest również wdrażane w TEST, co umożliwia kompleksowe testowanie aplikacji w tym środowisku. Dodatkowo Yara przeprowadza testy akceptacji użytkownika w TEST. Wyzwalaczem z wdrożenia TEST do PROD jest ręczne zatwierdzenie. Gdy nowa wersja modelu przejdzie zarówno testy funkcjonalne, jak i akceptacyjne użytkownika w TEST, zespół inżynierów zatwierdza wdrożenie modelu w PROD.

Poniższy rysunek ilustruje ten przepływ pracy.

Wspólne elementy

W przypadku ELC używamy kilku komponentów wspólnych dla wszystkich etapów wdrożenia (DEV, TEST, PROD) i modeli. Komponenty te znajdują się na naszym koncie wdrażania i obejmują kontrolę wersji modelu, repozytorium obrazu kontenera, klucz szyfrowania oraz zasobnik do przechowywania typowych artefaktów.

Korzystanie ze wspólnych artefaktów ma kilka zalet. Na przykład zasoby nie muszą być tworzone dla każdego konta, co wymusza zgodność między kontami. Oznacza to, że tworzymy obrazy kontenerów raz i wykorzystujemy je ponownie na wszystkich kontach docelowych, skracając czas tworzenia.

Ten potok przechowuje różne wersje modeli we wspólnym rejestrze modeli na koncie wdrożenia. Z tej centralnej lokalizacji modele można wdrażać na wszystkich kontach bez ich przenoszenia. Podobnie korzystanie z centralnie przechowywanego klucza szyfrowania ułatwia zarządzanie kluczem i uprawnieniami między kontami.

Jedną z wad korzystania z typowych artefaktów jest to, że etap wdrażania nowego przypadku użycia może stać się bardziej skomplikowany. Aby wdrożyć nowy przypadek użycia, należy utworzyć nowy rejestr modeli i, w razie potrzeby, nowe repozytorium obrazów kontenerów. Zalecamy również utworzenie nowego klucza szyfrowania w celu ścisłego oddzielenia zasobów i przechowywanych danych.

Wnioski

W tym poście pokazaliśmy, jak Yara wykorzystała SageMaker i ADF do zbudowania wysoce skalowalnej platformy MLOps. ML to funkcja wielofunkcyjna, a zespoły wdrażają modele na kontach różnych jednostek biznesowych. Dlatego ADF, który oferuje natywną integrację z organizacjami, sprawia, że ​​jest idealnym kandydatem do ładowania kont w celu skonfigurowania potoków CI/CD. Pod względem operacyjnym potoki ADF są uruchamiane na centralnym koncie wdrażania, co ułatwia uzyskanie ogólnego widoku kondycji wdrożeń. Wreszcie, ADF korzysta z usług zarządzanych AWS, takich jak CodeBuild, CodeDeploy, CodePipeline i CloudFormation, co ułatwia konfigurację i konserwację.

SageMaker zapewnia szerokie spektrum możliwości uczenia maszynowego, co pozwala zespołom skupić się bardziej na rozwiązywaniu problemów biznesowych, a mniej na budowaniu i utrzymywaniu infrastruktury. Ponadto SageMaker Pipelines zapewnia bogaty zestaw interfejsów API do tworzenia, aktualizowania i wdrażania przepływów pracy ML, dzięki czemu doskonale pasuje do MLOps.

Wreszcie, MLOps zapewnia najlepsze praktyki niezawodnego i wydajnego wdrażania i utrzymywania modeli ML w środowisku produkcyjnym. W przypadku zespołów, które tworzą i wdrażają rozwiązania ML na dużą skalę, niezwykle ważne jest wdrażanie MLOps. W przypadku firmy Yara MLOps znacznie zmniejsza wysiłek wymagany do wdrożenia nowej fabryki, wdrożenia aktualizacji ELC i zapewnienia monitorowania jakości modeli.

Aby uzyskać więcej informacji na temat wdrażania aplikacji przy użyciu usługi ADF, zobacz przykłady.

---

O autorach

Shaheera Mansoora jest Data Scientist w AWS. Skupia się na budowaniu platform uczenia maszynowego, które mogą obsługiwać rozwiązania AI na dużą skalę. Jego obszary zainteresowań to MLOps, sklepy z funkcjami, hosting modeli i monitorowanie modeli.

Tima Beckera jest starszym analitykiem danych w Yara International. W ramach produkcji cyfrowej koncentruje się na optymalizacji procesów produkcji amoniaku i kwasu azotowego. Posiada doktorat z termodynamiki i jest pasjonatem łączenia inżynierii procesowej i uczenia maszynowego.

Yongyosa Kaewpitakkuna jest starszym analitykiem danych w zespole Digital Production w Yara International. Ma doktorat z sztucznej inteligencji/uczenia maszynowego i ma wieloletnie praktyczne doświadczenie w wykorzystywaniu uczenia maszynowego, wizji komputerowej i modeli przetwarzania języka naturalnego do rozwiązywania trudnych problemów biznesowych.