Dzmitry Lazerka, VictoriaMetricsin yhteisperustaja – Haastattelusarja

Dzmitry Lazerka, VictoriaMetricsin yhteisperustaja on kokenut ohjelmistosuunnittelija ja teknologiaveto, jolla on syvä asiantuntemus koneoppimisessa, suurten mittakaavojen tietojärjestelmissä, observabiliteetissa ja infrastruktuurissa. Ennen VictoriaMetricsin perustamista vuonna 2018 hän työskenteli koneoppimisen insinöörinä Lyftin Level 5 -autonomisen ajoneuvon osastolla, jossa hän auttoi kehittämään järjestelmiä todellisten ajo-tilanteiden tunnistamiseen ja analysointiin. Aikaisemmin hän johti koneoppimis- ja data‑infrastruktuuriprojekteja Spire Globalissa, toimi insinööriperustajana Bellgramissa ja työskenteli data‑ ja analytiikkajärjestelmien parissa Duetto Researchissa ja Googlessa EPAM Systemsin kautta. Uransa aikana Lazerka on rakentanut ja johtanut projekteja, jotka kattavat autonomisen ajamisen, merelliset ennusteet, haun, analytiikan, hajautetun tiedonkäsittelyn ja erittäin skaalautuvat taustajärjestelmät.

VictoriaMetrics on avoimen lähdekoodin observabiliteettiyritys, joka rakentaa työkaluja operatiivisen datan keräämiseen, tallentamiseen, kyselyyn ja analysointiin suurina määriä. Sen teknologia alkoi VictoriaMetricsista, korkeasuorituskykyisestä aikasarjadatabasesta ja valvontaratkaisusta, joka on suunniteltu skaalautuvuuteen, nopeisiin kyselyihin, tehokkaaseen tallennukseen ja alhaiseen operatiiviseen kuormitukseen, ja on sittemmin laajentunut laajempaan observabiliteettipinoon, joka kattaa mittarit, lokit ja hajautetut jäljet VictoriaMetricsin, VictoriaLogsin ja VictoriaTracesin kautta. Yritys tarjoaa myös yritystason ja täysin hallinnoituja pilviympäristöjä sekä poikkeavuuksien havaitsemisominaisuuksia, jotka soveltavat koneoppimista aikasarjadataan. Sen alusta tukee teknologioita kuten OpenTelemetry, Prometheus-yhteensopivat työnkulut, Grafana ja Kubernetes, antaen organisaatioille joustavuutta integroida VictoriaMetrics olemassa oleviin observabiliteettialustoihin.

Ennen VictoriaMetricsin perustamista työskentelit suurten mittakaavojen data-, analytiikka- ja koneoppimisjärjestelmien parissa Googlella, Spire Globalilla, Lyftin autonomisen ajoneuvon osastolla ja muissa startup-yrityksissä. Mikä lopulta sai sinut perustamaan VictoriaMetricsin, ja mitkä näiden aikaisempien roolien ongelmat vakuuttivat sinut siitä, että valvonta ja observabiliteetti vaativat perinpohjaisesti erilaisen lähestymistavan?

Olen urani viettänyt työskennellen suurten tietomäärien parissa. Googlessa, Spiressä, Lyftissä ja muissa yrityksissä oppii nopeasti, että jokin, mikä toimii hyvin yhdessä mittakaavassa, voi toisessa mittakaavassa muuttua kalliiksi tai vaikeaksi ylläpitää. Valvonnalla on juuri tämä ongelma.

Kun infrastruktuuri kasvaa, luot enemmän mittareita. Lisäät enemmän palveluita, instansseja ja tunnisteita, kunnes yhtäkkiä itse valvontajärjestelmä tarvitsee merkittävän määrän infrastruktuuria, mikä ei koskaan ollut meille järkevää. Tuotantoympäristösi valvomiseen suunniteltu järjestelmä ei saa muuttua monimutkaiseksi ja kalliiksi ylläpitää.

Tämä oli se, mitä kollegani perustajajäsenet Aliaksandr Valialkin ja Roman Khavronenko näkivät suoraan. Heillä oli kokemusta Prometheuksen käytöstä ja muistirajoitteiden kohtaamisesta. Järjestelmien kuten Thanos lisääminen ratkaisi joitakin skaalautumisongelmia, mutta toi mukanaan myös lisää komponentteja ja operatiivista monimutkaisuutta. InfluxDB:n kanssa näimme, miten lisenssimuutos voi vaikuttaa insinööripäätöksiin sen jälkeen, kun tiimit ovat jo investoineet teknologiaan.

Joten VictoriaMetricsin taustalla oleva idea oli käytännöllinen: Voimmeko rakentaa aikasarjadatabasen, joka tekee saman työn merkittävästi vähemmillä resursseilla ja on yksinkertaisempi ylläpitää?

Emme aloittaneet suunnitelmalla rakentaa suurta observabiliteettiyritystä. Aloitimme ratkaisemalla insinööriongelman.

Avoimeksi lähdekoodiksi tekeminen oli osa sitä. Insinöörit voivat ladata VictoriaMetricsin, asettaa siihen todellisia tuotantokuormia ja vertailla tuloksia itse. Meidän ei tarvinnut kertoa heille, että se on nopeampi tai tehokkaampi. He voivat mitata sen.

Tämä on paras tapa rakentaa infrastruktuuriohjelmistoja. Jos teknologia on hyvä, insinöörien tulisi voida todistaa se itse.

Observabiliteettikustannukset voivat hiljaisesti kasvaa merkittäväksi osaksi yrityksen pilvilaskutusta. Missä nämä kustannukset tyypillisesti karautuvat hallitsemattomiksi, ja mitkä arkkitehtuuri- tai hankintapäätökset insinööritiimit useimmiten tekevät väärin?

Katsoisin ensin kardinaalisuutta.

Sanotaan, että aloitat kohtuullisella mittarilla, ja lisäät sen jälkeen tunnisteen, jossa on mahdollisia arvoja. Yhtäkkiä yksi mittari muuttuu tuhansiksi tai miljooniksi ainutlaatuisiksi aikasarjoiksi. Järjestelmällä on nyt enemmän dataa otettavanaan, indeksoitavanaan, tallennettavanaan ja kyseltävänä, mikä johtaa suurempaan CPU‑, muisti‑ ja tallennuskapasiteettiin.

Vaikea osa on se, että tämä ei tapahdu yhden huonon päätöksen takia. Se tapahtuu vähitellen. Lisää palveluita, K8s‑podseja, asiakkaita ja tunnisteita, ja kustannus moninkertaistuu.

Toinen ongelma on kaiken tallentaminen samassa resoluutiossa samaksi ajaksi. Kaikilla observabiliteettidatalla ei ole samaa arvoa. Mittarit, joita tarvitset hälytykseen tai SLO:hon, eroavat suurta volyymia omaavasta diagnostiikkatelemetriasta, jota saatat tarkastella kerran tapahtuman aikana.

Jos kohtelet kaikkea dataa samalla tavalla, päädyt maksamaan premium‑infrastruktuuri- tai SaaS-hintoja datasta, joka ei sitä vaadi.

Tämän vuoksi jotkut yritykset lähestyvät observabiliteettia hankintakysymyksenä, kysyen, mikä alusta on helpoin ottaa käyttöön tänään. Kysyn esimerkiksi: “Mitä tapahtuu, kun telemetrian määrä kasvaa kymmenkerraksi? Mitä tapahtuu kardinaalisuudelle? Mitä tallennamme? Kuinka pitkään? Ja mitä kustannuksille tapahtuu?”

Näihin ongelmiin on insinööri­ratkaisuja. Esimerkiksi suoratoistoyhteenvedon avulla voit yhdistää mittareita ennen kuin ne saavuttavat tallennuksen, sen sijaan että tallentaisit jokaisen raakan aikasarjan ja yhdistäisit ne myöhemmin. Voit erottaa korkean kardinaalisuuden työkuormat liiketoimintakriittisestä valvonnasta. Voit myös käyttää erilaisia säilytys‑ ja resoluutio­käytäntöjä datan arvon mukaan.

Tavoitteena ei ole kerätä mahdollisimman vähän telemetriaa. Tarvitset riittävästi tietoa ymmärtääksesi, mitä järjestelmäsi tekevät.

Tavoitteena on välttää resurssien käyttöä datan keräämiseen, käsittelyyn ja tallentamiseen tavalla, joka ei tuo lisäarvoa.

Observabiliteetti on insinööri­järjestelmä. Sen kustannuksetkin tulisi suunnitella.

Grammarly on kertonut, että sen proof‑of‑concept VictoriaMetricsin kanssa johti kymmenkertaiseen alenemiseen AWS‑laskussa. Kun yritykset saavuttavat tällaisia säästöjä, mikä oikeastaan muuttuu moottorin alla: datan pakkaus, laskenta‑vaatimukset, tallennusarkkitehtuuri, operatiivinen monimutkaisuus vai näiden tekijöiden yhdistelmä?

Se on yhdistelmä, mutta pakkaus ja resurssijalanjälki tekevät suurimman osan työstä. VictoriaMetrics käyttää aikasarjadatan erityisesti suunniteltua pakkausta, joten samat mittarit vievät murto‑osan levytilasta, jonka ne käyttäisivät yleiskäyttöisessä tietokannassa. Lisäksi käytämme neljä‑viisi kertaa vähemmän RAM-muistia kuin Prometheus vastaavilla sisääntulonopeuksilla, ja jopa kymmenen kertaa vähemmän levytilaa. Kun Grammarly suoritti proof‑of‑conceptin, se näkyi suoraan heidän AWS‑laskussaan, koska he eivät ainoastaan tallentaneet vähemmän dataa; he myös ajoivat vähemmän ja pienempiä instansseja sen tekemiseen.

Operatiivinen monimutkaisuuskin on merkityksellinen, mutta se on epäsuorempaa. Monet tiimit, jotka arvioivat observabiliteettikustannuksia, tarkastelevat vain tallennus‑ ja laskentakustannuksia ja jättävät huomiotta insinööri‑tunnit, jotka kuluu viiden komponentin Thanos‑pinon ylläpitoon verrattuna yhteen binääriin. Se on oikeaa rahaa; sen määrän arvioiminen on vain vaikeampaa.

Prometheus on muodostunut peruspilariksi pilvi‑natiivisessa valvonnassa, mutta jotkut organisaatiot kohtaavat lopulta skaalautuvuus‑ tai operatiivisia rajoituksia. Mikä tyypillisesti saa yrityksen etsimään vaihtoehtoja perinteiselle Prometheus‑asennukselle, ja milloin VictoriaMetricsista tulee looginen vaihtoehto?

Prometheus on erinomainen siinä, mihin se on rakennettu: yksittäisen solmun keräys- ja hälytysmekaniikka. Tiimit yleensä kohtaavat esteen kahdella tavalla: joko niiden kardinaliteetti kasvaa yli sen, mitä yksi Prometheus‑instanssi voi pitää muistissa, tai ne tarvitsevat pitkäaikaista säilytystä ja globaalin kyselyn useiden klustereiden yli, mihin Prometheus ei koskaan suunniteltu. Silloin ihmiset liittävät päälle Thanos‑ tai Cortex‑ratkaisut, ja juuri siellä operatiivinen kipu alkaa. Siirrytään yhdestä binääristä hajautettuun järjestelmään, jossa on kompaktoija, kyselijä, tallennusväylä ja paljon muuta, mikä voi hajota kello kolme aamulla.

VictoriaMetrics on looginen seuraava askel, koska se on suoraan korvattava, ei uudelleensuunnittelu. Tiimit ohjaavat olemassa olevan Prometheus‑keräysasetuksensa VictoriaMetricsiin ja säilyttävät kaikki Grafana‑kojelautat, hälytykset ja tallennussäännöt, jotka he ovat jo rakentaneet. Siirtyminen on vain asetusten muutos, ei projekti, ja he saavat skaalautuvuuden lisäämättä viittä uutta komponenttia käyttöön.

Huomaamme, että insinööritiimit pohtivat uudelleen, tarvitsevatko ne suuria, täysin hallinnoituja observabiliteettialustoja vai voivatko ne rakentaa tehokkaampia pinoja avoimen lähdekoodin komponenteista. Näetkö tämän laajempana rakenteellisena muutoksena observabiliteettimarkkinoilla, ja kuinka paljon paineita avoin lähdekoodi asettaa perinteisille hinnoittelumalleille?

Se on rakenteellista; ei tilapäinen reaktio huonoon budjettivuoteen. Observabiliteettitoimittajat ovat historiallisesti hinnoitelleet joko sisääntulomäärän tai isäntälukumäärän perusteella, ja tämä malli toimii asiakkaan haitaksi liiketoiminnan kasvaessa. Mitä menestyneempi yritys on, sitä enemmän se maksaa, eikä hinnoittelulla ole todellista yhteyttä toimitettuun arvoon. Insinööritiimit ovat alkaneet laskea itse, tajuten, että itseisännöity, tehokas avoimen lähdekoodin pino muuttaa yhtälön täysin. Tämä johtuu siitä, että kustannus skaalautuu todellisesti käytetyn infrastruktuurin mukaan eikä toimittajan hallinnoiman mittauskaavan mukaan.

Tämä asettaa todellista painetta vallitsevalle hinnoittelulle. Kun tiimi voi ohjata olemassa olevan keräysasetuksensa avoimeen vaihtoehtoon ja leikata laskun 60–80 % menettämättä toiminnallisuutta, se ei ole vaikea sisäinen keskustelu. Toimittajat, jotka edelleen veloittavat per isäntä tai mukautettu mittari, jatkavat asiakkaiden haavojen verottamista, jotka eivät tee tätä laskentaa.

AI‑infrastruktuuri tuo yhtälöön epätavallisen kalliin uuden resurssin: GPU:t. Mitä yritysten, jotka suorittavat AI‑koulutusta tai inferenssiä, tulisi valvoa perus‑GPU‑hyötysuhteen lisäksi, ja missä parempi observabiliteetti voi suoraan muuttaa AI‑infrastruktuurin kustannuksia alhaisemmaksi?

Pelkkä GPU‑hyötysuhde ei kerro tarpeeksi.

Voit nähdä 90 %:n hyötysuhteen kojelaudalla ja olettaa kaiken olevan kunnossa. Mutta mitä todella haluat tietää on: mitä GPU tekee?

Sinun täytyy katsoa syvemmin. Mitkä CUDA‑ytimet ovat käynnissä? Miten GPU‑muisti on varattu? Kuinka paljon aikaa kuluu muistin siirtämiseen sen sijaan, että suoritettaisiin laskenta? Käyttääkö työkuorma Tensor‑ytimiä silloin kun sen pitäisi? Onko GPU todella pullonkaula vai odottaako se dataa jostain muualta?

Nämä ovat tärkeitä kysymyksiä, koska GPU:t ovat kalliita. Pieni tehottomuus, joka toistuu sadoissa tai tuhansissa GPU:ssa, muuttuu erittäin suureksi rahasummaksi.

Esimerkiksi, jos GPU:t odottavat, koska dataputki ei pysty syöttämään niitä tarpeeksi nopeasti, lisää GPU:ita ostaminen ei ratkaise ongelmaa. Sinun täytyy löytää pullonkaula. Sama pätee muistiin. Jos työkuormat varaavat muistin tehottomasti, parempi näkyvyys voi auttaa insinöörejä säätämään eräkokoja tai ajamaan enemmän työkuormia samalla laitteistolla.

Tässä observabiliteetti tekee AI‑infrastruktuurista mielenkiintoisen. Kyse ei ole pelkästään siitä, että havaitsee, että jokin on rikki. Se voi kertoa, missä hukkaat laskentatehoa.

Tähän liittyy myös observabiliteettiongelma, jonka kaikki tämä valvonta aiheuttaa. GPU:t voivat tuottaa paljon yksityiskohtaista, korkean kardinaliteetin telemetriaa. Jos keräät kaiken ja lähetät sen suoraan kalliille SaaS‑alustalle, voit vähentää GPU‑kustannuksiasi ja käyttää osan säästöistä valvontadatan tallentamiseen. Mutta se ei ole hyvä optimointi.

OpenTelemetryn ja esimerkiksi OpenLIT‑projektien avulla voimme saada paljon syvempää näkyvyyttä GPU‑työkuormiin. Sitten VictoriaMetricsin avulla voimme aggregoida tiedot, poistaa hyödyttömät dimensiot ja säilyttää tehokkaasti insinööreille todellisesti tarvitsemat tiedot.

Hyödyllinen kysymys ei ole: “Kuinka hyödynnettyjä GPU:ni ovat?”

Se on: “Mitä hyödyllistä työtä saan maksamiltani GPU:ilta?”

Kun pystyt vastaamaan siihen, voit alkaa tehdä parempia insinööri- ja kustannuspäätöksiä.

AI‑agentit luovat hyvin erilaisia observabiliteettihäiriöitä kuin perinteinen ohjelmisto, koska yksi pyyntö voi käynnistää mallikutsuja, työkalun käyttöä, vektoritietokantakyselyitä, siirtoja ja mahdollisesti pitkiä ketjuja autonomisia toimintoja. Miten observabiliteetin tulee kehittyä, kun yrityssovellukset muuttuvat yhä agenttisemmiksi?

Perinteinen observabiliteetti olettaa, että pyyntö kulkee melko ennustettavalla reitillä infrastruktuurissasi. Agenttipohjaiset työkuormat eivät toimi näin. Yksi agentti saattaa kutsua mallia, sitten työkalua, sitten toista mallia ja yrittää uudelleen kolme kertaa ennen kuin se palauttaa mitään. Jokainen näistä vaiheista tarvitsee oman näkyvyytensä.

Epäonnistumistavat ovat myös erilaisia. Perinteinen palvelu joko vastaa oikein tai ei. Agentti voi vastata onnistuneesti, mutta silti olla väärä, hidas tai kallis, eikä mikään tästä näy tyypillisenä virheenä uptime‑kojelaudassa.

Tiimejä yllättävä osa on kardinaliteetti. Yksi agenttityönkulku voi tuottaa mittareita, jotka liittyvät tiettyyn käyttäjään, kehotteeseen ja työkalukutsuun, ja tämä määrä kasvaa nopeasti, erityisesti rekursiokierroksissa, joissa suunnittelija kutsuu jatkuvasti samaa työkalua. Mikä tahansa järjestelmä, jonka tarkoitus on tarkkailla agenttipohjaisia työkuormia, on käsiteltävä tämä mittakaava ilman, että kustannuskäyrä nousee pystysuoraan, mikä on juuri se ongelma, jonka ratkaisemme. Mittarit, lokit ja jäljitykset ovat edelleen oikeita rakennuspalikoita. Muutettava on niiden määrä ja niiden alla oleva kustannusmalli.

VictoriaMetrics on myös soveltanut koneoppimista ja AI‑avusteisia työnkulkuja poikkeavuuksien havaitsemiseen. Missä uskot AI:n voivan aidosti parantaa valvontaa ja tapahtumavastetta tänään, ja missä ihmisen harkintaa on edelleen vaikea korvata?

On tärkeää pitää henkilö mukana ideoiden tuottamisessa, toteutuksen ohjaamisessa ja tulosten vahvistamisessa. Toisin sanoen, mikään ei ole oikeastaan muuttunut perinteiseen työnkulkuun verrattuna. Muuttunut on se, että ratkaisujen tuottamisen kyvyt ovat vahvistuneet. Kuka tahansa voi nyt luoda ohjelmistoja, mutta sen ei pitäisi laskea hyväksymiskriteerejä. Niiden tulisi nousta merkittävästi.

Missä AI todella auttaa, on tuoda esiin se, mitä henkilö muuten menettäisi melussa, kuten poikkeamat ja trendit, jotka eivät laukaise manuaalista kynnystä. VictoriaMetricsilla on yksinkertainen sisäinen AI‑käytäntö: työntekijät voivat automatisoida työnkulun haluamallaan tavalla, mutta he ovat edelleen vastuussa lopputuloksesta. Tämä on suurin piirtein sama standardi, jonka soveltaisimme poikkeavuuksien havaitsemiseen asiakkaan tuotantoympäristössä. Malli voi merkitä sen, mutta henkilö joutuu edelleen päättämään, mitä se tarkoittaa ja mitä siitä tehdään.

