S2 की शुरुआत की घोषणा

 (s2.dev)
1 पॉइंट द्वारा GN⁺ 2024-12-22 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • S2 एक serverless Stream Store प्रीव्यू है, जिसका लक्ष्य durable real-time streams को object storage जितना सरल तरीके से संभालना है, और logs व streams को cloud storage के मूल building blocks के स्तर तक लाना है
  • records stream tail में append होते हैं, और कई writers एक साथ लिखें तब भी S2 durable ordering संभालता है, जिससे past reads और real-time tailing दोनों संभव होते हैं
  • S2 का basin bucket की तरह streams के namespace की भूमिका निभाता है, और streams की संख्या या retention period की सीमा के बिना per-user streams जैसे modeling को संभव बनाता है
  • storage classes Standard और Express से शुरुआत होती है, जो क्रमशः p99 500ms से कम और 50ms से कम latency को लक्ष्य बनाकर latency और cost के विकल्प देते हैं
  • अभी gRPC API, Rust SDK, और CLI उपलब्ध हैं, जबकि REST API, Kafka protocol compatibility, multi-region basins, और 5ms से कम latency अगले चरण में हैं

S2 द्वारा प्रस्तावित stream storage model

  • S2 का लक्ष्य cloud युग के streaming data के लिए एक serverless Stream Store बनना है
  • मुख्य विचार यह है कि log या stream भी object की तरह cloud storage का एक मूल building block बन सकता है
  • object storage named objects के लिए PUT / GET / DELETE और blob·byte range पर केंद्रित होता है, इसलिए यह at-rest data के लिए उपयुक्त है
  • S2 का stream storage named Stream के लिए APPEND / READ / TRIM देता है, और records व sequence numbers को मूल इकाई मानता है
  • writes stream tail में append होते हैं, और कई writers एक साथ रिकॉर्ड करें तब भी S2 सभी records को क्रमबद्ध करता है और durability सुनिश्चित करता है
  • reads seconds ago से लेकर years तक किसी भी बिंदु से शुरू हो सकते हैं, और S3 blob के साथ कठिन होने वाली real-time tailing भी संभव है
  • basin stream के namespace की भूमिका निभाता है, जैसे bucket object के namespace की भूमिका निभाता है
    • basin और stream बिना किसी संख्या-सीमा के इस्तेमाल किए जा सकते हैं
    • data retention period पर भी कोई सीमा नहीं है
    • per-user stream modeling भी संभव है, और Kafka की तरह cluster limits या infrastructure tuning से नहीं जूझना पड़ता
  • stream tail को strong consistency के साथ जाँचने का व्यवहार और write के समय concurrency control भी समर्थित है
    • fencing token का उपयोग करने वाला pessimistic तरीका संभव है
    • expected sequence number देने वाला optimistic तरीका संभव है
    • यह डिज़ाइन MemoryDB और Neon जैसे databases द्वारा उपयोग किए जाने वाले durable offloading और compute-storage separation को ध्यान में रखता है

