Kakao Öneri Ekibinin Rust Benimsemesi

Kakao öneri ekibi, mevcut makine öğrenimi platformunun yerini alacak yeni bir platform geliştiriyor.

Ekibin ana dili olan Python ile uygulamanın hem performansını hem de güvenliğini aynı anda sağlamak bazı açılardan zordu.

Kullanıcı metrikleri uygulamasına Rust eklenerek, uygulamayı Rust ile geliştirmenin uygun olup olmadığını doğrulama süreci yürütüldü.

• Rust, işleri Python'dan yaklaşık 1,9 kat daha hızlı işledi
• Bellek kullanımı açısından Python, Rust'tan yaklaşık 4,5 kat daha fazla kullandı
• Python'un CPU kullanımı Rust'a göre en fazla 3 kat, ortalamada ise yaklaşık 2 kat daha yüksekti
• Python'un asyncio'su ve Rust'ın tokio'su her iki dildeki uygulamalara uygulanmıştı; bu nedenle asenkron işleme aynı şekilde uygulanmış tek iş parçacıklı ortamda bile, Rust'ın mesaj işleme hızı Python'dan yaklaşık 10 kat daha hızlıydı.

Rust'ın en büyük dezavantajlarından biri, öğrenme maliyetinin yüksek olmasıydı.

Python ile geliştirirken de tip anotasyonları zorunlu tutuluyordu. Kullanıcı metrikleri uygulaması iki farklı sürümle geliştirilirken, Python ve Rust arasındaki geliştirme süresi farkı çok büyük hissedilmedi.

Verimlilik açısından en belirgin fark derleme süresiydi. (paket indirme ve Docker süresi dahil)

• Rust yaklaşık 340 saniye
• Python ise yaklaşık 100 saniye

Python kullanılırken, tip bilgisi olmayan kütüphanelerde üretilen veriler tip denetiminin yok sayıldığı Any tipine sahip oluyor. Bu da tüm projenin tip denetimi doğruluğunu düşürüyor.

Python istisnalar kullanırken Rust'ın Result adlı bir enum tipi kullanması gibi farklılıklar da vardı.

Geliştirme araçları
Rust tarafında cargo'nun varsayılan olarak sunduğu birçok özellik bulunuyor.
Python geliştirme araçları ise olgunlaşmış durumda ve kurulumdan sonra kullanımı görece kolaydı.

[jongpak]

Python ve Rust konusunda deneyimim yok ama sadece yazıya bakınca, Rust’a geçişin büyük bir avantajını hissedemiyorum.

Rust’ın kötü olduğunu söylemiyorum; ancak Rust’ı benimsemek için yapılan deneyler de zayıf görünüyor
(sadece 50 mesajın işlenme sonucuna bakıp birkaç kat daha hızlıysa birkaç kat daha iyidir diye iddia etmek bana fazla zayıf bir kurgu gibi geliyor..)

Ayrıca karşılaştırma da aynı işleme mantığıyla yapılmamış (senkron vs asenkron değil)..
[Asenkron mesaj işlemeyi destekliyor ama çok fazla referansı olmayan bir Python kütüphanesi] vs [öğrenme maliyeti yüksek ve az sayıda kişinin bakım yapması nedeniyle sürdürülebilirlik riski taşıyan Rust dili]
Bu iki duruma bakınca, gelecekteki sürdürülebilirlik kısmı üzerine gerçekten ciddi şekilde düşünülüp düşünülmediği de bana soru işareti gibi geliyor (en azından yazıdan aldığım izlenim buydu)

ETL’in doğası gereği kısa aralıklarla sık sık test yapmak gereken durumlar çok olur gibi geliyor; bu yüzden build time 100 saniye vs 300 saniye geliştirme açısından büyük bir darboğaz olabilir diye düşünüyorum..
Yazıda artımlı derlemenin çok iyi olduğundan bahsediliyor ama bunun açıklaması bir hiperlink ile geçiştirilmiş...

