Dzmitry Lazerka, współzałożyciel VictoriaMetrics – seria wywiadów

Dzmitry Lazerka, współzałożyciel VictoriaMetrics jest doświadczonym inżynierem oprogramowania i liderem technologicznym z głęboką wiedzą w dziedzinie uczenia maszynowego, systemów danych na dużą skalę, obserwowalności i infrastruktury. Przed współzałożeniem VictoriaMetrics w 2018 roku pracował jako inżynier uczenia maszynowego w dziale pojazdów autonomicznych Level 5 firmy Lyft, gdzie pomagał opracowywać systemy rozpoznawania i analizowania rzeczywistych scenariuszy jazdy. Wcześniej prowadził projekty związane z uczeniem maszynowym i infrastrukturą danych w Spire Global, był współzałożycielem technicznym w Bellgram oraz pracował nad systemami danych i analityki w Duetto Research i Google poprzez EPAM Systems. W trakcie swojej kariery Lazerka budował i prowadził projekty obejmujące autonomiczną jazdę, prognozowanie morskim, wyszukiwanie, analitykę, przetwarzanie rozproszonych danych oraz wysoce skalowalne systemy zaplecza.

VictoriaMetrics to firma open‑source zajmująca się obserwowalnością, tworząca narzędzia do zbierania, przechowywania, zapytań i analizowania dużych wolumenów danych operacyjnych. Jej technologia rozpoczęła się od VictoriaMetrics, wysokowydajnej bazy danych szeregów czasowych i rozwiązania monitorującego zaprojektowanego pod kątem skalowalności, szybkich zapytań, efektywnego przechowywania i niskiego narzutu operacyjnego, a od tego czasu rozrosła się do szerszego stosu obserwowalności obejmującego metryki, logi i rozproszone ślady dzięki produktom VictoriaMetrics, VictoriaLogs i VictoriaTraces. Firma oferuje także wdrożenia enterprise oraz w pełni zarządzane w chmurze, a także możliwości wykrywania anomalii wykorzystujące uczenie maszynowe do danych szeregów czasowych. Jej platforma obsługuje technologie takie jak OpenTelemetry, przepływy kompatybilne z Prometheus, Grafana i Kubernetes, dając organizacjom elastyczność integracji VictoriaMetrics z istniejącymi środowiskami obserwowalności.

Przed współzałożeniem VictoriaMetrics pracowałeś nad systemami danych na dużą skalę, analizą i uczeniem maszynowym w Google, Spire Global, dziale pojazdów autonomicznych Lyft oraz innych startupach. Co ostatecznie skłoniło Cię do założenia VictoriaMetrics i które problemy z tych wcześniejszych ról przekonały Cię, że monitorowanie i obserwowalność wymagają zasadniczo innego podejścia?

Spędziłem karierę pracując z dużymi ilościami danych. W Google, Spire, Lyft i innych firmach szybko uczysz się, że coś, co działa dobrze na jednej skali, może stać się kosztowne lub trudne w eksploatacji na innej skali. Monitorowanie ma dokładnie ten problem.

W miarę rozwoju infrastruktury tworzysz więcej metryk. Dodajesz kolejne usługi, instancje i etykiety, aż nagle sam system monitorujący potrzebuje znaczącej ilości infrastruktury, co nigdy nie miało dla nas sensu. System zaprojektowany do monitorowania środowiska produkcyjnego nie powinien stać się bardziej skomplikowany i kosztowny w eksploatacji.

To właśnie zauważyli moi współzałożyciele Aliaksandr Valialkin i Roman Khavronenko. Mieli doświadczenie w obsłudze Prometheus i napotykali ograniczenia pamięci. Dodanie systemów takich jak Thanos rozwiązało niektóre problemy skalowalności, ale wprowadziło także więcej komponentów i większą złożoność operacyjną. Natomiast w przypadku InfluxDB zobaczyliśmy, jak zmiana licencji może wpłynąć na decyzje inżynieryjne po tym, jak zespoły już zainwestowały w tę technologię.

Dlatego pomysł stojący za VictoriaMetrics był praktyczny: Czy możemy zbudować bazę danych szeregów czasowych, która wykonuje tę samą pracę przy znacznie mniejszym zużyciu zasobów i jest prostsza w eksploatacji?

Nie zaczęliśmy od planu stworzenia dużej firmy zajmującej się obserwowalnością. Zaczęliśmy od rozwiązania problemu inżynieryjnego.

