Komponent do śledzenia danych i zdarzeń

Rozpoczęliśmy projekt od stworzenia mapy historii, aby:

• Zdefiniować kluczowe komponenty i funkcje Trackera.
• Zidentyfikować i rozwiązać główne wyzwania techniczne, takie jak wydajność, prędkość i skalowalność.
• Zdecydować, jakie informacje powinny być zbierane i w jaki sposób. Zdefiniowaliśmy wymagania funkcjonalne.

Na podstawie wyników story mappingu stworzyliśmy listę wymagań funkcjonalnych dla naszego narzędzia.

Tracker musi:

• Obsługiwać wiele rodzajów żądań (wyświetleń, kliknięć, konwersji itp.).
• Przetwarzać żądania i generować zdarzenia z odpowiednimi wymiarami i metrykami.
• Pozwalać na konfigurowanie typów żądań i przetwarzanie zdarzeń.
• Rozszerzać swoje podstawowe funkcje za pomocą wtyczek poprzez udostępnianie swojego interfejsu API.
• Wystawiać generowane zdarzenia do określonych kolektorów (wtyczek) i pozwalać na ich przypisanie do konkretnych rodzajów zdarzeń poprzez konfigurację.
• Obejmuje wbudowane kolektory dzienników i kolejek.
• Obejmuje wbudowaną wtyczkę dla naszego komponentu zarządzania budżetem, ad bankera.
• Obsługuje przekierowania żądań.

Wymagania niefunkcjonalne projektu nie są związane z budowaniem działającego produktu, ale z wydajnością, skalowalnością, bezpieczeństwem, dostawą i interoperacyjnością Trackera.

Zidentyfikowaliśmy następujące wymagania niefunkcjonalne:

• Wysoka dostępność (99,999%).
• Wysoka liczba requestów na sekundę (2000 żądań/s).
• Niska latencja przetwarzania żądań (średnio 15 ms).
• Bezpieczeństwo
  • Prywatność – np. zapewnienie, że nie ujawniamy danych osobowych osobom trzecim, gdy musimy je udostępnić innym komponentom.
  • Dostępność – zapewnienie, że platforma nie będzie podatna na ataki typu DDoS.
• Możliwość wdrożenia w AWS, GCP i Azure.
• Możliwość integracji z customowymi wtyczkami.
• Możliwość integracji z innymi komponentami DSP, takimi jak ad bankier.
• Skalowalność platformy – tracker musi być w stanie obsługiwać zwiększający się ruch na zdarzeniach.
• Idempotentność – przetwarzanie tych samych logów wiele razy w przypadku błędów lub tymczasowej niedostępności.

Wybraliśmy architekturę i stos technologiczny dla Trackera poprzez:

• Badanie narzędzi do testowania wydajności języków programowania.
• Porównywanie różnych tech stacków.

Główne metryki, które chcieliśmy przetestować, to:

• Latencja żądań
• Żądania na sekundę
• Stosunek błędów
• Percentyle opóźnień

Porównanie tech stacku

Zdecydowaliśmy się przetestować następujące języki programowania i technologie:

• Golang (Go) ze względu na jego rosnącą popularność i nasze doświadczenie z nim.
• Rust, ponieważ inne zespoły programistyczne używały go do budowy trackerów w przeszłości.
• Python, ponieważ często pracujemy z tym językiem.
• OpenResty = Nginx + Lua, ponieważ pozwala nam stworzyć tracker za pomocą tylko serwera HTTP nginx.

Pierwsze testy wydajności przeprowadziliśmy z wszystkimi technologiami, ale później skupiliśmy się na przeprowadzeniu dodatkowych testów za pomocą narzędzi wrk2, gatling i locust.

Wszystkie trzy narzędzia zostały skonfigurowane tak, aby umożliwić maksymalną elastyczność.

Wyniki i wybrany język programowania

Dwa najlepiej działające języki programowania to Nginx + Lua i Golang, i mimo że miały podobne wyniki we wszystkich narzędziach do testowania wydajności, wybraliśmy Golang ze względu na obecne potrzeby rynku i jego popularność.

Scoping MVP zajął 1 sprint (2 tygodnie).

Po zakończeniu scopingu MVP i wybraniu architektury oraz tech stacku, rozpoczęliśmy budowanie MVP trackera.

Zbudowaliśmy trackera w 5 sprintach (10 tygodni).

Oto co działo się po kolei.

Sprint 1

W tym sprincie:

• Wdrożyliśmy najważniejszą funkcjonalność.
• Skonfigurowaliśmy typy zdarzeń.
• Utworzyliśmy benchmarki jako continuus integration (CI).
• Wygenerowaliśmy benchmarki w formie wizualnej.

Sprint 2

W tym sprincie:

• Utworzyliśmy i przetestowaliśmy przekierowania żądań.
• Przetestowaliśmy trackera.

Sprint 3

W tym sprincie:

• Zbudowaliśmy wtyczkę do komponentu przechowywania logów.
• Poprawiliśmy konfiguracje dla tworzenia dowolnych ścieżek śledzenia.
• Stworzyliśmy dokumentację trackera.

Sprint 4

W tym sprincie:

• Stworzyliśmy wtyczkę dla ad bankiera (komponent zarządzania budżetem).
• Skonfigurowaliśmy event extraction.
• Przeprowadziliśmy testy end-to-end.

Sprint 5

W tym sprincie:

• Utworzyliśmy dokumentację generowaną automatycznie.
• Stworzyliśmy krótki przewodnik po trackerze.
• Zbudowaliśmy Docker images i wypchnęliśmy je do wewnętrznego rejestru.

Tracker został zaprojektowany w celu:

• Przyspieszenia wydewelopowania customowej platformy AdTech lub MarTech.
• Rozszerzenia funkcjonalności istniejących platform AdTech lub MarTech o możliwość zbierania danych.