Công bố ra mắt S2

 (s2.dev)
1 điểm bởi GN⁺ 2024-12-22 | 1 bình luận | Chia sẻ qua WhatsApp
  • S2 là bản xem trước của một Stream Store serverless nhằm xử lý các luồng thời gian thực bền vững đơn giản như object storage, với mục tiêu nâng log và stream thành thành phần cơ bản của cloud storage
  • Bản ghi được append vào tail của stream, và ngay cả khi nhiều writer ghi đồng thời thì S2 vẫn đảm nhiệm việc sắp thứ tự bền vững, hỗ trợ cả đọc dữ liệu lịch sử lẫn tailing thời gian thực
  • Basin của S2 đóng vai trò namespace của stream giống như bucket, cho phép mô hình hóa như stream theo từng người dùng mà không bị giới hạn số lượng stream hay thời gian lưu giữ
  • Các storage class bắt đầu với Standard và Express, lần lượt nhắm tới độ trễ p99 dưới 500ms và dưới 50ms, tách bạch các lựa chọn giữa độ trễ và chi phí
  • Hiện cung cấp gRPC API, Rust SDK, CLI, và đặt REST API, khả năng tương thích giao thức Kafka, multi-region basins, cùng độ trễ dưới 5ms làm các bước tiếp theo

Mô hình lưu trữ stream mà S2 đề xuất

  • S2 hướng tới một Stream Store serverless cho dữ liệu streaming trong kỷ nguyên đám mây
  • Ý tưởng cốt lõi là log hoặc stream cũng có thể trở thành thành phần cơ bản của cloud storage như object
  • Object storage tập trung vào PUT / GET / DELETE cho các object có tên, cùng blob và byte range, phù hợp với dữ liệu ở trạng thái tĩnh
  • Stream storage của S2 cung cấp APPEND / READ / TRIM cho Stream có tên, lấy bản ghi và số thứ tự làm đơn vị cơ bản
  • Ghi dữ liệu được append vào tail của stream, và dù nhiều writer cùng ghi thì S2 vẫn sắp thứ tự toàn bộ bản ghi và đảm bảo độ bền vững
  • Việc đọc có thể bắt đầu từ vài giây trước cho tới nhiều năm trước, đồng thời hỗ trợ tailing thời gian thực vốn khó thực hiện với blob trên S3
  • Basin đóng vai trò namespace cho stream giống như bucket là namespace của object
    • Có thể dùng basin và stream mà không bị giới hạn số lượng
    • Không có giới hạn về thời gian lưu giữ dữ liệu
    • Cũng có thể mô hình hóa stream theo từng người dùng mà không cần xử lý giới hạn cluster hay tinh chỉnh hạ tầng như Kafka
  • Hệ thống cũng hỗ trợ kiểm tra tail của stream với tính nhất quán mạnh và kiểm soát đồng thời khi ghi
    • Có thể dùng cách bi quan với fencing token
    • Có thể dùng cách lạc quan bằng cách cung cấp số thứ tự kỳ vọng
    • Thiết kế này nhắm tới durable offloading và tách biệt compute-storage mà các cơ sở dữ liệu như MemoryDB và Neon đang sử dụng

Hiệu năng, giá cả, tính năng hiện có và lộ trình

  • Dựa trên khả năng mở rộng và độ bền của object storage, S2 cung cấp một API serverless theo mô hình dịch vụ đa tenant
  • Độ bền là yếu tố không thỏa hiệp, còn lựa chọn về độ trễ và chi phí được điều chỉnh bằng storage class theo từng stream
    • Standard: dựa trên AWS S3 Standard, và vì mọi nhà cung cấp public cloud đều có sản phẩm tương đương nên họ tin có thể cung cấp ở mọi khu vực cloud khi mở rộng
    • Express: dựa trên quorum của 3 bucket AWS S3 Express One Zone, có regional counterpart trên Azure và được cho là cũng có khả năng trên GCP
  • Mục tiêu hiệu năng và các giới hạn ban đầu như sau
    • Standard cung cấp độ trễ end-to-end p99 dưới 500ms
    • Express có thể kỳ vọng độ trễ dưới 50ms
    • Mọi lần ghi đều được lưu an toàn vào S3 với regional durability trước khi acknowledgement
    • Thông lượng hỗ trợ ở mức hàng trăm MB mỗi giây cho mỗi stream
    • Việc đọc dữ liệu mới ghi gần đây có overhead thấp nhờ caching trong bộ nhớ
    • Reader bị trễ sẽ được phục vụ trực tiếp từ object storage và không có cap
    • Giai đoạn đầu giới hạn write ở mức 125 MiBps mỗi stream, và read với dữ liệu ghi gần đây ở mức 500 MiBps mỗi stream
  • Trong thời gian preview sẽ được cung cấp miễn phí, đồng thời công bố intended pricing với mục tiêu rẻ hơn đáng kể so với mặt bằng chung của các hệ thống streaming trên cloud
  • Không có chi phí cố định như instance hay đơn vị cluster
  • Các giao diện cho nhà phát triển hiện được cung cấp gồm
  • Hệ thống chạy trên hạ tầng cloud đã được kiểm chứng, và codebase Rust trải qua deterministic simulation testing
    • Đây vẫn là một hệ thống còn non trẻ nên có thể vẫn tồn tại vấn đề
    • Nhóm phát triển đang hoàn thiện để hướng tới general availability và SLA đáng tin cậy trong production
  • Lộ trình tiếp theo được chia thành ba trục
    • Kafka protocol compatibility: sẽ cung cấp dưới dạng một lớp mã nguồn mở, và một số tính năng như key-based compaction sẽ được tích hợp trực tiếp vào S2
    • Multi-region basins: sau khi mở rộng sang nhiều khu vực cloud hơn, sẽ xem xét khả năng basin trải rộng qua nhiều region và cloud
    • Under 5 millisecond latencies: với tính linh hoạt về cấu trúc của storage class, họ cho rằng có thể cải thiện thêm 10 lần so với Express
  • Nếu chủ yếu dùng API “low-level” của Kafka hay Kinesis, S2 nhắm trực tiếp tới các nhu cầu như không giới hạn số lượng stream, ordered throughput cao hơn 10-100 lần và kiểm soát đồng thời

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-12-22
Ý kiến trên Hacker News

  • Tôi không phải luật sư, nhưng việc đặt tên sản phẩm là S2 và nói trong phần giới thiệu rằng đây là công nghệ cải tiến AWS S3 có vẻ rất dễ dẫn đến khiếu nại về nhãn hiệu/bản quyền từ Amazon
    Vì cùng lĩnh vực nên rõ ràng cũng có thể gây nhầm lẫn cho người tiêu dùng. Chắc hẳn họ đã kiểm tra chuyện đăng ký nhãn hiệu, nhưng: https://tsdr.uspto.gov/#caseNumber=98324800&caseSearchType=U...

    • Sự thật thú vị: trong tiếng Tây Ban Nha, S2 và EC2 đều nghe giống hệt nhau là “ese dos”
      Vốn dĩ EC2 và S3 nghe bằng tai đã dễ lẫn lộn, giờ lại thêm một cái nữa
    • Công bằng mà nói, nếu mục tiêu là cải tiến S3 thì có lẽ nên gọi là S4
    • Ít nhất R2 của Cloudflare còn có lý lẽ cho cái tên đó
      Cách đặt tên kiểu IBM so với HAL, tức theo phong cách 『2001: A Space Odyssey』
    • Không rõ họ đã tư vấn với luật sư nhãn hiệu tệ hay là hoàn toàn không tư vấn, nhưng chi phí lẽ ra cũng không quá nhiều
      Gần đây tôi bắt đầu quy trình nộp đơn nhãn hiệu, và theo trang web của nhà đăng ký tên miền thì chi phí tương đương việc mua một domain như s4.dev. Đổi thương hiệu sau khi ra mắt đau đớn hơn nhiều so với đổi trước khi ra mắt
    • Amazon có thể chỉ tự làm thứ tương tự, gọi là S3 Streams và không bận tâm đến S2
      Có khi họ còn đưa ra đề nghị mua lại, còn khả năng đi đến kiện tụng có vẻ rất thấp

  • Ý tưởng thật sự rất hay và API cũng đẹp, tôi muốn dùng cho dự án của mình, nhưng hoàn toàn không chắc startup này sẽ tồn tại lâu ở hình thái hiện tại
    Nếu thành công, AWS sẽ tạo một phiên bản nội bộ tốt hơn và rẻ hơn; ngược lại cũng có khả năng lớn là không đạt được traction trên thị trường. Nếu nó được đưa ra như một sản phẩm cho người dùng cuối có dashboard kiểu Papertrail, thay vì một API “thành phần cơ bản của cloud” gắn chặt với AWS, thì sẽ hợp lý hơn nhiều. Nếu thêm khả năng tự mang backend tương thích S3 như Digital Ocean Spaces vào, đây sẽ trở thành một sản phẩm trung lập cloud tuyệt vời và bền lâu

    • Từ góc nhìn nhà sáng lập, họ đang lên kế hoạch multi-cloud, và hiện bắt đầu với AWS trước
      Kiến trúc nội bộ không bị trói vào AWS, mà là cấu trúc interface có thể triển khai cho các hệ thống cloud khác
    • Sẽ khá trớ trêu nếu toàn bộ thứ này vốn đã chạy trên AWS
      Không thiếu những startup đóng gói phần mềm mã nguồn mở hiện có thành dịch vụ, quảng bá là rẻ hơn sản phẩm AWS, nhưng rốt cuộc lại chạy trên chính AWS
    • Aptible(https://aptible.com) cũng liên tục bị phản biện như vậy, nhưng sau hơn 10 năm vẫn là một PaaS rất thành công
    • Nếu làm về hạ tầng cloud, AWS có thể sẽ cố dìm bằng giá, nhưng về trải nghiệm lập trình viên/trải nghiệm người dùng thì họ tuyệt đối không thể làm tốt hơn
      Vì vậy tôi nghĩ không cần dừng lại vì Beezus
    • AWS đã làm thứ tương tự rồi: https://news.ycombinator.com/item?id=42211280
      “Amazon S3 now supports the ability to append data to an object” được công bố 30 ngày trước, và Azure cũng đã có chức năng tương tự từ lâu với append blob. Nó vẫn còn thô hơn S2 và chưa có khái niệm record, nhưng bước để nhà cung cấp cloud cung cấp native chuyện này là rất nhỏ. Nếu thêm cả khái niệm record thì về cơ bản nó gần với message queue, và không gian cạnh tranh đó cũng lớn tương tự, phía giải pháp lưu trữ log cũng vậy

  • Tôi muốn hiểu rõ hơn. Nếu xây dựng trên AWS thì AWS tính $0.09 mỗi GB cho lưu lượng gửi ra Internet, còn ở đây họ tính phí lưu lượng gửi ra Internet là $0.05 mỗi GB à?
    Nghe như đang bù lỗ chi phí egress của AWS. Hay là họ có thể dùng mức giá egress không công khai?

    • Từ góc nhìn nhà sáng lập, trong giai đoạn preview họ không tính phí
      Khi đạt quy mô có ý nghĩa thì họ sẽ giải quyết, và rõ ràng trong đó có vài giả định
    • Ngay cả theo giá niêm yết, sau 150TB thì cũng là $0.05 mỗi GB, và với dung lượng lớn thì còn rẻ hơn
    • Có vẻ họ đang đặt cược rằng phần lớn người dùng ở trong AWS nên chỉ phải trả 1–2 cent chi phí truyền tải
    • Những nơi có quy mô đủ lớn không trả giá bán lẻ cho truyền dữ liệu
    • Có vẻ giờ họ đã đổi thành $0.08 mỗi GB
      Như vậy ở mức 50TB thì lỗ tối đa $300/tháng, và từ sau đó bắt đầu kiếm tiền

  • Về cơ bản đây là WarpStream, nhưng thay vì đi thẳng tới khả năng tương thích Kafka thì cung cấp một API cấp thấp hơn phải không?
    Nếu được chấp nhận lâu dài, một API nền tảng ở cấp S3 cho streaming trông thật sự có giá trị

    • Từ góc nhìn nhà sáng lập, tóm tắt này phần nào đúng
      Tuy nhiên cách tiếp cận kiến trúc khác với WarpStream, nên có thể cung cấp độ trễ thấp hơn nhiều. Hệ thống cũng không có đĩa

  • Những người này coi như đã có ý thức chọn việc suốt phần còn lại của sự nghiệp phải giải thích rằng “thật ra chúng tôi không phải S3”

    • Từ góc nhìn nhà sáng lập, có thể xem là 50% cái tên khác rồi
    • Giờ đã có bao nhiêu dịch vụ lưu trữ chữ+có số kiểu này rồi? S3, B2, R2, S2...
    • Hoặc còn cái này nữa: https://github.com/google/s2geometry
    • Dù sao thì có vẻ vẫn tốt hơn việc phải giải thích rằng họ không phải một tổ chức bán quân sự từng gây ra những tội ác chiến tranh khó diễn tả
      Chuyện đó không buồn cười đâu
    • Chẳng phải có thể họ cũng phải giải thích như vậy trước tòa hoặc trước luật sư sao? Tôi không phải luật sư, nhưng chuyện này trông như đang mời Amazon lập luận rằng họ cố ý tận dụng nhãn hiệu “S3” và tạo nhầm lẫn để xây dựng thương hiệu của mình
      Cá nhân tôi nghĩ lập luận đó đúng, và trong bài gốc cũng thể hiện khá rõ ràng

  • Trông có vẻ ổn, nhưng không có Java SDK à?
    Cá nhân tôi từng làm ở các công ty mà trong 90% trường hợp họ phụ thuộc rất sâu vào Spring hoặc client cơ bản để sản xuất/tiêu thụ Kafka. Như vậy thì ngay cả proof-of-concept nhẹ cũng gần như bị chặn đứng

    • Từ phía đội ngũ S2, Java/Kotlin SDK và Python SDK nằm trong danh sách sắp tới
      Hiện có Rust SDK và CLI (https://s2.dev/docs/quickstart). Dịch vụ lõi cũng được viết bằng Rust, nên Rust có vẻ là điểm khởi đầu tốt

  • Tôi thích cái này. Điều tiếp theo tôi mong ai đó xây dựng bên trên nó là phần áp dụng “sự kiện” stream thành biểu diễn có thể truy vấn tại một thời điểm cụ thể
    Về cơ bản đây là nửa còn lại để làm ra thứ giống Datomic. Thay vì một cơ sở dữ liệu cụ thể, có lẽ một pattern hoặc framework để tạo dữ liệu in-memory có thể truy vấn cụ thể sẽ phù hợp hơn. Có thể làm theo nhiều cách, như áp dụng vào Sqlite cục bộ, hoặc dựa trên MySQL binlog để áp dụng vào một instance truy vấn cục bộ rồi tua ngược về một thời điểm cụ thể, hoặc áp dụng các sự kiện apply/undo theo từng ứng dụng vào trạng thái cục bộ

  • Tôi bắt đầu Gazette khoảng 10 năm trước [0]
    Gazette nằm ở điểm giữa về kiến trúc giữa Kafka và WarpStream/S2. Nó cung cấp các stream log vô hạn, hướng byte, dùng S3 làm backend, nhưng broker dùng đĩa scratch cục bộ để bảo đảm sao chép/độ bền ban đầu và giảm độ trễ append/read. Vì vậy p99 dưới 5ms chứ không phải hơn 500ms, đồng thời bảo đảm mọi file đều tới S3 cùng với các tiện ích như kích thước mục tiêu/nén/giới hạn độ trễ có thể cấu hình. Các client đọc dữ liệu cũ lấy nội dung trực tiếp từ S3, rồi sau đó chuyển sang live tailing các append rất mới
    Gazette bắt đầu là công cụ nội bộ của startup trước đây, và khi lập công ty hiện tại, chúng tôi đã cân nhắc rất ngắn việc cung cấp nó dưới dạng raw service [1], rồi chuyển hướng sang một nền tảng di chuyển dữ liệu tổng thể [2] dùng Gazette như chi tiết triển khai nội bộ. Định vị thị trường của loại dịch vụ này cực kỳ hẹp. Hoặc phải làm tương thích API với thứ khách hàng mục tiêu đang dùng để chi phí thử nghiệm bằng 0 (WarpStream đã làm tốt điều này), hoặc phải đi cao hơn trong application stack và giải quyết trực tiếp hơn vấn đề mà khách hàng thực sự muốn xử lý
    [0]: https://gazette.readthedocs.io/en/latest/
    [1]: https://news.ycombinator.com/item?id=21464300
    [2]: https://estuary.dev

    • Từ phía nhà sáng lập S2, xin chúc mừng thành công của Estuary
      Bạn không phải người đầu tiên nói rằng thị trường này không tồn tại hoặc rất nhỏ. Nhưng khi bạn tìm kiếm sự xác thực trên HN, chắc hẳn bạn cũng nghĩ là có gì đó ở đó. Chúng tôi có thể cung cấp nhiều thứ hơn trên S2, như tương thích Kafka, nhưng các khối xây dựng cốt lõi mới quan trọng. Cá nhân tôi cũng muốn có nó, và đã thấy nó được làm lại trong đủ loại bối cảnh rồi bị tái sử dụng kém hiệu quả dưới dạng những hệ thống đã đánh mất bản chất ban đầu; chỉ niềm tin đó thôi cũng đủ để trở thành founder. Tôi hiểu bối cảnh của lời khuyên, biết những khó khăn phía trước, và cảm ơn lời khuyên đó

  • Đây là một mô hình dịch vụ rất hữu ích, nhưng nếu mọi ghi đều được lưu bền vững vào S3 trước khi trả xác nhận thì value proposition hơi khó hiểu
    Tác giả có thể batch các nhóm record trước khi ghi thành blob lớn hơn, và một tiến trình nền có thể thực hiện compaction, nhưng rốt cuộc đây vẫn là dịch vụ streaming dựa trên object storage, phải không? AWS đã cho thấy họ nhìn chung sẵn sàng triển khai các dịch vụ tương thích giao thức, như từ RDS sang Aurora, và có vẻ họ cũng có thể làm điều tương tự với việc tái triển khai Kafka

    • Từ phía đội ngũ S2, về bản chất đúng là theo cách đó
      Nếu thiết kế chunk được ghi vào object storage trước khi xác nhận ghi theo kiểu multi-tenant, và để nó chứa record của các stream khác nhau cùng nhau, thì dù ghi thường xuyên vẫn có thể nhắm tới kích thước blob lý tưởng về giá/hiệu năng cho từng loại PUT của S3 standard và express

  • Công nghệ trông thật sự rất hay. Chỉ tiếc là không công khai mã nguồn
    Có thể đây là ý kiến thiểu số, nhưng nếu công nghệ lõi được công khai theo giấy phép như FSL và có thể tự host với hỗ trợ đầy đủ, tôi sẽ nghiêm túc cân nhắc dịch vụ thương mại. Nếu không thì khó biện minh cho sự phụ thuộc so với những thứ như Kafka

    • Từ phía nhà sáng lập, chúng tôi hoan nghênh việc xuất hiện các triển khai thay thế của S2 API
      Chúng tôi cũng đang xem xét một emulator in-memory sẽ trực tiếp phát hành open source. Bản thân API không quá phức tạp. Nếu muốn giữ Kafka API mà vẫn có các tính năng như storage class của S2, số lượng topic/partition rất lớn, throughput cao trên mỗi partition, chúng tôi đang lên kế hoạch cho một lớp tương thích Kafka open source có thể self-host. Chúng tôi cũng dự định thêm các tính năng như mã hóa phía client để giúp yên tâm hơn