Dzmitry Lazerka, VictoriaMetrics Kurucu Ortak – Röportaj Serisi

Dzmitry Lazerka, VictoriaMetrics Kurucu Ortağı, makine öğrenimi, büyük ölçekli veri sistemleri, gözlemlenebilirlik ve altyapı konularında derin uzmanlığa sahip deneyimli bir yazılım mühendisi ve teknoloji lideridir. VictoriaMetrics’i 2018’de kurmadan önce, Lyft’in Level 5 otonom araç bölümü’nde Makine Öğrenimi Mühendisi olarak çalıştı ve gerçek dünya sürüş senaryolarını tanıyan ve analiz eden sistemlerin geliştirilmesine yardımcı oldu. Daha önce Spire Global’da makine öğrenimi ve veri altyapı projelerini yönetti, Bellgram’da mühendislik kurucu ortağı olarak görev yaptı ve EPAM Systems aracılığıyla Duetto Research ve Google’da veri ve analiz sistemleri üzerinde çalıştı. Kariyeri boyunca Lazerka, otonom sürüş, denizcilik tahmini, arama, analiz, dağıtık veri işleme ve yüksek ölçeklenebilir arka uç sistemlerini kapsayan projeler inşa etti ve yönetti.

VictoriaMetrics, büyük miktarda operasyonel veriyi toplamak, depolamak, sorgulamak ve analiz etmek için araçlar geliştiren açık kaynaklı bir gözlemlenebilirlik şirketidir. Teknolojisi, ölçeklenebilirlik, hızlı sorgular, verimli depolama ve düşük operasyonel yük için tasarlanmış yüksek performanslı bir zaman serisi veritabanı ve izleme çözümü olan VictoriaMetrics ile başladı ve o zamandan beri VictoriaMetrics, VictoriaLogs ve VictoriaTraces aracılığıyla metrikler, günlükler ve dağıtık izleri kapsayan daha geniş bir gözlemlenebilirlik yığınına genişledi. Şirket ayrıca kurumsal ve tam yönetilen bulut dağıtımları ile zaman serisi verilerine makine öğrenimi uygulayan anomali tespit yetenekleri sunar. Platformu, OpenTelemetry, Prometheus uyumlu iş akışları, Grafana ve Kubernetes gibi teknolojileri destekleyerek organizasyonların VictoriaMetrics’i mevcut gözlemlenebilirlik ortamlarına entegre etme esnekliği sağlar.

VictoriaMetrics’i kurmadan önce, Google, Spire Global, Lyft’in otonom araç bölümü ve diğer girişimlerde büyük ölçekli veri, analiz ve makine öğrenimi sistemleri üzerinde çalıştınız. Sizi nihayet VictoriaMetrics’i kurmaya iten nedir ve bu önceki görevlerdeki hangi sorunlar, izleme ve gözlemlenebilirliğin temelde farklı bir yaklaşıma ihtiyaç duyduğunu size gösterdi?

Kariyerim boyunca büyük miktarda veriyle çalıştım. Google, Spire, Lyft ve diğer şirketlerde, bir ölçekte iyi çalışan bir şeyin başka bir ölçekte pahalı ya da işletmesi zor hale gelebileceğini çabucak öğrenirsiniz. İzleme tam da bu soruna sahiptir.

Altyapı büyüdükçe daha fazla metrik oluşturursunuz. Daha fazla hizmet, daha fazla örnek ve daha fazla etiket ekleyerek, bir anda izleme sisteminin kendisinin de önemli bir altyapı gerektirmesine yol açarsınız; bu bizim için hiç mantıklı değildi. Üretim ortamınızı izlemek için tasarlanmış bir sistem, daha karmaşık ve işletmesi daha pahalı hale gelmemelidir.

