Mevcut “serverless” veritabanları gerçek anlamda sunucusuz değildir

Sunucusuzluğun Efsanesi

• Serverless, bulut teknolojisinin kilit bir trendi haline geldi.
• Bu paradigma, geliştiricilerin yalnızca iş mantığına odaklanmasını sağlar ve sunucu yönetimi yüküne gerek bırakmaz.
• Ödeme modeli: Sadece kullandığınız kadar ödeme yaparsınız, operasyonel maliyet ise fiilen sıfıra yakındır.
• Piyasada birden fazla serverless veritabanı ortaya çıktı; Elastic, Confluent, Pinecone gibi yerleşik liderlerin yanı sıra Neon, WarpStream, Upstash ve Turbopuffer gibi yeni adaylar da rekabet ediyor.

Mevcut serverless veritabanlarının sorunları

• Pek çok serverless veritabanı gerçek anlamda serverless değildir.
• Çoğu hizmet bulut yerel mimariye (cloud-native architecture) dayanır; bu da sunucu havuzu dönemine göre yenilikçi bir tasarımdır.
• Hizmetler sunucu kümeleri işletir ve karmaşık yazılımlar ile insan müdahalesiyle yükü tahmin edip kapasiteyi yönetir.
• Bu tür bir efsane, kullanıcılara gerçek sorunlar yaşatır.

Verimsiz mimarinin etkisi

• Mimari uyumsuzluk, basit bir teknik ayrıntı değil, kullanıcı için gerçek bir problem yaratır.
• Kullanıcılar boşta kalan sunucuların maliyetini ödemek zorunda kalır; sunucu kümeleri her zaman farklı amaçlar için çalıştırılır.
• Ölçeklenebilirlik sorunu: Kümeye yeni bir sunucu eklenmesi birkaç dakika sürer, ani trafik sıçramaları anında karşılanamaz.
• Sınırlı seçenek: Her bulut bölgesi için altyapı yönetimi gerektiğinden, kullanıcılar seçebileceği hizmet bölgesi açısından kısıtlanır.

Sürdürülemeyen model

• Sunucu havuzu mimarisine dayanan “serverless” veritabanları sürdürülebilir değildir.
• Sağlayıcılar, sunucu kümesi işletimi için ciddi yatırım gereksinimi duyar; bu da fiyatların değişmesine yol açabilir.
• Hafif kullanıcılar, sistemi desteklemek için orantısız ücret öderken; başarılı kullanıcılar beklenmedik fiyat artışlarıyla karşılaşır.

Serverless-native mimarinin gerekliliği

• Bulut bilişimin ilk dönemlerinde çoğu “bulut” veritabanı legacy veritabanıydı.
• Serverless-native mimari, altyapı yönetiminin tamamını bulut sağlayıcısına bırakır ve sunucu kümeleri yerine durumsuz fonksiyonlar ile serverless servisler kullanır.
• Bu yaklaşım, bulut altyapısını tek büyük bir süper bilgisayar gibi ele alarak anlık ölçeklenebilirlik ve gerçek anlamda istek başına ödeme modelini mümkün kılar.
• Litmus testi: Bir veritabanının gerçekten serverless-native olup olmadığını doğrulamak için Kubernetes kümesi veya VM sağlamadan bulut hesabına dağıtılabilir olması gerekir.

LambdaDB tanıtımı

• LambdaDB, serverless-native olarak inşa edilen yeni bir arama motorudur.
• Bu sistem, serverless fonksiyonlar ve kaynaklar kümesiyle çalışır ve veritabanı mantığını altyapıdan tamamen ayırır.
• Kullanıcı istekleri bölgesel bir gateway üzerinden geçer; istek türüne göre Control Functions (Kontrol İşlevleri) veya Data Functions (Veri İşlevleri) olarak yönlendirilir.
• Kurumsal özellikler: LambdaDB, anlık geri yükleme ve sıfır kopyalı klonlama gibi özellikler sunar ve altyapı yönetimine gerek kalmaz.

LambdaDB’nin çalışma biçimi

• LambdaDB mimarisi: Tüm bileşenler serverless bulut servisleriyle kurulur.
• Gateway, kullanıcı isteğinin API anahtarını doğrular ve isteği kontrol işlevine veya veri işlevine yönlendirir.
• Kontrol işlevleri CRUD işlemlerini ve veri yönetimi isteklerini işler; veri işlevleri ise gerçek veri yazma ve okuma işlemlerini gerçekleştirir.
• Yazma yolu: Writer Function isteği kaydeder, bunu dayanıklı bir serverless yazma tamponuna yazar ve ardından istemciye yanıt verir.

Maliyet etkinliğinin paradoksu

• LambdaDB, sunucu havuzu veritabanlarına kıyasla hesaplama maliyetini düşürür.
• Lambda’nın birim fiyatı EC2 örneklerinden yüksek olsa da, yüksek kullanılabilirlik ve hata toleransı sağlamak için gereken çoğaltma sayesinde maliyet azalır.
• Sabit kapasite israfı: Kuruluşların ortalama hesaplama kullanımı yalnızca %10-20 olduğundan, serverless hesaplama %50-90 arasında maliyet tasarrufu sağlayabilir.

Performans ve ölçeklenebilirlik

• Performans ve ölçeklenebilirlik: LambdaDB, 960 boyutlu vektörlerle milyonlarca vektörün eklendiği bir deneyle performansını kanıtladı.
• Yazma gecikmesi: Saniyede 10 upsert işleminde medyan gecikme 43 ms'dir ve trafik 100 kat artsa bile gecikme benzer kalır.
• Sorgu gecikmesi: Sorgu gecikmesi farklı yüklerde stabildir; 99. yüzdelik değeri 172 ms ile 210 ms arasındadır.
• Optimizasyon çabası: Sorgu fonksiyonundaki gecikmeyi iyileştirmek için sürekli olarak optimize ediyoruz ve serverless altyapı da geliştiriliyor.

Kullanıcılara sağlanan faydalar

• Maliyet tasarrufu: LambdaDB’de bekleyen sunucu olmadığından, 10 kat ve üzeri daha ucuzdur.
• Anlık ve sınırsız ölçeklenebilirlik: LambdaDB, milisaniyeler içinde binlerce paralel fonksiyona genişleyebilir.
• Kolay başlangıç ve ölçekleme: Güçlü yapay zeka uygulamaları kurabilirsiniz ve büyüdükçe mimari hâlâ basit ve maliyet açısından verimlidir.
• Kurumsal özellikler: Anlık geri yükleme ve sıfır kopyalı klonlama gibi özellikler sunar, ek karmaşıklık veya maliyet gerektirmez.

Gelecek planlar ve vizyon

• LambdaDB, zaten yüz milyonlarca belge için her gün milyonlarca isteği işliyor.
• Uzun vadeli plan: İlişkisel veri, stream, key-value, grafik gibi diğer veri modellerini desteklemek planlanıyor.