Sytuacja kobiet w IT w 2024 roku
9.12.20206 min
Paweł Haracz
Predica Sp. z o.o.

Paweł HaraczTeam LeadPredica Sp. z o.o.

Jak zbudować platformę IoT, wykorzystując architekturę event-driven

Sprawdź, jak jak wykorzystać architekturę event-driven do zbudowania rozwiązania IoT na przykładzie skalowalnej, globalnej platformy Internetu Rzeczy.

Jak zbudować platformę IoT, wykorzystując architekturę event-driven

Internet Rzeczy to coraz powszechniejszy temat. Mamy już aplikacje do zarządzania oświetleniem, zegarkiem, a nawet szczoteczką do zębów! Ale jak wygląda taka technologia na skalę przemysłową i co jest konieczne dla jej opracowania? O tym jest ten artykuł. 

Nasz klient z branży produkcyjnej postanowił przekształcić model biznesowy z czysto sprzedażowego na subskrypcyjny. Na tym przykładzie pokażę, jak wykorzystać architekturę event-driven do zbudowania skalowalnej, globalnej platformy, pozwalającej użytkownikom na bezpieczne zarządzanie urządzeniami z dowolnego miejsca na świecie. W skrócie... będzie ciekawie!

Jaki był cel projektu?

Jednym z naszych klientów w Predica jest producent pomp wodnych. Z ich urządzeń korzystają użytkownicy na całym świecie. Firma chciała rozszerzyć swoją ofertę i wprowadzić model abonamentowy jako kolejny aspekt swojej działalności. 

Aby tego dokonać, potrzebowali oni zbudować nowoczesną platformę IoT, która pozwoliłaby na podłączenie i zarządzanie urządzeniami za pośrednictwem strony internetowej. Użytkownicy mogliby wtedy uruchomić portal i monitorować swoje urządzenia, zarządzać nimi, czy otrzymywać alerty i prognozy dotyczące zużycia wody lub ryzyka awarii mechanicznej, zanim cokolwiek się stanie.

Każde urządzenie zawiera już elektronikę do sterowania. Dlatego spełnienie tego zadania nie wymagało skomplikowanej restrukturyzacji, a jedynie wykorzystania danych, które są już dostępne.

Rozwiązanie

Poprzednio nasz klient korzystał z innej usługi, która została stworzona jako system sekwencyjny, więc jej wydajność i skalowalność były niewystarczające. Było to rozwiązanie on-premises, a więc trzeba też było zajmować się utrzymaniem infrastruktury. Dodatkowo, platforma ta była przygotowana tylko dla jednego typu urządzenia, bez możliwości jej rozbudowy.

Celem nowej platformy było wyeliminowanie słabych punktów starej platformy i przeniesienie rozwiązania do chmury. Wspólnie z klientem zdecydowaliśmy się na wykorzystanie podejścia event-driven do obsługi urządzeń. 

Razem stworzyliśmy zatem nową platformę opartą na chmurze, która docelowo w pełni zastąpi dotychczasowe rozwiązanie. Obecnie każde urządzenie (tak wcześniej wyprodukowane, jak i nowe) może być zarządzane za pomocą odpowiedniej dla niego platformy.

Czym jest podejście event-driven?

Bazujące na architekturze event-driven, jest to sposób na zbudowanie skalowalnego systemu opartego na rozproszonej i asynchronicznej komunikacji pomiędzy mikrousługami. 

Jak to działa?

Każde urządzenie lub usługa (np. usługa A) wysyła dane do magistrali zdarzeń (ang. event bus), w efekcie produkując zdarzenie. Druga usługa lub urządzenie (np. usługa B) oczekuje informacji z magistrali zdarzeń. Magistrala wysyła zdarzenie do usługi B, które, w odpowiednim czasie, pobiera i przetwarza tę informację w odpowiedni sposób.

W efekcie, usługa B powinna wygenerować kolejne zdarzenie, które zawiera dane o tym, co się wydarzyło i przesłać je na powrót do magistrali zdarzeń.