Bu, ortak kurucu ortaklarım Aliaksandr Valialkin ve Roman Khavronenko’nun doğrudan gördükleri şeydi. Prometheus’u işletme ve bellek sınırlamalarıyla karşılaşma deneyimine sahiplerdi. Thanos gibi sistemler eklemek belirli ölçekleme sorunlarını çözdü, ancak aynı zamanda daha fazla bileşen ve operasyonel karmaşıklık getirdi. Ve InfluxDB ile, bir lisans değişikliğinin, ekipler teknolojiye zaten yatırım yaptıktan sonra mühendislik kararlarını nasıl etkileyebileceğini gördük.

Bu yüzden VictoriaMetrics’in arkasındaki fikir pratiktir: Aynı işi çok daha az kaynakla yapan ve işletmesi daha basit bir zaman serisi veritabanı oluşturabilir miyiz?

Büyük bir gözlemlenebilirlik şirketi kurma planıyla başlamadık. Bir mühendislik sorununu çözerek başladık.

Bunu açık kaynak yapmak da bunun bir parçasıydı. Mühendisler VictoriaMetrics’i indirip gerçek üretim iş yüklerini üzerine koyabilir ve sonuçları kendileri karşılaştırabilirdi. Onlara daha hızlı ya da daha verimli olduğunu söylememize gerek yoktu. Ölçebiliyorlardı.

Bu, altyapı yazılımı inşa etmenin en iyi yoludur. Teknoloji iyiyse, mühendisler bunu kendileri kanıtlayabilmelidir.

Gözlemlenebilirlik maliyetleri, bir şirketin bulut faturasının önemli bir kısmını sessizce oluşturabilir. Bu maliyetler genellikle nerede kontrolden çıkar ve mühendislik ekipleri en sık hangi mimari ya da satın alma kararlarını yanlış yapar?

İlk olarak kardinaliteye bakardım.

Varsayalım ki makul bir metrikle başlıyorsunuz, ardından olası değerleri olan bir etiket ekliyorsunuz. Bir anda, bir metrik binlerce ya da milyonlarca benzersiz zaman serisine dönüşür. Sistem artık daha fazla veri alıp, indeksleyip, depolayıp sorgulamak zorunda kalır; bu da daha fazla CPU, bellek ve depolama anlamına gelir.

Zor kısmı, bunun birinin kötü bir karar vermesinden kaynaklanmamasıdır. Bu yavaş yavaş olur. Daha fazla hizmet, K8s podu, müşteri ve etiket ekledikçe maliyet katlanır.

İkinci sorun, her şeyi aynı çözünürlükte ve aynı süre boyunca depolamaktır. Tüm gözlemlenebilirlik verileri aynı değere sahip değildir. Bir uyarı ya da SLO için ihtiyaç duyduğunuz metrikler, bir olay sırasında bir kez inceleyebileceğiniz yüksek hacimli tanı telemetrisiyle farklıdır.

Eğer tüm bu verileri aynı şekilde ele alırsanız, gerekmeyen veri için premium altyapı ya da SaaS fiyatları ödemek zorunda kalırsınız.

Bu yüzden bazı şirketler gözlemlenebilirliği bir satın alma sorunu olarak ele alır ve hangi platformun bugün en kolay dağıtılacağını sorarlar. Ben de şu soruları sorarım: “Telemetri miktarı 10 kat artarsa ne olur? Kardinalite ne olur? Ne depoluyoruz? Ne kadar süreyle? Ve maliyet ne olur?”

Bu sorunlara mühendislik çözümleri vardır. Örneğin, akış birleştirme ile metrikleri depolamaya ulaşmadan önce birleştirebilir, her ham zaman serisini saklayıp sonradan birleştirmek yerine. Yüksek kardinaliteli iş yüklerini iş kritik izlemelerden ayırabilirsiniz. Ayrıca verinin değerine bağlı olarak farklı saklama ve çözünürlük politikaları da kullanabilirsiniz.

Amacın mümkün olduğunca az telemetri toplamak olmadığını unutmayın. Sistemlerinizin ne yaptığını anlamak için yeterli bilgiye ihtiyacınız var.

Amacın, veri toplama, işleme ve depolama için kaynak harcarken ek bir değer sağlamayan bir şekilde harcamaktan kaçınmaktır.

Gözlemlenebilirlik bir mühendislik sistemidir. Maliyeti de mühendislik olarak ele alınmalıdır.

Grammarly, VictoriaMetrics ile yaptığı kanıt konseptinin AWS faturasını 10 kat düşürdüğünü söyledi. Şirketler bu ölçekte tasarruf sağladığında, aslında kaputun altında ne değişiyor: veri sıkıştırması, işlem gereksinimleri, depolama mimarisi, operasyonel karmaşıklık ya da bu faktörlerin bir kombinasyonu?

Bu bir kombinasyondur, ancak sıkıştırma ve kaynak ayak izi işi büyük ölçüde yapar. VictoriaMetrics, zaman serisi verileri için özel olarak tasarlanmış sıkıştırma kullanır, bu sayede aynı metrikler genel amaçlı bir veritabanında alacakları disk alanının bir kısmını kaplar. Bunun üzerine, eşdeğer veri alma hızlarında Prometheus’a göre RAM’de dört beş kat daha hafif çalışıyoruz ve diskte ise 10 kata kadar daha hafif. Grammarly kanıt konseptini çalıştırdığında, bu doğrudan AWS faturalarında göründü; çünkü sadece daha az veri depolamıyorlardı; bunu yapmak için daha az ve daha küçük örnekler çalıştırıyorlardı.

Operasyonel karmaşıklık kısmı da önemlidir, ancak daha dolaylıdır. Birçok ekip gözlemlenebilirlik maliyetlerini fiyatlandırırken sadece depolama ve işlem kalemlerine bakar ve beş bileşenli bir Thanos yığını ile tek bir ikili arasındaki işletme mühendisliği saatlerini göz ardı eder. Bu gerçek bir maliyettir; sadece sayısal bir değer vermek daha zordur.

Prometheus, bulut‑yerel izleme için temel haline gelmiştir, ancak bazı organizasyonlar zamanla ölçeklenebilirlik ya da operasyonel sınırlamalara takılır. Bir şirketin geleneksel bir Prometheus dağıtımının ötesine bakmaya başlamasına genellikle ne sebep olur ve VictoriaMetrics ne zaman mantıklı bir alternatif haline gelir?

Prometheus, inşa edildiği amaçta mükemmeldir: tek düğüm kazıma ve uyarı motoru. Takımlar genellikle iki şekilde bir duvara çarpar: Ya kardinaliteleri tek bir Prometheus örneğinin bellekte tutabileceğinden daha büyük olur, ya da uzun vadeli saklama ve birden çok küme üzerinde küresel sorgulama ihtiyacı duyarlar; bu, Prometheus’un tek başına yapacak şekilde tasarlanmamıştı. İşte o zaman insanlar Thanos ya da Cortex ekler ve genellikle operasyonel sıkıntı burada başlar. Tek bir ikili dosyadan, bir kompaktör, bir sorgulayıcı, bir depolama geçidi ve sabah 3’te kırılabilecek daha birçok bileşen içeren dağıtık bir sisteme geçersiniz.

VictoriaMetrics mantıklı bir sonraki adım olur çünkü yeniden mimari bir değişiklik değil, doğrudan bir ikame çözümüdür. Takımlar mevcut Prometheus kazıma yapılandırmalarını VictoriaMetrics’e yönlendirir ve zaten oluşturdukları tüm Grafana panoları, uyarılar ve kayıt kurallarını korurlar. Geçiş bir yapılandırma değişikliği, bir proje değildir ve beş yeni bileşen eklemeden ölçeklendirmeyi elde ederler.

Mühendislik ekiplerinin büyük, tam yönetilen gözlemlenebilirlik platformlarına ihtiyaç duyup duymadıklarını ve açık kaynak bileşenlerinden daha verimli yığınlar oluşturup oluşturamayacaklarını yeniden değerlendirdiğini görüyoruz. Bunu gözlemlenebilirlik pazarında daha geniş bir yapısal kayma olarak görüyor musunuz ve açık kaynak geleneksel fiyatlandırma modellerine ne kadar baskı yapıyor?