Uczynienie go otwartym źródłem było tego częścią. Inżynierowie mogli pobrać VictoriaMetrics, uruchomić na nim rzeczywiste obciążenia produkcyjne i sami porównać wyniki. Nie musieliśmy im mówić, że jest szybszy lub bardziej wydajny. Mogli to zmierzyć.

To najlepszy sposób budowania oprogramowania infrastrukturalnego. Jeśli technologia jest dobra, inżynierowie powinni być w stanie udowodnić to samodzielnie.

Koszty obserwowalności mogą cicho stać się znaczną częścią rachunku za chmurę firmy. Gdzie te koszty zazwyczaj wymykają się kontroli i jakie decyzje architektoniczne lub zakupowe najczęściej popełniają zespoły inżynieryjne?

Najpierw przyjrzałbym się kardynalności.

Załóżmy, że zaczynasz od rozsądnej metryki, a następnie dodajesz etykietę z możliwymi wartościami. Nagle jedna metryka przekształca się w tysiące lub miliony unikalnych szeregów czasowych. System ma teraz więcej danych do pobrania, indeksowania, przechowywania i zapytań, co skutkuje większym zużyciem CPU, pamięci i przestrzeni dyskowej.

Trudna część polega na tym, że nie dzieje się to z powodu jednej złej decyzji. Zachodzi stopniowo. Dodajesz kolejne usługi, podsy K8s, klientów i etykiety, a koszt się mnoży.

Drugim problemem jest przechowywanie wszystkiego w tej samej rozdzielczości przez ten sam okres czasu. Nie wszystkie dane obserwowalności mają taką samą wartość. Metryki potrzebne do alarmu lub SLO różnią się od wysokowolumenowej telemetrii diagnostycznej, którą możesz przeglądać jednorazowo podczas incydentu.

Jeśli traktujesz wszystkie te dane tak samo, kończysz płacąc premium za infrastrukturę lub usługi SaaS za dane, które tego nie wymagają.

Dlatego niektóre firmy podchodzą do obserwowalności jako problemu zakupowego, pytając, która platforma jest najłatwiejsza do wdrożenia dziś. Zadaję pytania typu: „Co się stanie, gdy ilość telemetrii wzrośnie dziesięciokrotnie? Co się stanie z kardynalnością? Co przechowujemy? Jak długo? I co się stanie z kosztami?”

Istnieją rozwiązania inżynieryjne tych problemów. Na przykład przy użyciu agregacji strumieniowej możesz agregować metryki zanim trafią do przechowywania, zamiast przechowywać każdy surowy szereg czasowy i agregować go później. Możesz oddzielić obciążenia o wysokiej kardynalności od monitoringu krytycznego dla biznesu. Możesz także stosować różne polityki retencji i rozdzielczości w zależności od wartości danych.

Celem nie jest zbieranie jak najmniej telemetrii. Potrzebujesz wystarczającej ilości informacji, aby zrozumieć, co robią Twoje systemy.

Celem jest unikanie wydatkowania zasobów na zbieranie, przetwarzanie i przechowywanie danych w sposób, który nie przynosi dodatkowej wartości.

Obserwowalność jest systemem inżynieryjnym. Jej koszt powinien być również zaprojektowany.

Grammarly twierdzi, że ich proof‑of‑concept z VictoriaMetrics przełożył się na 10‑krotnie niższy rachunek AWS. Kiedy firmy osiągają oszczędności w tej skali, co tak naprawdę zmienia się pod maską: kompresja danych, wymagania obliczeniowe, architektura przechowywania, złożoność operacyjna czy ich kombinacja?

To kombinacja, ale to kompresja i ślad zasobowy wykonują większość pracy. VictoriaMetrics używa specjalnie zaprojektowanej kompresji dla danych szeregów czasowych, więc te same metryki zajmują ułamek przestrzeni dyskowej w porównaniu z bazą danych ogólnego przeznaczenia. Dodatkowo działamy cztery‑pięć razy lżej pod względem pamięci RAM niż Prometheus przy równoważnych szybkościach ingestu i do 10‑krotnie lżej pod względem dysku. Kiedy Grammarly przeprowadzili swój proof‑of‑concept, odzwierciedliło to się bezpośrednio w ich rachunku AWS, ponieważ nie tylko przechowywali mniej danych; uruchamiali mniej i mniejsze instancje, aby to zrobić.

Czynnik złożoności operacyjnej również ma znaczenie, ale jest bardziej pośredni. Wiele zespołów wyceniających koszty obserwowalności patrzy jedynie na pozycje związane z przechowywaniem i obliczeniami, pomijając godziny inżynieryjne spędzone na obsłudze pięciokomponentowego stosu Thanos w porównaniu do pojedynczego binarnego rozwiązania. To prawdziwe pieniądze; po prostu trudniej jest podać konkretną liczbę.

