Warstwy funkcjonalne
Systemy pracują w oparciu o architekturę mikroserwisową, co oznacza, że ich logika została podzielona na niezależne, konteneryzowane komponenty. Interakcja użytkownika z aplikacją odbywała się z poziomu warstwy frontendowej, za pośrednictwem przeglądarki internetowej, gdzie deweloper – jako końcowy użytkownik – ma możliwość komunikowania się z systemem zarówno w sposób synchroniczny, jak i asynchroniczny. Dwa główne protokoły wykorzystywane do przesyłania danych to REST oraz WebSocket. Obsługa obu typów komunikacji została powierzona warstwie pośredniczącej, którą pełnił komponent typu brama API, wdrożony z wykorzystaniem rozwiązania Tyk API Gateway.
Tyk API Gateway stanowi strategiczny element infrastruktury, odpowiedzialny za przyjmowanie, autoryzację i przekazywanie żądań HTTP oraz WebSocket do odpowiednich usług backendowych. Rozwiązanie to wspierało zaawansowane mechanizmy zarządzania ruchem, takie jak rate limiting, kontrola dostępu oparta na tokenach (JWT oraz OAuth2), cache’owanie odpowiedzi czy rejestrowanie metryk i logów operacyjnych. Brama Tyk jest elastyczna pod względem integracji z innymi komponentami i dobrze przystosowana do środowisk kontenerowych, co umożliwia łatwe wdrażanie i skalowanie.
W warstwie backendowej znajdują się kontenery Docker z aplikacjami stworzonymi przy użyciu frameworka FastAPI. FastAPI, będący nowoczesnym, wydajnym i asynchronicznym frameworkiem w języku Python, zapewnia szybkie tworzenie usług RESTful oraz wsparcie dla komunikacji WebSocket. Dzięki swojej strukturze opartej na typowaniu i zgodności z OpenAPI, umożliwia on generowanie dokumentacji API w czasie rzeczywistym oraz eliminację wielu błędów wynikających z niezgodności typów danych. Każda usługa FastAPI jest uruchamiana jako osobny kontener, co odpowiadało założeniom mikrousług – niezależności, możliwości indywidualnego skalowania oraz wdrażania.
Centralnym elementem komunikacji między usługami backendowymi jest platforma Apache Kafka, która pełni rolę rozproszonego systemu kolejkowania wiadomości. Kafka została wdrożona jako szyna danych (message bus), umożliwiająca przesyłanie komunikatów między serwisami pełniącymi rolę producentów i konsumentów danych w sposób asynchroniczny. W architekturze przedstawionej na schemacie każda usługa FastAPI może publikować zdarzenia do konkretnego tematu (topic), które następnie są subskrybowane przez inne komponenty systemu. Takie podejście gwarantowało odseparowanie logiki biznesowej od warstwy komunikacyjnej, co zwiększało odporność systemu na błędy oraz pozwalało na elastyczne przetwarzanie strumieniowe i wsadowe.
Dane w systemie są przetwarzane i przechowywane w dwóch odrębnych repozytoriach danych. Dane strukturalne, obejmujące na przykład informacje o użytkownikach, konfiguracjach, stanach operacyjnych czy metadanych, zapisywane są w relacyjnej bazie danych PostgreSQL. PostgreSQL oferuje pełne wsparcie dla transakcji ACID, zaawansowane mechanizmy indeksowania, replikacji i partycjonowania danych oraz rozszerzalność poprzez wtyczki i funkcje użytkownika. Baza ta doskonale sprawdza się w środowiskach wymagających wysokiej integralności i spójności danych.
Dane binarne, niestrukturalne lub wymagające wysokiej dostępności w modelu obiektowym są przechowywane w systemie MinIO, który oferuje interfejs zgodny z Amazon S3. MinIO umożliwia przechowywanie dużych ilości danych w formie obiektów z przypisanymi metadanymi, a także wspiera mechanizmy wersjonowania, szyfrowania oraz polityki dostępu na poziomie poszczególnych zasobów. Dzięki lekkości implementacyjnej oraz kompatybilności z narzędziami chmurowymi i on-premise, MinIO dobrze wpisuje się w potrzeby elastycznego, skalowalnego i odpornego systemu magazynowania danych.
Ostatni komponent backendowy przedstawiony na schemacie to kontener FastAPI pełniący rolę konsumenta danych z tematów Kafka, którego zadaniem było przetwarzanie przychodzących wiadomości oraz zapisywanie wyników do PostgreSQL lub MinIO – w zależności od charakteru przetworzonych danych. Taki model działania pozwalał na wdrażanie mechanizmów przetwarzania strumieniowego, w których dane były odbierane i analizowane w czasie rzeczywistym, oraz przetwarzania wsadowego, w którym dane były kolekcjonowane i przetwarzane okresowo.
Monitoring
Centralnym elementem warstwy monitoringu jest Prometheus, który pełni funkcję systemu gromadzenia metryk. Jest to narzędzie typu open-source stworzone z myślą o monitorowaniu aplikacji kontenerowych i środowisk mikroserwisowych. Prometheus działa na zasadzie aktywnego scrapowania danych, co oznacza, że w regularnych odstępach czasu odpytuje skonfigurowane endpointy eksportujące metryki w specjalnym formacie tekstowym. Zaletą tego podejścia jest decentralizacja odpowiedzialności za udostępnianie danych – każda usługa musi samodzielnie eksponować odpowiedni endpoint, co zwiększa przejrzystość i elastyczność konfiguracji. Prometheus agreguje dane czasowe, umożliwiając ich retencję, przeszukiwanie i korelację w czasie.
Źródła metryk stanowią różnorodne eksportery, które zostały rozmieszczone w odpowiednich lokalizacjach logicznych systemu. W celu monitorowania podstawowych zasobów infrastrukturalnych, takich jak użycie procesora, pamięci RAM, przestrzeni dyskowej czy obciążenie systemu operacyjnego, zastosowano komponent Node Exporter. Ten eksportuje metryki systemowe z poziomu hosta, na którym uruchomione są kontenery, i pozwala na identyfikację ewentualnych wąskich gardeł na poziomie fizycznym.
Dla kontenerów FastAPI, które odpowiadają za przetwarzanie logiki biznesowej, zaimplementowano odpowiednie endpointy z metrykami zgodnymi z formatem Prometheus. Te metryki mogą zawierać informacje o czasie odpowiedzi, liczbie obsłużonych żądań, kodach statusu HTTP, a także wykorzystaniu zasobów systemowych przez daną usługę. Takie podejście umożliwia szczegółową obserwację kondycji mikroserwisów i szybką detekcję anomalii w ich działaniu.
Aby zapewnić monitoring warstwy pośredniej, bramy API Tyk, wykorzystano narzędzie Tyk Pump, które pełni rolę eksportera metryk operacyjnych gromadzonych przez Tyk Gateway. Zawiera metryki dotyczące liczby żądań, przepustowości, opóźnień oraz błędów, co jest kluczowe z punktu widzenia bezpieczeństwa i kontroli dostępu.
W celu monitorowania systemu kolejkowania wiadomości Apache Kafka zastosowano dedykowany Kafka Exporter, który umożliwia zbieranie danych o liczbie komunikatów w poszczególnych tematach, opóźnieniach konsumentów, wskaźnikach błędów oraz czasie przetwarzania. Dzięki temu możliwa jest identyfikacja przeciążeń lub problemów z przetwarzaniem zdarzeń w czasie rzeczywistym, co stanowi podstawę dla optymalizacji systemu opartego na zdarzeniach.
W przypadku warstwy bazodanowej zastosowano osobny PostgreSQL Exporter, który umożliwia zbieranie metryk związanych z wydajnością zapytań SQL, liczbą połączeń, czasem odpowiedzi, zużyciem zasobów oraz stanem indeksów i transakcji. Analogiczne metryki mogą być również gromadzone z obiektu MinIO, który eksponuje własne dane diagnostyczne umożliwiające ocenę czasu odpowiedzi, dostępności zasobów oraz liczby zapytań.
Zebrane przez Prometheus dane są następnie wizualizowane w interfejsie użytkownika systemu Grafana, który umożliwia tworzenie dynamicznych dashboardów, wykresów i alertów. Grafana działa jako frontend do danych gromadzonych przez Prometheus, oferując rozbudowany język zapytań PromQL oraz mechanizmy uwierzytelniania i kontroli dostępu do paneli wizualizacyjnych. Dzięki integracji z Prometheus możliwe jest definiowanie reguł alertowych, które w przypadku wykrycia przekroczenia określonych progów mogą uruchamiać powiadomienia e-mailowe, webhooki, bądź wysyłać komunikaty do systemów zewnętrznych, takich jak Slack czy PagerDuty.
Warstwa monitoringu została osadzona w osobnej domenie logicznej, co pozwala na jej niezależne zarządzanie i skalowanie, a także zapewnia izolację od krytycznej logiki biznesowej systemu. Taka separacja ułatwia również integrację z zewnętrznymi systemami nadzoru infrastruktury oraz pozwala na centralizację logowania i alertowania w większych środowiskach produkcyjnych.