Takie podejście pozwala na zachowanie autonomii usług i skalowanie rozwiązania.

Usługi komunikują się asynchronicznie wyłącznie za pomocą zdarzeń, więc musimy pamiętać, by były ze sobą spójne.


Przykład architektury event-driven

Jakich usług użyliśmy do budowy naszego rozwiązania?

Platforma opiera się o szereg usług Azure. Oto najważniejsze z tych, których użyliśmy:

Azure Kubernetes Service (AKS)

Kubernetes to system do zarządzania klastrami kontenerów. Został on zaprojektowany tak, aby był elastyczny i odporny na błędy, pozwalając restartować i przenosić komponenty aplikacji pomiędzy systemami według potrzeb. Usługa AKS jest w pełni utrzymywana przez Microsoft i hostowana na Azure.

Kubernetes automatycznie zarządza wyszukiwaniem usług czy równoważeniem przepływu danych, śledzi też alokację zasobów i skaluje je odpowiednio na podstawie wykorzystania mocy obliczeniowej. Automatyczne skalowanie jest dzięki temu szybsze niż w Azure PaaS.

Azure Container Registry (ACR)

Jest to system zarządzania cyklem życia kontenera. Wszystkie usługi i wdrożenia Kubernetes są przechowywane i wersjonowane w ACR jako obrazy Docker i Helm Charts. Korzystając z ACR, możemy utrzymywać wiele wersji naszych mikrousług z odpowiednimi definicjami wdrożeń.

ACR może skanować wszystkie dodane tam obrazy. Pozwala to odkryć znane problemy w pakietach lub zależnościach zdefiniowanych w pliku obrazu kontenera. Możemy też otrzymać oceny i rekomendacje dotyczące tych problemów, w tym konkretne wskazówki dotyczące ich naprawy.

Azure DevOps 

Azure DevOps używamy, aby zarządzać całym procesem. Wszelkie zmiany w kodzie, podczas łączenia z główną gałęzią, uruchomią procesy build & test, utworzą obraz i Helm Chart, po czym przkekażą informacje do Azure Container Registry. Kiedy obraz wyląduje w ACR, Azure DevOps uruchomi skrypty wdrożeniowe.

Ważną rzeczą w tym procesie jest to, że wszystko jest napisane jako jeden pipeline przy użyciu podejścia Infrastructure as Code, w związku z czym każda zmiana w pipeline jest śledzona.

Azure IoT Hub

To jedna z najczęściej wykorzystywanych usług w naszym rozwiązaniu. IoT Hub pozwala nam na podłączenie urządzeń do Azure. Za jego pomocą możemy zarządzać urządzeniami IoT, bezpiecznie wysyłać polecenia i odbierać dane z urządzeń. Częścią tej usługi jest funkcja wykrywania, która przypisuje urządzenia do danej usługi czy użytkownika.

Azure Event Hub

W pełni zarządzana usługa przesyłania danych w czasie rzeczywistym. Przesyła ona miliony zdarzeń z wielu źródeł. Gwarantuje, że nawet ogromne ilości danych zostaną przesłane do właściwych usług.

Azure Service Bus

Usługa do przekazywania komunikatów, w pełni zarządzana przez Azure. Służy do asynchronicznej wymiany informacji między usługami.

Azure PostgreSQL

Czyli baza danych PostgreSQL, zarządzana przez Azure. Używamy w szczególności rozszerzenia Timescale do zarządzania danymi typu time-series. Dane z urządzeń są przechowywane jako kolekcja dokumentów w formacie JSONB – natywnym dla PostgreSQL binarnym formacie JSON, który może być dołączony do zapytania.

Azure Storage Account

Używany do przechowywania surowych danych z urządzeń, a czasami jako magazyn dla wewnętrznego stanu usług.

Jak połączyliśmy te usługi?