Prometheus stał się podstawą monitorowania cloud‑native, jednak niektóre organizacje w końcu napotykają ograniczenia skalowalności lub operacyjne. Co zazwyczaj skłania firmę do poszukiwania alternatyw poza tradycyjnym wdrożeniem Prometheus i kiedy VictoriaMetrics staje się logiczną alternatywą?

Prometheus jest doskonały w tym, do czego został stworzony: w jednowęzłowym silniku zbierania danych i alertów. Zespoły zazwyczaj napotykają ograniczenia na dwa sposoby: albo ich kardynalność rośnie ponad to, co pojedyncza instancja Prometheus może pomieścić w pamięci, albo potrzebują długoterminowego przechowywania i globalnego zapytania w wielu klastrach, do czego Prometheus nigdy nie był przeznaczony. Wtedy ludzie dodają Thanos lub Cortex, co zwykle jest początkiem problemów operacyjnych. Przechodzisz od uruchamiania jednego binarnego pliku do obsługi rozproszonego systemu z kompresorem, zapytującym, bramą magazynu i wieloma innymi komponentami, które mogą zepsuć się o 3 nad ranem.

VictoriaMetrics staje się logicznym kolejnym krokiem, ponieważ jest zamiennikiem typu drop‑in, a nie przebudową. Zespoły kierują swoją istniejącą konfigurację zbierania Prometheus do VictoriaMetrics i zachowują wszystkie pulpity Grafana, alerty oraz reguły nagrywania, które już stworzyły. Migracja to zmiana konfiguracji, a nie projekt, i uzyskują skalowalność bez dodawania pięciu nowych komponentów do obsługi.

Obserwujemy, że zespoły inżynierskie przemyślają, czy potrzebują dużych, w pełni zarządzanych platform obserwowalności, czy też mogą zbudować bardziej efektywne stosy z komponentów open‑source. Czy postrzegasz to jako szerszą zmianę strukturalną na rynku obserwowalności i jak duży nacisk open source wywiera na tradycyjne modele cenowe?

To strukturalne, a nie tymczasowa reakcja na słaby rok budżetowy. Dostawcy rozwiązań obserwowalności tradycyjnie wyceniali się albo według wolumenu danych, albo liczby hostów, a taki model działa na niekorzyść klienta w miarę rozwoju jego działalności. Im bardziej firma odnosi sukces, tym więcej płaci, a cena nie ma rzeczywistego związku z dostarczoną wartością. Zespoły inżynierskie zaczęły same liczyć, zdając sobie sprawę, że samodzielnie hostowany, wydajny stos open‑source całkowicie zmienia tę równanie. Dzieje się tak, ponieważ koszt skaluje się wraz z faktycznie uruchomioną infrastrukturą, a nie według formuły pomiarowej kontrolowanej przez dostawcę.

To wywiera realny nacisk na istniejące modele cenowe. Kiedy zespół może skierować swoją obecną konfigurację zbierania do alternatywy open‑source i obniżyć rachunek o 60‑80 % bez utraty funkcjonalności, nie jest to trudna rozmowa wewnętrzna. Dostawcy wciąż pobierający opłaty za hosta lub niestandardową metrykę będą dalej wyssać klientów, którzy nie przeprowadzą takiej kalkulacji.

Infrastruktura AI wprowadza niezwykle kosztowny nowy zasób do równania: GPU. Co firmy prowadzące trening lub inferencję AI powinny monitorować oprócz podstawowego wykorzystania GPU i gdzie lepsza obserwowalność może przełożyć się bezpośrednio na niższe koszty infrastruktury AI?

Sam wskaźnik wykorzystania GPU nie dostarcza wystarczających informacji.

Na pulpicie możesz zobaczyć 90 % wykorzystania i założyć, że wszystko jest w porządku. Ale to, co naprawdę chcesz wiedzieć, to: Co robi GPU?

Musisz zajrzeć głębiej. Które jądra CUDA są uruchomione? Jak przydzielana jest pamięć GPU? Ile czasu jest poświęcane na przenoszenie pamięci zamiast na obliczenia? Czy obciążenie korzysta z Tensor Cores, gdy powinno? Czy GPU jest faktycznie wąskim gardłem, czy czeka na dane z innego miejsca?

To ważne pytania, ponieważ GPU są kosztowne. Mała nieefektywność powtarzana na setkach lub tysiącach GPU przekształca się w bardzo dużą kwotę pieniędzy.

