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

ที่มา

• ในเดือนเมษายน 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 ทำให้เป็นโปรเจกต์ที่มีประโยชน์มากสำหรับผู้ที่สนใจด้านนี้

[GN⁺]

ความคิดเห็นจาก Hacker News

• สิ่งที่ทำให้เริ่มสนใจวงการซอฟต์แวร์ในตอนแรกไม่ใช่เรื่องเงิน แต่เป็นอุดมคติของผู้คนที่พยายามร่วมกันเพื่อเป้าหมายเดียวกัน ขอให้โปรเจกต์นี้โชคดี และหวังว่าการเปรียบเทียบกับทางเลือกอื่น ๆ จะช่วยให้เข้าใจตำแหน่งของโปรเจกต์ได้ดียิ่งขึ้น
• ชอบบล็อกโพสต์นี้ และผู้เขียนดูเป็นผู้นำโปรเจกต์ที่ถ่อมตัว ซื่อสัตย์ และสร้างสรรค์ ขอให้โปรเจกต์โชคดี
• ดูเหมือนเป็นผลิตภัณฑ์ที่แข่งขันโดยตรงกับ JetStream และถือว่าก้าวหน้าได้อย่างน่าประทับใจสำหรับงานที่ทำมาไม่ถึง 1 ปี
• เป็นโพสต์ที่ทำให้นึกถึงจุดเริ่มต้นของ Fluvio อีกครั้ง ทีมเล็ก ๆ ที่มีความสัมพันธ์อันยาวนานกับแอปพลิเคชันที่ขับเคลื่อนด้วยข้อมูลในหลากหลายสาขามาหลายทศวรรษ กำลังตื่นเต้นกับ data streaming ที่ใช้ Rust และ WebAssembly
• ยังไม่ชัดเจนว่าแตกต่างจาก Kafka และ Fluvio (คู่แข่งของ Kafka ที่เขียนด้วย Rust อีกราย) อย่างไร แต่อาจเป็น message queue แบบ RabbitMQ ก็ได้
• เมื่อไม่กี่ปีก่อนเคยทำอะไรคล้าย ๆ กันกับเพื่อนโดยใช้ Go
• หลังจากเรียน Rust แล้วก็อยากลองทำดู และชอบความสวยงามของเว็บไซต์นี้
• โปรเจกต์นี้น่าสนใจ แต่ก่อนจะลองใช้งานอยากเข้าใจก่อนว่าจะรัน server instance หลายตัวอย่างไร และการทำงานร่วมกันของ file system ระหว่างเซิร์ฟเวอร์ทำงานอย่างไร
• เมื่อเทียบกับระบบสตรีมมิงของ KeyDB ข้อดีที่นึกออกคือ persistence ที่แข็งแกร่งกว่า
• แปลกใจกับการเลือกใช้ monoio เพราะต้องใช้ nightly compiler และคิดว่าไม่ใช่ทางเลือกที่ดีต่อการดูแลรักษาโปรเจกต์ในระยะยาว