Niektóre lokalizacje, gdzie działa nasz klient, mają swoje własne tzw. pakiety lub ograniczenia (np. geograficzne). Pakiety w tym przypadku to grupy urządzeń, rozwiązujących konkretne problemy – np. wykrywanie pożarów, uruchamianie zraszaczy lub mieszanie ciepłej i zimnej wody w infrastrukturze miejskiej. W zależności od typu urządzenia, mogą mieć zupełnie różne zestawy punktów danych lub protokołów danych.

W celu dopasowania rozwiązania do tych różnorodnych potrzeb, zdecydowaliśmy się stworzyć osobną infrastrukturę Kubernetes dla każdej lokalizacji. Każdy region ma swój własny klaster i infrastrukturę Azure. Takie podejście pozwala nam na stopniowe udostępnianie rozwiązania kolejnym użytkownikom, przy jednoczesnym zachowaniu stabilności rozwiązania.

Infrastruktura platformy IoT

Pojedynczy IoT Hub zarządza wieloma rodzajami urządzeń, które funkcjonują niezależnie od pakietów czy protokołów, używanych przez inne urządzenia. Aby umożliwić współdzielenie tych informacji, wprowadziliśmy bliźniacze tagi. 

W jaki sposób je dodajemy? W trakcie procesu wykrywania urządzenia, nasze rozwiązanie automatycznie dodaje tagi do jego odpowiednika na podstawie konfiguracji.

Dane te są niezbędne do przetwarzania danych - funkcja routingu wiadomości IoT Hub przekazuje każdą wiadomość z urządzenia do odpowiedniego event hub. Dodatkowo wykorzystujemy funkcję wzbogacenia wiadomości, aby dodawać bliźniacze tagi podczas przekazywania danych. Takie podejście pozwala nam na sortowanie zdarzeń według typów i protokołów.

Inne zespoły developerskie, a nawet firmy partnerskie mogą również odbierać, przetwarzać i reagować na dane z odpowiedniego dla siebie kanału. 


Sortowanie danych według rodzaju zdarzenia

Na powyższym schemacie widzimy, jak IoT Hub sortuje zdarzenia do odpowiedniej magistrali zdarzeń. Ta z kolei przesyła odpowiednie dane w oparciu o kategorię (telemetria, zdarzenie, polecenie) oraz protokół. Nie sortujemy tu zdarzeń wg pakietów, gdyż nie jest to konieczne na tym poziomie. Dzieje się to jednak na poziomie mikrousług.

Jak monitorować te wszystkie dane?

Nasze rozwiązanie korzysta z wielu usług i przetwarza ogromne ilości danych. Z tego powodu może być trudno wykryć jakieś problemy. Jedynym sposobem, by zrobić to skutecznie, jest monitorowanie wszystkich zdarzeń i tego, ile z nich każda z usług przetwarza w danym momencie. W tym celu użyliśmy AKS, a konkretniej rozwiązania Prometheus.

Prometheus jest usługą Kubernetes, która zbiera potrzebne informacje z naszego rozwiązania. Po otrzymaniu nowej wiadomości, usługa najpierw wysyła tę informację do Prometheusa, a następnie przywołuje logikę biznesową i notuje, ile czasu to zajęło i ile zdarzeń zostało wygenerowanych.


Przykładowe statystyki na temat zdarzeń

Dane są przetwarzane w czasie rzeczywistym, więc jeśli coś się wydarzy, wiemy o tym od razu. Jesteśmy również dobrze przygotowani do skalowania, ponieważ nasze usługi wykorzystują do tego celu te same informacje. Bez nich nie bylibyśmy w stanie oszacować obciążenia i możliwości naszych usług.

 Podsumowanie

Teraz już wiesz, jak można zbudować architekturę event-driven, aby zarządzać dużą ilością danych z urządzeń IoT. Korzystając z rozwiązań chmurowych, można w miarę łatwo zbudować skalowalne rozwiązanie. Jeśli chcesz dowiedzieć się więcej, śmiało daj znać!

MakeAnImpact - miej wpływ!

Artykuł powstał w ramach akcji #MakeAnImpact promującej projekty IT, które mają wpływ na otaczający nas świat. Skierowana jest do do społeczności IT.

<p>Loading...</p>