Kakao की recommendation टीम में Rust अपनाना

Kakao की recommendation टीम मौजूदा machine learning platform को बदलने के लिए एक नया platform विकसित कर रही है.

टीम की मुख्य भाषा Python होने के कारण application की performance और safety दोनों को साथ में संभालना थोड़ा मुश्किल था.

user metrics application में Rust को अपनाकर यह सत्यापित करने की प्रक्रिया चलाई गई कि Rust में application implement करना उपयुक्त है या नहीं.

• Rust ने Python की तुलना में काम लगभग 1.9 गुना तेजी से प्रोसेस किया
• memory usage में Python ने Rust की तुलना में लगभग 4.5 गुना अधिक उपयोग किया
• Python का CPU usage Rust की तुलना में अधिकतम 3 गुना, औसतन 2 गुना अधिक था
• Python के asyncio और Rust के tokio को प्रत्येक भाषा के application में लागू किया गया, और asynchronous processing को समान रूप से लागू किए गए single-thread environment में भी Rust की message processing speed Python से लगभग 10 गुना तेज थी.

Rust की सबसे बड़ी कमियों में से एक इसका learning cost अधिक होना था.

Python में development करते समय भी type annotation को अनिवार्य किया गया. user metrics application के दो versions लागू करते हुए Python और Rust के बीच development time में बहुत बड़ा अंतर महसूस नहीं हुआ.

productivity के दृष्टिकोण से सबसे बड़ा महसूस होने वाला अंतर compile time था. (package download Docker time सहित)

• Rust लगभग 340 सेकंड
• Python के मामले में लगभग 100 सेकंड

Python का उपयोग करते समय type information के बिना libraries से बने data का type Any हो जाता है, जिससे type checking अनदेखी हो जाती है. इससे पूरे project की type checking accuracy कम हो जाती है.

Python में exceptions का उपयोग होता है, जबकि Rust में Result नामक enum type का उपयोग होता है — ऐसा अंतर भी था.

development tools
Rust के मामले में cargo कई सुविधाएँ मूल रूप से प्रदान करता है.
Python development tools काफ़ी advanced थे, इसलिए install करने के बाद उनका उपयोग तुलनात्मक रूप से आसान था.

[jongpak]

मुझे Python और Rust — दोनों का अनुभव नहीं है, लेकिन सिर्फ़ इस लेख को देखकर... Rust अपनाने के कोई बड़े फ़ायदे मुझे महसूस नहीं होते।

मेरा मतलब यह नहीं है कि Rust खराब है, बल्कि Rust अपनाने के लिए जो प्रयोग किए गए, वे भी काफ़ी कमज़ोर लगते हैं।
(सिर्फ़ 50 messages प्रोसेस करने के नतीजों को देखकर, कुछ गुना तेज़ है इसलिए कुछ गुना बेहतर है — ऐसा दावा करना बहुत कमज़ोर तर्क लगता है..)

और तुलना भी एक ही processing logic (synchronous vs asynchronous) पर नहीं की गई है..
[ऐसी Python library जो asynchronous message processing को support करती है लेकिन जिसके references बहुत कम हैं] vs [ऐसी Rust language जिसका learning cost ऊँचा है और जिसे कुछ ही लोग maintain करेंगे, इसलिए maintenance risk है]
इन दो स्थितियों को सामने रखकर देखें, तो यह भी सवाल उठता है कि क्या आगे की sustainability पर गंभीरता से विचार किया गया था या नहीं (कम-से-कम लेख पढ़कर तो मुझे ऐसा ही लगा)।

ETL की प्रकृति ही ऐसी होती है कि अक्सर छोटे-छोटे और बार-बार tests करने पड़ते हैं, तो build time 100 सेकंड vs 300 सेकंड development में बड़ा bottleneck लग सकता है।
लेख में कहा गया है कि incremental build बहुत अच्छा है, लेकिन इस पर असल विवरण देने के बजाय hyperlink दे दिया गया है...

असल में उन्होंने काफ़ी मेहनत से जाँच-पड़ताल और review किया होगा, लेकिन कम-से-कम लेख से जो महसूस होता है... उससे यह समझना मुश्किल है कि Rust अपनाने से वास्तव में क्या बेहतर हुआ, अपेक्षित प्रभाव क्या था, और इससे कौन-सी समस्या हल हुई। इसलिए इससे सहमत होना भी कठिन है।

