Pengumuman peluncuran S2

 (s2.dev)
1 poin oleh GN⁺ 2024-12-22 | 1 komentar | Bagikan ke WhatsApp
  • S2 adalah pratinjau Stream Store serverless yang ingin menangani stream real-time yang tahan lama sesederhana object storage, dengan tujuan mengangkat log dan stream menjadi elemen dasar penyimpanan cloud
  • Record di-append ke tail stream, dan meskipun beberapa writer menulis secara bersamaan, S2 menangani pengurutan yang tahan lama sehingga mendukung pembacaan historis maupun tailing real-time
  • Basin di S2 berperan sebagai namespace untuk stream seperti bucket, memungkinkan pemodelan seperti stream per pengguna tanpa batas jumlah stream maupun periode retensi
  • Kelas penyimpanan dimulai dengan Standard dan Express, masing-masing menargetkan latensi p99 di bawah 500ms dan di bawah 50ms, sehingga memisahkan opsi latensi dan biaya
  • Saat ini tersedia gRPC API, Rust SDK, dan CLI, dengan REST API, kompatibilitas protokol Kafka, multi-region basins, dan latensi di bawah 5ms sebagai langkah berikutnya

Model penyimpanan stream yang diajukan S2

  • S2 menargetkan Stream Store serverless untuk data streaming di era cloud
  • Gagasan utamanya adalah bahwa log atau stream juga dapat menjadi elemen dasar penyimpanan cloud seperti object
  • Object storage berfokus pada PUT / GET / DELETE untuk objek bernama serta blob dan byte range, sehingga cocok untuk data at-rest
  • Penyimpanan stream S2 menyediakan APPEND / READ / TRIM untuk Stream bernama, dengan record dan sequence number sebagai unit dasar
  • Penulisan dilakukan dengan append ke tail stream, dan meskipun beberapa writer mencatat secara bersamaan, S2 mengurutkan semua record dan menjamin durabilitas
  • Pembacaan dapat dimulai dari hitungan detik yang lalu hingga bertahun-tahun, dan juga memungkinkan tailing real-time yang sulit dilakukan dengan blob S3
  • Basin berperan sebagai namespace untuk stream, seperti bucket yang menjadi namespace untuk object
    • basin dan stream dapat digunakan tanpa batas jumlah
    • tidak ada batas pada periode retensi data
    • pemodelan stream per pengguna juga dimungkinkan, tanpa perlu menangani batas cluster atau tuning infrastruktur seperti di Kafka
  • Operasi untuk memeriksa tail stream dengan konsistensi kuat dan kontrol konkurensi saat menulis juga didukung
    • pendekatan pesimistis dengan fencing token dimungkinkan
    • pendekatan optimistis dengan memberikan sequence number yang diharapkan juga dimungkinkan
    • desain ini menargetkan offloading durabilitas serta pemisahan compute dan storage yang dimanfaatkan database seperti MemoryDB dan Neon

Performa, harga, fitur yang tersedia saat ini, dan roadmap

  • Berdasarkan skalabilitas dan durabilitas object storage, S2 menyediakan API serverless dalam bentuk layanan multi-tenant
  • Durabilitas ditempatkan sebagai aspek yang tidak bisa dikompromikan, sementara pilihan latensi dan biaya disesuaikan melalui storage class per stream
    • Standard: berbasis AWS S3 Standard, dan karena ada produk padanan di semua penyedia cloud publik, S2 menilai ini dapat tersedia di semua region cloud seiring pertumbuhan
    • Express: berbasis quorum 3 bucket AWS S3 Express One Zone, dengan padanan regional di Azure dan kemungkinan juga di GCP
  • Target performa dan batas awalnya adalah sebagai berikut
    • Standard menyediakan latensi p99 end-to-end di bawah 500ms
    • Express diharapkan dapat memberikan latensi di bawah 50ms
    • semua write disimpan dengan aman ke S3 dengan durabilitas regional sebelum acknowledgement
    • throughput mendukung ratusan MB per detik per stream
    • pembacaan data yang baru ditulis memiliki overhead kecil berkat caching in-memory
    • reader yang tertinggal dilayani langsung dari object storage tanpa batas atas
    • pada tahap awal, write dibatasi hingga 125 MiBps per stream, dan read untuk write terbaru hingga 500 MiBps per stream
  • Selama masa pratinjau, layanan ini tersedia gratis, dan intended pricing telah dipublikasikan dengan target harga yang secara berarti lebih murah daripada tingkat umum sistem streaming cloud
  • Tidak ada biaya tetap seperti instance atau unit cluster
  • Antarmuka pengembang yang saat ini tersedia adalah sebagai berikut
  • Sistem ini dibangun di atas infrastruktur cloud yang telah teruji, dan codebase Rust-nya menjalani deterministic simulation testing
    • karena sistem ini masih muda, masalah masih mungkin ada
    • sistem ini sedang dimatangkan menuju general availability dan SLA yang dapat diandalkan di produksi
  • Roadmap berikutnya diringkas dalam tiga sumbu
    • Kafka protocol compatibility: akan disediakan sebagai lapisan open source, dan beberapa fitur seperti key-based compaction direncanakan untuk diintegrasikan langsung ke S2
    • Multi-region basins: setelah diperluas ke lebih banyak region cloud, ada kemungkinan basin yang melintasi region dan cloud
    • Under 5 millisecond latencies: dengan fleksibilitas struktural storage class, S2 menilai peningkatan tambahan 10x dibanding Express dimungkinkan
  • Jika Anda terutama menggunakan API “low-level” dari Kafka atau Kinesis, S2 secara langsung menargetkan kebutuhan seperti tanpa batas jumlah stream, ordered throughput 10–100x lebih tinggi, dan kontrol konkurensi

