S2’nin Duyurusu

 (s2.dev)
1 puan yazan GN⁺ 2024-12-22 | 1 yorum | WhatsApp'ta paylaş
  • S2, dayanıklı gerçek zamanlı stream’leri nesne depolama kadar basit ele almayı amaçlayan serverless Stream Store önizlemesidir; log’ları ve stream’leri bulut depolamanın temel yapı taşları seviyesine taşımayı hedefler
  • Kayıtlar stream tail’e append edilir; birden çok writer aynı anda yazsa bile S2 dayanıklı sıralamayı üstlenir ve hem geçmiş okumayı hem de gerçek zamanlı tailing’i destekler
  • S2’nin basin’i, bucket gibi stream’ler için namespace görevi görür; stream sayısı ve saklama süresi sınırı olmadan kullanıcı başına stream gibi modellemeleri mümkün kılar
  • Depolama sınıfları Standard ve Express ile başlar; bunlar sırasıyla p99’da 500 ms altı ve 50 ms altı gecikmeyi hedefleyerek gecikme·maliyet seçeneklerini ayırır
  • Şu anda gRPC API, Rust SDK ve CLI sunuluyor; REST API, Kafka protokol uyumluluğu, multi-region basins ve 5 ms altı gecikme sonraki adımlar arasında

S2’nin önerdiği stream depolama modeli

  • S2, bulut çağının streaming verileri için serverless Stream Store olmayı hedefler
  • Temel fikir, log’un veya stream’in de nesne gibi bulut depolamanın temel bir unsuru olabileceğidir
  • Nesne depolama, adlandırılmış nesneler için PUT / GET / DELETE işlemlerine ve blob·byte range’e odaklanır; durağan hâldeki veriler için uygundur
  • S2’nin stream depolaması, adlandırılmış Stream için APPEND / READ / TRIM sunar; kayıtları ve sıra numaralarını temel birim olarak alır
  • Yazmalar stream tail’e append edilir; birden çok writer eşzamanlı kayıt yapsa bile S2 tüm kayıtları sıralar ve dayanıklılığı garanti eder
  • Okuma, seconds ago’dan years’a kadar herhangi bir noktadan başlayabilir; S3 blob’larıyla zor olan gerçek zamanlı tailing de mümkündür
  • basin, bucket’ın object’ler için namespace görevi görmesi gibi stream’ler için namespace görevi görür
    • Basin ve stream sınırsız sayıda kullanılabilir
    • Veri saklama süresinde de sınır yoktur
    • Kullanıcı başına stream modellemesi de mümkündür; Kafka’daki gibi cluster sınırlarıyla veya altyapı ayarlarıyla uğraşmak gerekmez
  • Stream tail’i güçlü tutarlılıkla kontrol etme ve yazma sırasında eşzamanlılık kontrolü de desteklenir
    • Fencing token kullanan kötümser yaklaşım mümkündür
    • Beklenen sıra numarasını sağlayan iyimser yaklaşım mümkündür
    • Bu tasarım, MemoryDB ve Neon gibi veritabanlarının kullandığı dayanıklılık offloading’i ile compute·storage ayrımını hedefler

