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.
5 yorum
Fikir iyi olsa da, sorgu gecikmesini azaltmak için kaçınılmaz olarak duruma ihtiyaç duyuluyor. MySQL, PostgreSQL gibi sistemlerle karşılaştırıldığında sorgu gecikmesinin neredeyse 100 kat daha yüksek olduğu görünüyor. Neredeyse bir dosya sistemine veri yazıp çıktı alıyormuşuz gibi bir şey.
Değerli geri bildiriminiz için teşekkür ederiz. 'Gecikmeyi azaltmak için state’e ihtiyaç vardır' diye belirttiğiniz nokta, mimarimizin temel trade-off'unu tam olarak yakalıyor.
Önce sorgu gecikmesi konusunda şunu söyleyebilirim: benchmark testlerimizde p99 (99. yüzdelik dilim) yaklaşık 130-210 ms seviyesindedir. Sanırım "100 kat fark" dediğiniz kısım, metinde belirtilen "soğuk başlangıçta birkaç saniye sürebilir" ifadesindeki en kötü senaryoya bakarak söylenmiş olmalı. Belirttiğiniz gibi bu nokta açıkça mimarimizin bir dezavantajıdır; metinde de paylaştığımız üzere, üretim ortamlarında bu yalnızca %0.01'in altında (P99.99) gerçekleşmektedir. Bunun dışında çoğu sorgu, her Lambda'nın yerel belleği ve diskini önbellek olarak kullanarak tutarlı performans verecek şekilde tasarlanmıştır.
Bu nedenle, belirttiğiniz gibi tüm sorguların 10 ms'nin altında garanti edildiği ultra düşük gecikmeli finansal işlem sistemleri gibi durumlarda bu mimari uygun olmayabilir. Ancak çoğu yapay zeka tabanlı arama ve öneri uygulamasında P99 temel alınarak 100-200 ms seviyesindeki gecikme yeterince iyi bir performanstır; altyapı maliyetlerini ve operasyonel yükü %90'dan fazla azaltmanın avantajı çok daha büyüktür.
Tekrar bir kez daha derinlemesine görüş ve katkı sağladığınız için teşekkür ederiz.
Dediğiniz gibi, bu tür bir çözümün genel amaçlı bir veritabanından çok, belirli durumlarda "gerçek" sunucusuz olarak kullanılabileceğini düşünüyorum.
Korece yanıt geleceğini hiç beklemiyordum! (Çok alaycı bir şekilde yazdım...)
Önce gerçekten yenilikçi bir fikir olduğunu düşündüm. Aslında sunucusuz veritabanlarının en büyük sorunu, görünürdeki gibi olmadan arka planda gerçek bir sunucunun çalışmasıydı. Bu yüzden trafiğin artması durumunda, o sunucunun atanmasını beklerken sistem 5 dakikaya kadar cevap vermez hale geliyor. Bu yüzden mevcut bulut (AWS vb.) sunucusuz veritabanları üretim seviyesinde kullanmak zor oluyor.
Denemeyi düşündüm ama endişem, MySQL, PostgreSQL gibi sistemlerde oluşturulmuş indeksleme, sıralama gibi ikili mantıkların yine inşa edilmesi gerekeceği ve bu kadar güvenilir bir açık kaynak veritabanı projesini Lambda üzerinde yeniden kurmanın ne kadar zor olacağıydı.
Doğrudan sizin yaptığınız bir ürün olduğu için çok gelişmesini dilerim~!
Güzel yorumunuz için teşekkür ederim. Belirttiğiniz gibi, RDB kullanım örneklerine uygun değil; bunun bir arama motoru (Elasticsearch) ve vektör veritabanı (Pinecone) konumunda olduğunu anlamanız doğru olur. İçeride ayrıca indeksleme, sıralama ve toplama (agregasyon) gibi işlevleri desteklemek için uzun süredir doğrulanmış Lucene'i de kullanıyoruz. Teşekkürler :)