- Google Cloud, Cloud Spanner fiyatını korurken işlem kapasitesini %50’ye kadar artırdığını ve düğüm başına depolama kapasitesini 2,5 kat büyüttüğünü, böylece çoğu iş yükünde Amazon DynamoDB’ye kıyasla maliyetin yarısına geldiğini açıkladı
- İyileştirmelerden sonra da Spanner, güçlü dış tutarlılığı, tek haneli milisaniye gecikmesi, fiilen sınırsız ölçeklenebilirlik ve %99,999 kullanılabilirlik SLA’sını koruyor
- Düğüm başına depolama kapasitesi 4 TB’den 10 TB’ye çıkıyor; kullanıcılar artan sınırdan bağımsız olarak yalnızca fiilen kullandıkları depolama alanı için ödeme yapmaya devam edecek
- Güncelleme önce bazı bölge ve çok bölgeli instance yapılandırmalarında sunuluyor; diğer yapılandırmalar ve depolama kapasitesi yükseltmeleri ise önümüzdeki birkaç ay içinde uygulanacak
- Müşteriler yeniden provizyonlama, kesinti veya kullanıcı müdahalesi olmadan mevcut ücretlerle bu iyileştirmelerden yararlanacak; ayrıca ayda 65 dolardan başlayan üretim kullanıma hazır instance’larla başlayabilecek veya 90 günlük ücretsiz denemeyi kullanabilecek
Cloud Spanner’da fiyat/performans iyileştirmesi
- Google Cloud, Cloud Spanner fiyatını değiştirmeden işlem kapasitesini %50’ye kadar artırıyor ve düğüm başına depolama kapasitesini 2,5 kat yükseltiyor
- Şirket, bu iyileştirmeyle birlikte çoğu iş yükünde Spanner’ın Amazon DynamoDB’nin yarı maliyetine kullanılabildiğini söylüyor
- Spanner; yüksek işlem kapasitesi, fiilen sınırsız ölçeklenebilirlik, tek haneli milisaniye gecikmesi, %99,999 kullanılabilirlik SLA’sı ve güçlü dış tutarlılık semantiğini birlikte sunuyor
- Bunun önümüzdeki birkaç ay içinde tüm Spanner müşterilerine uygulanacağı, yeniden provizyonlama, kesinti veya kullanıcı müdahalesi gerektirmediği belirtiliyor
Compute ve depolamadaki değişiklikler
- Compute tarafında işlem kapasitesi %50 iyileşerek ilişkisel iş yükleri ve anahtar-değer iş yüklerinde maliyet verimliliğini artırıyor
- Depolama tarafında ise tek bir Spanner düğümünün barındırabileceği kapasite 4 TB’den 10 TB’ye çıkıyor
- Kapasite sınırı artsa da yalnızca fiilen kullanılan depolama alanı için ödeme yapılıyor
- Bu da Spanner ortamını optimize etme esnekliğini artırıyor
- Benzer iş yükleri baz alındığında, Spanner’ın dolar başına okuma throughput’unun Amazon DynamoDB’ye göre 2 kata kadar daha yüksek olduğu belirtiliyor
Performans özellikleri ve hedef iş yükleri
- Spanner, aynı bölgedeki birden fazla erişilebilirlik alanına yayılan güçlü tutarlı okuma ve yazmalarda öngörülebilir tek haneli milisaniye gecikmesi sunuyor
- Tanıdık SQL, bakım kaynaklı kesinti olmaması ve %99,999 kullanılabilirlik SLA’sı ile yalnızca ilişkisel veriler için değil, okuma ağırlıklı anahtar-değer iş yükleri için de uygun görülüyor
- Google, şirket içinde Ads, Gmail ve Photos gibi hizmetlerde Spanner kullandığını belirtiyor
- Amazon’un Prime Day blog yazısına göre DynamoDB, zirvede saniyede 126 milyon sorgu işliyor
- Google, Spanner’ın zirvede saniyede 3 milyar sorgu işlediğini ve yönettiği veri miktarının 12 eksabaytı aştığını söylüyor
Müşteri örnekleri ve sunum takvimi
- Uber, Spanner’ın kritik operasyonlar için önemli bir bileşen olduğunu, ölçeklenebilirlik ve düşük operasyon maliyeti açısından değer sağladığını belirtiyor
- Spanner öncesinde veri yönetimi framework’ünün yoğun gözetim ve operasyonel çaba gerektirdiği, bunun da karmaşıklığı ve harcamaları artırdığı ifade ediliyor
- Sharding ve eventual consistency gibi geleneksel geçici çözümler geliştirme hızının önünde engel oluşturuyordu
- Spanner sonrasında operasyon maliyetleri sadeleşti, kararlılık iyileşti ve aynı fiyata daha iyi throughput ile performans elde edildi
- CERC, işlem kapasitesi ve düğüm başına depolama artışı sayesinde operasyonel verimliliği geliştirdiğini aktarıyor
- Fiyat/performans iyileştirmesi şu anda bazı bölge ve çok bölgeli instance yapılandırmalarında kullanılabiliyor; diğer yapılandırmalar daha sonra eklenecek
- Depolama yükseltmesi önümüzdeki birkaç ay içinde dağıtılacak
- Kullanıcılar 90 günlük ücretsiz deneme kullanabilir veya ayda 65 dolardan başlayan üretime hazır instance’larla başlayabilir
1 yorum
Hacker News görüşleri
Yakın zamanda altyapıyı GCP’den AWS’ye taşıdık. Kubernetes kümeleri, load balancer’lar, depolama, Lambda, KMS; hepsini taşıdık.
Google, teknoloji stack’ini sanki özgeçmişini şişirmeye çalışan bir startup gibi işletiyor hissi veriyordu; olgunlaşmamış kısımlar, hack’ler ve dokümante edilmemiş özellikler fazlaydı. GKE kullanınca yeni sürümler ve özellikler sürekli geliyordu; Google tarafındaki kusurlar nedeniyle altyapıya koyduğumuz kritik workaround’ları durmadan yeniden elden geçirmek zorunda kalıyorduk.
Altyapı ekibinin zamanının yarısı Google kaynaklı sorunlara hazırlanmakla, yarısı da asıl planladığımız altyapı işleriyle geçiyordu ve bunun sonu yoktu. AWS’ye geçtikten sonra 3 Kubernetes kümesi için fatura, GCP zamanındaki tutarın %60’ı seviyesine indi.
AWS desteği inanılması güç derecede iyiydi, Google desteği ise berbattı. 2020’de bildirdiğimiz bir hata yakın zamanda hiçbir işlem yapılmadan stale diye kapatıldı; API o kadar değişmişti ki artık bir anlamı da kalmamıştı denildi. Her ay fatura günü, başka şirketlerin çok daha iyi yaptığı işleri yapamayan geliştiricilere para ödediğimi hatırlıyordum; hiç özlemiyorum.
Avrupa’da video oyunları alanında çalışıyorum; Ubisoft’ta olduğum dönemde AWS bende çok kötü bir izlenim bırakmıştı. Tencent/Sharkmob’a geçtikten sonra sektör standardı olduğu için AWS’yi sevmeye çalıştım ama çoğu şey, üstü Lambda fonksiyonlarıyla kapatılmış tutarsız bir çöp yığını gibi hissettirdi.
Bu tuhaf tuzaklara saat 03.00 konuları diyorduk. Çünkü sabahın 3’ünde başa çıkacak zihinsel gücünüzün olmayacağı sorunlardı; stüdyoyu GCP’ye geçmeye ikna ettim ve bugün hâlâ o karar için çok minnettarım.
Buna karşılık GCP’den çok daha büyük pazar payına sahip Azure korkunç ve genel olarak tam bir karmaşa. Destek için para verseniz bile mühendislik tarafındaki birine ulaşmak zor; AWS ise harika.
Enterprise Support kullanıyoruz; ilgili kişiler Slack kanalımızda, TAM’ler de iyi. Route53 sorumlusu gerekiyorsa o hafta içinde görüşme ayarlanıyor; EKS özellik talebi için aynı öğleden sonra ürün yöneticisiyle konuşabiliyoruz. Azure ise temelden itibaren curcuna.
AWS servisleri geliştirirken müşteri destek çağrılarını doğrudan biz alırdık; arada kimse yoktu. Teknik kişiler doğrudan konuşurdu, anında müşteriye söz verdiğimiz olurdu, hatta bazen müşteri bizim işimizi proje yönetimi açısından yönlendirirdi.
GAE ile konuştuklarında, gerçekten de gördükleri kesintilerin GAE kesintileriyle korelasyon içinde olduğunu fark ettiler. Bir süre GAE’nin çalışma süresi iyileşti ama biz de artık AWS kullanıyoruz.
Buna karşılık GCP desteği F notluk; herhangi bir seviyede yardım alabilmek için neredeyse yalvarmak gerekiyor.
“Amazon Prime Day bloguna göre DynamoDB yoğun zamanda saniyede 126 milyon sorgu işliyor. Buna karşılık Spanner yoğun zamanda saniyede 3 milyar sorgu işleyerek 20 kattan fazla yüksek bir değere ulaşıyor ve 12 eksabayttan fazla veriyi yönetiyor” şeklindeki karşılaştırma tam olarak adil görünmüyor
Amazon’un saniyede 126 milyon sorgusu, Prime Day’i yürüten Amazon’la ilgili servislerin DynamoDB üzerinde oluşturduğu yük; AWS’in tamamı değil gibi okunuyor
Daha adil bir karşılaştırma için Google servislerinin Cloud Spanner üzerinde oluşturduğu tepe yük paylaşılmalı; GCP’nin tamamı ve Google’ın GCP dışı iç altyapısında çalışan tüm Spanner servisleri toplanmamalı
Photos, Gmail ve Ads’in GCP altyapısına büyük ölçüde bağlı olduğu söylenirse bu güçlü bir güven sinyali olurdu, ama benim için yeni bir bilgi. Özellikle bu yazıda normalde “Cloud Spanner” denirken Gmail, Ads ve Photos’tan bahsedildiğinde yalnızca “Spanner” ifadesi kullanılıyor; bu yüzden bunların Cloud Spanner altyapısını mı kullandığı, yoksa kendi altyapılarında Spanner mı çalıştırdığı belirsizleşiyor
Amazon’da neredeyse tüm servisler AWS üzerinde kurulu olduğu için bu net bir güven oyu gibi görünüyor, ancak GCP’nin tarihsel olarak Google’ın iç servislerinde çok daha az kullanıldığı izlenimine sahiptim
“DynamoDB powers multiple high-traffic Amazon properties and systems including Alexa, the Amazon.com sites, and all Amazon fulfillment centers. Over the course of Prime Day, these sources made trillions of calls to the DynamoDB API. DynamoDB maintained high availability while delivering single-digit millisecond responses and peaking at 126 million requests per second.”
Amazon bu noktayı çok net belirtmiş. Google bu sayıyı böyle bir bağlam olmadan kullandıysa, bu tamamen sinsi ve dürüst olmayan bir karşılaştırma. Bu yazıyı yazan kişide dürüstlük eksikliği var gibi görünüyor
https://www.youtube.com/watch?v=268jdNwH6AM
Blogda “Spanner is used ubiquitously inside of Google, supporting services such as; Ads, Gmail and Photos.” deniyor. Ancak Google’ın iç Spanner’ı ile GCP Spanner ayrıdır. Bir Google servisinin Spanner kullanması, mutlaka GCP kullandığı anlamına gelmez
Yine de benim anladığım kadarıyla Spanner ile GCP Spanner arasındaki ilişki, Borg ile Kubernetes arasındaki ilişkiden çok daha benzerdir
AWS’in toplam kullanımının tamamı toplansa bile, Prime Day’de Amazon’un kendi kullanımının saniyede 126 milyon sorgu olduğu düşünülürse DynamoDB’nin Spanner’ı geçip geçmeyeceği oldukça şüpheli
“Database as a Queue” diye aratırsanız ortamı anlarsınız. Aslında AWS’te ilişkisel veritabanı kullanmak gerçekten zordur; bir ekibin istisna alması için CEO onayına kadar gitmesi gerekir; bu da DDB’nin sağlamlığını gösterir
Birçok projede Postgres hâlâ ikisinden de daha ucuz. İkisini de kullandım, ama Spanner ya da DynamoDB kullanmaktansa projeyi Postgres/CockroachDB’ye uydurmayı çok daha fazla tercih ederim
Spanner ve DynamoDB’de çok daha fazla tuzak var; ani maliyet sıçramaları, satıcıya bağımlılık ve başka sorunlar da cabası. AWS, GCP, Azure, Oracle Cloud ve Kubernetes operatörü tabanlı dağıtımlara kadar Postgres’i çok iyi destekliyor; o yüzden doğrudan Postgres kullanın
Postgres’i düzgün şekilde işletebiliyorsanız elbette kullanmalısınız. Tüm verilerinizi tek bir makinedeki Postgres’e koyabiliyorsanız, küresel ölçekte ölçeklenebilen P sınıfı bir veritabanı kullanmanız için bir neden yok
Milyonlarca mesajın olduğu ve neredeyse hiç “ilişki” bulunmayan bir sohbet uygulaması geliştiriyorsam Postgres mi kullanmalıyım, yoksa NoSQL ailesinden bir şey mi, gerçekten merak ediyorum
Dağıtık fonksiyonlar ve Lambda üzerinde çalışan kodlarla uğraşırken SQL bağlantı yönetimi kâbusa dönüştü ve istek kayıpları her yerde ortaya çıkmaya başladı
PostgreSQL harika; Google’da çalışıyorum ama buna %100 katılıyorum. İş görmediği noktaya kadar sadece PG kullanın. Spanner ve DynamoDB’nin alanına girdiğinizde ancak bu tartışmalar anlamlı hale gelir
Tamamen farklı ama biraz daha ucuz olan herhangi bir şey için “sadece onu kullanın” denebilir. Örneğin kayıtları commit olarak bir GitHub deposuna kaydetmek ücretsizdir ve küçük projeler için yeterince ucuz olabilir, ama aynı şey değildir
GCP Spanner “ayda 65 dolardan başlayan” fiyatlara sahipken, AWS ücretsiz katmanı “25 GB veri depolama, 2,5 milyon stream okuma isteği” vb. sunuyor
https://aws.amazon.com/dynamodb/pricing/
Grafikte bir noktada çizgiler elbette kesişecektir, ama Google’ın başlığı bence yanıltıcı
Eğitim amacı dışında küçük projelerde kullanmak için pek bir sebep yok; Spanner müşterileri örneğin CockroachDB’nin bile yetersiz kaldığı yerlerdir. O kadar devasa olmayan bir veritabanı için PostgreSQL yeterlidir
Günümüzde bir ay içinde 100 milyondan fazla kullanıcıya ulaşan çok uygulama var; 50 QPS’lik bir durumdan söz etmiyoruz. Üstelik DynamoDB’nin bayt sınırını da atlamış. 1 KB’yi tek 1 bayt bile aşarsanız 2 okuma birimi ücretlendirilir
“Google da başlangıç indirimi sunmalı” demek gayet makul, ama gerçek ürünün daha pahalı mı ucuz mu olduğunu söylemez
Kişisel projelerde veya yan projelerde Spanner’ı denemek istiyorum, ama üretime hazır bir instance ayda 65 dolardan başlıyor. DynamoDB ise istek başına ücretlendirmeyle ayda neredeyse 0 dolara çalıştırılabiliyor
Ancak istek başına ücretlendirme de yalnızca ücretsiz katman içinde kaldığında ücretsizdir. Limitleri kontrol etmek gerekir; aşarsanız artık ücretsiz değildir
CRDB mimarisi özünde içeride Spanner’a yakındır
https://www.cockroachlabs.com/get-started-cockroachdb/
Eskiden Google ürünlerini epey severdim, o yüzden kararsızım. Gmail’e oldukça bağlıyım ve GCP’de hâlihazırda çeşitli şeyler çalıştırıyorum
Ama Google’ın servisleri birden kapatmasından giderek daha çok ağzım yandı gibi hissediyorum. Tüm domain’lerimi Google Domains’te tutuyordum ve memnundum; yakın zamanda birden Squarespace’e satıldı, o şirketle iş yapmak istemiyorum
Google Pixel kullanıyorum ve Google Podcasts uygulamasını da kullanıyordum; onun da kapatılıp YouTube Music’e taşınacağını duydum. YouTube Music’i denedim ama gerçekten nefret ettim, alternatif bulmam gerekecek
Uzun vadede bunlar önemsiz servisler olabilir, ama kritik servisleri yeniden Google’a emanet etmek beni tedirgin ediyor. Zaman harcamadan önce “Bir gün Google Cloud Spanner’ı satarsa ya da kapatırsa ne olur? O zaman zor durumda kalır mıyım?” diye sormaya başlıyorum
Domain kaydı, düzenleme ve itibar açısından mayın tarlası olabilir; ama içerik dağıtımı dahil diğer bulut ürünleri de öyle. Bunun henüz Google Cloud servislerinin kapatılmasına dair büyük bir örüntü gösterdiğini söylemek zor, ama en azından sarı ışık yandı
Google ürünlerinin durdurulması sinir bozucu, ama Google Cloud ürün ve servisleriyle ilgisi yok. Google Cloud’un ücretli müşterileri var; ürün ve servis kapatmayı birden duyuracağını sanmıyorum
Google Domains bir Google ürünüdür; Google tarafındaki karşılığı, Google Cloud müşterilerine sunulan Google Cloud Domains’tir
“Her ölçekte ve her sektörden kuruluşların dijital dönüşümü hızlandırma ve AI odaklı inovasyonu ilerletme ihtiyacı artıyor” denmiş; Google nasıl bu hale geldi
Spanner’ın düğüm bazında değil de iş yükü birimi bazında ücretlendiren on-demand sürümü yoksa, birçok kullanım senaryosunda DynamoDB ile karşılaştırmak zor
Ortalama işlem hacmi tepe değerden çok daha düşük olduğundan, Spanner’da maliyet tasarrufu görüp göremeyeceğinizden şüpheliyim
Yine de geliştirme tarafında Spanner, DynamoDB’den çok daha kolay olur gibi
Google’ın servis maliyetlerini ciddi biçimde artırmışlığı var. Vendor lock-in risklidir
Başka servislerde de oldu mu merak ediyorum. AWS’in epey gerisindeki 2. ya da 3. sıradaki kurumsal bulut servisinde bunun olma olasılığı çok daha düşük görünüyor
Eski bir örnek olsa da maliyet düşürdükleri bir örnek biliyorum: https://cloudplatform.googleblog.com/2015/05/Pay-Less-Comput...
Bildiğim kadarıyla AWS örneğin servis fiyatlarını hep düşürdü
Droplet üzerinde Postgres DB çalıştırırsanız neredeyse bedavaya gelir ve performansı da oldukça iyidir
Aylık 65 dolara Hetzner’dan çok güçlü bir sunucu da alabilirsiniz. Bulut ürün menüsü denen çılgın çalılığın içinden yolunuzu bulmanız gerekiyor; ben bir kez baktıktan sonra, bunun yerine Linux yönetiminin temellerini öğrenip ömür boyu kullanmanın daha iyi olduğuna karar verdim
Postgres ile Spanner’ı karşılaştırmak, teslimat minibüsüyle treni karşılaştırmaya benzer. Trenin sabit maliyeti her zaman daha yüksektir
Linux yönetimi faydalı bir beceri, ama benim Linux yönetim yeteneğim Dynamo, S3, Spanner gibi bulut sistemlerinin güvenilirliği, erişilebilirliği ve ölçeklenebilirliğiyle rekabet edemez
Zamanın çok büyük bir kısmı, başka yerlerde pek anlamı olmayan servise özgü yapılandırma ve sorun gidermeye harcanıyor
1 GB depolama, 1 KB öğe boyutu, 100 bin yazma ve 100 bin okuma ile bir ay boyunca DynamoDB On-Demand’de 0,39 dolar tutar. Yazma ve okumayı ayrı ayrı 1 milyona çıkarsanız bile 1,63 dolar olur. Güçlü tutarlılıklı okuma kullanırsanız 1,75 dolar, işlemli yazma da kullanırsanız 3,00 dolar olur