Gerçekte muhtemelen ciddi biçimde araştırıp değerlendirmişlerdir; ama en azından yazıdan hissettirdiği kadarıyla.. Rust’a geçince tam olarak neyin iyileştiğini, beklenen etkinin ne olduğunu ve hangi sorunu çözdüğünü ne anlayabiliyorum ne de buna kolayca katılabiliyorum..

---

Kişisel olarak, teknolojinin bazen “son dönemin popüler konusu” ya da kariyer satırına eklenecek bir madde uğruna seçildiğini çok gördüm; sonuçta da ekip içinde bakımı yapılamayan ve teknik borç olarak kalan örnekler çoğunluktaydı.

• Örneğin, iş yükü küçük ve sıralı işleme yapsanız da hiçbir sorun olmayacakken ille de Kafka ya da asenkron işleme gerektiğini savunan durumlar
• (Ekip içi koşullar dikkate alınmadan) asenkron işlemenin iyi olduğu söylenip uygulandıktan sonra, troubleshooting aşırı zorlaşıyor ve sonuçta başka bir legacy’ye dönüşüyor....
• Son zamanlarda popüler olan ooo’yu getirirsek şunun iyi olacağı söyleniyor.. ama sonra başka popüler bir ooo çıkınca bu kez onun daha iyi olduğu savunuluyor..

Elbette yukarıdaki Rust yazısının böyle olduğunu söylemiyorum ve öyle olmamasını umuyorum..
Ama yeterince ciddi düşünmeden benimsenen teknolojilerin yükünü ekip arkadaşlarının çektiğini defalarca gördükten sonra, böyle teknoloji tanıtım yazılarını okurken daha temkinli olmaya başladığımı düşünüyorum.

[ehlegeth]

Temelde ETL görevi gibi görünüyor; bu alanda Python’la birlikte güçlü yanları olan Java’yı hiç değerlendirmediniz mi, Rust karşısında onu dışarıda bırakmanızın bir nedeni varsa bilmek isterim.

[kayws426]

Bazı performans karşılaştırma verilerinin küçük ölçekli testlerle elde edilmiş olması, insanda biraz eksiklik hissi bırakıyor.

[ehlegeth]

Performans testlerinin anlamı, iş yükünün niteliğine göre büyük ölçüde değişiyor; ancak test tasarımına ya da sayıların nasıl elde edildiğine dair bir açıklama olmadığı için bu biraz eksik kalmış.
Örneğin 5 milyon kaydı işledikten sonra 50 kayıt işleme üzerinden aritmetik ortalama mı alındı, öyleyse bellek kullanımı nasıl hesaplandı, CPU kullanımındaki fark nasıl ölçüldü gibi noktaları merak ediyorum. (Süre muhtemelen wall-clock time'dır, değil mi?)
Ayrıca, "CPU kullanımına bakıldığında iki dil arasındaki performans farkının büyük kısmının girdi/çıktı (Input Output, bundan sonra IO) işleri olan Kafka mesaj tüketimi ve Mongo DB doküman kaydetme işlemlerinden kaynaklandığı" şeklinde bir yorum var; ama sonuçlarda wall-clock time'ın Rust'ta yaklaşık 1/2, CPU kullanımının (CPU time?) ise 1/4,5 olduğu söylenmiş. Burada kastedilen şey I/O ile ilgili uygulama yöntemlerindeki fark mı, yoksa CPU-intensive I/O hedef verisini işleme sürecindeki fark mı, mantığı tam olarak anlayamadığım bir nokta var. Aslında Rust'ın CPU-intensive görevlerde avantaj sağladığı zaten iyi biliniyor; dolayısıyla kastedilen ikincisiyse, açıkçası kütüphane farkından söz etmeye de pek gerek yok gibi. Hatta deneyde eğer mesele CPU-intensive bir iş olsaydı, yazıda da değinilen asyncio/tokio uygulama karşılaştırmasında olduğu gibi çok daha büyük bir fark ortaya çıkması gerekirdi; bu durumda performans farkının I/O yüzünden daha az çıktığı şeklinde yorumlamak gerekmez miydi diye düşünüyorum.