Bu yapısaldır; kötü bir bütçe yılına geçici bir tepki değildir. Gözlemlenebilirlik satıcıları tarihsel olarak ya veri hacmi ya da host sayısına göre fiyatlandırma yapmışlardır ve bu model, müşterinin işi büyüdükçe ona karşı çalışır. Şirket ne kadar başarılı olursa, o kadar çok öder ve fiyatlandırma sunulan değere gerçek bir bağlam taşımaz. Mühendislik ekipleri kendi hesaplarını yapmaya başladı; kendileri barındırılan, verimli açık kaynak bir yığının bu denklemi tamamen değiştirdiğini fark ettiler. Bunun nedeni, maliyetin bir satıcının kontrol ettiği ölçüm formülü yerine gerçekte çalışan altyapıya göre ölçeklenmesidir.

Bu, mevcut fiyatlandırmaya gerçek bir baskı uygular. Bir ekip mevcut kazıma yapılandırmasını açık kaynak bir alternatife yönlendirip işlevselliği kaybetmeden faturayı %60‑%80 azaltabildiğinde, bu içerde zor bir konuşma değildir. Host başına ya da özel metrik başına hâlâ ücret alan satıcılar, bu hesabı yapmayan müşterileri kanama yoluyla kaybedeceklerdir.

AI altyapısı, denkleme alışılmadık derecede pahalı yeni bir kaynak ekliyor: GPU’lar. AI eğitimi ya da çıkarımı yapan şirketler temel GPU kullanımının ötesinde neyi izlemeli ve daha iyi gözlemlenebilirlik doğrudan AI altyapı maliyetlerini nasıl düşürebilir?

Sadece GPU kullanım oranı yeterli bilgi vermez.

Bir panoda %90 kullanım görebilir ve her şeyin iyi olduğunu varsayabilirsiniz. Ancak gerçekten bilmek istediğiniz şey şudur: GPU ne yapıyor?

Daha derine bakmanız gerekir. Hangi CUDA çekirdekleri çalışıyor? GPU belleği nasıl tahsis ediliyor? Belleği taşımak için ne kadar zaman harcanıyor, hesaplama yerine? İş yükü Tensor Çekirdeklerini gerektiği gibi kullanıyor mu? GPU gerçekten darboğaz mı, yoksa başka bir yerden veri bekliyor mu?

Bu sorular önemlidir çünkü GPU’lar pahalıdır. Yüzlerce ya da binlerce GPU’da tekrarlanan küçük bir verimsizlik çok büyük bir para miktarına dönüşür.

Örneğin, veri hattı GPU’ları yeterince hızlı besleyemediği için bekletiyorsa, daha fazla GPU satın almak sorunu çözmez. Darboğazı bulmanız gerekir. Bellek için de aynı şey geçerlidir. İş yükleri belleği verimsiz tahsis ediyorsa, daha iyi görünürlük mühendislerin toplu boyutlarını ayarlamasına ya da aynı donanımda daha fazla iş yükü çalıştırmasına yardımcı olabilir.

İşte gözlemlenebilirliğin AI altyapısı için ilginç hale geldiği nokta. Sadece bir şeyin kırıldığını tespit etmekle kalmaz; nerede hesaplama israfı yaptığınızı da söyleyebilir.

Tüm bu izleme nedeniyle bir gözlemlenebilirlik sorunu da ortaya çıkar. GPU’lar çok detaylı, yüksek kardinaliteli telemetri üretebilir. Her şeyi toplar ve doğrudan pahalı bir SaaS platformuna gönderirseniz, GPU maliyetlerinizi azaltabilir ve tasarrufun bir kısmını izleme verilerini depolamaya harcayabilirsiniz. Ancak bu iyi bir optimizasyon değildir.

OpenTelemetry ve OpenLIT gibi projelerle GPU iş yüklerine çok daha derin bir görünürlük elde edebiliriz. Ardından VictoriaMetrics ile verileri toplayıp, faydalı olmayan boyutları kaldırarak mühendislerin gerçekten ihtiyaç duyduğu bilgiyi verimli bir şekilde saklayabiliriz.

