Iggy.rs - การสตรีมข้อความที่สร้างด้วย Rust

 (blog.iggy.rs)
3 คะแนน โดย GN⁺ 2024-01-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

ที่มา

  • ในเดือนเมษายน 2023 ตัดสินใจเรียนรู้ Rust
  • จากประสบการณ์ด้านระบบกระจายและการรับส่งข้อความ จึงตัดสินใจพัฒนาแพลตฟอร์มสตรีมข้อความ
  • เป้าหมายคือเพื่อทำความเข้าใจหลักการทำงานภายในของระบบรับส่งข้อความและ trade-off ที่นักพัฒนาต้องเผชิญ
  • Iggy.rs จึงถือกำเนิดขึ้น โดยตั้งเป้าเป็นแพลตฟอร์มสตรีมข้อความที่เน้นความเร็วและความเบา

โปรเจกต์

  • Iggy รุ่นแรกใช้โปรโตคอล QUIC เพื่อให้ความสามารถพื้นฐานในการแลกเปลี่ยนข้อความ
  • ผ่านการทำต้นแบบและปรับปรุงอย่างต่อเนื่อง จนได้เซิร์ฟเวอร์ที่รองรับการเขียน/อ่านแบบขนานและสตรีมที่แยกอิสระ
  • เพิ่มการรองรับโปรโตคอล TCP และ HTTP พร้อมปรับปรุงประสิทธิภาพผ่านการเพิ่มประสิทธิภาพกลไกซิงก์ข้อมูล
  • จากการทำเบนช์มาร์กพบว่ามี throughput สูงและ latency ต่ำ จึงเปลี่ยนเป็นโปรเจกต์ระยะยาว

ทีม

  • Iggy มีทีมราว 10 คนที่ร่วมกันมีส่วนช่วยในหลายด้าน
  • มีส่วนร่วมในโปรเจกต์หลากหลาย เช่น คอร์เซิร์ฟเวอร์, SDK, เว็บ UI และ CLI
  • นักพัฒนาที่มีประสบการณ์หลากหลายและมีความหลงใหลในการเขียนโปรแกรม เข้าร่วมกันโดยสมัครใจ
  • การมีส่วนร่วมของผู้ร่วมพัฒนาภายนอกจากทั่วโลกช่วยเพิ่มความมั่นใจต่อโปรเจกต์นี้

ฟีเจอร์

  • เซิร์ฟเวอร์สตรีมข้อความประสิทธิภาพสูงแบบอิง log ที่ยั่งยืน
  • throughput สูง, latency ต่ำ และการใช้ทรัพยากรที่คาดการณ์ได้จากภาษาแบบคอมไพล์อย่าง Rust
  • รองรับหลายสตรีม, ท็อปปิก, พาร์ทิชัน และรองรับโปรโตคอลขนส่งที่หลากหลาย
  • มี RESTful API, client SDK หลายภาษา และทำงานกับข้อมูลไบนารีได้โดยตรง
  • ปรับแต่งความสามารถของเซิร์ฟเวอร์ได้, เก็บ consumer offset ไว้ที่เซิร์ฟเวอร์ และรองรับหลายวิธีในการ polling ข้อความ
  • มี consumer group เพื่อคงลำดับข้อความและรองรับการขยายแนวนอน รวมถึงฟีเจอร์หมดอายุข้อความและกำจัดข้อความซ้ำ
  • รองรับ TLS สำหรับทุกโปรโตคอลขนส่ง พร้อมการเข้ารหัสข้อมูลแบบเลือกใช้และรองรับ message header
  • มี CLI ในตัวสำหรับจัดการสตรีมมิงเซิร์ฟเวอร์และแอปเบนช์มาร์ก พร้อมการแจกจ่ายแบบไบนารีเดียว

โรดแมป

  • หลังจากไปปรากฏบนหน้า GitHub Trending ก็ได้มีการพูดคุยกับผู้ใช้เกี่ยวกับการเพิ่มฟีเจอร์
  • ตั้งเป้ายกระดับประสิทธิภาพและความน่าเชื่อถือผ่าน clustering, low-level I/O และสถาปัตยกรรม thread-per-core
  • กำลังทดลองกลไกฉันทามติ Raft, ปรับปรุงงาน I/O ด้วย io_uring และมีแผนใช้ runtime ของ monoio

อนาคต

  • ตั้งเป้าเป็นแพลตฟอร์มสตรีมข้อความสำหรับงานทั่วไป และท้าทายขีดจำกัดของ OS กับฮาร์ดแวร์
  • วางแผนรองรับภาษาโปรแกรมที่หลากหลาย รวมถึง CLI และเว็บ UI ในรูปแบบแพลตฟอร์มรวมที่ใช้งานง่าย
  • ตั้งเป้าพัฒนาต่อผ่านฟีดแบ็กและไอเดียจากชุมชน

GN⁺ ความเห็น

  • Iggy.rs เป็นแพลตฟอร์มสตรีมข้อความที่สร้างบน Rust โดยมุ่งเน้นประสิทธิภาพสูงและ latency ต่ำ
  • ในฐานะโปรเจกต์โอเพนซอร์ส มันยังคงเติบโตอย่างต่อเนื่องผ่านการเข้าร่วมและการมีส่วนร่วมโดยสมัครใจจากนักพัฒนาทั่วโลก
  • เป้าหมายอันทะเยอทะยานในการก้าวข้ามขีดจำกัดด้านประสิทธิภาพของระบบกระจายผ่านเทคโนโลยีน่าสนใจอย่าง clustering, การปรับ low-level I/O และสถาปัตยกรรม thread-per-core ทำให้เป็นโปรเจกต์ที่มีประโยชน์มากสำหรับผู้ที่สนใจด้านนี้

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

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

 
GN⁺ 2024-01-06
ความคิดเห็นบน Hacker News
  • เรื่องราวแบบนี้แหละที่ทำให้ผมเข้ามาสายซอฟต์แวร์ตั้งแต่แรก
    แม้แต่ละคนจะมีเหตุผลต่างกัน แต่การได้ทำงานร่วมกันเพื่อมุ่งสู่ เป้าหมายเดียวกัน และไม่ได้มีผลตอบแทนทางการเงินเป็นจุดประสงค์เดียว ดูเป็นภาพในอุดมคติมาก
    ขอให้โปรเจกต์ไปได้สวย และถ้ามี การเปรียบเทียบ กับทางเลือกอื่น ๆ ก็น่าจะช่วยให้เข้าใจได้ดีขึ้นว่าโปรเจกต์นี้อยู่ตรงไหน
    • เริ่มต้นมาแบบนั้นจริง ๆ และสักวันก็อยากใส่ เบนช์มาร์กและการเปรียบเทียบ กับเครื่องมืออื่น ๆ ด้วย
  • ไอเดียก็ดี บทความบล็อกก็ดี
    ผู้เขียนดูถ่อมตัว ตรงไปตรงมา และเหมือนเป็น ผู้นำโปรเจกต์ที่สร้างสรรค์
    • ทีมยอดเยี่ยมจริง ๆ
      ทุกคนตัดสินใจมาร่วมความพยายามนี้ด้วยใจที่อยากลองสนุกไปด้วยกัน
  • การเริ่มด้วย QUIC ดูเป็นการเลือกที่เฉียบและฉลาดมาก
    มันให้การทำหลายสตรีมพร้อมกันที่มีประโยชน์คล้าย SCTP จึงเป็นจุดเริ่มต้นที่ดี มีไลบรารีดี ๆ ให้ใช้ได้อยู่แล้วมากมาย และมีโอกาสจะดีขึ้นและถูกปรับแต่งให้เหมาะสมยิ่งขึ้นในอนาคต: https://github.com/xileteam/awesome-quic?tab=readme-ov-file#...
    เป็นพื้นที่ที่การใช้โปรโตคอลขนส่งที่ดีกว่าเดิมอีกเล็กน้อยก็ให้ประโยชน์ได้มากโดยธรรมชาติ เลยตั้งตารอ QUIC ในอีก 10 ปีข้างหน้า
    • เริ่มด้วย QUIC เพราะอยากลองอะไรใหม่ ๆ
      แต่ โปรโตคอล TCP ที่ใช้งานอยู่ตอนนี้เร็วกว่า QUIC เล็กน้อย ซึ่งอาจเป็นเพราะยังปรับจูนเพิ่มเติมไม่พอ
      อีกอย่างคือบน MacOS นั้น QUIC ช้ากว่าเมื่อเทียบกับ Linux
  • ดูเหมือนเป็นคู่แข่งโดยตรงของ JetStream ไหม? ความคืบหน้าระดับนี้ในเวลาไม่ถึงปีน่าประทับใจมาก
    https://docs.nats.io/nats-concepts/jetstream
    • โซลูชัน message streaming มีค่อนข้างเยอะ เช่น JetStream, Kafka, Redpanda, RabbitMQ Streams, Fluvio
  • ยังไม่แน่ใจว่าเทียบกับ Kafka และ Fluvio ซึ่งเป็นคู่แข่งของ Kafka ที่เขียนด้วย Rust แล้วเป็นอย่างไร
    มันใกล้เคียงกับ message queue อย่าง RabbitMQ มากกว่าหรือเปล่า?
    https://www.fluvio.io/
    • เป็น message stream จึงใกล้กับ Kafka, Redpanda และปลั๊กอิน RabbitMQ Streams มากกว่า
      Fluvio เป็นผลิตภัณฑ์จริงและมีบริษัทอยู่เบื้องหลัง จึงสุกงอมกว่า แต่ Iggy ก็มีไอเดียของตัวเองในการทำให้เป็น โซลูชัน message streaming ที่แข่งขันได้
    • Fluvio ตั้งเป้าจะแทนทั้ง Flink และ Kafka ไม่ใช่หรือ? เพิ่งรู้จัก เลยกำลังพยายามทำความเข้าใจอยู่
  • เมื่อหลายปีก่อนเคยทำของคล้าย ๆ กันกับเพื่อนด้วย Go
    https://github.com/thibauts/styx
    • ดูคล้ายกันมากทีเดียว
      สงสัยว่าทำไมถึงไม่ได้ทำต่อแล้ว
  • สักวันอยากลองใช้ดู แต่คงต้องเรียน Rust ก่อน
    อีกอย่างคือชอบ สุนทรียะ ของเว็บไซต์
    • มี SDK หลายตัว และบล็อกใช้เอนจิน Rust Zola
    • ในบทความบล็อกมีพูดถึง SDK สำหรับภาษาโปรแกรมอื่น ๆ ด้วย ดังนั้นน่าจะใช้ได้โดยไม่ต้องเรียน Rust
  • เห็นบทความนี้แล้วทำให้กลับไปหยิบ จุดเริ่มต้นของ Fluvio มาดูอีกครั้ง
    เป็นทีมเล็ก ๆ ที่มีความสัมพันธ์ยาวนานกับแอปพลิเคชันที่เน้นข้อมูลในหลายโดเมนตลอดหลายทศวรรษที่ผ่านมา และกำลังฝากความหวังกับ data streaming ที่ใช้ Rust และ WebAssembly แทน Java และ JVM
    บทความที่ CTO สรุปวิสัยทัศน์ของ Fluvio เมื่อเดือนมิถุนายน 2021 อยู่ที่นี่: https://news.ycombinator.com/item?id=38880743
    เห็นมีคำถามเรื่องการเปรียบเทียบออกมาเรื่อย ๆ จึงแชร์ข้อมูลที่ฝั่ง Fluvio มีได้ เป็นงานเอกสารยาว แต่สิ่งที่มีตอนนี้ก็แบ่งปันได้ Iggy ก็เป็นผลงานที่ทำได้ดีมากจริง ๆ
  • เป็นไอเดียและโปรเจกต์ที่เจ๋งมาก
    แต่ก่อนจะลองใช้ คิดว่าต้องเข้าใจสองเรื่องก่อน: จะรัน อินสแตนซ์เซิร์ฟเวอร์ มากกว่าหนึ่งตัวได้อย่างไร และเมื่อรันมากกว่าหนึ่งตัว การโต้ตอบของไฟล์ซิสเต็มระหว่างเซิร์ฟเวอร์เป็นอย่างไร
    • ในบทความบล็อกระบุว่ารันแบบ โหนดเดียว ตอนนี้ยังไม่รองรับคลัสเตอร์
      ถ้ารองรับคลัสเตอร์เมื่อไร ก็น่าจะแข่งขันกับ Kafka ได้
  • แปลกใจที่เลือก monoio
    เท่าที่รู้ต้องใช้คอมไพเลอร์ nightly ซึ่งผมมองว่าไม่ใช่ตัวเลือกที่ดีสำหรับการดูแลโปรเจกต์
    • ต้องใช้ nightly จริง แต่ใช้ฟีเจอร์แค่ห้าอย่าง และหนึ่งในนั้นสามารถตัดออกได้ถ้าเพิ่ม crate ภายนอก
      ที่เหลือส่วนใหญ่ก็ไม่ใช่ฟีเจอร์หวือหวารุนแรงอะไร ผมไม่ได้ดูโค้ดลึก ๆ แต่ทั้งหมดดูสมเหตุสมผล เช่น อย่างหนึ่งคือ API ของไลบรารีมาตรฐานสำหรับสร้างคอนเทนเนอร์ที่ยังไม่ถูกกำหนดค่าเริ่มต้น ช่วยให้ตัดการคัดลอกออกได้
      ยังไม่ได้ลองเทียบ glommio ซึ่งทำงานบน stable กับ monoio แต่น่าจะน่าสนใจ
    • Monoio ดูเหมือนเป็น runtime ที่ประสิทธิภาพดีที่สุด และใช้งานจริงก็ง่าย
      เลยเลือกแนวทาง bleeding edge อยู่แล้วกว่าจะใช้งาน io_uring และการปรับแต่งอื่น ๆ ได้ก็คงต้องใช้เวลาอีกหลายเดือน และมีความเป็นไปได้สูงว่าจะย้ายไปใช้โครงสร้างแบบเธรดต่อคอร์ ระหว่างเขียนส่วนสำคัญบางส่วนใหม่