icon-search

Rozwiązania telematyczne – case study na przykładzie systemu OctoU

Tomasz Traczyk 04.07.2018

OctoU jest platformą do oceniania techniki i stylu jazdy kierowców. Platforma składa się z aplikacji mobilnej oraz systemu back-endowego, którego tworzeniem zajmujemy się w Sparkbicie. Do marca 2018 zgromadziliśmy w systemie 330 milionów kilometrów historycznych tras (to więcej niż na Słońce i z powrotem) wykonanych przez użytkowników naszych wdrożeń. W każdym miesiącu mamy ponad 30 tysięcy aktywnych użytkowników, a każdy z nich rejestruje średnio ponad 70 nowych tras.

W niniejszym artykule opiszę założenia architektoniczne back-endu OctoU i wykorzystane narzędzia, które pozwoliły mierzyć się z rosnącym obciążeniem systemu i umożliwiły jego horyzontalne skalowanie.

Pokaż mi swojego smartfona a powiem Ci jakim kierowcą jesteś

Zanim przejdziemy do konkretów, parę słów o tym czym jest platforma OctoU i jakie zadania spełnia omawiany back-end. Aplikacja OctoU na smartfonie kierowcy automatycznie wykrywa start podróży i rozpoczyna przesyłanie danych do back-endu. Trasa pokonywana przez kierowcę reprezentowana jest jako sekwencja punktów z GPS zawierających informacje takie jak współrzędne geograficzne, szacowana dokładność położenia, prędkość pojazdu czy kierunek w którym pojazd się przemieszcza.

W oparciu o te dane, nazywane danymi telematycznymi, back-end OctoU wykrywa niebezpieczne zachowania kierowcy, a następnie wystawia punktową ocenę pokonanej trasy i, w konsekwencji, samego kierowcy.

Biznesowo OctoU jest graczem na rynku Usage-based insurance, gdzie ubezpieczyciele nagradzają ostrożnych kierowców zniżkami na polisy. A jest o co grać – według firmy analitycznej Berg Insight, łączna liczba polis opierających się na telematyce w Europie wzrośnie w 2021 r. do 30 mln (na koniec 2016 ta liczba wynosiła 6.7 mln).

Kontekst jest ważny

Zebrane dane z GPS to jeszcze za mało. Łatwo sobie wyobrazić, że czym innym jest jazda 120 km/h na autostradzie, a czym innym na lokalnej uliczce w terenie zabudowanym. Podobnie zbyt ostre wchodzenie w zakręty nie jest może najlepszym pomysłem nawet w słoneczny dzień przy dobrej widoczności, ale może mieć dużo gorsze konsekwencje, gdy nawierzchnia jest śliska, a kierowca widzi tylko własne wycieraczki.

Dlatego, dla pełniejszej oceny zachowań kierowcy, dane przekazane przez apkę mobilną wzbogacane są danymi z serwisów zewnętrznych, dotyczącymi ograniczeń prędkości, aktualnych warunków pogodowych, czy natężenia ruchu. Pobieramy też ostrzeżenia drogowe, aby w czasie rzeczywistym przekazać je kierowcy. Proces wzbogacania danych przedstawiłem na Rysunku 1.

Screen Shot 2018-07-04 at 11.05.49

Na koniec, w oparciu o zgromadzone dane, back-end OctoU wykrywa i ocenia niebezpieczne zachowania kierowcy.

Skoro już wiemy co robi omawiany system, możemy nareszcie zajrzeć pod maskę.

Skalowalna architektura systemu

Na back-end OctoU składają się dwa klastry aplikacji webowych, baza danych MySQL w konfiguracji master-slave, kolejka komunikatów ActiveMQ z konfiguracją przełączenia awaryjnego (Active-Passive) oraz klaster bazy danych Apache Cassandra.

Głównym założeniem omawianej architektury jest zapewnienie horyzontalnej skalowalności, czyli możliwości rozbudowy systemu poprzez zwiększenie liczby maszyn, w opozycji do skalowalności wertykalnej rozumianej jako zwiększanie zasobów istniejących węzłów.

Aplikacje webowe wchodzące w skład back-endu OctoU podzielone są na dwa typy: web i worker. Węzły web obsługują ruch przychodzący ze świata – głównie dane telematyczne z aplikacji mobilnych, a węzły worker przetwarzają dane asynchronicznie i nie są wystawione na świat.

Z założenia weby, wykonują krótkie, synchronicznie operacje i muszą szybko odpowiadać aplikacjom mobilnym, dlatego ich głównym zadaniem jest wstępna walidacja otrzymanych danych i zakolejkowanie ich w ActiveMQ do przetworzenia przez workery. Wystawiają także rozbudowane API pozwalające na wizualizację zebranych danych użytkownika w aplikacji mobilnej.

Screen Shot 2018-07-04 at 11.06.05

Workery odpowiedzialne są za główną część pracy: to one koordynują proces wzbogacania danych informacjami z zewnętrznych usług i to one wykonują obliczenia pozwalające na wykrycie niebezpiecznych zdarzeń i wystawienie oceny punktowej.

Dzięki asynchronicznej komunikacji między webami a workerami, interfejsy wystawione na świat są niewrażliwe na opóźnienia w przetwarzaniu danych spowodowane np. kłopotami z dostępnością którejś z zewnętrznych usług wzbogacających dane.

