Dzmitry Lazerka, Salah Satu Pendiri VictoriaMetrics – Seri Wawancara

Dzmitry Lazerka, salah satu pendiri VictoriaMetrics adalah seorang insinyur perangkat lunak berpengalaman dan pemimpin teknologi dengan keahlian mendalam dalam pembelajaran mesin, sistem data berskala besar, observabilitas, dan infrastruktur. Sebelum mendirikan VictoriaMetrics pada 2018, ia bekerja sebagai Machine Learning Engineer di divisi kendaraan otonom Level 5 Lyft, di mana ia membantu mengembangkan sistem untuk mengenali dan menganalisis skenario mengemudi dunia nyata. Sebelumnya, ia memimpin proyek pembelajaran mesin dan infrastruktur data di Spire Global, menjadi co-founder teknik di Bellgram, dan bekerja pada sistem data serta analitik di Duetto Research dan Google melalui EPAM Systems. Sepanjang kariernya, Lazerka telah membangun dan memimpin proyek yang mencakup mengemudi otonom, prediksi maritim, pencarian, analitik, pemrosesan data terdistribusi, dan sistem backend yang sangat skalabel.

VictoriaMetrics adalah perusahaan observabilitas open-source yang membangun alat untuk mengumpulkan, menyimpan, menanyakan, dan menganalisis volume besar data operasional. Teknologinya dimulai dengan VictoriaMetrics, basis data time-series berperforma tinggi dan solusi pemantauan yang dirancang untuk skalabilitas, kueri cepat, penyimpanan efisien, dan beban operasional rendah, dan sejak itu telah berkembang menjadi stack observabilitas yang lebih luas mencakup metrik, log, dan jejak terdistribusi melalui VictoriaMetrics, VictoriaLogs, dan VictoriaTraces. Perusahaan juga menawarkan penyebaran enterprise dan cloud terkelola penuh, bersama dengan kemampuan deteksi anomali yang menerapkan pembelajaran mesin pada data time-series. Platformnya mendukung teknologi termasuk OpenTelemetry, alur kerja kompatibel Prometheus, Grafana, dan Kubernetes, memberi organisasi fleksibilitas untuk mengintegrasikan VictoriaMetrics ke dalam lingkungan observabilitas yang ada.

Sebelum mendirikan VictoriaMetrics, Anda bekerja pada sistem data berskala besar, analitik, dan pembelajaran mesin di Google, Spire Global, divisi kendaraan otonom Lyft, dan startup lainnya. Apa yang pada akhirnya mendorong Anda untuk mendirikan VictoriaMetrics, dan masalah apa dari peran-peran sebelumnya yang meyakinkan Anda bahwa pemantauan dan observabilitas memerlukan pendekatan yang secara fundamental berbeda?

Saya menghabiskan karier saya bekerja dengan sejumlah besar data. Di Google, Spire, Lyft, dan perusahaan lain, Anda cepat belajar bahwa sesuatu yang berfungsi baik pada satu skala dapat menjadi mahal atau sulit dioperasikan pada skala lain. Pemantauan memiliki masalah yang persis seperti ini.

Seiring infrastruktur tumbuh, Anda menciptakan lebih banyak metrik. Anda menambahkan lebih banyak layanan, lebih banyak instance, dan lebih banyak label hingga tiba-tiba sistem pemantauan itu sendiri membutuhkan infrastruktur yang signifikan, yang tidak pernah masuk akal bagi kami. Sistem yang dirancang untuk memantau lingkungan produksi Anda tidak seharusnya menjadi lebih rumit dan mahal untuk dioperasikan.

Inilah yang secara langsung dilihat oleh rekan co-founder saya, Aliaksandr Valialkin dan Roman Khavronenko. Mereka memiliki pengalaman mengoperasikan Prometheus dan menghadapi keterbatasan memori. Menambahkan sistem seperti Thanos menyelesaikan beberapa masalah skalabilitas, tetapi juga memperkenalkan lebih banyak komponen dan kompleksitas operasional. Dan dengan InfluxDB, kami melihat bagaimana perubahan lisensi dapat memengaruhi keputusan teknik setelah tim-tim sudah berinvestasi pada teknologi tersebut.

Jadi gagasan di balik VictoriaMetrics bersifat praktis: Bisakah kami membangun basis data time-series yang melakukan pekerjaan yang sama dengan jauh lebih sedikit sumber daya dan lebih sederhana untuk dioperasikan?

Kami tidak memulai dengan rencana untuk membangun perusahaan observabilitas besar. Kami memulai dengan menyelesaikan masalah teknik.

Membuatnya open source adalah bagian dari itu. Insinyur dapat mengunduh VictoriaMetrics, menerapkan beban kerja produksi nyata padanya, dan membandingkan hasilnya sendiri. Kami tidak perlu memberi tahu mereka bahwa itu lebih cepat atau lebih efisien. Mereka dapat mengukurnya.

Ini adalah cara terbaik untuk membangun perangkat lunak infrastruktur. Jika teknologinya baik, insinyur harus dapat membuktikannya sendiri.

Biaya observabilitas dapat secara diam-diam menjadi bagian signifikan dari tagihan cloud perusahaan. Di mana biaya tersebut biasanya melambung tak terkendali, dan keputusan arsitektural atau pembelian apa yang paling sering salah dilakukan oleh tim teknik?

Saya akan melihat pada kardinalitas terlebih dahulu.

Misalkan Anda memulai dengan metrik yang wajar, lalu menambahkan label dengan nilai-nilai yang mungkin. Tiba-tiba, satu metrik menjadi ribuan atau jutaan rangkaian waktu unik. Sistem kini memiliki lebih banyak data untuk di‑ingest, di‑indeks, disimpan, dan di‑query, yang menghasilkan lebih banyak CPU, memori, dan penyimpanan.

Bagian sulitnya adalah ini tidak terjadi karena seseorang membuat satu keputusan buruk. Ini terjadi secara bertahap. Tambahkan lebih banyak layanan, pod K8s, pelanggan, dan label, dan biayanya berlipat ganda.

Masalah kedua adalah menyimpan semuanya dengan resolusi yang sama untuk durasi yang sama. Tidak semua data observabilitas memiliki nilai yang sama. Metrik yang Anda butuhkan untuk sebuah alarm atau SLO berbeda dari telemetri diagnostik bervolume tinggi yang mungkin Anda lihat sekali selama insiden.

Jika Anda memperlakukan semua data itu sama, Anda akan berakhir membayar harga premium untuk infrastruktur atau SaaS atas data yang tidak memerlukannya.

Inilah mengapa beberapa perusahaan mendekati observabilitas sebagai masalah pembelian, menanyakan platform mana yang paling mudah diterapkan hari ini. Saya mengajukan pertanyaan seperti, “Apa yang terjadi ketika jumlah telemetri meningkat 10 kali lipat? Apa yang terjadi pada kardinalitas? Apa yang kita simpan? Untuk berapa lama? Dan apa yang terjadi pada biayanya?”

Ada solusi teknik untuk masalah-masalah ini. Misalnya, dengan agregasi streaming, Anda dapat mengagregasi metrik sebelum mereka mencapai penyimpanan alih-alih menyimpan setiap rangkaian waktu mentah dan mengagregasinya kemudian. Anda dapat memisahkan beban kerja ber‑kardinalitas tinggi dari pemantauan yang kritis bagi bisnis. Anda juga dapat menggunakan kebijakan retensi dan resolusi yang berbeda tergantung pada nilai data.

Tujuannya bukan mengumpulkan telemetri sesedikit mungkin. Anda memerlukan informasi yang cukup untuk memahami apa yang dilakukan sistem Anda.

Tujuannya adalah menghindari menghabiskan sumber daya untuk mengumpulkan, memproses, dan menyimpan data dengan cara yang tidak memberikan nilai tambahan.

Observabilitas adalah sistem teknik. Biayanya juga harus direkayasa.

Grammarly menyatakan bahwa bukti konsepnya dengan VictoriaMetrics menghasilkan tagihan AWS yang 10 kali lebih rendah. Ketika perusahaan mencapai penghematan pada skala itu, apa yang sebenarnya berubah di balik layar: kompresi data, kebutuhan komputasi, arsitektur penyimpanan, kompleksitas operasional, atau kombinasi dari faktor-faktor tersebut?

Ini merupakan kombinasi, tetapi kompresi dan jejak sumber daya melakukan sebagian besar pekerjaan. VictoriaMetrics menggunakan kompresi khusus untuk data time series, sehingga metrik yang sama hanya memakan sebagian kecil ruang disk dibandingkan pada basis data tujuan umum. Selain itu, kami menggunakan RAM empat hingga lima kali lebih ringan daripada Prometheus pada tingkat ingest yang setara, dan hingga sepuluh kali lebih ringan pada disk. Ketika Grammarly menjalankan bukti konsep mereka, hal itu langsung terlihat pada tagihan AWS mereka, karena mereka tidak hanya menyimpan lebih sedikit data; mereka juga menjalankan lebih sedikit dan lebih kecil instance untuk melakukannya.

Bagian kompleksitas operasional juga penting, tetapi lebih tidak langsung. Banyak tim yang memperkirakan biaya observabilitas hanya melihat item penyimpanan dan komputasi serta melewatkan jam teknik yang dihabiskan untuk mengoperasikan stack Thanos dengan lima komponen dibandingkan dengan satu binary. Itu uang nyata; hanya saja lebih sulit untuk memberi angka pada hal tersebut.

Prometheus telah menjadi dasar pemantauan cloud-native, namun beberapa organisasi pada akhirnya menghadapi batasan skalabilitas atau operasional. Apa yang biasanya menyebabkan sebuah perusahaan mulai mencari alternatif di luar penerapan Prometheus konvensional, dan kapan VictoriaMetrics menjadi alternatif yang logis?

Prometheus sangat baik dalam apa yang dibangunnya: mesin pengambilan data (scrape) dan peringatan pada satu node. Tim biasanya menemui kendala dalam dua cara: Entah kardinalitas mereka tumbuh melebihi apa yang dapat ditampung oleh satu instance Prometheus dalam memori, atau mereka membutuhkan retensi jangka panjang dan kueri global di seluruh beberapa klaster, yang tidak pernah dirancang oleh Prometheus untuk dilakukan sendiri. Pada saat itulah orang menambahkan Thanos atau Cortex, yang biasanya menjadi titik awal rasa sakit operasional. Anda beralih dari menjalankan satu binary menjadi menjalankan sistem terdistribusi dengan compactor, querier, store gateway, dan banyak lagi yang dapat rusak pada pukul 3 pagi.

VictoriaMetrics menjadi langkah logis berikutnya karena merupakan pengganti yang dapat langsung dipasang, bukan arsitektur ulang. Tim mengarahkan konfigurasi scrape Prometheus mereka yang ada ke VictoriaMetrics dan mempertahankan semua dasbor Grafana, peringatan, dan aturan rekaman yang sudah mereka buat. Migrasi ini hanyalah perubahan konfigurasi, bukan proyek, dan mereka memperoleh skala tanpa menambahkan lima komponen baru untuk dioperasikan.

Kami melihat tim teknik mempertimbangkan kembali apakah mereka memerlukan platform observabilitas besar yang dikelola sepenuhnya atau apakah mereka dapat membangun tumpukan yang lebih efisien dari komponen open-source. Apakah Anda melihat ini sebagai pergeseran struktural yang lebih luas di pasar observabilitas, dan seberapa besar tekanan yang diberikan open source pada model harga tradisional?

Ini bersifat struktural; bukan reaksi sementara terhadap tahun anggaran yang buruk. Vendor observabilitas secara historis menetapkan harga berdasarkan volume ingest atau jumlah host, dan model itu bekerja melawan pelanggan seiring pertumbuhan bisnis mereka. Semakin sukses sebuah perusahaan, semakin banyak yang harus dibayar, dan harga tidak memiliki hubungan nyata dengan nilai yang diberikan. Tim teknik telah mulai menghitung sendiri, menyadari bahwa tumpukan open-source yang dihosting sendiri dan efisien mengubah persamaan itu sepenuhnya. Hal ini karena biaya berskala dengan infrastruktur yang sebenarnya dijalankan, bukan dengan formula pengukuran yang dikendalikan vendor.

Hal ini memberikan tekanan nyata pada harga incumbent. Ketika sebuah tim dapat mengarahkan konfigurasi scrape mereka yang ada ke alternatif open-source dan mengurangi tagihan sebesar 60 hingga 80% tanpa kehilangan fungsionalitas, itu bukan percakapan yang sulit secara internal. Vendor yang masih mengenakan biaya per host atau metrik khusus akan terus menguras pelanggan yang tidak melakukan perhitungan ini.

Infrastruktur AI memperkenalkan sumber daya baru yang sangat mahal ke dalam persamaan: GPU. Apa yang harus dipantau perusahaan yang menjalankan pelatihan atau inferensi AI selain pemanfaatan GPU dasar, dan di mana observabilitas yang lebih baik dapat langsung diterjemahkan menjadi biaya infrastruktur AI yang lebih rendah?

Pemanfaatan GPU saja tidak memberi Anda cukup informasi.

Anda dapat melihat pemanfaatan 90% pada dasbor dan menganggap semuanya baik. Tetapi yang sebenarnya ingin Anda ketahui adalah: Apa yang sedang dilakukan GPU?

Anda perlu melihat lebih dalam. Kernel CUDA mana yang sedang berjalan? Bagaimana memori GPU dialokasikan? Berapa banyak waktu yang dihabiskan untuk memindahkan memori alih-alih melakukan komputasi? Apakah beban kerja menggunakan Tensor Cores ketika seharusnya? Apakah GPU sebenarnya menjadi bottleneck, atau menunggu data dari tempat lain?

Ini adalah pertanyaan penting karena GPU mahal. Ketidakefisienan kecil yang terulang pada ratusan atau ribuan GPU menjadi jumlah uang yang sangat besar.

Misalnya, jika GPU menunggu karena pipeline data tidak dapat memberi mereka cukup cepat, membeli lebih banyak GPU tidak akan menyelesaikan masalah. Anda harus menemukan bottleneck. Hal yang sama berlaku untuk memori. Jika beban kerja mengalokasikan memori secara tidak efisien, visibilitas yang lebih baik dapat membantu insinyur menyesuaikan ukuran batch atau menjalankan lebih banyak beban kerja pada perangkat keras yang sama.

Inilah saat observabilitas menjadi menarik untuk infrastruktur AI. Ini tidak hanya tentang mendeteksi bahwa ada yang rusak. Ini dapat memberi tahu Anda di mana Anda membuang komputasi.

Ada juga masalah observabilitas yang diciptakan oleh semua pemantauan ini. GPU dapat menghasilkan banyak telemetri terperinci dengan kardinalitas tinggi. Jika Anda mengumpulkan semuanya dan mengirimkannya langsung ke platform SaaS yang mahal, Anda dapat mengurangi biaya GPU Anda dan kemudian menghabiskan sebagian penghematan untuk menyimpan data pemantauan. Namun itu bukan optimasi yang baik.

Dengan OpenTelemetry dan proyek seperti OpenLIT, kami dapat memperoleh visibilitas yang jauh lebih dalam ke beban kerja GPU. Kemudian, dengan VictoriaMetrics, kami dapat mengagregasi data, menghapus dimensi yang tidak berguna, dan secara efisien mempertahankan informasi yang sebenarnya dibutuhkan insinyur.

Pertanyaan yang berguna bukan, “Seberapa terpakai GPU saya?”

Melainkan, “Pekerjaan berguna apa yang saya dapatkan dari GPU yang saya bayar?”

Setelah Anda dapat menjawab itu, Anda dapat mulai membuat keputusan teknik dan biaya yang lebih baik.

Agent AI menciptakan tantangan observabilitas yang sangat berbeda dari perangkat lunak tradisional karena satu permintaan dapat memicu pemanggilan model, penggunaan alat, kueri basis data vektor, serah terima, dan kemungkinan rantai panjang tindakan otonom. Bagaimana observabilitas perlu berkembang seiring aplikasi perusahaan menjadi semakin bersifat agen?

Observabilitas tradisional mengasumsikan sebuah permintaan mengikuti jalur yang cukup dapat diprediksi melalui infrastruktur Anda. Beban kerja agenik tidak bekerja seperti itu. Satu agen dapat memanggil sebuah model, kemudian sebuah alat, kemudian model lain dan mencoba kembali tiga kali sebelum mengembalikan apa pun. Setiap langkah tersebut memerlukan visibilitasnya masing-masing.

Mode kegagalan juga berbeda. Layanan tradisional biasanya merespons dengan benar atau tidak merespons sama sekali. Sebuah agen dapat merespons dengan sukses namun tetap salah, lambat, atau mahal, dan semua itu tidak muncul sebagai kesalahan tipikal di dasbor yang dirancang untuk uptime.

Bagian yang mengejutkan tim adalah kardinalitas. Alur kerja agen tunggal dapat menghasilkan metrik yang terkait dengan pengguna tertentu, prompt, dan pemanggilan alat, dan volume tersebut bertambah cepat, terutama dengan loop rekursi di mana perencana terus memanggil alat yang sama. Setiap sistem yang dimaksudkan untuk mengamati beban kerja agenik harus menangani skala itu tanpa kurva biaya menjadi vertikal, yang merupakan masalah yang sedang kami selesaikan. Metrik, log, dan jejak tetap menjadi blok bangunan yang tepat. Yang harus berubah adalah volume dan model biaya di bawahnya.

VictoriaMetrics juga telah menerapkan pembelajaran mesin dan alur kerja berbantuan AI untuk deteksi anomali. Di mana Anda percaya AI dapat secara nyata meningkatkan pemantauan dan respons insiden saat ini, dan di mana penilaian manusia masih sulit digantikan?

Penting untuk menjaga seseorang dalam proses untuk menghasilkan ide, mengarahkan implementasi, dan memvalidasi hasil. Dengan kata lain, tidak ada yang benar-benar berubah dibandingkan alur kerja tradisional. Yang berubah adalah kemampuan untuk menghasilkan solusi yang diperkuat. Siapa pun dapat membuat perangkat lunak sekarang, tetapi hal itu tidak seharusnya menurunkan kriteria penerimaan. Sebaliknya, kriteria tersebut harus dinaikkan secara signifikan.

Di mana AI benar-benar membantu adalah dengan menampilkan apa yang mungkin terlewatkan seseorang di tengah kebisingan, hal-hal seperti outlier dan tren yang tidak memicu ambang batas manual. Di VictoriaMetrics, kami memiliki kebijakan AI internal yang sederhana: Karyawan bebas mengotomatisasi alur kerja mereka sesuka hati, tetapi mereka tetap bertanggung jawab atas hasil akhir. Itu kira-kira standar yang sama yang akan kami terapkan pada deteksi anomali di lingkungan produksi pelanggan. Model dapat menandainya, tetapi orang masih harus memutuskan apa artinya dan apa yang harus dilakukan.