Na przykład, jeśli GPU czekają, ponieważ pipeline danych nie jest w stanie ich dostarczyć wystarczająco szybko, zakup większej liczby GPU nie rozwiąże problemu. Trzeba znaleźć wąskie gardło. To samo dotyczy pamięci. Jeśli obciążenia przydzielają pamięć nieefektywnie, lepsza widoczność może pomóc inżynierom dostosować rozmiary batchy lub uruchomić więcej obciążeń na tym samym sprzęcie.

Tutaj obserwowalność staje się interesująca w kontekście infrastruktury AI. Nie chodzi tylko o wykrycie, że coś jest zepsute. Może wskazać, gdzie marnujesz moc obliczeniową.

Istnieje również problem obserwowalności spowodowany całym tym monitorowaniem. GPU mogą generować dużą ilość szczegółowej, wysokokardynalnej telemetrii. Jeśli zbierzesz wszystko i wyślesz bezpośrednio do drogiej platformy SaaS, możesz obniżyć koszty GPU, a następnie przeznaczyć część oszczędności na przechowywanie danych monitorujących. Jednak nie jest to dobre optymalizowanie.

Dzięki OpenTelemetry i projektom takim jak OpenLIT możemy uzyskać znacznie głębszą widoczność obciążeń GPU. Następnie, przy użyciu VictoriaMetrics, możemy agregować dane, usuwać nieprzydatne wymiary i efektywnie przechowywać informacje, których inżynierowie naprawdę potrzebują.

Użyteczne pytanie nie brzmi: „Jak bardzo wykorzystane są moje GPU?”

Brzmi: „Jaką użyteczną pracę otrzymuję od GPU, za które płacę?”

Gdy będziesz w stanie na to odpowiedzieć, możesz zacząć podejmować lepsze decyzje inżynieryjne i kosztowe.

Agenci AI stwarzają zupełnie inne wyzwania obserwowalności niż tradycyjne oprogramowanie, ponieważ pojedyncze żądanie może wywołać wywołania modeli, użycie narzędzi, zapytania do baz wektorowych, przekazania i potencjalnie długie łańcuchy autonomicznych działań. Jak obserwowalność musi się rozwijać, gdy aplikacje korporacyjne stają się coraz bardziej agentowe?

Tradycyjna obserwowalność zakłada, że żądanie podąża dość przewidywalną ścieżką przez infrastrukturę. Obciążenia agentowe nie działają w ten sposób. Jeden agent może wywołać model, potem narzędzie, potem kolejny model i trzykrotnie ponowić próbę, zanim zwróci jakikolwiek wynik. Każdy z tych kroków wymaga własnej widoczności.

Tryby awarii są również inne. Tradycyjna usługa albo odpowiada prawidłowo, albo nie. Agent może odpowiedzieć sukcesem, a mimo to być niepoprawny, wolny lub kosztowny, i nic z tego nie pojawia się jako typowy błąd na pulpicie przeznaczonym do monitorowania dostępności.

Część, która zaskakuje zespoły, to kardynalność. Jeden przepływ pracy agenta może generować metryki powiązane z konkretnym użytkownikiem, zapytaniem i wywołaniem narzędzia, a ich ilość szybko rośnie, szczególnie przy pętlach rekurencyjnych, w których planista wielokrotnie wywołuje to samo narzędzie. Każdy system przeznaczony do obserwacji obciążeń agentowych musi obsłużyć tę skalę, nie dopuszczając do pionowego wzrostu kosztów, co jest dokładnie problemem, który rozwiązujemy. Metryki, logi i ślady wciąż są właściwymi elementami budulcowymi. To, co musi się zmienić, to wolumen i model kosztowy pod nimi.

VictoriaMetrics również stosuje uczenie maszynowe i workflowy wspomagane AI do wykrywania anomalii. Gdzie Twoim zdaniem AI może naprawdę usprawnić monitorowanie i reagowanie na incydenty dziś, a gdzie ludzka ocena wciąż jest trudna do zastąpienia?

Ważne jest, aby człowiek pozostał w pętli przy generowaniu pomysłów, kierowaniu implementacją i weryfikacji wyników. Innymi słowy, nic tak naprawdę nie zmieniło się w porównaniu do tradycyjnego workflow. Zmieniły się jedynie możliwości generowania rozwiązań, które zostały wzmocnione. Każdy może teraz tworzyć oprogramowanie, ale nie powinno to obniżać kryteriów akceptacji. Powinno je znacząco podnieść.