Przetwarzanie danych w workerach podzielone zostało na wiele kroków, które również wykonują się asynchronicznie: każdy krok przetwarzania ma swoją kolejkę. Konsumenci odpowiedzialni za wykonywanie danego kroku podejmują wiadomości z dedykowanej do niego kolejki, a następnie przekazują je do kolejki związanej z kolejnym krokiem.

Taka architektura systemu pozwala na skalowanie go na wielu poziomach: począwszy od liczby konsumentów przypisanych do poszczególnych kolejek, a skończywszy na liczbie węzłów poszczególnych typów.

Najmniej skalowalnym horyzontalnie elementem systemu jest w tej chwili baza danych MySQL. Przechowujemy w niej jednak tylko relatywnie lekkie metadane o użytkownikach, administratorach itp., które wygodnie jest przechowywać w relacyjnej bazie danych. Dane telematyczne, a więc te, których jest naprawdę dużo przechowujemy w Cassandrze rozproszonej bazie danych NoSQL pozwalającej na dostosowywanie liczby węzłów przechowujących dane i poziomu ich replikacji.

Wyzwania – co i jak mierzyć

Każdy system produkcyjny wymaga monitoringu swojego działania. Utrzymując i rozwijając system, którego obciążenie stale rośnie, musimy obserwować wydajność poszczególnych elementów, tak żeby z wyprzedzeniem dostosowywać dostępność zasobów i przewidywać pojawienie się problemów.

OctoU jako system telematyczny jest wrażliwy na porę dnia – największym wyzwaniem są zawsze godziny popołudniowego szczytu, zwłaszcza w piątki. Rysunek 3. przedstawia przykładowy wykres liczby requestów na sekundę do jednego z naszych środowisk w ciągu tygodnia, od poniedziałku do niedzieli. Wzorzec widoczny na wykresie: dwa szczyty – poranny i popołudniowy – w dni powszednie oraz pojedyncza łagodniejsza górka w soboty i niedziele, powtarza się tydzień w tydzień. Jeśli czasem rano po przebudzeniu nie pamiętam jaki jest dzień tygodnia, to patrzę na wykresy i już wiem.

Screen Shot 2018-07-04 at 11.10.04

Największym wyzwaniem wydajnościowym jest zawsze szczyt popołudniowy w piątek – wtedy mamy największy ruch.

Skuteczne monitorowanie wydajności systemu, pozwalające dobrze przygotować się na stale rosnący ruch stawia wyzwania w dwóch kategoriach: jak mierzyć interesujące nas wartości i, co ważniejsze, jakie wartości powinny nas interesować.

Przykładem bardzo prostej koncepcyjnie metryki, która pozwoliła na duże usprawnienia działania systemu, jest liczba wiadomości w poszczególnych kolejkach. Obserwując, w których kolejkach zbiera się największa górka wiadomości czekających na przetworzenie, mogliśmy rozpoznać, które kroki przetwarzania danych nie nadążają za pozostałymi, czyli, krótko mówiąc, znaleźć wąskie gardła.

Implementując tę metrykę wykorzystaliśmy dane wystawiane standardowo przez ActiveMQ za pośrednictwem JMX oraz narzędzie jmxtrans (https://github.com/jmxtrans/jmxtrans), które pozwala na zapisywanie danych z JMX do wybranego narzędzia monitorującego. Jmxtrans okazał się dla nas przydatny również przy implementacji wielu innych metryk bazujących na danych wystawianych przez JMX i z całą pewnością jest narzędziem, o którego istnieniu warto wiedzieć.

Inną nauką, którą wyciągnęliśmy z projektowania i wykorzystywania metryk w naszym systemie jest to, że trzeba bardzo dobrze wiedzieć, co dokładnie dana metryka reprezentuje. Choć brzmi to jak truizm, łatwo przez nieuwagę skończyć porównując jabłka z pomarańczami. Nam zdarzyło się, że porównywaliśmy czasy wykonywania dwóch różnych zapytań logowane po stronie aplikacji. Zapytania były bardzo podobne, ale czasy – drastycznie różne. Rozwiązaniem zagadki okazało się to, że w jednym przypadku mierzyliśmy faktycznie czas zapytania, a w drugim – przypadkiem oprócz czasu zapytania również czas oczekiwania na przydzielenie połączenia z puli. Lesson learned.

Do śledzenia metryk używamy Grafany (https://grafana.com/) , która oprócz wizualizacji danych pozwala również na konfigurację powiadomień o niepożądanych wartościach.

Co dalej?

Zbudowaliśmy narzędzie, które zbiera dane telematyczne, wzbogaca je o kontekst z zewnętrznych usług i ocenia kierowców. Wytrzymaliśmy realny i wcale niemały ruch produkcyjny i zgromadziliśmy sporo interesujących danych. Na pewno czekają nas dalsze wyzwania wydajnościowe, bo liczba użytkowników systemu stale rośnie.

Kolejnym krokiem będzie analiza zebranych danych. Sparkbit rozwija swoje kompetencje w obszarze machine learning, a dane które zbieramy są doskonałą pożywką dla algorytmów uczenia maszynowego.

Komentarze: 0


Notice: Korzystanie z Motyw nieposiadający comments.php uznawane jest za przestarzałe od wersji 3.0.0! Nie istnieje żadna alternatywa. Proszę zawrzeć w motywie szablon comments.php. in /var/www/html/www_pl/wp-includes/functions.php on line 4592

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *