ประกาศเปิดตัว S2

 (s2.dev)
1 คะแนน โดย GN⁺ 2024-12-22 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • S2 คือพรีวิวของ Stream Store แบบ serverless ที่มุ่งทำให้การจัดการสตรีมแบบเรียลไทม์ที่คงทน เรียบง่ายเหมือน object storage โดยต้องการยกระดับ log และ stream ให้เป็นองค์ประกอบพื้นฐานของ cloud storage
  • เรคคอร์ดจะถูก append ไปที่ tail ของ stream และแม้มี writer หลายตัวเขียนพร้อมกัน S2 จะรับหน้าที่ จัดลำดับอย่างคงทน พร้อมรองรับทั้งการอ่านย้อนหลังและการ tail แบบเรียลไทม์
  • basin ของ S2 ทำหน้าที่เป็น namespace ของ stream คล้าย bucket ทำหน้าที่กับ object ทำให้สามารถทำโมเดลอย่าง stream ต่อผู้ใช้ได้โดยไม่จำกัดจำนวน stream และระยะเวลาเก็บรักษา
  • storage class เริ่มต้นด้วย Standard และ Express โดยตั้งเป้า latency p99 ต่ำกว่า 500ms และ ต่ำกว่า 50ms ตามลำดับ เพื่อแยกตัวเลือกด้าน latency และต้นทุน
  • ปัจจุบันมี gRPC API, Rust SDK และ CLI และวาง REST API, ความเข้ากันได้กับโปรโตคอล Kafka, multi-region basins และ latency ต่ำกว่า 5ms เป็นขั้นถัดไป

โมเดล stream storage ที่ S2 เสนอ

  • S2 มุ่งเป็น serverless Stream Store สำหรับข้อมูล streaming ในยุคคลาวด์
  • แนวคิดหลักคือ log หรือ stream ก็สามารถเป็นองค์ประกอบพื้นฐานของ cloud storage ได้เช่นเดียวกับ object
  • Object storage มุ่งเน้น PUT / GET / DELETE สำหรับ object ที่มีชื่อ รวมถึง blob และ byte range และเหมาะกับข้อมูลที่หยุดนิ่ง
  • stream storage ของ S2 ให้ APPEND / READ / TRIM สำหรับ Stream ที่มีชื่อ และใช้ record กับ sequence number เป็นหน่วยพื้นฐาน
  • การเขียนจะ append ไปที่ stream tail และแม้มี writer หลายตัวบันทึกพร้อมกัน S2 จะ จัดลำดับ record ทั้งหมดและรับประกันความคงทน
  • การอ่านสามารถเริ่มได้ตั้งแต่ seconds ago ไปจนถึง years และยังทำ real-time tailing ซึ่งทำได้ยากด้วย S3 blob ได้ด้วย
  • basin ทำหน้าที่เป็น namespace ของ stream เหมือนที่ bucket ทำหน้าที่เป็น namespace ของ object
    • สามารถใช้ basin และ stream ได้โดยไม่จำกัดจำนวน
    • ไม่มีข้อจำกัดด้านระยะเวลาเก็บรักษาข้อมูล
    • สามารถทำโมเดล stream ต่อผู้ใช้ได้ และไม่ต้องจัดการข้อจำกัดของ cluster หรือการจูน infrastructure แบบ Kafka
  • รองรับทั้งการตรวจสอบ stream tail ด้วย strong consistency และ concurrency control ตอนเขียน
    • ใช้วิธีแบบ pessimistic ด้วย fencing token ได้
    • ใช้วิธีแบบ optimistic โดยระบุ expected sequence number ได้
    • การออกแบบนี้มุ่งไปที่ durable offloading และการแยก compute กับ storage ซึ่งฐานข้อมูลอย่าง MemoryDB และ Neon ใช้งานอยู่

ประสิทธิภาพ ราคา ฟีเจอร์ที่มีในปัจจุบัน และ roadmap

  • S2 ให้ serverless API ในรูปแบบบริการ multi-tenant โดยอิง scalability และ durability ของ object storage
  • ถือว่าความคงทนเป็นสิ่งที่ไม่ประนีประนอม และปรับตัวเลือกระหว่าง latency กับต้นทุนด้วย storage class ราย stream
    • Standard: อิง AWS S3 Standard และมองว่าผู้ให้บริการ public cloud ทุกรายมีผลิตภัณฑ์เทียบเคียง จึงสามารถให้บริการได้ในทุก cloud region เมื่อเติบโตขึ้น
    • Express: อิง quorum ของ bucket AWS S3 Express One Zone จำนวน 3 ชุด โดย Azure มี regional counterpart และมองว่า GCP ก็มีความเป็นไปได้
  • เป้าหมายประสิทธิภาพและข้อจำกัดเริ่มต้นมีดังนี้
    • Standard ให้ end-to-end p99 latency ต่ำกว่า 500ms
    • Express คาดหวัง latency ต่ำกว่า 50ms ได้
    • write ทั้งหมดจะถูกเก็บอย่างปลอดภัยใน S3 ด้วย regional durability ก่อน acknowledgement
    • throughput รองรับระดับ หลายร้อย MB ต่อวินาที ต่อ stream
    • การอ่านข้อมูลที่เพิ่งเขียนมี overhead ต่ำด้วย in-memory caching
    • reader ที่ล่าช้าจะถูกให้บริการโดยตรงจาก object storage และไม่มี cap
    • ในช่วงแรกจำกัด write ไว้ที่ 125 MiBps ต่อ stream และ read สำหรับ write ล่าสุดไว้ที่ 500 MiBps ต่อ stream
  • ในช่วงพรีวิวให้ใช้ฟรี และเปิดเผย intended pricing โดยตั้งเป้าราคาที่ถูกกว่าระดับทั่วไปของระบบ cloud streaming อย่างมีนัยสำคัญ
  • ไม่มี ต้นทุนคงที่ อย่าง instance หรือ cluster unit
  • developer interface ที่มีในปัจจุบันมีดังนี้
  • ระบบอยู่บน cloud infrastructure ที่ผ่านการพิสูจน์แล้ว และ codebase ภาษา Rust ผ่าน deterministic simulation testing
    • ระบบยังใหม่ จึงอาจมีปัญหาได้
    • กำลังทำให้ mature ขึ้นเพื่อไปสู่ general availability และ SLA ที่เชื่อถือได้ในการใช้งาน production
  • roadmap ถัดไปสรุปได้เป็นสามแกน
    • Kafka protocol compatibility: จะให้เป็นเลเยอร์ open source และฟีเจอร์บางส่วน เช่น key-based compaction จะผนวกเข้ากับ S2 โดยตรง
    • Multi-region basins: หลังขยายไปยัง cloud region มากขึ้น จะพิจารณาความเป็นไปได้ของ basin ที่ข้าม region และ cloud
    • Under 5 millisecond latencies: มองว่าความยืดหยุ่นเชิงโครงสร้างของ storage class ทำให้ปรับปรุงเพิ่มได้อีก 10 เท่าเมื่อเทียบกับ Express
  • หากใช้งาน API “low-level” ของ Kafka หรือ Kinesis เป็นหลัก S2 มุ่งตอบโจทย์โดยตรง เช่น ไม่จำกัดจำนวน stream, ordered throughput สูงขึ้น 10-100 เท่า และ concurrency control

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-12-22
ความคิดเห็นบน Hacker News

  • ผมไม่ใช่นักกฎหมาย แต่การตั้งชื่อผลิตภัณฑ์ว่า S2 แล้วบอกในบทนำว่าเป็นเทคโนโลยีที่ปรับปรุง AWS S3 ดูมีแนวโน้มสูงที่จะเรียก ข้อเรียกร้องเรื่องเครื่องหมายการค้า/ลิขสิทธิ์ จาก Amazon
    อยู่ในสาขาเดียวกัน จึงน่าจะเกิดความสับสนในหมู่ผู้บริโภคได้ชัดเจน แน่นอนว่าคงตรวจสอบเรื่องการจดทะเบียนเครื่องหมายการค้าแล้ว: https://tsdr.uspto.gov/#caseNumber=98324800&caseSearchType=U...

    • ข้อเท็จจริงที่น่าสนใจ: ในภาษาสเปน ทั้ง S2 และ EC2 ออกเสียงเหมือนกันว่า “ese dos”
      แค่ EC2 กับ S3 ก็แยกด้วยหูยากอยู่แล้ว นี่เท่ากับเพิ่มเข้ามาอีกหนึ่งชื่อ
    • ถ้าจะพูดอย่างเป็นธรรม หากสร้างขึ้นโดยมีเป้าหมายเพื่อปรับปรุง S3 ก็น่าจะเรียกว่า S4 มากกว่า
    • อย่างน้อย R2 ของ Cloudflare ก็มีเหตุผลรองรับเรื่องชื่อ
      เป็นการตั้งชื่อสไตล์ IBM เทียบกับ HAL หรือแบบเรื่อง 『2001: A Space Odyssey』
    • ไม่รู้ว่าไปปรึกษาทนายเครื่องหมายการค้าที่แย่หรือไม่ได้ปรึกษาเลย แต่ค่าใช้จ่ายคงไม่ได้มากขนาดนั้น
      ผมเพิ่งเริ่มกระบวนการยื่นเครื่องหมายการค้าเมื่อไม่นานมานี้ และถ้าอิงจากเว็บไซต์ผู้รับจดทะเบียนโดเมน ค่าใช้จ่ายก็พอ ๆ กับการซื้อโดเมนอย่าง s4.dev การรีแบรนด์หลังเปิดตัวเจ็บปวดกว่าการเปลี่ยนก่อนเปิดตัวมาก
    • Amazon อาจแค่ทำสิ่งเดียวกันเองแล้วเรียกว่า S3 Streams และไม่สนใจ S2 ก็ได้
      บางทีอาจยื่นข้อเสนอซื้อกิจการด้วยซ้ำ และดูแล้วโอกาสที่จะถึงขั้นฟ้องร้องต่ำมาก

  • ไอเดียดีมากและ API ก็สวยงาม ผมอยากใช้กับโปรเจกต์ของตัวเอง แต่ไม่มีความมั่นใจเลยว่าสตาร์ทอัพนี้จะอยู่รอดได้นานในรูปแบบปัจจุบัน
    ถ้าประสบความสำเร็จ AWS ก็จะสร้างเวอร์ชันภายในที่ดีกว่าและถูกกว่า ส่วนในทางกลับกัน ก็มีโอกาสสูงที่จะไม่ได้ traction ในตลาด ถ้าออกมาเป็นผลิตภัณฑ์สำหรับผู้ใช้ปลายทางที่มีแดชบอร์ดแบบ Papertrail มากกว่าจะเป็น API “องค์ประกอบพื้นฐานของคลาวด์” ที่ผูกติดกับ AWS อย่างใกล้ชิด มันน่าจะสมเหตุสมผลกว่ามาก และถ้าสามารถนำ แบ็กเอนด์ที่เข้ากันได้กับ S3 อย่าง Digital Ocean Spaces มาใช้เองได้ ก็จะกลายเป็นผลิตภัณฑ์ที่เป็นกลางต่อคลาวด์ ยอดเยี่ยม และอยู่ได้นาน

    • จากมุมมองผู้ก่อตั้ง พวกเขาวางแผนแบบมัลติคลาวด์ และตอนนี้เริ่มจาก AWS ก่อน
      สถาปัตยกรรมภายในไม่ได้ผูกกับ AWS และเป็นโครงสร้างอินเทอร์เฟซที่สามารถนำไป implement สำหรับระบบคลาวด์อื่นได้
    • ถ้าทั้งหมดนี้รันอยู่บน AWS อยู่แล้ว ก็คงค่อนข้างย้อนแย้ง
      มีสตาร์ทอัพไม่จบไม่สิ้นที่เอาซอฟต์แวร์โอเพนซอร์สเดิมมาห่อเป็นบริการ แล้วทำการตลาดว่าถูกกว่าผลิตภัณฑ์ของ AWS ทั้งที่ตัวเองก็รันอยู่บน AWS
    • Aptible(https://aptible.com) ก็ถูกโต้แย้งแบบเดียวกันมาตลอด แต่ผ่านมากว่า 10 ปีแล้วก็ยังคงเป็น PaaS ที่ประสบความสำเร็จอย่างมาก
    • ถ้าทำด้านโครงสร้างพื้นฐานคลาวด์ AWS คงพยายามกดราคาลง แต่ในด้าน ประสบการณ์นักพัฒนา/ประสบการณ์ผู้ใช้ ไม่มีทางทำได้ดีกว่าแน่นอน
      ดังนั้นผมคิดว่าไม่จำเป็นต้องหยุดเพราะ Beezus
    • AWS เคยทำสิ่งที่คล้ายกันแล้ว: https://news.ycombinator.com/item?id=42211280
      “Amazon S3 now supports the ability to append data to an object” ประกาศเมื่อ 30 วันก่อน และ Azure ก็มีฟังก์ชันเดียวกันผ่าน append blob มานานแล้ว ตอนนี้ยังดิบกว่า S2 และไม่มีแนวคิด record แต่ขั้นที่ผู้ให้บริการคลาวด์จะให้บริการสิ่งนี้แบบเนทีฟนั้นเล็กมาก หากใส่แนวคิด record เข้าไป ก็แทบจะใกล้เคียงกับ message queue ซึ่งพื้นที่การแข่งขันนั้นก็ใหญ่เช่นกัน และฝั่งโซลูชันจัดเก็บ log ก็คล้ายกัน

  • อยากทำความเข้าใจให้ชัด ถ้าสร้างบน AWS แล้ว AWS คิดค่า egress ไปอินเทอร์เน็ต $0.09 ต่อ GB แต่ที่นี่คิดค่า egress ไปอินเทอร์เน็ต $0.05 ต่อ GB อย่างนั้นหรือ?
    ฟังดูเหมือนกำลังอุดหนุนค่า egress ของ AWS อยู่ หรือว่าใช้เรต egress ที่ไม่เปิดเผยได้?

    • จากมุมมองผู้ก่อตั้ง ช่วงพรีวิวจะยังไม่คิดเงิน
      เมื่อถึงขนาดที่มีนัยสำคัญ พวกเขาจะจัดการเรื่องนี้ และแน่นอนว่ามีสมมติฐานบางอย่างอยู่ในนั้น
    • แม้ตามราคาปลีก หลัง 150TB ก็อยู่ที่ $0.05 ต่อ GB และเมื่อปริมาณมากก็จะถูกกว่านั้นอีก
    • ดูเหมือนพวกเขากำลังเดิมพันว่าผู้ใช้ส่วนใหญ่อยู่ใน AWS จึงจ่ายแค่ ค่าโอน 1~2 เซนต์ ก็พอ
    • ที่ที่มีสเกลเพียงพอไม่จ่ายค่าถ่ายโอนข้อมูลในราคาขายปลีก
    • ตอนนี้ดูเหมือนเปลี่ยนเป็น $0.08 ต่อ GB แล้ว
      แบบนั้นที่ 50TB จะขาดทุนสูงสุดเดือนละ $300 และหลังจากนั้นก็เริ่มทำเงินได้

  • โดยพื้นฐานแล้วนี่คือ WarpStream แต่เป็นรูปแบบที่ไม่ได้ไปทาง Kafka compatibility ทันที และให้ API ระดับต่ำกว่านั้นหรือเปล่า?
    ถ้าได้รับการใช้งานในระยะยาว API พื้นฐานระดับ S3 สำหรับสตรีมมิงก็ดูมีคุณค่ามากจริง ๆ

    • จากมุมมองผู้ก่อตั้ง ถือว่าเป็นสรุปที่ค่อนข้างถูก
      แต่แนวทางสถาปัตยกรรมต่างจาก WarpStream และด้วยเหตุนี้จึงให้ latency ที่ต่ำกว่ามากได้ ระบบนี้ไม่มีดิสก์ด้วย

  • คนเหล่านี้เท่ากับเลือกอย่างมีสติว่าจะต้องอธิบายตลอดอาชีพต่อจากนี้ว่า “จริง ๆ แล้วเราไม่ใช่ S3”

    • จากมุมมองผู้ก่อตั้ง ถือว่าชื่อนี้ต่างออกไป 50%
    • ตอนนี้มี บริการจัดเก็บข้อมูลแบบตัวอักษร+ตัวเลข กี่ตัวแล้วกันแน่? S3, B2, R2, S2...
    • หรืออันนี้ก็มีด้วย: https://github.com/google/s2geometry
    • แต่ก็ดูดีกว่าต้องอธิบายว่าไม่ใช่กองกำลังกึ่งทหารที่ก่ออาชญากรรมสงครามสุดจะบรรยาย
      เรื่องนั้นไม่ใช่เรื่องตลก
    • อาจต้องอธิบายแบบนั้นต่อหน้าศาลหรือทนายด้วยไม่ใช่หรือ? ผมไม่ใช่นักกฎหมาย แต่เรื่องนี้ดูเหมือนเป็นการเชื้อเชิญให้ Amazon อ้างว่าพวกเขาตั้งใจใช้ประโยชน์จากเครื่องหมายการค้า “S3” และสร้างความสับสนเพื่อขยายแบรนด์ของตัวเอง
      โดยส่วนตัวผมคิดว่าเป็นข้อกล่าวอ้างที่ถูกต้อง และในบทความก็แสดงให้เห็นค่อนข้างโปร่งใส

  • ดูดีนะ แต่ไม่มี Java SDK เหรอ?
    โดยส่วนตัวแล้ว บริษัทที่ผมเคยทำงานด้วย 90% พึ่งพา Spring หรือไคลเอนต์พื้นฐานอย่างมากสำหรับการผลิต/บริโภค Kafka แบบนี้แม้แต่การพิสูจน์แนวคิดแบบเบา ๆ ก็แทบถูกปิดทาง

    • ในมุมของทีม S2 มี Java/Kotlin SDK และ Python SDK อยู่ในรายการสำหรับอนาคต
      ตอนนี้มี Rust SDK และ CLI (https://s2.dev/docs/quickstart) อยู่ บริการหลักก็เขียนด้วย Rust เลยรู้สึกว่า Rust เป็นจุดเริ่มต้นที่ดี

  • ชอบอันนี้นะ สิ่งถัดไปที่อยากให้ใครสักคนสร้างต่อบนสิ่งนี้ คือส่วนที่นำ “เหตุการณ์” ของสตรีมไปใช้เป็น ตัวแทนที่ query ได้ ณ ช่วงเวลาหนึ่ง ๆ
    โดยพื้นฐานแล้วนี่คืออีกครึ่งหนึ่งของการทำให้คล้าย Datomic มากกว่า database เฉพาะตัว คงจะดีกว่าถ้ามีแพตเทิร์นหรือเฟรมเวิร์กสำหรับสร้างข้อมูล in-memory ที่ query ได้อย่างเป็นรูปธรรม เช่น นำไปใช้กับ Sqlite ในเครื่อง, ใช้กับอินสแตนซ์ query ในเครื่องโดยอิงจาก MySQL binlog แล้ว rewind ไปยังจุดเวลาเฉพาะ, หรือใช้เหตุการณ์ apply/undo ของแต่ละแอปพลิเคชันกับสถานะในเครื่อง ก็ทำได้หลายแบบ

  • เริ่มทำ Gazette เมื่อราว 10 ปีก่อน [0]
    Gazette อยู่กึ่งกลางทางสถาปัตยกรรมระหว่าง Kafka กับ WarpStream/S2 มันให้บริการสตรีม log แบบ byte-oriented ที่ไร้ขีดจำกัดโดยมี S3 เป็นแบ็กเอนด์ แต่ broker ใช้ scratch disk ในเครื่องเพื่อการรับประกัน replication/durability ช่วงต้น และลด latency ของ append/read ดังนั้น p99 จึงต่ำกว่า 5ms ไม่ใช่เกิน 500ms และยังรับประกันว่าไฟล์ทั้งหมดจะไปถึง S3 พร้อมฟีเจอร์อำนวยความสะดวกอย่างขนาดเป้าหมาย/การบีบอัด/ขีดจำกัด latency ที่กำหนดค่าได้ ไคลเอนต์ที่อ่านข้อมูลในอดีตจะดึงคอนเทนต์จาก S3 โดยตรง แล้วหลังจากนั้นจะสลับไปเป็น live tailing ของ append ที่ใหม่มาก ๆ
    Gazette เริ่มจากเครื่องมือภายในของสตาร์ทอัพก่อนหน้า และตอนสร้างบริษัทปัจจุบันก็เคยพิจารณาอย่างสั้น ๆ ว่าจะให้บริการเป็น raw service [1] ก่อนจะเปลี่ยนทิศไปเป็นแพลตฟอร์มเคลื่อนย้ายข้อมูลแบบครบถ้วน [2] ที่ใช้ Gazette เป็นรายละเอียดการติดตั้งใช้งานภายใน การวางตำแหน่งในตลาด ของบริการแบบนี้แคบมาก ๆ ต้องทำให้ API เข้ากันได้กับสิ่งที่ลูกค้าเป้าหมายใช้อยู่แล้ว เพื่อลดต้นทุนการทดลองให้เหลือ 0 (WarpStream ทำเรื่องนี้ได้ดี) หรือไม่ก็ต้องขยับขึ้นไปบน application stack ให้สูงขึ้น เพื่อแก้ปัญหาที่ลูกค้าต้องการแก้จริง ๆ ได้โดยตรงมากขึ้น
    [0]: https://gazette.readthedocs.io/en/latest/
    [1]: https://news.ycombinator.com/item?id=21464300
    [2]: https://estuary.dev

    • ในฐานะผู้ก่อตั้ง S2 ขอแสดงความยินดีกับความสำเร็จของ Estuary
      คุณไม่ใช่คนแรกที่บอกว่าตลาดนี้ไม่มีอยู่หรือเล็กมาก แต่ตอนที่คุณเองมาขอการตรวจสอบบน HN คุณก็คงคิดว่ามีอะไรบางอย่างอยู่ S2 อาจให้สิ่งอย่างความเข้ากันได้กับ Kafka ได้มากกว่านี้มาก แต่ building block พื้นฐานหลักนั้นสำคัญ โดยส่วนตัวผมก็อยากได้ และเคยเห็นมันถูกสร้างซ้ำในบริบทสารพัด แล้วถูกนำกลับมาใช้ใหม่อย่างไม่มีประสิทธิภาพในรูปของระบบที่สูญเสียลักษณะดั้งเดิมไป ความมั่นใจเพียงเท่านั้นก็พอที่จะทำให้เป็นผู้ก่อตั้งได้แล้ว ผมเข้าใจบริบทของคำแนะนำและรู้ถึงความยากลำบากข้างหน้า ขอบคุณสำหรับคำแนะนำครับ

  • เป็นโมเดลบริการที่มีประโยชน์มาก แต่ถ้าทุก write ถูก ทำให้คงอยู่ถาวรใน S3 ก่อนส่ง acknowledgement ข้อเสนอคุณค่าก็ดูสับสน
    ผู้เขียนอาจ batch กลุ่ม record ก่อนเขียนเป็น blob ที่ใหญ่ขึ้น และให้กระบวนการเบื้องหลังทำ compaction ได้ แต่ก็ยังเป็นบริการสตรีมมิงที่ใช้ object storage เป็นฐานอยู่ดีไม่ใช่หรือ? AWS แสดงให้เห็นโดยทั่วไปแล้วว่ามีความตั้งใจจะทำบริการที่เข้ากันได้ในระดับโปรโตคอล อย่างที่ไปจาก RDS สู่ Aurora และดูเหมือนว่าจะทำแบบเดียวกันกับการนำ Kafka ไปใช้ใหม่ได้

    • ในมุมของทีม S2 โดยเนื้อแท้แล้วแนวทางนั้นถูกต้อง
      ถ้าออกแบบ chunk ที่เขียนลง object storage ก่อน acknowledgement ของ write ให้เป็นแบบ multi-tenant และให้บรรจุ record จากหลายสตรีมร่วมกัน ก็จะสามารถเขียนได้บ่อย ขณะเดียวกันก็มุ่งเป้าไปที่ขนาด blob ที่เหมาะสมด้านราคา/ประสิทธิภาพสำหรับทั้ง S3 standard และ express PUT

  • เทคโนโลยีดูเจ๋งมากจริง ๆ แค่เสียดายที่ไม่ใช่ source-available
    อาจเป็นความเห็นส่วนน้อย แต่ถ้าเทคโนโลยีหลักถูกเปิดเผยภายใต้ไลเซนส์อย่าง FSL และรองรับการ self-host ได้เต็มที่ ผมก็พร้อมพิจารณาบริการเชิงพาณิชย์อย่างจริงจัง ไม่อย่างนั้นก็ยากที่จะให้เหตุผลกับการถูก lock-in เมื่อเทียบกับอะไรอย่าง Kafka

    • ในฐานะผู้ก่อตั้ง ยินดีต้อนรับให้มี implementation ทางเลือกของ S2 API
      กำลังพิจารณา in-memory emulator ที่จะเปิดเป็นโอเพนซอร์สเองด้วย ตัว API เองไม่ได้ซับซ้อนมากนัก ถ้าต้องการคง Kafka API ไว้ พร้อมได้ฟีเจอร์อย่าง storage class ของ S2, topic/partition จำนวนมากมหาศาล และ throughput ต่อ partition สูง ก็กำลังวางแผนเลเยอร์ที่เข้ากันได้กับ Kafka แบบโอเพนซอร์สที่ self-host ได้อยู่ จะใส่ฟีเจอร์อย่างการเข้ารหัสฝั่งไคลเอนต์ด้วย เพื่อให้สบายใจมากขึ้น