performance, pricing, मौजूदा सुविधाएँ और roadmap

  • S2 object storage की scalability और durability पर आधारित एक multi-tenant service के रूप में serverless API प्रदान करता है
  • durability को बिना समझौते वाला तत्व माना गया है, और latency तथा cost के विकल्प stream-स्तरीय storage class से समायोजित किए जाते हैं
    • Standard: AWS S3 Standard पर आधारित है, और क्योंकि सभी public cloud providers के पास इसके समकक्ष products हैं, S2 का मानना है कि वृद्धि के साथ इसे सभी cloud regions में दिया जा सकता है
    • Express: AWS S3 Express One Zone bucket के 3-quorum पर आधारित है, और Azure में इसका regional counterpart है, जबकि GCP में भी संभावना देखी जाती है
  • performance targets और शुरुआती सीमाएँ इस प्रकार हैं
    • Standard end-to-end p99 latency 500ms से कम देता है
    • Express में 50ms से कम latency की अपेक्षा की जा सकती है
    • सभी writes acknowledgement से पहले regional durability के साथ S3 में सुरक्षित रूप से स्टोर किए जाते हैं
    • throughput प्रति stream सैकड़ों MB प्रति सेकंड के स्तर तक समर्थित है
    • हाल ही में लिखे गए data की reads in-memory caching के कारण कम overhead के साथ होती हैं
    • पीछे रह गए readers को object storage से सीधे serve किया जाता है और उस पर कोई cap नहीं है
    • शुरुआत में writes को प्रति stream 125 MiBps और recent writes की reads को प्रति stream 500 MiBps तक सीमित किया गया है
  • preview अवधि में यह मुफ्त उपलब्ध है, और intended pricing प्रकाशित की गई है, जिसका लक्ष्य cloud streaming systems के सामान्य स्तर की तुलना में अर्थपूर्ण रूप से कम कीमत रखना है
  • instance या cluster unit जैसी कोई fixed cost नहीं है
  • फिलहाल उपलब्ध developer interfaces इस प्रकार हैं
  • सिस्टम proven cloud infrastructure पर बना है, और Rust codebase deterministic simulation testing से गुज़रता है
    • यह अभी भी एक नया सिस्टम है, इसलिए समस्याएँ हो सकती हैं
    • इसे general availability और production में भरोसेमंद SLA की दिशा में परिपक्व किया जा रहा है
  • आगे का roadmap तीन हिस्सों में व्यवस्थित है
    • Kafka protocol compatibility: इसे open source layer के रूप में दिया जाएगा, और key-based compaction जैसी कुछ सुविधाएँ सीधे S2 में integrate की जाएँगी
    • Multi-region basins: अधिक cloud regions में विस्तार के बाद region और cloud के पार basin की संभावना देखी जा रही है
    • Under 5 millisecond latencies: storage class की structural flexibility के कारण Express की तुलना में अतिरिक्त 10x सुधार संभव माना जाता है
  • अगर आप मुख्यतः Kafka या Kinesis की “low-level” API का उपयोग करते हैं, तो S2 streams की संख्या पर सीमा न होना, 10-100x अधिक ordered throughput, और concurrency control जैसी जरूरतों को सीधे लक्ष्य करता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-12-22
