- Bulut veri hizmetlerinin geleceği, "büyük ölçekli, çok kiracılı" yapıdır
- S3 gibi en üst düzey SaaS hizmetlerinin sadelik, güvenilirlik, dayanıklılık, ölçeklenebilirlik ve düşük fiyat sunmasının nedeni, bu hizmetlerin teknolojilerinin bunları sağlamak üzere yapısal olarak tasarlanmış olmasıdır
- Büyük kaynak havuzları üzerinden müşterilere hizmet sunmak, ölçek ekonomisi ve güvenilirlik sağlar
[Sunucusuz çok kiracılı (Serverless Multi Tenant) sistemlerin tanımı]
"Multi-Tenancy" tanımı
- Çok kiracılık, iş yüklerini paylaşılan donanım üzerinde birlikte konumlandırarak kaynakların paylaşılmasıyla ilgilidir
- Bulutta sistem kurmak, birden fazla kiracının paylaşılan işlem örnekleri (örn. Amazon EC2 veya Google Compute) ya da paylaşılan PaaS hizmetleri (örn. bulut nesne depolama) üzerinden hizmet alması anlamına gelir
- Çok kiracılık, "paylaşılan kaynaklar (sanal sunucular, diskler ve PaaS yapı taşı hizmetleri vb.) üzerinde birden fazla kiracıya hizmet sunmak" olarak tanımlanır
- Birden fazla kaynak paylaşım modeli kullanılabilir ve bazı sistemler bileşenlerin geneline yayılmış biçimde birden çok paylaşım modelini birleştirir
- Paylaşılan süreç: Aynı yazılım süreci birden fazla kiracıya hizmet verir. Veri ve güvenlik izolasyonu mantıksaldır
- Konteynerler: Tek kiracılı düğümler çalıştırılır ve her host üzerinde birden fazla konteyner paketlenir. Genellikle belirli bir K8s düğümünün çok sayıda kiracının pod'unu barındırdığı Kubernetes üzerinden yapılır
- Sanallaştırma: VM (örn. QEMU) veya microVM (örn. Firecracker) içinde tek kiracılı düğümler çalıştırılır ve host başına birden fazla VM paketlenir. Kubernetes, Kata Containers aracılığıyla VM'lerle birlikte de kullanılabilir
- Kiracıların aynı V8 sürecini paylaşırken ayrı hafif bağlamlarda çalışabildiği V8 isolation yöntemi de vardır, ancak veri sistemlerinde buna henüz rastlanmamıştır
Sunucusuz tanımı
- Müşteriler sunucu türü seçmez veya donanımı açıkça seçmez
- Bu sistemler, müşterinin donanım boyutunu açıkça ayarlamasına gerek kalmadan tüm iş yükü talebini karşılayabilmek için belirli bir esneklik ve hareket kabiliyetine dayanır
- Esneklik: İş yükünün ihtiyacına göre hizmeti büyütüp küçültebilme ve kapasiteyi azaltıp artırabilme yeteneği
- Hareket kabiliyeti: Performans ve kararlılık gereksinimlerini karşılamak için iş yüklerini sistem içinde taşıyıp dengeleyebilme yeteneği
- Sunucusuz model, müşteriler için giderek daha önemli hale gelen kullanım bazlı fiyatlandırmayı kullanır
- Birçok müşteri önceden büyük taahhütler vermek istemez ve yalnızca kullandığı kadar ücretlendirilmeyi tercih eder
- Kullanım bazlı fiyatlandırmanın, iş yüküne ve alttaki sistem uygulamasına göre büyük ölçüde değişen birçok çeşidi vardır
- (Milyon) işlem başına ödeme
- İş yükünün CPU ve bellek kullanımına göre ödeme
- GB başına depolama ücreti
- Kaynaklar ve iş oranıyla ilişkili sanal performans/kapasite birimleri (örn. DynamoDB'deki RCU/WCU) için ödeme
- Müşterinin belli bir taban kapasite için ödeme yaptığı ve bunun üzerindeki kullanım için ayrıca ücretlendirildiği hibrit modeller ("tabanı öde, zirveyi ayrıca öde")
[Ortak zorluklar]
İş yükünün dayattığı kısıtlar içinde çalışmak
- Belirli bir veri sisteminin iş yükünün dayattığı çok sayıdaki kısıt, temel mimarinin önemli belirleyicileridir
- Gecikme/kullanılabilirlik gereksinimleri
- Tutarlılık gereksinimleri
- İstekler ile veri arasındaki korelasyon/bağımlılık
- Sıralı erişim kalıpları ile rastgele erişim kalıpları
- İstek başına yapılan işin çeşitliliği
- Veri boyutu
- Oturum odaklı protokoller ile istek odaklı protokoller, push ile pull mekanizmaları
- İşlemin hesaplama yoğunluğu
- Gevşek gecikme ve tutarlılık gereksinimleri, mühendislere daha fazla hareket alanı sağlar
- Düşük maliyet ve yüksek dayanıklılık sunan bulut nesne depolamanın avantajlarından yararlanmak buna iyi bir örnektir; çünkü düşük gecikmeli sistemlerde yüksek gecikmeli bileşenleri devreye almak kısıtlıdır
- Eventually Consistent sistemler, veriyi eşzamanlı veri hot path içine almadan nesne depolamaya asenkron biçimde yazarak bu ikilemi aşabilir
- Düşük gecikmeli ve güçlü tutarlılığa sahip sistemlerde böyle bir kaçış kartı yoktur
- Düşük gecikme gibi kısıtlar bir araya geldiğinde, iş yükünün uzamsal ve zamansal yerelliği mimari seçimleri etkileyebilir
- Örneğin, sıralı taramanın baskın olduğu iş yüklerinde, disk üzerinde hızlı ve verimli tarama için bitişik veri aralıklarını birlikte tutmak avantajlıdır
- Bu aralıkları daha küçük alt aralıklara bölmek hotspot yönetimine yardımcı olur, ancak bunlar birbiriyle çelişen iki konudur ve aralarında denge bulunmalıdır
- Tekil istekler arasında çok az korelasyon bulunan rastgele erişim kalıpları, birçok sunucuya eşit ve ince biçimde dağıtılabilen düz bir adres alanından faydalanabilir
- Kalıcı bağlantılar kuran oturum odaklı protokoller, genellikle her isteğin bir öncekinden bağımsız olduğu istek odaklı protokollere göre daha zordur
- Kalıcı bağlantılar bağlantı havuzlaması gerektirebilir ve rolling node ile veri dengeleme gibi bozulmalar yaşandığında istemcide dışarıdan fark edilen etkiler oluşabilir
- Bazı sistemler nesne depolama veya Kafka API'si gibi basit depolama API'leri sunarken, bazıları SQL veritabanı gibi hesaplama yoğun sistemlerdir
- Bu da her isteği işlemek için gereken iş miktarının öngörülebilirliği ve değişkenliği konusuna bağlanır
- Uç örnek olarak, yalnızca ardışık kayıt bloklarını getirmesi gereken Kafka benzeri veri akışı API'leri vardır; diğer uçta ise sorgudan sorguya iş miktarında büyük farklar yaratabilen SQL bulunur
Kiracı izolasyonu
- Kaynak paylaşımı donanım kullanım oranını artırır, ancak bir kiracının iş yükünün başka kiracıları etkilemesine yol açan kaynak çekişmesi de yaratabilir
- Çok kiracılı sistemlerde, paylaşılan donanım kaynaklarından hizmet alan kiracılara sanki kendilerine ait özel bir hizmetten yararlanıyormuş gibi güvence verilmelidir
Depolama ile hesaplamanın ayrılması
- Depolama ile hesaplamanın ayrılması, şimdiye kadar incelenen tüm sistemlerin bir ölçüde uyguladığı temel bir tasarım ilkesidir
- Donanım eğilimleri nedeniyle depolama ile hesaplamanın ayrılması giderek daha uygulanabilir hale geliyor; bunun bir nedeni de ağın artık eskisi kadar büyük bir darboğaz olmaması
- Ağ bant genişliği artsa da, bulut nesne depolamanın ön plana çıkmasıyla bu ayrımın getirdiği yeni zorluklar sürüyor
- Bulut nesne depolama hâlâ görece yüksek gecikmeli, çok dayanıklı ve ucuzdur
- Ancak OLTP veritabanları gibi tipik olarak düşük gecikme gerektiren iş yüklerinde kullanıma almak zor olabilir
- Ayrıca bulut nesne depolamanın ekonomik modeli, çok sayıda küçük nesneye dayanan tasarımlar için elverişli değildir; daha az istekle daha büyük nesnelerde veri biriktirmeyi gerektirir ve bu da düşük gecikmeli sistemlerin yaşam döngüsünü daha da karmaşık hale getirir
- Mühendisler, yavaş nesne depolamanın önüne dayanıklı ve hata toleranslı bir yazma önbelleği ile öngörücü bir okuma önbelleği koyarak, nesne depolamayı düşük gecikmeli sistemlere dahil edip gecikme sorununu hafifletebilir
- Bu dayanıklı yazma önbelleği, temelde çoğaltma protokolü uygulayan ve block storage'a veri yazan bir sunucu kümesidir
- Arka planda küme, daha az sayıda büyük dosya yazmanın ekonomik desenine uygun şekilde veriyi nesne depolamaya asenkron olarak yükler
- Hata toleranslı yazma önbelleği, düşük gecikmeli yazmaları iyi destekler
- Bu mimaride sorun çıkarabilecek kısım okuma önbelleğidir
- Olay akışı gibi sıralı iş yüklerinde çözüm basit ve çok etkilidir
- Aggregate Prefetching talebi karşılayabildiği sürece, okumalar her zaman yerel okuma önbelleğine ulaşmalıdır
- Veritabanları, öngörülmesi zor rastgele erişim kalıpları nedeniyle bundan daha zor bir problem yaşar; yine de tablo taramaları read-ahead'den faydalanabilir
- Çoğaltma protokolüyle dağıtık, hata toleranslı bir yazma önbelleği uygulamak pek kolay değildir ve çoklu AZ ortamlarında cross-AZ ücretleri gibi ek maliyetler doğabilir
- Ancak şu an için, ucuz ve dayanıklı nesne depolamayı temel veri deposu olarak kullanmak isteyen düşük gecikmeli sistemler için başka bir alternatif yoktur
- Düşük gecikmeli diğer sistemler ise bulut nesne depolama kullanımından tamamen kaçınmalı ve her şeyden önce öngörülebilir kısa gecikmeyi tercih etmelidir
- Bulut depolama yaygın olarak kullanılsa da, gecikme trade-off'ları nedeniyle evrensel değildir
Isı yönetimi
- Isı yönetimi, gecikme sıçramaları veya saniye başına işlem sayısında düşüş gibi dışarıdan görülebilen performans sorunlarına yol açabilecek hotspot'ları önlemek için yükü mümkün olduğunca eşit biçimde birden fazla depolama düğümüne dağıtma işidir
- Buna load balancing de denebilir, ancak genelde load balancer terimi stateless düğümler için kullanılır
- Stateful sistemlerde, yüksek talep gören nesnelerin belirli depolama düğümlerinde gruplanması çekişmeye yol açan hotspot'lar oluşturabilir
- Load balancer'lar, rastgele, en az bağlantı veya bazı FIFO varyasyonları gibi basit stratejilerle yükü stateless düğümler arasında eşit dağıtabilir; fakat stateful sistemlerde isteklerin, verinin bulunduğu düğümlere yönlendirilmesi gerekir
- Yükü yeniden dağıtmak için veriyi taşımaya genellikle rebalancing denir
- Daha da karmaşık olan konu, yük dağılımının zaman içinde değişebilmesidir
- Veri dağıtımı, verinin küçük bir alt kümesini etkileyen kısa süreli zirvelerden birden fazla kiracıyı etkileyen günlük desenlere veya mevsimsel olayların yarattığı daha büyük yük değişimlerine kadar her şeyi ele almak zorunda olan dinamik bir süreç haline gelir
- Büyük veritabanları veya yüksek hacimli olay akışları gibi büyük veri kümeleri, yükü etkili biçimde dağıtmak için shard edilmelidir
- Rebalancing burada shard'ların yeniden dengelenmesi anlamına gelir ve sistem, yük dağılımı değiştikçe shard'ları bölüp birleştirebilir
- Ancak shard sayısı ve boyutuyla ilgili, veri yerelliği gibi çelişen konular olabilir
- Bir yandan, verinin birlikte konumlanması arttıkça erişim daha verimli olur
- Öte yandan, çok fazla shard'dan veri çekmek zorunda kalan hesaplama işlerinin maliyeti, yükü daha fazla sunucuya dağıtmaktan elde edilen faydayı aşabilir
- Isı yönetimi tek kiracılı sistemlerde de gerekli olabilir; dolayısıyla yalnızca çok kiracılı sistemlere özgü bir sorun değildir
- Ancak MT veri sistemlerinde, kiracıların hizmet kalitesinde dalgalanma yaşamaması için ısı yönetimi daha da önemli hale gelir
Yüksek kaynak kullanımı sağlamak
- Sunucusuz çok kiracılı mimarileri uygulamanın başlıca motivasyonlarından biri, alttaki donanım kaynaklarını daha verimli kullanarak daha iyi ekonomik verim sağlamaktır
- Kaynak havuzlama yoluyla kullanım oranını artırmak çok önemlidir, ancak bunu kiracı izolasyonu ve öngörülebilir performansla birlikte başarmak zorlu bir görevdir
Cold start
- Kaynakları kiracı bazında sıfıra kadar küçültebilen sunucusuz sistemler, kiracı iş yükünü yeniden başlattığında cold start sorunuyla karşılaşabilir
- Cold start, en başından beri sunucusuz işlevlerin odak noktalarından biri olmuştur ve bazı sunucusuz veri sistemlerini de etkileyebilir
- Bazı sistemlerde cold start hiç yaşanmazken, bazılarında ise mimari ve scale-to-zero ürün sunumu nedeniyle kaçınılmaz hale gelebilir
- Gördüğüm tüm örneklerde cold start sorunu bir ürün kararıdır ve fiyat planına ile fiyatlandırma yöntemine bağlı olarak kaynak küçültme düzeyi değişebilir
- Sonuçta müşteri ve sağlayıcı, kendi ihtiyaçlarına uygun ödünleşimi seçebilir
İncelenen sistemler
- Group 1 - Storage APIs (compute-light)
- Amazon DynamoDB (chapter 1)
- Kora - Confluent Cloud içindeki sunucusuz Kafka motoru (chapter 2)
- Backblaze B2 (planned)
- Group 2 - SQL OLTP databases (compute-heavy)
- Neon - sunucusuz PostgreSQL (chapter 3)
- CockroachDB'nin sunucusuz çok kiracılı mimarisi. (in progress)
- Planetscale (planned)
- Group 3 - SQL OLAP databases and data warehouses (compute-heavy)
- Google BigQuery (planned)
- ClickHouse Cloud (in progress).
- Bu çalışma devam edecek, ancak 2024 Ocak/Şubat döneminde bir tür 'sonuç' yazısı planlanıyor
Henüz yorum yok.