Gdzie AI naprawdę pomaga, to w wyłanianiu tego, co człowiek przegapiłby w szumie, takich jak odchylenia i trendy, które nie uruchamiają ręcznego progu. W VictoriaMetrics mamy prostą wewnętrzną politykę AI: Pracownicy mogą automatyzować swoje workflow w dowolny sposób, ale pozostają odpowiedzialni za ostateczny rezultat. To mniej więcej ten sam standard, jaki zastosowalibyśmy do wykrywania anomalii w środowisku produkcyjnym klienta. Model może to oznaczyć, ale człowiek musi nadal zdecydować, co to oznacza i co z tym zrobić.

VictoriaMetrics pozostała otwarto‑źródłowa i przyjęła podejście samofinansowane, finansowane przez klientów, zamiast tradycyjnego modelu startupu infrastrukturalnego wspieranego przez venture capital. Jak to wpłynęło na sposób, w jaki budujesz produkt, go wyceniasz i decydujesz, które technologie pozostają otwarto‑źródłowe?

Bycie samofinansowanym zmienia strukturę zachęt bardziej, niż ludzie się spodziewają. Bez zarządu, który wymagałby od nas osiągnięcia określonej liczby ARR w danym kwartale, nie musieliśmy podejmować kompromisów, które zwykle wynikają z takiej presji, takich jak osłabianie wersji open‑source, aby zmusić ludzi do płatnej warstwy, czy zmiana licencji, jak zrobiły InfluxDB lub HashiCorp, gdy musiały chronić przychody przed dostawcami chmury. VictoriaMetrics OSS jest dziś na licencji Apache 2.0 i nie planujemy tego zmieniać.

Sposób, w jaki decydujemy, co pozostaje open source, jest prosty: rdzeń silnika, czyli to, czego inżynierowie potrzebują, by zaufać nam w kwestii swoich danych produkcyjnych, pozostaje otwarty. Pobieramy opłaty za to, czego firma potrzebuje, gdy działa w skali i potrzebuje kogoś odpowiedzialnego: wielodzierżawczość, uwierzytelnianie korporacyjne, wsparcie w zakresie zgodności, SLA dotyczące CVE oraz bezpośredni dostęp do inżynierów, którzy napisali kod, zamiast kolejki wsparcia. Finansowanie przez klientów oznacza również, że roadmapa jest kształtowana przez to, z czym ludzie naprawdę spotykają się w produkcji, a nie przez to, co można sfinansować w prezentacji inwestorskiej.

W miarę jak metryki, logi, ślady, telemetryka aplikacji AI, monitorowanie GPU i automatyczne wykrywanie anomalii coraz bardziej się zbliżają, jak myślisz, jak będzie wyglądał stos obserwowalności w ciągu najbliższych kilku lat i czego zespoły inżynierskie będą oczekiwać od platform, które chcą pozostać istotne?

Stos zbliża się operacyjnie zanim połączy się w jeden produkt i to rozróżnienie ma znaczenie. Większość zespołów nie chce jednej monolitycznej platformy z jedynym interfejsem, który wszystko scala. Chcą metryk, logów i śladów działających na jednym modelu operacyjnym, u jednego dostawcy i na jednej licencji, bez konieczności rezygnacji z możliwości uruchamiania każdego sygnału niezależnie, jeśli tak wymaga dany zespół. To jest kierunek, w którym rozwija się VictoriaMetrics. Nie staramy się wpakować wszystkiego do jednego pliku binarnego. Staramy się zapewnić, aby trzy sygnały korzystały z tego samego silnika i tych samych cech wydajności, tak aby dodanie drugiego lub trzeciego sygnału nie oznaczało przyjęcia drugiego lub trzeciego operacyjnego problemu.

Platformy, które pozostają istotne, to te, które potrafią wchłonąć telemetrykę AI i monitorowanie GPU do tego samego modelu bez łamania krzywej kosztów. Obciążenia AI generują telemetrykę w takiej objętości, na jaką tradycyjne rozliczanie per‑metryka lub per‑host nie było przygotowane. Zespoły albo przestają zbierać potrzebne dane, albo ich rachunek za obserwowalność rośnie szybciej niż inwestycja w AI, którą ma monitorować. Zespoły inżynierskie będą oczekiwać, że platformy poradzą sobie z tą objętością tak, jak oczekują, że każda infrastruktura będzie się skalować, bez konieczności przeprojektowywania czy renegocjacji przy każdym wzroście obciążenia.

Dziękujemy za świetny wywiad, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić VictoriaMetrics.