VictoriaMetrics on pysynyt avoimen lähdekoodin projektina ja omaksunut itserahoitetun, asiakasrahoitetun lähestymistavan sen sijaan, että se olisi seurannut perinteistä riskipääomaa saaneen infrastruktuurialan startup‑mallia. Miten se on vaikuttanut siihen, miten rakennat tuotetta, hinnoittelet sen ja päätät, mitkä teknologiat pysyvät avoimena lähdekoodina?

Itserahoitus muuttaa kannustinjärjestelmää enemmän kuin ihmiset odottavat. Kun ei ole hallitusta, joka vaatisi meitä saavuttamaan ARR‑lukeman tiettyyn neljännekseen, meidän ei ole täytynyt tehdä niitä kompromisseja, jotka tavallisesti syntyvät tästä paineesta, kuten heikentää avoimen lähdekoodin versiota pakottaaksemme käyttäjät maksulliseen tasoon, tai muuttaa lisenssiä kuten InfluxDB tai HashiCorp tekivät suojellakseen tuloja pilvipalveluntarjoajilta. VictoriaMetrics OSS on tänään Apache 2.0, eikä meillä ole suunnitelmia muuttaa sitä.

Tapamme päättää, mikä pysyy avoimen lähdekoodin, on yksinkertainen: ydinmoottori, se osa, johon insinöörit luottavat tuotantodataan, pysyy avoimena. Laskutamme sen, mitä yritys tarvitsee, kun se toimii mittakaavassa ja tarvitsee vastuullisen tahon: monivuokraus, yritystason todennus, vaatimustenmukaisuustuki, CVE‑SLA ja suora pääsy koodin kirjoittaneisiin insinööreihin tukijonon sijaan. Asiakasrahoitteisuus tarkoittaa myös sitä, että tiekartta määräytyy sen perusteella, mihin ihmiset todella törmäävät tuotannossa, eikä sen perusteella, mikä on rahoitettavissa esitysdokumentissa.

Kun mittarit, lokit, jäljet, tekoälysovellusten telemetria, GPU‑valvonta ja automatisoitu poikkeavuuksien havaitseminen yhä enemmän lähestyvät toisiaan, miltä mielestäsi observabiliteettipino näyttää seuraavien vuosien aikana, ja mitä insinööritiimit odottavat alustoilta, jotka haluavat pysyä relevantteina?

Pino yhtyy operatiivisesti ennen kuin se yhtyy yhtenä tuotteena, ja tämä ero on merkittävä. Useimmat tiimit eivät halua yhtä monoliittista alustaa, jossa yksi käyttöliittymä lukitsee kaiken yhteen. He haluavat mittarit, lokit ja jäljet toimimaan yhden operatiivisen mallin, yhden toimittajan ja yhden lisenssitarinan alla, ilman että heidän täytyy luopua kunkin signaalin itsenäisestä ajamisesta, jos se on tiimin tarpeita. Tämä on se suunta, johon VictoriaMetrics kehittyy. Emme pyri pakkaamaan kaikkea yhteen binääriin. Pyrimme varmistamaan, että kolme signaalia jakavat saman moottorin ja samat tehokkuusominaisuudet, jotta toisen tai kolmannen signaalin lisääminen ei tarkoita toisen tai kolmannen operatiivisen päänvaivan omaksumista.

Relevantteina pysyvät alustat ovat ne, jotka pystyvät sisällyttämään AI‑telemetrian ja GPU‑valvonnan samaan malliin ilman, että kustannuskäyrä katkeaa. AI‑työkuormat tuottavat telemetriaa sellaisessa mittakaavassa, johon perinteinen mittari‑ tai isäntäkohtainen hinnoittelu ei ole koskaan suunniteltu. Tiimit joko lopettavat tarvittavan datan keräämisen tai niiden observabiliteettilasku kasvaa nopeammin kuin AI‑investointi, jota sen pitäisi seurata. Insinööritiimit odottavat, että alustat käsittelevät tämän volyymin samalla tavalla kuin mitä tahansa infrastruktuuria skaalattaessa, ilman että heidän täytyy uudelleensuunnitella tai neuvotella uudelleen jokaisen työkuorman kasvun yhteydessä.

Kiitos erinomaisesta haastattelusta, lukijat, jotka haluavat oppia lisää, kannattaa käydä osoitteessa VictoriaMetrics.