Performans, fiyatlandırma, mevcut özellikler ve yol haritası

  • S2, nesne depolamanın ölçeklenebilirliği ve dayanıklılığı üzerine kurulu, çok kiracılı servis biçiminde bir serverless API sunar
  • Dayanıklılık taviz verilmeyen bir unsur olarak ele alınır; gecikme ve maliyet seçimi ise stream bazında storage class ile ayarlanır
    • Standard: AWS S3 Standard tabanlıdır; tüm public cloud sağlayıcılarında karşılık gelen ürünler bulunduğu için büyüdükçe tüm bulut region’larında sunulabileceği düşünülür
    • Express: AWS S3 Express One Zone bucket’larından oluşan 3’lü quorum tabanlıdır; Azure’da regional counterpart vardır ve GCP’de de olasılık olduğu düşünülür
  • Performans hedefleri ve ilk sınırlamalar şöyledir
    • Standard, end-to-end p99’da 500 ms altı gecikme sağlar
    • Express için 50 ms altı gecikme beklenebilir
    • Tüm write’lar, acknowledgement öncesinde regional durability ile S3’e güvenli şekilde kaydedilir
    • Throughput, stream başına saniyede yüzlerce MB seviyesini destekler
    • Yakın zamanda yazılan verilerin okunmasında in-memory caching sayesinde overhead düşüktür
    • Gecikmiş reader’lara doğrudan object storage üzerinden hizmet verilir ve cap yoktur
    • Başlangıçta write’lar stream başına 125 MiBps, yakın tarihli write’lara yönelik read’ler stream başına 500 MiBps ile sınırlandırılır
  • Önizleme döneminde ücretsiz sunulur; bulut streaming sistemlerinin genel seviyesinden anlamlı ölçüde daha ucuz bir fiyat hedefiyle intended pricing yayımlanmıştır
  • Instance veya cluster unit gibi sabit maliyetler yoktur
  • Şu anda sunulan geliştirici arayüzleri şunlardır
  • Sistem, kendini kanıtlamış bulut altyapısının üzerindedir; Rust codebase’i deterministic simulation testing’den geçer
    • Sistem hâlâ genç olduğu için sorunlar olabilir
    • General availability ve production’da güvenilebilecek SLA’ya doğru olgunlaştırılmaktadır
  • Sonraki yol haritası üç eksende özetlenir
    • Kafka protocol compatibility: Açık kaynak bir katman olarak sunulacak; key-based compaction gibi bazı özellikler doğrudan S2’ye entegre edilecektir
    • Multi-region basins: Daha fazla bulut region’ına genişledikten sonra region’lar ve bulutlar arasında çalışabilen basin olasılığı değerlendirilecektir
    • Under 5 millisecond latencies: Storage class’ın yapısal esnekliği sayesinde Express’e kıyasla ek 10 kat iyileşmenin mümkün olduğu düşünülür
  • Kafka veya Kinesis’in “low-level” API’lerini ağırlıklı olarak kullanıyorsanız S2; sınırsız stream sayısı, 10-100 kat daha yüksek ordered throughput ve eşzamanlılık kontrolü gibi ihtiyaçları doğrudan hedefler

İlgili okumalar

