ทีมแนะนำของ Kakao นำ Rust มาใช้

ทีมแนะนำของ Kakao กำลังพัฒนาแพลตฟอร์มใหม่เพื่อทดแทนแพลตฟอร์มแมชชีนเลิร์นนิงเดิม

มีบางส่วนที่ค่อนข้างยากที่จะดูแลทั้งประสิทธิภาพและความปลอดภัยของแอปพลิเคชันไปพร้อมกันด้วย Python ซึ่งเป็นภาษาหลักของทีม

ทีมจึงนำ Rust มาใช้กับแอปพลิเคชันตัวชี้วัดผู้ใช้ และดำเนินกระบวนการตรวจสอบว่าเหมาะสมหรือไม่ที่จะพัฒนาแอปพลิเคชันด้วย Rust

• Rust ประมวลผลงานได้เร็วกว่า Python ราว 1.9 เท่า
• การใช้หน่วยความจำ Python ใช้มากกว่า Rust ราว 4.5 เท่า
• การใช้ CPU ของ Python สูงกว่า Rust สูงสุด 3 เท่า และโดยเฉลี่ยราว 2 เท่า
• มีการใช้ asyncio ของ Python และ tokio ของ Rust กับแอปพลิเคชันของแต่ละภาษา ทำให้แม้ในสภาพแวดล้อมเธรดเดียวที่มีการทำงานแบบอะซิงโครนัสเหมือนกัน ความเร็วในการประมวลผลข้อความของ Rust ก็ยังเร็วกว่าของ Python ราว 10 เท่า

หนึ่งในข้อเสียใหญ่ของ Rust คือมีต้นทุนการเรียนรู้สูง

แม้ตอนพัฒนาด้วย Python ทีมก็มีการบังคับใช้ type annotation อยู่แล้ว เมื่อพัฒนาแอปพลิเคชันตัวชี้วัดผู้ใช้ทั้งสองเวอร์ชัน จึงไม่ได้รู้สึกถึงความแตกต่างของเวลาในการพัฒนาระหว่าง Python กับ Rust มากนัก

ความแตกต่างที่รู้สึกได้ชัดที่สุดในด้านผลิตภาพคือเวลาในการคอมไพล์ (รวมเวลาของ Docker สำหรับดาวน์โหลดแพ็กเกจ)

• Rust อยู่ที่ประมาณ 340 วินาที
• ส่วน Python อยู่ที่ประมาณ 100 วินาที

เมื่อใช้ Python ข้อมูลที่สร้างจากไลบรารีซึ่งไม่มีข้อมูลชนิดข้อมูลจะมีชนิด Any ที่ระบบตรวจสอบชนิดข้อมูลจะมองข้ามไป ส่งผลให้ความแม่นยำของการตรวจสอบชนิดข้อมูลทั้งโปรเจ็กต์ลดลง

ยังมีความแตกต่างอย่างการที่ Python ใช้ exception ขณะที่ Rust ใช้ enum ชื่อ Result

เครื่องมือพัฒนา
ในกรณีของ Rust, cargo มีฟังก์ชันที่ให้มาเป็นพื้นฐานอยู่มาก
ส่วนเครื่องมือพัฒนาของ Python มีความพัฒนาไปมาก และเพียงติดตั้งก็ใช้งานได้ค่อนข้างง่าย

[jongpak]

แม้ว่าจะไม่มีประสบการณ์ทั้งกับ Python และ Rust แต่ถ้าดูจากบทความอย่างเดียว.. ผมยังไม่รู้สึกถึงข้อดีที่ชัดเจนมากของการนำ Rust มาใช้เลยครับ

ไม่ได้บอกว่า Rust ไม่ดีนะ แต่การทดลองที่ทำเพื่อรองรับการนำ Rust มาใช้ก็ดูอ่อนเกินไป
(ถ้าดูแค่ผลการประมวลผลข้อความเพียง 50 รายการ แล้วบอกว่าเร็วกว่าอีกหลายเท่าเลยดีกว่าอีกหลายเท่า ก็เหมือนเป็นการสรุปที่เบาบางเกินไป..)

อีกอย่างก็ไม่ได้เปรียบเทียบด้วยตรรกะการประมวลผลแบบเดียวกันด้วยครับ (synchronous vs asynchronous)
[ไลบรารี Python ที่รองรับการประมวลผลข้อความแบบ asynchronous แต่มี reference ไม่มาก] vs [ภาษา Rust ที่มีต้นทุนการเรียนรู้สูงและมีความเสี่ยงด้านการบำรุงรักษาจากการพึ่งพาคนจำนวนน้อย]
เมื่อดูจากสองสถานการณ์นี้ ก็ยังสงสัยว่ามีการพิจารณาเรื่องความยั่งยืนในระยะยาวอย่างจริงจังหรือไม่ (อย่างน้อยจากที่อ่านในบทความก็ให้ความรู้สึกแบบนั้น)

ด้วยลักษณะของ ETL น่าจะมีหลายกรณีที่ต้องทดสอบสั้น ๆ แต่บ่อยครั้ง ดังนั้น build time 100 วินาที vs 300 วินาที ก็ดูเหมือนจะเป็นคอขวดใหญ่ในการพัฒนาเหมือนกันนะครับ..
ในบทความมีพูดถึงว่า incremental build ทำได้ดี แต่รายละเอียดกลับแทนที่ด้วยไฮเปอร์ลิงก์...