---

व्यक्तिगत रूप से, मैंने कई बार देखा है कि लोग 'आजकल की hot technology' या फिर career में एक लाइन जोड़ने के लिए technology चुनते हैं, लेकिन नतीजा यह होता है कि टीम उसे maintain भी नहीं कर पाती और वह technical debt बनकर रह जाती है।

• जैसे, workload छोटा है और sequential processing से भी बिल्कुल कोई समस्या नहीं है, फिर भी Kafka या asynchronous processing ज़रूरी है — ऐसा ज़ोर देकर कहा जाता है
• (टीम की वास्तविक स्थिति पर विचार किए बिना) asynchronous processing के फायदे सुनकर उसे लागू कर दिया, लेकिन बाद में troubleshooting बहुत कठिन हो गई और अंततः वह एक और legacy बन गई....
• अभी जो ooo hot है, उसे अपनाने से क्या-क्या फ़ायदे होंगे — ऐसा कहा गया, लेकिन कुछ समय बाद कोई और hot ooo आ गया तो फिर उसी को बेहतर बताने लगे..

बेशक, मेरा यह मतलब नहीं है कि Rust पर वह लेख भी वैसा ही है, और मैं उम्मीद करता हूँ कि ऐसा न हो..
लेकिन बिना गंभीरता से सोचे-समझे अपनाई गई technology का नुकसान आख़िरकार टीम के लोगों को ही झेलना पड़ता है — यह बात मैंने कई बार देखी है, इसलिए ऐसे technology promotion वाले लेख पढ़ते समय मैं अब और ज़्यादा सतर्क हो जाता हूँ।

[ehlegeth]

मूल रूप से यह ETL task जैसा दिखता है, तो क्या इस डोमेन में Python के साथ अपनी मजबूतियों वाला Java आपने consider नहीं किया? Rust की तुलना में उसे बाहर रखने की कोई वजह थी, तो वह जानना चाहूंगा।

[kayws426]

कुछ performance comparison डेटा छोटे पैमाने के टेस्ट से प्राप्त किया गया था, इसलिए थोड़ी कमी महसूस होती है।

[ehlegeth]

परफ़ॉर्मेंस टेस्ट का मतलब workload की प्रकृति के अनुसार बहुत बदल जाता है, लेकिन यह थोड़ा अफ़सोसजनक है कि टेस्ट डिज़ाइन या आँकड़े कैसे प्राप्त किए गए, इस बारे में कोई विवरण नहीं है.
उदाहरण के लिए, 50 लाख मामलों को प्रोसेस करने के बाद क्या 50 मामलों के आधार पर arithmetic mean आदि निकाला गया था? अगर ऐसा था, तो memory usage कैसे मापा गया, और CPU usage का अंतर कैसे मापा गया, यह जानने की जिज्ञासा है. (समय शायद wall-clock time होगा?)
इसके अलावा, एक व्याख्या दी गई है कि 'CPU usage को देखने पर, दोनों भाषाओं के बीच performance difference का अधिकांश हिस्सा I/O कार्यों, यानी Kafka message consumption और MongoDB document storage, से आया.' लेकिन परिणाम में कहा गया कि wall-clock time में Rust लगभग 1/2 था, और CPU usage (CPU time?) 1/4.5 था. इसलिए यह थोड़ा स्पष्ट नहीं है कि बात I/O के implementation तरीके के अंतर की है, या फिर CPU-intensive I/O target data को संभालने की प्रक्रिया के अंतर की. दरअसल CPU-intensive task में Rust के फ़ायदे अच्छी तरह ज्ञात हैं, इसलिए अगर दूसरा मामला है तो शायद library के अंतर का अलग से उल्लेख करने की ज़रूरत भी नहीं लगती. बल्कि अगर प्रयोग सचमुच CPU-intensive काम पर था, तो जैसा लेख में asyncio/tokio implementation comparison का ज़िक्र है, उससे कहीं बड़ा अंतर दिखना चाहिए था; इसलिए क्या यह नहीं समझना चाहिए कि I/O की वजह से performance difference कम दिखाई दिया?