1 yorum

 
GN⁺ 2024-12-22
Hacker News yorumları

  • Hukukçu değilim ama ürüne S2 adını verip tanıtımda AWS S3'ü iyileştiren bir teknoloji olduğunu söylemek, Amazon'dan marka/telif hakkı iddiaları gelmesine yol açma ihtimali yüksek görünüyor.
    Aynı alanda oldukları için tüketici karışıklığı da kesinlikle oluşabilir. Marka tescilini elbette araştırmışlardır ama: https://tsdr.uspto.gov/#caseNumber=98324800&caseSearchType=U...

    • İlginç bilgi: İspanyolcada S2 ve EC2 ikisi de “ese dos” diye aynı duyuluyor.
      Zaten EC2 ile S3'ü kulaktan ayırt etmek karışıkken buna bir tane daha eklenmiş oluyor.
    • Adil olmak gerekirse, amaç S3'ü iyileştirmekse buna S4 demek daha doğru olur gibi.
    • En azından Cloudflare'in R2 adı için bir gerekçesi var.
      IBM'e karşı HAL, yani 『2001: A Space Odyssey』 tarzı bir adlandırma.
    • Kötü bir marka avukatına mı danıştılar, yoksa hiç mi danışmadılar bilmiyorum ama maliyeti o kadar yüksek olmazdı.
      Yakın zamanda marka başvuru sürecine başladım; alan adı kayıt şirketi web sitelerindeki fiyatlara göre s4.dev gibi bir alan adı satın alma maliyetine benziyordu. Lansmandan sonra rebranding yapmak, lansmandan önce değiştirmekten çok daha sancılıdır.
    • Amazon aynı şeyi yapıp S3 Streams diye adlandırabilir ve S2'yi umursamayabilir de.
      Belki satın alma teklifi bile yapabilir; davaya kadar gitme ihtimali çok düşük görünüyor.

  • Fikir gerçekten çok iyi, API de güzel ve kendi projemde kullanmak isterim; ama bu startup'ın mevcut haliyle uzun süre dayanacağına hiç güvenmiyorum.
    Başarılı olursa AWS daha iyi ve daha ucuz bir dahili sürümünü yapacaktır; tersine, pazarda traction elde edememe ihtimali de yüksek. AWS'e sıkı sıkıya bağlı bir “bulut temel bileşeni” API'si değil de Papertrail gibi dashboard içeren bir son kullanıcı ürünü olarak çıksaydı çok daha mantıklı olurdu. Üstüne Digital Ocean Spaces gibi S3 uyumlu backend'leri doğrudan getirebilme imkânı eklense, harika ve kalıcı bir bulut-bağımsız ürün olurdu.

    • Kurucu açısından bakınca multi-cloud planlanıyor ve şu anda AWS ile başlanıyor.
      İç mimari AWS'e bağlı değil; başka bulut sistemleri için uygulanabilir bir arayüz yapısında.
    • Bütün bunlar zaten AWS üzerinde çalışıyorsa epey ironik olur.
      Mevcut açık kaynak yazılımları hizmet olarak paketleyip AWS ürünlerinden daha ucuz diye pazarlayan, ama aslında AWS üzerinde çalışan startup'ların sonu yok.
    • Aptible(https://aptible.com) için de sürekli aynı itiraz geliyordu, ama 10 yılı aşkın süre sonra hâlâ çok başarılı bir PaaS olarak duruyor.
    • Bulut altyapısı tarafında çalışırsanız AWS fiyatla sizi aşağı çekmeye çalışır, ama geliştirici deneyimi/kullanıcı deneyimi tarafında asla daha iyisini yapamaz.
      Bu yüzden Beezus yüzünden durmaya gerek olmadığını düşünüyorum.
    • AWS zaten benzer bir şey yaptı: https://news.ycombinator.com/item?id=42211280
      “Amazon S3 now supports the ability to append data to an object” 30 gün önce duyuruldu; Azure da append blob ile uzun zamandır aynı işleve sahipti. Henüz S2'den daha ham ve record kavramı yok, ama bulut sağlayıcısının bunu native olarak sunması için gereken adım çok küçük. Record kavramını da eklerseniz aslında mesaj kuyruğuna yakın bir şeye dönüşüyor; o rekabet alanı da benzer şekilde büyük, log depolama çözümleri tarafı da benzer.

  • Anlamaya çalışıyorum. AWS üzerinde kurulduğunda AWS internet çıkışı için GB başına $0.09 alıyor; burada ise internet çıkışı GB başına $0.05 mi ücretlendiriliyor?
    AWS çıkış maliyetini sübvanse ediyorlarmış gibi geliyor. Yoksa açıklanmayan bir çıkış birim fiyatı mı kullanabiliyorlar?

    • Kurucu açısından bakınca preview döneminde ücretlendirme yok.
      Anlamlı bir ölçeğe ulaşıldığında çözülecek ve burada kesinlikle birkaç varsayım var.
    • Liste fiyatına göre bile 150TB'den sonra GB başına $0.05 ve yüksek hacimlerde bundan da ucuz.
    • Kullanıcıların çoğunun AWS içinde olup yalnızca 1-2 sent transfer maliyeti ödeyeceği üzerine bahis oynuyor gibi görünüyorlar.
    • Yeterli ölçeğe sahip yerler veri transferi için perakende fiyat ödemez.
    • Şimdi GB başına $0.08 olarak değiştirmiş gibi görünüyorlar.
      Böyle olunca 50TB'de ayda en fazla $300 zarar ederler, sonrasında para kazanmaya başlarlar.

  • Bu temelde WarpStream, ama doğrudan Kafka uyumluluğuna gitmek yerine daha düşük seviyeli bir API sunan hali mi?
    Uzun vadede benimsenirse streaming için S3 seviyesinde temel bir API gerçekten değerli görünüyor.

    • Kurucu açısından bakınca bu bir ölçüde doğru bir özet.
      Ancak WarpStream'den farklı bir mimari yaklaşımı var ve bu yüzden çok daha düşük gecikme sağlayabiliyor. Sistemde disk de yok.

  • Bu insanlar kariyerlerinin geri kalanında “aslında biz S3 değiliz” diye açıklama yapmayı bilinçli olarak seçmiş oluyor.

    • Kurucu açısından bakınca adın %50'si farklı sayılabilir.
    • Bu tür harf+rakam depolama hizmetleri artık kaç tane oldu? S3, B2, R2, S2...
    • Ya da şu da var: https://github.com/google/s2geometry
    • Yine de tarif edilemez savaş suçları işlemiş bir paramiliter örgüt olmadığını açıklamaktan daha iyi görünüyor.
      Bu gülünecek bir şey değil.
    • Mahkemede ya da avukatların önünde de böyle açıklamak zorunda kalabilirler mi? Hukukçu değilim ama bu, Amazon'a “S3” markasını kasıtlı olarak kullanıp karışıklık yaratarak kendi markalarını büyütmeye çalıştıklarını iddia etmesi için davetiye çıkarıyor gibi görünüyor.
      Şahsen bunun doğru bir iddia olduğunu düşünüyorum ve metinde de oldukça şeffaf biçimde görülüyor.

  • Güzel görünüyor ama Java SDK yok mu?
    Kişisel olarak çalıştığım şirketlerde, vakaların %90'ında Kafka üretme/tüketme için Spring'e ya da temel istemciye derinden bağımlı olunuyordu. Bu da hafif bir kavram kanıtlamayı bile fiilen engelliyor

    • S2 ekibi açısından, ileride listede Java/Kotlin SDK ve Python SDK var
      Şu anda Rust SDK ve CLI var (https://s2.dev/docs/quickstart). Çekirdek servis de Rust ile yazıldığı için Rust iyi bir başlangıç noktası gibi geldi

  • Bunu sevdim. Sırada birinin bunun üzerine inşa etmesini istediğim şey, stream “event”lerini belirli bir zamanda sorgulanabilir bir temsile uygulama kısmı
    Temelde Datomic benzeri bir şey yapmak için gereken diğer yarı bu. Belirli bir veritabanındansa, somut bellek içi sorgulanabilir veri oluşturmak için bir desen ya da framework daha iyi olabilir gibi. Yerel Sqlite'a uygulamak, MySQL binlog'u temel alarak yerel bir sorgu instance'ına uygulayıp belirli bir zamana geri sarmak ya da uygulamaya özel apply/undo event'lerini yerel duruma uygulamak gibi birçok yol mümkün

  • Yaklaşık 10 yıl önce Gazette'i başlattım [0]
    Gazette, mimari olarak Kafka ile WarpStream/S2 arasında bir yerde duruyor. Arka uç olarak S3 kullanan sonsuz, byte odaklı log stream'leri sağlıyor; ancak broker'lar ilk replikasyon/dayanıklılık garantisi ve append/read gecikmesini azaltmak için yerel scratch disk kullanıyor. Bu yüzden p99 500 ms'nin üzerinde değil, 5 ms'nin altında; ayrıca yapılandırılabilir hedef boyut/sıkıştırma/gecikme sınırları gibi kullanışlı özelliklerle birlikte tüm dosyaların S3'e ulaşmasını garanti ediyor. Geçmiş verileri okuyan istemciler içeriği doğrudan S3'ten alıyor ve ardından çok yakın zamandaki append'lerin live tailing'ine geçiyor
    Gazette, önceki startup'ın dahili aracı olarak başladı; mevcut şirketi kurarken bunu raw service olarak sunma seçeneğini [1] çok kısa süre değerlendirdik, sonra Gazette'i dahili bir uygulama detayı olarak kullanan genel bir veri taşıma platformuna [2] yöneldik. Böyle bir servisin pazar konumlandırması son derece dar. Ya hedef müşterinin zaten kullandığı şeyle API uyumlu yapıp deneme maliyetini 0'a indirirsiniz (WarpStream bunu iyi yaptı) ya da uygulama stack'inde daha yukarı çıkıp müşterinin gerçekten çözmeye çalıştığı problemi daha doğrudan çözmeniz gerekir
    [0]: https://gazette.readthedocs.io/en/latest/
    [1]: https://news.ycombinator.com/item?id=21464300
    [2]: https://estuary.dev

    • S2 kurucusu açısından, Estuary'nin başarısını tebrik ederim
      Bu pazarın olmadığı ya da çok küçük olduğu söylendiğini ilk kez duymuyorum. Ama siz de HN'de doğrulama ararken bir şeyler olduğunu düşünmüş olmalısınız. S2'nin üzerine Kafka uyumluluğu gibi çok daha fazla şey sunabiliriz; ancak çekirdek temel yapı taşı önemli. Şahsen ben de bunu istedim ve her türlü bağlamda yeniden oluşturulup asıl niteliğini kaybetmiş sistem biçimleriyle verimsizce yeniden kullanıldığını gördüğüm için, tek başına bu inanç bile kurucu olmama yetti. Tavsiyenin arka planını anlıyorum, önümüzdeki zorlukların da farkındayım ve tavsiye için teşekkür ederim

  • Çok kullanışlı bir servis modeli, ancak tüm yazmalar onay yanıtından önce S3'e kalıcı olarak yazılıyorsa değer önerisi kafa karıştırıcı
    Yazar record gruplarını daha büyük bir blob olarak yazmadan önce batch'leyebilir ve arka plan süreci compaction yapabilir; ama bu yine de nesne depolama tabanlı bir streaming servisi değil mi? AWS, RDS'den Aurora'ya giderken olduğu gibi genelde protokol uyumlu servisler uygulamaya istekli olduğunu gösterdi ve Kafka'yı yeniden uygularken de aynı şeyi yapabilir gibi görünüyor

    • S2 ekibi açısından, özünde yöntem tam olarak bu
      Yazmaları onaylamadan önce nesne depolamaya yazan chunk'ları çok kiracılı olacak ve farklı stream'lerin record'larını birlikte içerecek şekilde tasarlarsanız, sık yazarken bile S3 standard ve express PUT için fiyat/performans açısından ideal blob boyutlarını hedefleyebilirsiniz

  • Teknoloji gerçekten harika görünüyor. Yalnız kaynak kodunun açık olmaması üzücü
    Azınlık görüşü olabilir ama çekirdek teknoloji FSL gibi bir lisansla açık olsaydı ve tamamen desteklenen self-hosting mümkün olsaydı, ticari servisi kesinlikle değerlendirirdim. Aksi halde Kafka gibi bir şeye kıyasla bağımlılığı gerekçelendirmek zor

    • Kurucu açısından, S2 API'sinin alternatif uygulamalarının ortaya çıkmasını memnuniyetle karşılarız
      Kendimizin açık kaynak olarak yayımlayacağı bir bellek içi emülatörü de değerlendiriyoruz. API'nin kendisi pek karmaşık değil. Kafka API'sini korurken S2'nin depolama sınıfları, çok yüksek sayıda topic/partition ve partition başına yüksek throughput gibi özellikleri elde etmek istiyorsanız, self-host edilebilir açık kaynak Kafka uyumluluk katmanı planlıyoruz. İstemci tarafı şifreleme gibi özellikler de ekleyerek daha fazla güven sağlamayı amaçlıyoruz