ในความเป็นจริงคงมีการค้นคว้าและพิจารณามาอย่างหนักแหละครับ แต่เท่าที่บทความสื่อออกมา.. มันยังไม่ชัดเลยว่าการนำ Rust มาใช้ทำให้ดีขึ้นตรงไหน ผลที่คาดหวังคืออะไร และมันแก้ปัญหาอะไรได้บ้าง เลยทั้งเข้าใจยากและเห็นด้วยได้ยากครับ..

---

โดยส่วนตัว ผมเคยเห็นหลายกรณีที่เลือกเทคโนโลยีเพราะเป็น 'เทคโนโลยีกำลังฮิต' หรือเพื่อเพิ่มบรรทัดหนึ่งในโปรไฟล์อาชีพ แต่สุดท้ายส่วนใหญ่มักดูแลรักษาต่อในทีมไม่ได้และกลายเป็นหนี้ทางเทคนิค

• เช่น ทั้งที่ workload เล็กและประมวลผลแบบลำดับก็ไม่ได้มีปัญหาอะไรเลยแม้แต่น้อย แต่ก็ยังยืนยันว่าต้องใช้ Kafka หรือทำ asynchronous processing
• หรือ (โดยไม่คำนึงถึงสถานการณ์ในทีม) พอได้ยินว่า asynchronous processing ดี ก็เอามาใช้ ผลคือ troubleshooting ยากมาก และสุดท้ายก็กลายเป็น legacy อีกก้อนหนึ่ง....
• หรือบอกว่าถ้านำ ooo ที่กำลังฮิตมาใช้จะดีอย่างนั้นอย่างนี้.. แต่พอมี ooo ตัวใหม่ที่ฮิตกว่าออกมา ก็หันไปบอกว่าอันนั้นดีกว่าอีก..

แน่นอนว่าผมไม่ได้บอกว่าบทความเรื่อง Rust ข้างต้นเป็นแบบนั้น และก็หวังว่าจะไม่เป็นแบบนั้น..
แต่พอเจอมาหลายครั้งว่าคนที่ต้องรับผลกระทบจากเทคโนโลยีที่นำมาใช้โดยไม่ได้คิดอย่างจริงจังคือเพื่อนร่วมทีม เวลาผมอ่านบทความแนวโปรโมตเทคโนโลยีแบบนี้ก็เลยยิ่งระมัดระวังมากขึ้นครับ

[ehlegeth]

โดยพื้นฐานแล้วมันดูเหมือนงาน ETL task แต่ผมสงสัยว่าในโดเมนนี้ได้พิจารณา Java ซึ่งมีจุดแข็งเมื่อใช้ร่วมกับ Python หรือไม่ และถ้ามีเหตุผลที่ตัดตัวเลือกนี้ออกไปเมื่อเทียบกับ rust ก็อยากทราบครับ

[kayws426]

น่าเสียดายที่ข้อมูลเปรียบเทียบประสิทธิภาพบางส่วนได้มาจากการทดสอบขนาดเล็ก

[ehlegeth]

ความหมายของการทดสอบประสิทธิภาพจะแตกต่างกันมากตามลักษณะของเวิร์กโหลด จึงน่าเสียดายที่ไม่มีคำอธิบายอย่างการออกแบบการทดสอบหรือวิธีที่ได้ค่าตัวเลขเหล่านั้นมา
ยกตัวอย่างเช่น หลังจากประมวลผล 5 ล้านรายการแล้ว ได้นำการประมวลผล 50 รายการมาเป็นเกณฑ์แล้วคำนวณค่าเฉลี่ยเลขคณิตหรือไม่ ถ้าเป็นเช่นนั้น วัดการใช้หน่วยความจำอย่างไร และวัดความแตกต่างของการใช้ CPU อย่างไรบ้าง ก็น่าสงสัยครับ (เวลาอาจจะเป็น wall-clock time ใช่ไหม?)
นอกจากนี้ ยังมีการตีความว่า 'เมื่อดูการใช้ CPU แล้ว ความแตกต่างด้านประสิทธิภาพส่วนใหญ่ของสองภาษามาจากงานรับส่งข้อมูล (Input Output; ต่อไปจะเรียกว่า IO) ได้แก่ งาน consume ข้อความจาก Kafka และงานบันทึกเอกสารลง MongoDB' แต่ในผลลัพธ์ระบุว่า wall-clock time ของ Rust อยู่ที่ประมาณ 1/2 และการใช้ CPU (CPU time?) อยู่ที่ 1/4.5 จึงมีจุดที่ผมยังไม่ค่อยเข้าใจตรรกะนัก ว่ากำลังหมายถึงความแตกต่างของวิธี implement ที่เกี่ยวกับ I/O หรือหมายถึงความแตกต่างในกระบวนการจัดการข้อมูลปลายทางของ I/O ที่เป็นงานแบบ CPU-intensive กันแน่ จริง ๆ แล้วข้อได้เปรียบของ Rust สำหรับงานที่ CPU-intensive เป็นสิ่งที่รู้กันดีอยู่แล้ว ดังนั้นถ้าเป็นอย่างหลัง ก็ดูเหมือนไม่จำเป็นต้องกล่าวถึงความแตกต่างของไลบรารีเลยเสียด้วยซ้ำ กลับกัน ถ้าในการทดลองเป็นงานที่ CPU-intensive จริง ก็น่าจะต้องเกิดความแตกต่างที่มากกว่านี้เหมือนการเปรียบเทียบ implementation ของ asyncio/tokio ที่กล่าวถึงในบทความเสียอีก ดังนั้นน่าจะตีความว่าเพราะมี I/O อยู่ด้วย ความแตกต่างด้านประสิทธิภาพจึงออกมาน้อยลง ไม่ใช่หรือครับ