VictoriaMetrics tetap open source dan mengambil pendekatan yang dibiayai sendiri, dibiayai pelanggan, alih-alih mengikuti model startup infrastruktur tradisional yang didukung ventura. Bagaimana hal itu memengaruhi cara Anda membangun produk, menentukan harganya, dan memutuskan teknologi mana yang tetap open source?

Menjadi dibiayai sendiri mengubah struktur insentif lebih dari yang diperkirakan orang. Tanpa dewan yang menuntut kami mencapai angka ARR pada kuartal tertentu, kami tidak harus membuat kompromi yang biasanya muncul akibat tekanan tersebut, seperti melemahkan versi open-source untuk memaksa orang beralih ke tier berbayar, atau mengubah lisensi seperti yang dilakukan InfluxDB atau HashiCorp ketika mereka perlu melindungi pendapatan dari penyedia cloud. VictoriaMetrics OSS saat ini berlisensi Apache 2.0, dan kami tidak berencana mengubahnya.

Cara kami memutuskan apa yang tetap open source sangat sederhana: mesin inti, hal yang dibutuhkan insinyur untuk mempercayakan data produksi mereka kepada kami, tetap terbuka. Kami mengenakan biaya untuk apa yang dibutuhkan perusahaan setelah beroperasi pada skala besar dan memerlukan akuntabilitas: multi‑tenancy, autentikasi perusahaan, dukungan kepatuhan, SLA CVE, serta akses langsung ke insinyur yang menulis kode alih‑alih antrian dukungan. Dibiayai oleh pelanggan juga berarti peta jalan ditentukan oleh apa yang sebenarnya dihadapi orang di produksi, bukan oleh apa yang dapat dibiayai dalam presentasi pitch deck.

Seiring metrik, log, jejak, telemetri aplikasi AI, pemantauan GPU, dan deteksi anomali otomatis semakin konvergen, bagaimana menurut Anda tumpukan observabilitas akan terlihat dalam beberapa tahun ke depan, dan apa yang akan diharapkan tim teknik dari platform yang ingin tetap relevan?

Tumpukan tersebut konvergen secara operasional sebelum menjadi satu produk tunggal, dan perbedaan itu penting. Kebanyakan tim tidak menginginkan satu platform monolitik dengan satu UI yang mengunci semuanya bersama. Apa yang mereka inginkan adalah metrik, log, dan jejak yang berjalan pada satu model operasional, satu vendor, dan satu cerita lisensi, tanpa harus melepaskan kemampuan menjalankan setiap sinyal secara independen bila itu yang dibutuhkan tim tertentu. Itulah arah yang sedang dibangun VictoriaMetrics. Kami tidak berusaha menyatukan semuanya dalam satu binary. Kami berusaha memastikan ketiga sinyal berbagi mesin yang sama dan karakteristik efisiensi yang sama, sehingga menambahkan sinyal kedua atau ketiga tidak berarti mengadopsi masalah operasional kedua atau ketiga.

Platform yang tetap relevan adalah yang dapat menyerap telemetri AI dan pemantauan GPU ke dalam model yang sama tanpa kurva biaya terputus. Beban kerja AI menghasilkan telemetri dengan volume yang tidak pernah dibangun untuk harga per‑metrik atau per‑host tradisional. Tim terpaksa berhenti mengumpulkan data yang mereka butuhkan atau tagihan observabilitas mereka tumbuh lebih cepat daripada investasi AI yang seharusnya dipantau. Tim teknik akan mengharapkan platform menangani volume tersebut dengan cara yang sama seperti mereka mengharapkan infrastruktur apa pun skalabel, tanpa meminta mereka merancang ulang atau merundingkan kembali setiap kali beban kerja meningkat.

Terima kasih atas wawancara yang luar biasa, pembaca yang ingin belajar lebih lanjut dapat mengunjungi VictoriaMetrics.