Yararlı soru “GPU’larım ne kadar kullanılıyor?” değil,

“Ödediğim GPU’lardan ne kadar faydalı iş alıyorum?” sorusudur.

Bunu yanıtlayabildiğinizde, daha iyi mühendislik ve maliyet kararları almaya başlayabilirsiniz.

AI ajanları, tek bir isteğin model çağrıları, araç kullanımı, vektör veritabanı sorguları, devretmeler ve potansiyel olarak uzun zincirli otonom eylemler tetikleyebildiği geleneksel yazılımlardan çok farklı gözlemlenebilirlik zorlukları yaratıyor. Kurumsal uygulamalar giderek daha fazla ajan odaklı hale geldikçe gözlemlenebilirlik nasıl evrimleşmeli?

Geleneksel gözlemlenebilirlik, bir isteğin altyapınızda oldukça öngörülebilir bir yol izlediğini varsayar. Ajan odaklı iş yükleri bu şekilde çalışmaz. Tek bir ajan bir modeli, ardından bir aracı, sonra başka bir modeli çağırabilir ve bir şey döndürmeden önce üç kez yeniden deneyebilir. Bu adımların her birinin kendi görünürlüğüne ihtiyacı vardır.

Başarısızlık modları da farklıdır. Geleneksel bir hizmet ya doğru yanıt verir ya da vermez. Bir ajan başarılı bir yanıt verebilir ancak yine de yanlış, yavaş ya da pahalı olabilir ve bunların hiçbiri, yalnızca çalışma süresine odaklı bir panoda tipik bir hata olarak görünmez.

Takımları şaşırtan kısım kardinalitedir. Tek bir ajan iş akışı, belirli bir kullanıcı, istem ve araç çağrısına bağlı metrikler üretebilir ve bu hacim, özellikle aynı aracı sürekli çağıran bir planlayıcıyla döngüsel tekrarlar olduğunda hızla birikir. Ajan odaklı iş yüklerini gözlemlemek için tasarlanmış herhangi bir sistem, bu ölçeği maliyet eğrisi dikleşmeden yönetebilmelidir; bu da tam olarak çözmeye çalıştığımız sorundur. Metrikler, günlükler ve izler hâlâ doğru yapı taşlarıdır. Değişmesi gereken, onların altındaki hacim ve maliyet modelidir.

VictoriaMetrics, anomali tespiti için makine öğrenimi ve AI destekli iş akışlarını da uyguluyor. AI’nın bugün izleme ve olay müdahalesini gerçekten nerede iyileştirebileceğini ve insan yargısının hâlâ nerede zorlayıcı olduğunu düşünüyorsunuz?

Fikir üretmek, uygulamayı yönlendirmek ve sonuçları doğrulamak için bir kişinin süreçte bulunması önemlidir. Başka bir deyişle, geleneksel iş akışıyla kıyaslandığında pek bir şey değişmedi. Değişen şey, çözüm üretme yeteneklerinin artırılmış olmasıdır. Artık herkes yazılım oluşturabiliyor, ancak bu kabul kriterlerini düşürmemeli; aksine önemli ölçüde yükseltmelidir.

AI’nın gerçekten yardımcı olduğu nokta, bir kişinin gürültü içinde kaçırabileceği şeyleri, örneğin manuel eşiklere takılmayan aykırı değerleri ve eğilimleri ortaya çıkarmaktır. VictoriaMetrics’te basit bir iç AI politikamız var: Çalışanlar iş akışlarını istedikleri gibi otomatikleştirebilir, ancak son sonuçtan sorumlu olmaya devam ederler. Bu, bir müşterinin üretim ortamındaki anomali tespiti için uygulayacağımız standartla büyük ölçüde aynı. Model bunu işaretleyebilir, ancak ne anlama geldiğine ve ne yapılacağına karar vermek hâlâ bir kişinin sorumluluğundadır.