Hacker News की राय

  • मैं वकील नहीं हूं, लेकिन product का नाम S2 रखना और introduction में यह कहना कि यह AWS S3 को बेहतर बनाने वाली technology है, Amazon की ओर से trademark/copyright claim बुलाने की काफी संभावना दिखती है
    वही क्षेत्र होने से consumer confusion भी साफ तौर पर हो सकता है। trademark registration की जांच तो बेशक की होगी: https://tsdr.uspto.gov/#caseNumber=98324800&caseSearchType=U...

    • मजेदार बात: Spanish में S2 और EC2 दोनों “ese dos” जैसे बिल्कुल एक जैसे सुनाई देते हैं
      पहले से ही EC2 और S3 को सुनकर अलग करना थोड़ा भ्रमित करता है, अब इसमें एक और जुड़ गया
    • निष्पक्ष रूप से कहें तो, अगर मकसद S3 को बेहतर बनाना है तो इसे S4 कहना ज्यादा सही लगता है
    • कम-से-कम Cloudflare के R2 के नाम के पीछे एक तर्क है
      IBM बनाम HAL, यानी 『2001: A Space Odyssey』 वाली naming style
    • पता नहीं उन्होंने किसी खराब trademark lawyer से सलाह ली या बिल्कुल सलाह ही नहीं ली, लेकिन इसका खर्च इतना ज्यादा नहीं रहा होगा
      मैंने हाल ही में trademark filing process शुरू की थी, और domain registrar website के हिसाब से यह s4.dev जैसा domain खरीदने की लागत के आसपास था। launch के बाद rebranding करना, launch से पहले बदलने की तुलना में कहीं ज्यादा दर्दनाक होता है
    • हो सकता है Amazon बस वही चीज खुद बना दे, उसे S3 Streams कहे और S2 की परवाह न करे
      शायद acquisition offer भी दे सकता है, और lawsuit तक जाने की संभावना बहुत कम लगती है

  • idea सच में बहुत अच्छा है और API भी सुंदर है, और मैं इसे अपने project में इस्तेमाल करना चाहूंगा, लेकिन मुझे बिल्कुल भरोसा नहीं है कि यह startup अपने मौजूदा रूप में लंबे समय तक टिकेगा
    अगर सफल हुआ तो AWS इसका बेहतर और सस्ता internal version बना देगा, और उलटा market में traction न मिलने की संभावना भी बड़ी है। AWS से कसकर बंधे “cloud basic building block” API के बजाय अगर यह Papertrail जैसे dashboard वाला end-user product बनकर आता तो ज्यादा समझ में आता। इसमें Digital Ocean Spaces जैसे S3-compatible backend को सीधे लाने की सुविधा हो तो यह शानदार और टिकाऊ cloud-neutral product बन जाता

    • founder के नजरिए से वे multi-cloud की योजना बना रहे हैं, और अभी AWS से शुरुआत कर रहे हैं
      internal architecture AWS से बंधा नहीं है, और यह दूसरे cloud systems के लिए implement की जा सकने वाली interface structure है
    • अगर यह पूरा सिस्टम पहले से ही AWS पर चल रहा है तो यह काफी ironic होगा
      existing open-source software को service के रूप में package करके AWS product से सस्ता बताकर market करने वाले, लेकिन असल में AWS पर चलने वाले startups की कमी नहीं है
    • Aptible(https://aptible.com) पर भी यही objection लगातार आया था, लेकिन 10 साल से ज्यादा बाद भी यह बहुत सफल PaaS बना हुआ है
    • अगर आप cloud infra side में हैं तो AWS कीमत में नीचे मारने की कोशिश करेगा, लेकिन developer experience/user experience में वह कभी बेहतर नहीं कर पाएगा
      इसलिए मुझे नहीं लगता कि Beezus की वजह से रुकने की जरूरत है
    • AWS ने पहले ही कुछ मिलता-जुलता किया है: https://news.ycombinator.com/item?id=42211280
      “Amazon S3 now supports the ability to append data to an object” 30 दिन पहले announce हुआ था, और Azure में भी append blob के रूप में यह feature बहुत पहले से था। अभी यह S2 से ज्यादा raw है और record concept नहीं है, लेकिन cloud provider के इसे native तौर पर देने तक का कदम बहुत छोटा है। record concept जोड़ दें तो यह असल में message queue के करीब हो जाता है, और वह competitive space भी उतना ही बड़ा है; log storage solutions की दिशा भी कुछ ऐसी ही है

  • मैं समझना चाहता हूं। अगर इसे AWS के ऊपर build किया गया है, तो AWS internet egress के लिए $0.09 प्रति GB लेता है, और यहां internet egress के लिए $0.05 प्रति GB charge कर रहे हैं?
    यह AWS egress cost को subsidize करने जैसा लगता है। या फिर क्या इन्हें कोई unpublished egress rate मिल सकता है?

    • founder के नजरिए से preview period में billing नहीं होगी
      meaningful scale पर पहुंचने पर इसे solve करने की योजना है, और इसमें निश्चित रूप से कुछ assumptions शामिल हैं
    • list price के हिसाब से भी 150TB के बाद $0.05 प्रति GB है, और बड़े volume पर उससे भी सस्ता है
    • लगता है वे इस पर bet कर रहे हैं कि ज्यादातर users AWS के अंदर होंगे, इसलिए सिर्फ 1~2 cent transfer cost देनी होगी
    • जिन जगहों पर पर्याप्त scale होता है वे data transfer के लिए retail price नहीं देते
    • लगता है अब उन्होंने इसे $0.08 प्रति GB कर दिया है
      तो 50TB पर अधिकतम monthly $300 का नुकसान होगा, और उसके बाद से पैसे बनेंगे

  • यह मूल रूप से WarpStream है, लेकिन सीधे Kafka compatibility की ओर जाने के बजाय lower-level API देने वाला रूप है?
    long term में अगर adoption होता है, तो streaming के लिए S3-level का basic API सच में valuable लगता है

    • founder के नजरिए से यह summary कुछ हद तक सही है
      हालांकि WarpStream से architectural approach अलग है, इसलिए यह कहीं कम latency दे सकता है। system में disk भी नहीं है

  • इन लोगों ने जैसे consciously तय कर लिया है कि अपने बाकी career में “असल में हम S3 नहीं हैं” समझाते रहेंगे

    • founder के नजरिए से नाम का 50% अलग माना जा सकता है
    • ऐसे letter+number storage services अब कितने हो गए हैं? S3, B2, R2, S2...
    • या यह भी है: https://github.com/google/s2geometry
    • फिर भी यह समझाने से बेहतर लगता है कि वे कोई अकथनीय युद्ध-अपराध करने वाला paramilitary group नहीं हैं
      वह हंसने की बात नहीं है
    • क्या उन्हें court या lawyers के सामने भी ऐसा ही समझाना नहीं पड़ सकता? मैं वकील नहीं हूं, लेकिन यह Amazon को यह कहने का खुला मौका देने जैसा लगता है कि उन्होंने “S3” trademark का जानबूझकर फायदा उठाया और confusion पैदा करके अपना brand बढ़ाने की कोशिश की
      निजी तौर पर मुझे यह दावा सही लगता है, और main text में भी यह काफी transparent दिखता है

  • अच्छा लग रहा है, लेकिन क्या Java SDK नहीं है?
    जिन कंपनियों में मैंने व्यक्तिगत रूप से काम किया है, उनमें 90% मामलों में Kafka produce/consume के लिए Spring या basic client पर गहरी निर्भरता थी। इससे हल्का-फुल्का proof of concept भी व्यावहारिक रूप से रुक जाता है

    • S2 टीम के तौर पर, आगे Java/Kotlin SDK और Python SDK सूची में हैं
      फिलहाल Rust SDK और CLI हैं (https://s2.dev/docs/quickstart)। core service भी Rust में लिखी गई है, इसलिए Rust एक अच्छा starting point लगा

  • यह मुझे पसंद है। इसके बाद मैं चाहता हूं कि कोई इसके ऊपर जो चीज बनाए, वह stream “events” को किसी खास समय-बिंदु पर query किए जा सकने वाले representation के रूप में apply करने वाला हिस्सा हो
    मूल रूप से Datomic जैसा कुछ बनाने का दूसरा आधा हिस्सा। किसी खास database की बजाय, ठोस in-memory queryable data बनाने के लिए pattern या framework बेहतर लगेगा। इसे कई तरीकों से किया जा सकता है: local Sqlite पर apply करना, MySQL binlog के आधार पर local query instance पर apply करके उसे किसी खास समय-बिंदु तक rewind करना, या application-specific apply/undo events को local state पर apply करना

  • करीब 10 साल पहले Gazette शुरू किया था [0]
    Gazette, Kafka और WarpStream/S2 के बीच का architectural midpoint है। यह S3 को backend बनाकर infinite byte-oriented log streams देता है, लेकिन broker initial replication/durability guarantee और append/read latency घटाने के लिए local scratch disk का इस्तेमाल करता है। इसलिए p99 500ms से ज्यादा नहीं, बल्कि 5ms से कम है, और configurable target size/compression/latency limits जैसी सुविधाओं के साथ सभी files के S3 तक पहुंचने की गारंटी देता है। पुराना data पढ़ने वाले clients सीधे S3 से content लेते हैं, और फिर बहुत हालिया appends की live tailing पर switch कर जाते हैं
    Gazette पिछले startup के internal tool के रूप में शुरू हुआ था, और मौजूदा company बनाते समय हमने इसे raw service के रूप में देने का विकल्प [1] बहुत थोड़ी देर के लिए सोचा, फिर दिशा बदलकर एक end-to-end data movement platform [2] बनाया जिसमें Gazette internal implementation detail के तौर पर इस्तेमाल होता है। ऐसी service की market positioning बेहद narrow है। या तो इसे target customers द्वारा पहले से इस्तेमाल की जा रही चीज के साथ API-compatible बनाकर trial cost 0 करनी होगी (WarpStream ने यह अच्छे से किया), या application stack में ऊपर जाकर customers जिस समस्या को वास्तव में हल करना चाहते हैं, उसे ज्यादा सीधे हल करना होगा
    [0]: https://gazette.readthedocs.io/en/latest/
    [1]: https://news.ycombinator.com/item?id=21464300
    [2]: https://estuary.dev

    • S2 founder के तौर पर, Estuary की सफलता के लिए बधाई
      आप पहले व्यक्ति नहीं हैं जिन्होंने कहा कि यह market नहीं है या बहुत छोटा है। लेकिन जब आपने भी HN पर validation मांगा था, तो आपको लगा होगा कि इसमें कुछ है। S2 के ऊपर Kafka compatibility जैसी चीजें बहुत ज्यादा दी जा सकती हैं, लेकिन core primitive महत्वपूर्ण है। व्यक्तिगत रूप से मैं भी यह चाहता था, और मैंने देखा है कि इसे हर तरह के contexts में फिर से बनाया जाता है और अपनी मूल प्रकृति खो चुके system के रूप में inefficiently reuse किया जाता है; सिर्फ वही conviction founder बनने के लिए काफी था। सलाह का background समझता हूं, आगे की मुश्किलें भी जानता हूं, और सलाह के लिए धन्यवाद

  • यह बहुत उपयोगी service model है, लेकिन अगर हर write acknowledgement से पहले S3 में persist होती है, तो value proposition थोड़ा confusing है
    writer records के batch को बड़े blob के रूप में लिखने से पहले batch कर सकता है, और background process compaction कर सकता है, लेकिन फिर भी क्या यह object storage-based streaming service ही नहीं है? AWS ने RDS से Aurora तक जाते हुए मोटे तौर पर protocol-compatible services implement करने की इच्छा दिखाई है, और लगता है कि Kafka reimplementation के साथ भी वही कर सकता है

    • S2 टीम के तौर पर, मूल रूप से यह तरीका सही है
      write को acknowledge करने से पहले object storage में लिखे जाने वाले chunk को multitenant के रूप में design किया जाए, और उसमें अलग-अलग streams के records साथ रखे जाएं, तो frequent writes करते हुए भी S3 standard और express PUT, दोनों के लिए price/performance के लिहाज से ideal blob size target किया जा सकता है

  • technology सचमुच शानदार लगती है। बस अफसोस है कि यह source-available नहीं है
    यह minority opinion हो सकता है, लेकिन अगर core technology FSL जैसे license के तहत available हो और पूरी तरह supported self-hosting संभव हो, तो मैं commercial service पर जरूर विचार करूंगा। नहीं तो Kafka जैसी चीजों की तुलना में lock-in को justify करना मुश्किल है

    • founder के तौर पर, S2 API की alternative implementations का स्वागत है
      हम एक in-memory emulator पर भी विचार कर रहे हैं जिसे खुद open source करेंगे। API अपने-आप में बहुत जटिल नहीं है। अगर आप Kafka API बनाए रखते हुए S2 के storage classes, बहुत बड़ी संख्या में topics/partitions, और प्रति-partition high throughput जैसी capabilities पाना चाहते हैं, तो हम self-hostable open source Kafka-compatible layer की योजना बना रहे हैं। client-side encryption जैसी capabilities भी जोड़ेंगे ताकि और ज्यादा भरोसा मिल सके