Bacaan terkait

1 komentar

 
GN⁺ 2024-12-22
Opini di Hacker News

  • Saya bukan ahli hukum, tetapi memberi nama produk S2 dan dalam perkenalannya mengatakan bahwa ini teknologi untuk memperbaiki AWS S3 tampaknya sangat berpotensi memicu klaim merek dagang/hak cipta dari Amazon
    Karena berada di bidang yang sama, kebingungan konsumen juga jelas bisa terjadi. Tentu mereka pasti sudah meneliti apakah merek dagangnya terdaftar, tetapi: https://tsdr.uspto.gov/#caseNumber=98324800&caseSearchType=U...

    • Fakta menarik: dalam bahasa Spanyol, S2 dan EC2 sama-sama terdengar persis seperti “ese dos”
      EC2 dan S3 saja sudah membingungkan untuk dibedakan dengan telinga, dan sekarang ditambah satu lagi
    • Agar adil, kalau dibuat dengan tujuan memperbaiki S3, sepertinya lebih tepat disebut S4
    • Setidaknya R2 milik Cloudflare punya argumen untuk namanya
      Penamaannya ala IBM vs HAL, yaitu gaya 『2001: A Space Odyssey』
    • Entah mereka berkonsultasi dengan pengacara merek dagang yang buruk, atau sama sekali tidak berkonsultasi, tetapi biayanya seharusnya tidak semahal itu
      Saya baru-baru ini mulai proses pengajuan merek dagang, dan berdasarkan situs registrar domain, biayanya kurang lebih mirip dengan membeli domain seperti s4.dev. Rebranding setelah peluncuran jauh lebih menyakitkan daripada menggantinya sebelum peluncuran
    • Amazon bisa saja membuat hal yang sama dan menamainya S3 Streams, lalu tidak memedulikan S2
      Mungkin juga mereka mengajukan penawaran akuisisi, dan kemungkinan sampai gugatan tampaknya sangat kecil

  • Idenya benar-benar bagus dan API-nya juga indah, dan saya ingin memakainya di proyek saya, tetapi saya sama sekali tidak yakin startup ini akan bertahan lama dalam bentuknya sekarang
    Jika berhasil, AWS akan membuat versi internal yang lebih baik dan lebih murah; sebaliknya, kemungkinan besar juga bisa gagal mendapatkan traction di pasar. Akan jauh lebih masuk akal jika ini hadir sebagai produk pengguna akhir yang menyertakan dashboard seperti Papertrail, bukan API “komponen dasar cloud” yang sangat erat terikat dengan AWS. Jika memungkinkan pengguna membawa langsung backend kompatibel S3 seperti Digital Ocean Spaces, ini akan menjadi produk cloud-netral yang bagus dan tahan lama

    • Dari sisi pendiri, mereka merencanakan multi-cloud, dan sekarang mulai dari AWS terlebih dahulu
      Arsitektur internalnya tidak terikat pada AWS, melainkan struktur antarmuka yang bisa diimplementasikan untuk sistem cloud lain
    • Akan cukup ironis jika seluruh hal ini sudah berjalan di atas AWS
      Tidak ada habisnya startup yang mengemas perangkat lunak open source yang sudah ada sebagai layanan dan memasarkannya lebih murah daripada produk AWS, tetapi ternyata berjalan di AWS
    • Bantahan yang sama terus muncul juga untuk Aptible(https://aptible.com), tetapi setelah lebih dari 10 tahun, ia masih tetap menjadi PaaS yang sangat sukses
    • Jika bergerak di infrastruktur cloud, AWS memang akan mencoba menekan dari sisi harga, tetapi mereka tidak akan pernah lebih baik dalam developer experience/user experience
      Jadi menurut saya tidak perlu berhenti hanya karena Beezus
    • AWS sudah melakukan hal serupa: https://news.ycombinator.com/item?id=42211280
      “Amazon S3 now supports the ability to append data to an object” diumumkan 30 hari lalu, dan Azure juga sudah lama memiliki fitur yang sama dengan append blob. Ini masih lebih mentah daripada S2 dan belum punya konsep record, tetapi langkah bagi penyedia cloud untuk menyediakannya secara native sangat kecil. Jika sampai memasukkan konsep record, pada dasarnya ini lebih dekat ke message queue, dan ruang persaingan itu juga sama besarnya, begitu pula area solusi penyimpanan log

  • Saya ingin memahami. Jika dibangun di atas AWS, AWS mengenakan biaya $0,09 per GB untuk egress internet, lalu di sini mereka menagih egress internet $0,05 per GB?
    Kedengarannya seperti mensubsidi biaya egress AWS. Atau mereka bisa memakai tarif egress yang tidak dipublikasikan?

    • Dari sisi pendiri, selama periode preview mereka tidak mengenakan biaya
      Mereka akan menyelesaikannya ketika mencapai skala yang berarti, dan jelas ada beberapa asumsi di sini
    • Bahkan berdasarkan harga daftar, setelah 150TB biayanya $0,05 per GB, dan untuk volume besar lebih murah lagi
    • Sepertinya mereka bertaruh bahwa sebagian besar pengguna berada di dalam AWS sehingga hanya perlu membayar biaya transfer 1–2 sen
    • Tempat yang punya skala cukup tidak membayar harga ritel untuk transfer data
    • Sepertinya sekarang mereka mengubahnya menjadi $0,08 per GB
      Dengan begitu, pada 50TB kerugiannya maksimal $300 per bulan, dan setelah itu mulai menghasilkan uang

  • Ini pada dasarnya WarpStream, tetapi bukannya langsung menuju kompatibilitas Kafka, mereka menyediakan API pada level yang lebih rendah?
    Jika diadopsi dalam jangka panjang, API dasar setingkat S3 untuk streaming tampaknya benar-benar bernilai

    • Dari sisi pendiri, itu ringkasan yang kurang lebih benar
      Namun pendekatan arsitekturnya berbeda dari WarpStream, sehingga bisa memberikan latensi yang jauh lebih rendah. Sistemnya juga tidak punya disk

  • Orang-orang ini pada dasarnya secara sadar memilih untuk sepanjang karier mereka menjelaskan “sebenarnya kami bukan S3”

    • Dari sisi pendiri, bisa dibilang 50% namanya berbeda
    • Sekarang sudah ada berapa banyak layanan penyimpanan huruf+angka seperti ini? S3, B2, R2, S2...
    • Atau ada juga ini: https://github.com/google/s2geometry
    • Meski begitu, tampaknya masih lebih baik daripada harus menjelaskan bahwa mereka bukan organisasi paramiliter yang melakukan kejahatan perang yang tak terlukiskan
      Itu bukan bahan lelucon
    • Bukankah mereka mungkin juga harus menjelaskannya di pengadilan atau di hadapan pengacara? Saya bukan ahli hukum, tetapi ini terlihat seperti mengundang Amazon untuk berargumen bahwa mereka sengaja memanfaatkan merek dagang “S3” dan menciptakan kebingungan demi membesarkan merek sendiri
      Secara pribadi menurut saya argumen itu benar, dan di teks utamanya pun terlihat cukup transparan

  • Kelihatannya bagus, tapi apakah tidak ada Java SDK?
    Secara pribadi, di perusahaan-perusahaan tempat saya bekerja, dalam 90% kasus produksi/konsumsi Kafka sangat bergantung pada Spring atau klien bawaan. Ini praktis menghalangi bahkan proof of concept yang ringan sekalipun.

    • Dari pihak tim S2, Java/Kotlin SDK dan Python SDK ada dalam daftar ke depannya.
      Saat ini ada Rust SDK dan CLI (https://s2.dev/docs/quickstart). Layanan intinya juga ditulis dengan Rust, jadi Rust terasa seperti titik awal yang baik.

  • Saya suka ini. Hal berikutnya yang saya harap seseorang bangun di atasnya adalah bagian yang menerapkan “event” stream menjadi representasi yang bisa di-query pada titik waktu tertentu.
    Pada dasarnya ini adalah separuh lain untuk membuat sesuatu yang mirip Datomic. Daripada database tertentu, sepertinya akan lebih baik berupa pola atau framework untuk membuat data in-memory yang konkret dan bisa di-query. Ada berbagai cara yang mungkin: menerapkannya ke Sqlite lokal, atau berdasarkan MySQL binlog menerapkannya ke instance query lokal lalu memutarnya kembali ke titik waktu tertentu, atau menerapkan event apply/undo per aplikasi ke state lokal.

  • Sekitar 10 tahun lalu saya memulai Gazette [0].
    Gazette berada di titik tengah arsitektur antara Kafka dan WarpStream/S2. Ia menyediakan stream log tak terbatas berorientasi byte dengan S3 sebagai backend, tetapi broker menggunakan scratch disk lokal untuk replikasi awal/jaminan durability dan untuk mengurangi latensi append/read. Jadi p99-nya bukan di atas 500 ms, melainkan di bawah 5 ms, dan ia menjamin semua file sampai ke S3 dengan fitur praktis seperti batas ukuran target/kompresi/latensi yang bisa dikonfigurasi. Klien yang membaca data lama mengambil konten langsung dari S3, lalu setelah itu beralih ke live tailing untuk append yang sangat baru.
    Gazette bermula sebagai tool internal di startup sebelumnya, dan ketika membangun perusahaan sekarang, kami sempat sangat singkat mempertimbangkan untuk menawarkannya sebagai raw service [1], lalu mengubah arah menjadi platform perpindahan data menyeluruh [2] yang memakai Gazette sebagai detail implementasi internal. Positioning pasar untuk layanan seperti ini sangat sempit. Anda harus membuatnya kompatibel API dengan apa yang sudah dipakai pelanggan target sehingga biaya mencoba menjadi 0 (WarpStream melakukan ini dengan baik), atau naik lebih tinggi di stack aplikasi dan menyelesaikan masalah yang sebenarnya ingin diselesaikan pelanggan secara lebih langsung.
    [0]: https://gazette.readthedocs.io/en/latest/
    [1]: https://news.ycombinator.com/item?id=21464300
    [2]: https://estuary.dev

    • Dari pihak pendiri S2, selamat atas keberhasilan Estuary.
      Anda bukan orang pertama yang mengatakan pasar ini tidak ada atau sangat kecil. Namun ketika Anda juga mencari validasi di HN, Anda pasti merasa ada sesuatu di sini. Di atas S2 kami bisa menyediakan jauh lebih banyak hal seperti kompatibilitas Kafka, tetapi komponen dasar inti itu penting. Secara pribadi saya juga menginginkannya, dan karena saya melihatnya dibuat ulang di berbagai konteks lalu digunakan kembali secara tidak efisien dalam bentuk sistem yang kehilangan sifat aslinya, keyakinan itu saja sudah cukup untuk menjadi founder. Saya memahami latar belakang saran Anda, tahu kesulitan yang akan datang, dan berterima kasih atas sarannya.

  • Ini model layanan yang sangat berguna, tetapi jika semua write dipersistenkan ke S3 sebelum acknowledgment, proposisi nilainya terasa membingungkan.
    Penulis mungkin bisa melakukan batching kumpulan record sebelum menuliskannya sebagai blob yang lebih besar, dan proses background bisa melakukan compaction, tetapi bukankah ini tetap layanan streaming berbasis object storage? AWS sudah menunjukkan bahwa mereka umumnya bersedia mengimplementasikan layanan yang kompatibel protokol, seperti saat beralih dari RDS ke Aurora, dan tampaknya mereka bisa melakukan hal yang sama untuk reimplementasi Kafka.

    • Dari pihak tim S2, pada dasarnya memang seperti itu.
      Jika chunk yang ditulis ke object storage sebelum mengonfirmasi write dirancang multi-tenant dan memuat record dari stream yang berbeda bersama-sama, Anda bisa sering melakukan write sambil tetap menargetkan ukuran blob yang ideal dari sisi harga/performa untuk masing-masing PUT S3 Standard dan Express.

  • Teknologinya terlihat sangat keren. Hanya saja sayang ini bukan source-available.
    Mungkin ini pendapat minoritas, tetapi jika teknologi intinya dibuka dengan lisensi seperti FSL dan self-hosting yang didukung penuh dimungkinkan, saya akan sangat mempertimbangkan layanan komersialnya. Kalau tidak, sulit membenarkan ketergantungan dibandingkan sesuatu seperti Kafka.

    • Dari pihak founder, kami menyambut adanya implementasi alternatif untuk S2 API.
      Kami juga sedang mempertimbangkan emulator in-memory yang akan kami rilis sebagai open source. API-nya sendiri tidak terlalu rumit. Jika Anda ingin mempertahankan Kafka API sambil mendapatkan fitur seperti kelas penyimpanan S2, jumlah topic/partition yang sangat banyak, dan throughput tinggi per partition, kami sedang merencanakan lapisan kompatibel Kafka open source yang bisa di-self-host. Kami juga akan memasukkan fitur seperti enkripsi sisi klien agar bisa lebih meyakinkan.