VictoriaMetrics açık kaynak kalmaya devam etti ve geleneksel risk sermayeli altyapı girişimi modelini izlemek yerine kendi kendine finanse edilen, müşteri finanse edilen bir yaklaşım benimsedi. Bu, ürün geliştirme, fiyatlandırma ve hangi teknolojilerin açık kaynak kalacağı kararlarını nasıl etkiledi?

Kendi kendine finanse edilmek, insanların düşündüğünden daha fazla teşvik yapısını değiştirir. Belirli bir çeyrekte bir ARR rakamına ulaşmamızı isteyen bir yönetim kurulu olmadığından, genellikle bu baskıyla gelen, açık kaynak sürümünü kısıtlayarak insanları ücretli bir katmana zorlamak ya da InfluxDB ya da HashiCorp gibi lisansı değiştirerek bulut sağlayıcılarından gelir korumak gibi takasları yapmamıza gerek kalmadı. VictoriaMetrics OSS bugün Apache 2.0 lisansına sahiptir ve bunu değiştirme planımız yok.

Open source olarak neyin kalacağına karar verme şeklimiz basit: Çekirdek motor, mühendislerin üretim verilerini bize emanet etmeleri gereken şey, açık kalır. Bir şirket ölçekli bir şekilde çalışmaya başladığında ve sorumlu birine ihtiyaç duyduğunda (çok kiracılık, kurumsal kimlik doğrulama, uyumluluk desteği, bir CVE SLA ve kodu yazan mühendislerle doğrudan erişim, destek kuyruğu yerine) ihtiyaç duyduğu şey için ücret alıyoruz. Müşteri finansmanı, yol haritasının bir pitch deck’te fonlanabilir olanla değil, üretimde gerçekten karşılaşılanlarla belirlendiği anlamına da gelir.

Metri̇kler, günlükler, izler, AI uygulama telemetrisi, GPU izleme ve otomatik anomali tespiti giderek birleşirken, önümüzdeki birkaç yıl içinde gözlemlenebilirlik yığını nasıl görünecek ve ilgili kalmak isteyen platformlardan mühendislik ekipleri ne bekleyecek?

Yığın, tek bir ürün olarak birleşmeden önce operasyonel olarak birleşir ve bu ayrım önemlidir. Çoğu ekip, her şeyi bir arada kilitleyen tek bir UI’ye sahip tek parça bir platform istemez. İstedikleri, metri̇kler, günlükler ve izlerin tek bir operasyonel model, tek bir satıcı ve tek bir lisans hikayesi üzerinde çalışmasıdır; bir ekip buna ihtiyaç duyuyorsa her sinyali bağımsız olarak çalıştırma yeteneğinden vazgeçmek zorunda kalmadan. VictoriaMetrics’in inşa ettiği yön bu. Her şeyi tek bir ikiliye sıkıştırmaya çalışmıyoruz. Üç sinyalin aynı motoru ve aynı verimlilik özelliklerini paylaşmasını sağlamaya çalışıyoruz, böylece ikinci veya üçüncü bir sinyal eklemek, ikinci veya üçüncü bir operasyonel baş ağrısı anlamına gelmez.

İlgili kalmaya devam eden platformlar, AI telemetrisi ve GPU izlemeyi aynı modele maliyet eğrisi kırılmadan entegre edebilenlerdir. AI iş yükleri, eski metrik başına veya host başına fiyatlandırmanın hiç tasarlanmamış olduğu bir hacimde telemetri üretir. Ekipler ya ihtiyaç duydukları verileri toplamayı bırakır ya da gözlemlenebilirlik faturaları, izlemeleri gereken AI yatırımlarından daha hızlı artar. Mühendislik ekipleri, platformların bu hacmi, herhangi bir altyapının ölçeklenmesini beklediği gibi yönetmesini, iş yükü her büyüdüğünde yeniden mimari tasarım yapmalarını veya yeniden müzakere etmelerini istemeden bekleyecek.

Harika röportaj için teşekkür ederiz, daha fazla bilgi edinmek isteyen okuyucular VictoriaMetrics adresini ziyaret etmelidir.